Forwarded from Максим Цепков (Maxim Tsepkov)
#Teamlead Игорь Гранщиков из Авито. Система управления с обратной связью. Тимлид вырастает и начинает руководить не командой, а другими тимлидами. И тут старая система управления перестает работать, надо строить новую, о которой был доклад. Система состоит из двух элементов: целеполагание и операционное ревью, на котором оценивается текущее состояние команд. При этом у руководителя - светофорная модель из метрик, и если на ней горит красный сигнал, то разобраться в деталях - задача тимлида. В этом смысле, получается, что руководитель второго уровня внутри квартала не нужен - за светофорами может наблюдать и автомат. Ну или у него получается почти бесконечное масштабирование по числу команд. Какая-то тут есть засада.
Возвращаясь к докладу. Целеполагание. Три группы целей:
* Продукт - ценность, поставляемая в продакшн
* Процессы - метрики их функционирования, например, cycle time
* Люди: счастье, найм.
Цели - фиксируем ожидания. Операционное ревью: есть цели и факт. И если есть невыполнение или риск невыполнения - должен сработать триггер и дать корректировку действий.
Были рассмотрены 5 задач.
1. Контролировать результативность и эффективность
2. Настраивать процессы чужими командами
3. Запускать команды чужими руками
4. Контролировать перформанс-менеджмент
5. Развивать старших инженеров.
Теперь о них по порядку.
1. Контролировать результативность и эффективность. Результативность - делать правильные вещи, эффективность - делать их правильно (быстро, качественно). Это - разное, следить надо за обоими.
Burndown. Результативность - поставка того, что выпускает. План-факт. А скорость - эффективность, производная от скорости. Одна из метрик - cycle time.
Если цель - запустить ипотечную анкету на мобильных платформах. Отставание 10 дней, один из эпиков заблокирован смежниками. Метод изменений: в начале квартала сверять планы свои со смежниками. Цель по cycle time может быть не достигнута по той же причине.
Тимлид докапывается до причин, а руководитель тимлидов смотрит на светофор. Есть еще несоклько метрик индексов: support ticket sla reaction, zero bug policy, crashes, LSR SLA
2. Настраиваем процессы чужими руками. Досталось легаси плохого качества, много пользователей обращались в поддержку. Обращения матчатся с багами, для каждого известно. Цель: привести HD count к целевому значению. И количество решенных тикетов от суппорта 10+. Дальше мониторили - и получилось успешно за пару кварталов. Потом вывели на мониторинг.
3. Запускать команды чужими руками. При запуске команды есть общее: процессы и практики соответствуют стандарту. Agile periodic table - чек лист. Начал печатать, класть на стол и помечать. Но не масштабируется.
В Авито есть модель зрелости Team maturity model. Опрос по соответствию. И дальше по каждому пункту светофорная модель. Тимлид видит детали у себя, а руководитель - сводку по командам и динамику. И раз есть метрика - мы можем ставить цели по движению по по модели.
4. Контролировать performance management. Тимлиды затягивают обратную связь сотрудникам. Особенно начинающие. И начал включать в операционное ревью мини-оценку сотрудника. При этом требовалось каждого оценить, обязательно хорошо-плохо. Бинарно, нормально объединено с хорошо, и это - сознательно. Потому что у начинающего тимлида нормально - это плохо, по которому он не хочет выдавать обратную связь. Если плохо - то причины и action plan. Это побуждает тимлида давать обратную связь.
5. Развивать старших инженеров. Стандартные планы не работают, нужны нестандартные challenge. Например challenge: реализовать платформу календарей и применить для разных платформ. Или повысить SLA.
Как часто? Есть быстродействие, регулирование и точность. Слишком часто - задергаем команду, слишком редко - не будем реагировать. Целеполагание - как целеполагание в организации, у них раз в квартал. А операционное ревью 10% - 1-2 недели (9 дней формально). На последней период операционного ревью есть выполнение целей. И мы можем воспользоваться для обратной связи. Но! Это не должно становиться KPI, это должно быть поддерживающей штукой.
Возвращаясь к докладу. Целеполагание. Три группы целей:
* Продукт - ценность, поставляемая в продакшн
* Процессы - метрики их функционирования, например, cycle time
* Люди: счастье, найм.
Цели - фиксируем ожидания. Операционное ревью: есть цели и факт. И если есть невыполнение или риск невыполнения - должен сработать триггер и дать корректировку действий.
Были рассмотрены 5 задач.
1. Контролировать результативность и эффективность
2. Настраивать процессы чужими командами
3. Запускать команды чужими руками
4. Контролировать перформанс-менеджмент
5. Развивать старших инженеров.
Теперь о них по порядку.
1. Контролировать результативность и эффективность. Результативность - делать правильные вещи, эффективность - делать их правильно (быстро, качественно). Это - разное, следить надо за обоими.
Burndown. Результативность - поставка того, что выпускает. План-факт. А скорость - эффективность, производная от скорости. Одна из метрик - cycle time.
Если цель - запустить ипотечную анкету на мобильных платформах. Отставание 10 дней, один из эпиков заблокирован смежниками. Метод изменений: в начале квартала сверять планы свои со смежниками. Цель по cycle time может быть не достигнута по той же причине.
Тимлид докапывается до причин, а руководитель тимлидов смотрит на светофор. Есть еще несоклько метрик индексов: support ticket sla reaction, zero bug policy, crashes, LSR SLA
2. Настраиваем процессы чужими руками. Досталось легаси плохого качества, много пользователей обращались в поддержку. Обращения матчатся с багами, для каждого известно. Цель: привести HD count к целевому значению. И количество решенных тикетов от суппорта 10+. Дальше мониторили - и получилось успешно за пару кварталов. Потом вывели на мониторинг.
3. Запускать команды чужими руками. При запуске команды есть общее: процессы и практики соответствуют стандарту. Agile periodic table - чек лист. Начал печатать, класть на стол и помечать. Но не масштабируется.
В Авито есть модель зрелости Team maturity model. Опрос по соответствию. И дальше по каждому пункту светофорная модель. Тимлид видит детали у себя, а руководитель - сводку по командам и динамику. И раз есть метрика - мы можем ставить цели по движению по по модели.
4. Контролировать performance management. Тимлиды затягивают обратную связь сотрудникам. Особенно начинающие. И начал включать в операционное ревью мини-оценку сотрудника. При этом требовалось каждого оценить, обязательно хорошо-плохо. Бинарно, нормально объединено с хорошо, и это - сознательно. Потому что у начинающего тимлида нормально - это плохо, по которому он не хочет выдавать обратную связь. Если плохо - то причины и action plan. Это побуждает тимлида давать обратную связь.
5. Развивать старших инженеров. Стандартные планы не работают, нужны нестандартные challenge. Например challenge: реализовать платформу календарей и применить для разных платформ. Или повысить SLA.
Как часто? Есть быстродействие, регулирование и точность. Слишком часто - задергаем команду, слишком редко - не будем реагировать. Целеполагание - как целеполагание в организации, у них раз в квартал. А операционное ревью 10% - 1-2 недели (9 дней формально). На последней период операционного ревью есть выполнение целей. И мы можем воспользоваться для обратной связи. Но! Это не должно становиться KPI, это должно быть поддерживающей штукой.
👍2🤔2
Forwarded from Максим Цепков (Maxim Tsepkov)
Итак, построение системы управления
1. Настройте целеполагание
2. Выберите метрики
3. Настройте операционное ревью - формат
4. Поставьте ревью в календари
5. Make policies explicit - чтобы люди знали, что от них ожидают
В вопросах - метрики же могут не корректно показывать. Ответ: надо периодически исследовать детали, для погружения в команду любит замещать руководителя на время отпуска. И это дает дополнительную диагностику.
1. Настройте целеполагание
2. Выберите метрики
3. Настройте операционное ревью - формат
4. Поставьте ревью в календари
5. Make policies explicit - чтобы люди знали, что от них ожидают
В вопросах - метрики же могут не корректно показывать. Ответ: надо периодически исследовать детали, для погружения в команду любит замещать руководителя на время отпуска. И это дает дополнительную диагностику.
❤4
🖐️ Друзья, следующие доклады ждут вас в 12:40
🔹 «00 Зал Башня». Инженерная культура. Что это и почему она важна? Антон Огородников (Mаgnit Tech)
Культура — понятие весьма неоднозначное, и инженерная культура — не исключение. В этом докладе Антон поделится принципами, на которых держится культура в его компании, а также расскажет, что это означает на практике и почему иметь описанную инженерную культуру лучше, чем её не иметь.
🔹 Зал «08 Шатер Голубой». Принципы построения команд, которые работают. Константин Лапин (Nexign)
Доклад — мотиватор/инструкция. Здесь вы вряд ли найдете тайные приемчики управления командами, зато очень подробно и практично будут рассмотрены основные работающие приемы.
🔹 «04 Зал Красный». Как мы не выбрали K8s, остались эффективными и повысили производительность. Кирилл Шваков (Kinescope)
В своем докладе Кирилл рассмотрит возможность эффективной работы без использования Docker и Kubernetes, предоставляя примеры успешной реализации этой концепции. Кроме того, будет проанализировано, как данный инструмент применим к проектам различных типов, включая веб-приложения.
🔹 «03 Зал Синий». Общество любителей диких котов: пользовательская документация как часть внутренней базы знаний. Александр Клименков (Bercut)
Пользовательская документация — отличный способ передать знания о продукте для Пользователей. Однако, если добавить ещё немножко усилий, такая документация может помочь выстроить базу знаний компании и переосмыслить внутренние процессы. Александр буквально «на кошках» покажет, как пройти этот путь.
🔹 «06 Зал Зелёный». Продолжение мастер-класса. Как формулировать проблемы так, чтобы их решения приближали к цели (НЖЯ, ТОС). Александра Брызгалова (bryzgalova.ru)
Хорошо, когда можно послушать доклад. Еще лучше — когда полученные знания можно попробовать применить под руководством опытного тренера, увидеть свои ошибки, исправить их и уверенно пользоваться инструментом, который предлагает Александра.
✋ВАЖНО. Количество мест на мастер-класс от Александры — ограничено
🔹 Зал «07 Шатер Оранжевый». Продолжение мастер-класса. Маркер всевластья, практика визуальных встреч. Александр Зинченко (Яндекс 360)
В случае, если слов недостаточно, чтобы у всех было одинаковое понимание идеи, проблемы, плана, на помощь может прийти визуализация, например — рисование. Александр расскажет и покажет, что рисовать не только полезно, но и гораздо проще, чем может казаться.
🔹 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса. Командные встречи: неизбежное зло или секрет вашей антихрупкости. Дарья Вьюнова (OTUS Онлайн-образование)
Как проводить встречи, чтобы после них было ощущение синхронизации команды, воодушевление от идей и желание двигаться дальше — потренируемся на мастер-классе от Дарьи. В итоге каждый участник заберет план встречи, лайфхаки для поддержки динамики на созвоне и вовлечения сотрудников.
🔹 «00 Зал Башня». Инженерная культура. Что это и почему она важна? Антон Огородников (Mаgnit Tech)
Культура — понятие весьма неоднозначное, и инженерная культура — не исключение. В этом докладе Антон поделится принципами, на которых держится культура в его компании, а также расскажет, что это означает на практике и почему иметь описанную инженерную культуру лучше, чем её не иметь.
🔹 Зал «08 Шатер Голубой». Принципы построения команд, которые работают. Константин Лапин (Nexign)
Доклад — мотиватор/инструкция. Здесь вы вряд ли найдете тайные приемчики управления командами, зато очень подробно и практично будут рассмотрены основные работающие приемы.
🔹 «04 Зал Красный». Как мы не выбрали K8s, остались эффективными и повысили производительность. Кирилл Шваков (Kinescope)
В своем докладе Кирилл рассмотрит возможность эффективной работы без использования Docker и Kubernetes, предоставляя примеры успешной реализации этой концепции. Кроме того, будет проанализировано, как данный инструмент применим к проектам различных типов, включая веб-приложения.
🔹 «03 Зал Синий». Общество любителей диких котов: пользовательская документация как часть внутренней базы знаний. Александр Клименков (Bercut)
Пользовательская документация — отличный способ передать знания о продукте для Пользователей. Однако, если добавить ещё немножко усилий, такая документация может помочь выстроить базу знаний компании и переосмыслить внутренние процессы. Александр буквально «на кошках» покажет, как пройти этот путь.
🔹 «06 Зал Зелёный». Продолжение мастер-класса. Как формулировать проблемы так, чтобы их решения приближали к цели (НЖЯ, ТОС). Александра Брызгалова (bryzgalova.ru)
Хорошо, когда можно послушать доклад. Еще лучше — когда полученные знания можно попробовать применить под руководством опытного тренера, увидеть свои ошибки, исправить их и уверенно пользоваться инструментом, который предлагает Александра.
✋ВАЖНО. Количество мест на мастер-класс от Александры — ограничено
🔹 Зал «07 Шатер Оранжевый». Продолжение мастер-класса. Маркер всевластья, практика визуальных встреч. Александр Зинченко (Яндекс 360)
В случае, если слов недостаточно, чтобы у всех было одинаковое понимание идеи, проблемы, плана, на помощь может прийти визуализация, например — рисование. Александр расскажет и покажет, что рисовать не только полезно, но и гораздо проще, чем может казаться.
🔹 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса. Командные встречи: неизбежное зло или секрет вашей антихрупкости. Дарья Вьюнова (OTUS Онлайн-образование)
Как проводить встречи, чтобы после них было ощущение синхронизации команды, воодушевление от идей и желание двигаться дальше — потренируемся на мастер-классе от Дарьи. В итоге каждый участник заберет план встречи, лайфхаки для поддержки динамики на созвоне и вовлечения сотрудников.
👍1
PVS-Studio – статический анализатор для C, C++, C# и Java кода.
Они развеивают миф о том, что статический анализатор нужен только новичкам. Миссия компании – повышение качества программ за счет продвижения идеи использования статического анализа кода в мире.
Приходите к ним на стенд, где у вас будет возможность пообщаться с экспертами мира статического анализатора, решить задачки на поиск ошибок коде программ и получить крутые призы.
Подробнее о компании на сайте
Реклама ООО "ПВС" erid: LjN8KUGhk
Они развеивают миф о том, что статический анализатор нужен только новичкам. Миссия компании – повышение качества программ за счет продвижения идеи использования статического анализа кода в мире.
Приходите к ним на стенд, где у вас будет возможность пообщаться с экспертами мира статического анализатора, решить задачки на поиск ошибок коде программ и получить крутые призы.
Подробнее о компании на сайте
Реклама ООО "ПВС" erid: LjN8KUGhk
🔥1
🖐️ Программа докладов и мастер-классов, которые стартуют в 13:50
🔹 «00 Зал Башня». TDR — процесс технического дизайн-ревью. Павел Лакосников (Авито)
Рано или поздно масштаб системы приводит к необходимости ее валидации. Иначе — хаос и постепенное превращение в Big Ball of Mud. Павел расскажет о своем опыте валидации архитектуры, популярных подходах, их плюсах и минусах, и главное — как в Авито решили проблему контроля архитектуры.
🔹 Зал «08 Шатер Голубой». Как внедрять инженерные практики в сопротивляющихся командах. Тимур Мухтаров (Газпромбанк)
Здесь должен был быть мем про внедрение аджайла в сжатые сроки. На самом деле — тема мегаактуальная. На фоне нестабильности люди естественно тяготеют к спокойной работе без изменений и встрясок. А что делать, если очень надо что-то менять?
🔹 «04 Зал Красный». Единственная ответственность. Роман Хаимов (Рексофт)
Доклад позволит посмотреть на фундаментальный принцип несколько глубже, чем многие привыкли. Роман разберет его применимость на всех уровнях, начиная с функций и компонентов, заканчивая экосистемой проектов, а также покажет связь с другими основными принципами.
🔹 «03 Зал Синий». Строим свою систему грейдов с нуля. Иван Поддубный (Вебпрактик)
Управление знаниями в контрактной разработке так же многогранно, как и пул проектов, которыми занимаются такие компании. Иван расскажет, как решить одну из самых распространенных задач, характерных для такой бизнес-модели — управляемый всесторонний рост компетенций команды
🔹 «06 Зал Зелёный». Мастер-класс. Коммуникативная компетентность в работе тимлида++, или Конец эпохи делегирования. Александр Зиза, Вирна Штерн (Aletheia Digital)
Тема коммуникаций — постоянный гость нашей программы. В этот раз будем копать еще глубже и экспериментировать.
🔹 Зал «07 Шатер Оранжевый». Мастер-класс. Строим архитектуру стартапа с большой кодовой базой. Роман Силаков (ex Яндекс Такси)
В работе техлида часто возникают ситуации, когда надо сделать решение в рамках существующей экосистемы. Как подойди к сбору технических требований и ограничений? Как эффективно использовать то, что есть? Как правильно выстроить процесс? Именно эти вопросы будут разбираться на мастер-классе Романа.
🔹 Зал «09 Шатер Фиолетовый». Мастер-класс. Запускаем цикл непрерывных улучшений. Алексей Лосев, Елена Большакова, Сергей Тесленко (Яндекс Маркет)
Мастер-класс наглядно показывает, что у каждого изменения в процессах есть свои плюсы и минусы. Он также демонстрирует, что результаты иногда могут противоречить здравому смыслу и то, что кажется минусом или плюсом, не всегда является таковым.
🔹 «00 Зал Башня». TDR — процесс технического дизайн-ревью. Павел Лакосников (Авито)
Рано или поздно масштаб системы приводит к необходимости ее валидации. Иначе — хаос и постепенное превращение в Big Ball of Mud. Павел расскажет о своем опыте валидации архитектуры, популярных подходах, их плюсах и минусах, и главное — как в Авито решили проблему контроля архитектуры.
🔹 Зал «08 Шатер Голубой». Как внедрять инженерные практики в сопротивляющихся командах. Тимур Мухтаров (Газпромбанк)
Здесь должен был быть мем про внедрение аджайла в сжатые сроки. На самом деле — тема мегаактуальная. На фоне нестабильности люди естественно тяготеют к спокойной работе без изменений и встрясок. А что делать, если очень надо что-то менять?
🔹 «04 Зал Красный». Единственная ответственность. Роман Хаимов (Рексофт)
Доклад позволит посмотреть на фундаментальный принцип несколько глубже, чем многие привыкли. Роман разберет его применимость на всех уровнях, начиная с функций и компонентов, заканчивая экосистемой проектов, а также покажет связь с другими основными принципами.
🔹 «03 Зал Синий». Строим свою систему грейдов с нуля. Иван Поддубный (Вебпрактик)
Управление знаниями в контрактной разработке так же многогранно, как и пул проектов, которыми занимаются такие компании. Иван расскажет, как решить одну из самых распространенных задач, характерных для такой бизнес-модели — управляемый всесторонний рост компетенций команды
🔹 «06 Зал Зелёный». Мастер-класс. Коммуникативная компетентность в работе тимлида++, или Конец эпохи делегирования. Александр Зиза, Вирна Штерн (Aletheia Digital)
Тема коммуникаций — постоянный гость нашей программы. В этот раз будем копать еще глубже и экспериментировать.
🔹 Зал «07 Шатер Оранжевый». Мастер-класс. Строим архитектуру стартапа с большой кодовой базой. Роман Силаков (ex Яндекс Такси)
В работе техлида часто возникают ситуации, когда надо сделать решение в рамках существующей экосистемы. Как подойди к сбору технических требований и ограничений? Как эффективно использовать то, что есть? Как правильно выстроить процесс? Именно эти вопросы будут разбираться на мастер-классе Романа.
🔹 Зал «09 Шатер Фиолетовый». Мастер-класс. Запускаем цикл непрерывных улучшений. Алексей Лосев, Елена Большакова, Сергей Тесленко (Яндекс Маркет)
Мастер-класс наглядно показывает, что у каждого изменения в процессах есть свои плюсы и минусы. Он также демонстрирует, что результаты иногда могут противоречить здравому смыслу и то, что кажется минусом или плюсом, не всегда является таковым.
Forwarded from Максим Цепков (Maxim Tsepkov)
#Teamlead Роман Поборчий. Особенности создания внутренних сервисов в крупных компаниях, и как избежать провала. Рассказ начался с вопроса, что такое провал? Мы попробовали, сделали, но это не оказалось полезным. Это провал или нет? Ответ - итерация, мы потратили свое время и чужие деньги, чтобы уточнить картину мира. Полезный опыт.
Дальше была история. 1957 fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про fairchild semiconductor, где впервые употребил термин silicon valley - и он прижился.
Все росло в 2 раза, и был год, когда дочка приносила 60% холдингу, там были внутренние дележки. Но в 1968 двое ушли, основали Integrated Electronics - Intel, был первый коммерчески неуспешный год. А в 1969 - Sanders уволился и основал advanced micro devices - AMD.
Провал - когда вы были в нужное время в нужном мести, придумали то что нужно людям, сделали. Но у вас это почему-то не получается, а этот нужный сервис делает кто-то другой.
Возвращаясь к внутренним сервисам. Внутренний сервис - это сервис, потребителями которого являются клиенты компании, может быть разным: платформа, биллинг, аналитика (человек+машина). Внутренние пользователи и внешние - отличаются. Внешние - многочисленны, обезличены. Хотя в b2b некоторые важнее других. Но в целом восполнимый ресурс. Внутри пользователей мало, они рядом с руководством, и они - не восполнимый ресурс.
Внутренний сервис делает своему подразделению, часто маленькими ресурсами, а потом распространяют на другие. И общий принцип: не стоит делать чужую работу. И есть подводные камни, которые этому мешают.
1. Интеграция. Аналитический сервис, мы получаем данные и возвращаем. Клиент приходит, говорит где взять. А дальше много клиентов - и везде разные форматы и разные данные. И интеграция разнородных форматов начинает занимать значительную часть работы. Нанять 15 стажеров - не выход, с ними надо общаться, развивать, они не хотят всю жизнь парсить логи, они отнимают твое время. А еще любые внутренние логи могут поменять формат и вам надо будет переделывать. Да еще тесты у них не упадут - НЕ работает у вас.
Поэтому правильно оставить интеграцию клиента на другом конце: клади данные в этом формате сюда. Но! удобный API - ваша часть. И помощь в написании тестов. Но это работает начиная с 3-4 клиента, первых надо сделать самим - иначе они просто не начнут пользоваться.
2. Приоритеты. Agile учит планировать спринт, собирая заказчиков, и заказчики договариваются. В принципе работает, если общее дело, есть точки пересечения, на которых договариваются. Если же много разных подразделений, то они отказываются договариваться. Не приходят на встречу, а если пришли - только познакомились на ней. И они не договариваются между собой, а пытаются договорить вас. Ошибка - пытаться самому принять решение, кто важнее. Но если подразделения далекие и компания большая, то вы не можете сделать.
Что помогает? Наименьший общий начальник. Был кейс в Яндекс-поиске, много начальник. Но оказалось, что можно привлечь к планированию одного из топов. Пару раз в месяц, на планировании спринта, он приходил. Так бывает можно, не надо бояться.
Правда, на мой взгляд, это больше счастливый случай, а не правило. Если же НОК не доступен - приходится решать самому. Помогают квоты и предложение при срочных азачах ими меняться или брать в долг. Дело в том, что не хотят договариваться не со зла, а потому что нет времени вникнать в проблемы другого, а чтобы договориться - это нужно. А обмен или взять в долг - понятная конструкция.
Дальше была история. 1957 fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про fairchild semiconductor, где впервые употребил термин silicon valley - и он прижился.
Все росло в 2 раза, и был год, когда дочка приносила 60% холдингу, там были внутренние дележки. Но в 1968 двое ушли, основали Integrated Electronics - Intel, был первый коммерчески неуспешный год. А в 1969 - Sanders уволился и основал advanced micro devices - AMD.
Провал - когда вы были в нужное время в нужном мести, придумали то что нужно людям, сделали. Но у вас это почему-то не получается, а этот нужный сервис делает кто-то другой.
Возвращаясь к внутренним сервисам. Внутренний сервис - это сервис, потребителями которого являются клиенты компании, может быть разным: платформа, биллинг, аналитика (человек+машина). Внутренние пользователи и внешние - отличаются. Внешние - многочисленны, обезличены. Хотя в b2b некоторые важнее других. Но в целом восполнимый ресурс. Внутри пользователей мало, они рядом с руководством, и они - не восполнимый ресурс.
Внутренний сервис делает своему подразделению, часто маленькими ресурсами, а потом распространяют на другие. И общий принцип: не стоит делать чужую работу. И есть подводные камни, которые этому мешают.
1. Интеграция. Аналитический сервис, мы получаем данные и возвращаем. Клиент приходит, говорит где взять. А дальше много клиентов - и везде разные форматы и разные данные. И интеграция разнородных форматов начинает занимать значительную часть работы. Нанять 15 стажеров - не выход, с ними надо общаться, развивать, они не хотят всю жизнь парсить логи, они отнимают твое время. А еще любые внутренние логи могут поменять формат и вам надо будет переделывать. Да еще тесты у них не упадут - НЕ работает у вас.
Поэтому правильно оставить интеграцию клиента на другом конце: клади данные в этом формате сюда. Но! удобный API - ваша часть. И помощь в написании тестов. Но это работает начиная с 3-4 клиента, первых надо сделать самим - иначе они просто не начнут пользоваться.
2. Приоритеты. Agile учит планировать спринт, собирая заказчиков, и заказчики договариваются. В принципе работает, если общее дело, есть точки пересечения, на которых договариваются. Если же много разных подразделений, то они отказываются договариваться. Не приходят на встречу, а если пришли - только познакомились на ней. И они не договариваются между собой, а пытаются договорить вас. Ошибка - пытаться самому принять решение, кто важнее. Но если подразделения далекие и компания большая, то вы не можете сделать.
Что помогает? Наименьший общий начальник. Был кейс в Яндекс-поиске, много начальник. Но оказалось, что можно привлечь к планированию одного из топов. Пару раз в месяц, на планировании спринта, он приходил. Так бывает можно, не надо бояться.
Правда, на мой взгляд, это больше счастливый случай, а не правило. Если же НОК не доступен - приходится решать самому. Помогают квоты и предложение при срочных азачах ими меняться или брать в долг. Дело в том, что не хотят договариваться не со зла, а потому что нет времени вникнать в проблемы другого, а чтобы договориться - это нужно. А обмен или взять в долг - понятная конструкция.
Forwarded from Максим Цепков (Maxim Tsepkov)
Еще один трюк. После планирования приходит заказчик, говорит "Мне очень надо, ты сделай, давай я тебе помогу". Ваша работа - заранее думать, что я могу попросить у такого клиента. И в этот момент быть готовым попросить. В идеале, когда разовая услуга меняется на долгосрочные обязательства. Например, попросили сервис, который в ответ на слово отдавал основную форму - это часто нужно. Это выигрышная стратегия, стоит вкладываться.
3. Стабильность. Начинается на маленьком железе, старый сервер. Внутренние лучше внешних, они не уходят, осознают ресурсный голод. Но в какой-то момент не могут терпеть. Как оттянуть этот момент, и успеть сделать нормально?
Если от внутреннего сервиса не зависит продакшн - его не обязательно резервировать. Достаточно мониторить и вешать плашку "не работаю планово". И по входным данным - вести мониторинг, вешать плашку "мы уже знаем". Это как "мы адекватны и стараемся".
Рост нагрузки системы. Измеряться может в разном, а скачки - с новым клиентом. И часто есть точка апокалипсиса - ресурс весь потребляется. Например, может быть время на ежедневную обработку данных - не должно превышать 24 часа. Пока всего мало, можно проводить тесты и предсказать точку апокалипсиса. Это надо сделать и готовиться.
Мониторинг и информирование - важнее постоянной доступности.
4. Велосипеды. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apach Superset - позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край - большой, надо дробить. А еще есть города - миллионники - они маленькие, людей много - их надо показывать специально. А еще состав региона надо уметь менять. Коробка - не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.
Готовые инструменты хороши для прототипов, но даже для MVP - не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.
3. Стабильность. Начинается на маленьком железе, старый сервер. Внутренние лучше внешних, они не уходят, осознают ресурсный голод. Но в какой-то момент не могут терпеть. Как оттянуть этот момент, и успеть сделать нормально?
Если от внутреннего сервиса не зависит продакшн - его не обязательно резервировать. Достаточно мониторить и вешать плашку "не работаю планово". И по входным данным - вести мониторинг, вешать плашку "мы уже знаем". Это как "мы адекватны и стараемся".
Рост нагрузки системы. Измеряться может в разном, а скачки - с новым клиентом. И часто есть точка апокалипсиса - ресурс весь потребляется. Например, может быть время на ежедневную обработку данных - не должно превышать 24 часа. Пока всего мало, можно проводить тесты и предсказать точку апокалипсиса. Это надо сделать и готовиться.
Мониторинг и информирование - важнее постоянной доступности.
4. Велосипеды. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apach Superset - позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край - большой, надо дробить. А еще есть города - миллионники - они маленькие, людей много - их надо показывать специально. А еще состав региона надо уметь менять. Коробка - не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.
Готовые инструменты хороши для прототипов, но даже для MVP - не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.
🖐️ Друзья, в 15:00 приходите на следующие доклады и мастер-классы:
🔹 «00 Зал Башня». История внедрения трансформационных изменений в кластере из 600+ инженеров. Ярослав Станишевский (МТС)
Рядом есть 600 человек, они вам не подчиняются напрямую, но надо внедрить им новый процесс. Кто-то на словах согласен, но ничего не делает. Кого-то не устраивает инструментарий. Кто-то, в принципе, избегает встречи. Как не сойти с ума и всё-таки внедрить изменения?
🔹 Зал «08 Шатер Голубой». Как превратить такой простой (но сложный) онбординг в инструмент развития всей команды. Надежда Погина (Cloud.ru)
Основная изюминка доклада в том, что он рассказывает о подходе внедрения онбординга «снизу вверх» — этот процесс не был спущен сверху из отделов кадров, а родился и вырос внутри департамента. А это значит, что любой сможет повторить подобное у себя в компании.
🔹 «04 Зал Красный». Как сделать инженерную культуру в компании однородной. Артём Кураев (Leroy Merlin)
Артем представит доклад о важности инженерного аудита, обсудит открытые метрики и формулы расчета зрелости команд. Продемонстрирует шаги, направленные на решение наиболее распространенных проблем в инженерном аудите, помогающие улучшить процесс разработки и качество продукта.
🔹 «03 Зал Синий». Как стать 10x экспертом. Игорь Курочкин (Enabling.team)
Игорь расскажет в своем докладе о том, как быть экспертом профессионально: вести свою базу знаний, сохраняя все самое важное для быстрой распаковки в случае необходимости решения задач с разными командами точно вовремя.
🔹 «06 Зал Зелёный». Продолжение мастер-класса. Коммуникативная компетентность в работе тимлида++, или Конец эпохи делегирования. Александр Зиза, Вирна Штерн (Aletheia Digital)
Тема коммуникаций — постоянный гость нашей программы. В этот раз будем копать еще глубже и экспериментировать.
🔹 Зал «07 Шатер Оранжевый». Продолжение мастер-класса. Строим архитектуру стартапа с большой кодовой базой. Роман Силаков (ex Яндекс Такси)
В работе техлида часто возникают ситуации, когда надо сделать решение в рамках существующей экосистемы. Как подойди к сбору технических требований и ограничений? Как эффективно использовать то, что есть? Как правильно выстроить процесс? Именно эти вопросы будут разбираться на мастер-классе Романа.
🔹 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса. Запускаем цикл непрерывных улучшений. Алексей Лосев, Елена Большакова, Сергей Тесленко (Яндекс Маркет)
Мастер-класс наглядно показывает, что у каждого изменения в процессах есть свои плюсы и минусы. Он также демонстрирует, что результаты иногда могут противоречить здравому смыслу и то, что кажется минусом или плюсом, не всегда является таковым.
🔹 «00 Зал Башня». История внедрения трансформационных изменений в кластере из 600+ инженеров. Ярослав Станишевский (МТС)
Рядом есть 600 человек, они вам не подчиняются напрямую, но надо внедрить им новый процесс. Кто-то на словах согласен, но ничего не делает. Кого-то не устраивает инструментарий. Кто-то, в принципе, избегает встречи. Как не сойти с ума и всё-таки внедрить изменения?
🔹 Зал «08 Шатер Голубой». Как превратить такой простой (но сложный) онбординг в инструмент развития всей команды. Надежда Погина (Cloud.ru)
Основная изюминка доклада в том, что он рассказывает о подходе внедрения онбординга «снизу вверх» — этот процесс не был спущен сверху из отделов кадров, а родился и вырос внутри департамента. А это значит, что любой сможет повторить подобное у себя в компании.
🔹 «04 Зал Красный». Как сделать инженерную культуру в компании однородной. Артём Кураев (Leroy Merlin)
Артем представит доклад о важности инженерного аудита, обсудит открытые метрики и формулы расчета зрелости команд. Продемонстрирует шаги, направленные на решение наиболее распространенных проблем в инженерном аудите, помогающие улучшить процесс разработки и качество продукта.
🔹 «03 Зал Синий». Как стать 10x экспертом. Игорь Курочкин (Enabling.team)
Игорь расскажет в своем докладе о том, как быть экспертом профессионально: вести свою базу знаний, сохраняя все самое важное для быстрой распаковки в случае необходимости решения задач с разными командами точно вовремя.
🔹 «06 Зал Зелёный». Продолжение мастер-класса. Коммуникативная компетентность в работе тимлида++, или Конец эпохи делегирования. Александр Зиза, Вирна Штерн (Aletheia Digital)
Тема коммуникаций — постоянный гость нашей программы. В этот раз будем копать еще глубже и экспериментировать.
🔹 Зал «07 Шатер Оранжевый». Продолжение мастер-класса. Строим архитектуру стартапа с большой кодовой базой. Роман Силаков (ex Яндекс Такси)
В работе техлида часто возникают ситуации, когда надо сделать решение в рамках существующей экосистемы. Как подойди к сбору технических требований и ограничений? Как эффективно использовать то, что есть? Как правильно выстроить процесс? Именно эти вопросы будут разбираться на мастер-классе Романа.
🔹 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса. Запускаем цикл непрерывных улучшений. Алексей Лосев, Елена Большакова, Сергей Тесленко (Яндекс Маркет)
Мастер-класс наглядно показывает, что у каждого изменения в процессах есть свои плюсы и минусы. Он также демонстрирует, что результаты иногда могут противоречить здравому смыслу и то, что кажется минусом или плюсом, не всегда является таковым.
В ecom.tech делают ИТ для ритейла реального времени.
Чтобы все нужные товары и продукты могли попадать домой к людям мгновенно, насколько это возможно в физическом мире.
На технологиях ecom.tech работают Самокат, Мегамаркет, логистическая инфраструктура.
В инженерной команде компании 4000 человек – они большие и разные, стремятся к technical excellence и business value, ценят процессы и избегают закостенелости.
В ecom.tech делают продукты, которыми пользуются сами. Приходите на стенд – вам покажут, что у них под капотом, пообщаетесь и поиграете
Телеграм
ХАБР
Ютуб
Реклама ООО "Умное пространство" erid: LjN8KC4o1
Чтобы все нужные товары и продукты могли попадать домой к людям мгновенно, насколько это возможно в физическом мире.
На технологиях ecom.tech работают Самокат, Мегамаркет, логистическая инфраструктура.
В инженерной команде компании 4000 человек – они большие и разные, стремятся к technical excellence и business value, ценят процессы и избегают закостенелости.
В ecom.tech делают продукты, которыми пользуются сами. Приходите на стенд – вам покажут, что у них под капотом, пообщаетесь и поиграете
Телеграм
ХАБР
Ютуб
Реклама ООО "Умное пространство" erid: LjN8KC4o1