Ценность и цель управленческих решений
Как менеджеры, мы выстраиваем процессы, измеряем метрики, стремимся выполнять KPI. А для чего? Я говорю в практическом смысле: какая цель за этим стоит?
Я часто слышал ответ на этот вопрос — “Деньги!”. Это отчасти верный ответ, но в нем кое-что упущено. Цель продуктовой разработки — максимизация ценности генерируемой за жизненный цикл продукта. Не просто деньги, а деньги, которые продукт принесет за всю свою жизнь, lifetime value. Интеграл денег по времени, получается.
Держа эту цель в голове принимать многие решения становится проще:
Нужно ли нанимать больше людей? Это увеличит lifetime value?
Нужно ли вкладывать в R&D? Как это повлияет на lifetime value?
Нужно ли вкладываться в engineering excellence и повышать качество? Как низкое качество и отказы влияют на lifetime value?
Нужно делать следующую фичу или устранять технический долг? Ну вы поняли.
Это не волшебная палочка, многие из упомянутых вещей трудно численно измерить. Однако, если вы можете выстроить связь планируемого изменения с конечной целью, то вы можете критически осмыслять плюсы и минусы решения, вы можете сравнивать решения между собой, вы можете попросить коллег поискать дыры в ваших рассуждениях.
Понимание конечной цели позволяет критически осмыслять ваши решения, последствия которых станут видимы очень нескоро, возможно, вы уже будете не на этой позиции и не в этой компании. И что останется после вас?
#менеджмент #рассуждения
Как менеджеры, мы выстраиваем процессы, измеряем метрики, стремимся выполнять KPI. А для чего? Я говорю в практическом смысле: какая цель за этим стоит?
Я часто слышал ответ на этот вопрос — “Деньги!”. Это отчасти верный ответ, но в нем кое-что упущено. Цель продуктовой разработки — максимизация ценности генерируемой за жизненный цикл продукта. Не просто деньги, а деньги, которые продукт принесет за всю свою жизнь, lifetime value. Интеграл денег по времени, получается.
Держа эту цель в голове принимать многие решения становится проще:
Нужно ли нанимать больше людей? Это увеличит lifetime value?
Нужно ли вкладывать в R&D? Как это повлияет на lifetime value?
Нужно ли вкладываться в engineering excellence и повышать качество? Как низкое качество и отказы влияют на lifetime value?
Нужно делать следующую фичу или устранять технический долг? Ну вы поняли.
Это не волшебная палочка, многие из упомянутых вещей трудно численно измерить. Однако, если вы можете выстроить связь планируемого изменения с конечной целью, то вы можете критически осмыслять плюсы и минусы решения, вы можете сравнивать решения между собой, вы можете попросить коллег поискать дыры в ваших рассуждениях.
Понимание конечной цели позволяет критически осмыслять ваши решения, последствия которых станут видимы очень нескоро, возможно, вы уже будете не на этой позиции и не в этой компании. И что останется после вас?
#менеджмент #рассуждения
Граница в отношениях руководитель — подчиненный
«Нам менеджер сказал не писать тесты и запилить эту фичу по-быстрому.»
«Мне сказали делать так, вот я и делаю»
Мне часто доводилось слышать такое, особо в случаях, когда руководитель без технического опыта управляет технической командой.
Получается, что авторитет и позиция в иерархии важнее компетентности в принятии решений. С другой стороны, понимаю такую покладистость со стороны разработчиков: ведь обычно мы не проверяем на собеседовании навыки переговоров, умение аргументировать, конфликт-менеджмент...
Если случайный разработчик завтра уйдет с проекта, сколько времени потребуется, чтобы найти нового? В моем опыте — 3 месяца от открытия вакансии до выхода человека, для синьоров — 6. Это только найти, а надо еще в специфику проекта вникнуть, понять как всё устроено. Это говорит о том, что у рядового разработчика достаточно много критических знаний о деталях работы системы, связях, рисках. Не обесценивайте их, проявляйте понимание, сдержанность и настойчивость. Не ходите туда, куда вас посылают, но и не посылайте в ответ. Не надо пугаться слова «менеджер» в названии позиции, как минимум, потому, что, когда ночью развалится продакшен, чинить его вам, а не вашему менеджеру.
Если вы менеджер, понимайте различие в том, кто несет ответственность за решения, и кто обладает необходимой экспертизой, чтобы принимать это решение. Это почти всегда разные люди! RACI-матрица в помощь.
Тут стоит привести контр-пример из западной разработки, где есть позиции principal и staff engineer. Это такие разработчики, которые принимают технические решения на уровне всей компании, участвуют в разработке стратегии, зачастую репортят напрямую CTO, и при этом пишут код. Они разработчики, у них нет подчиненных, но при этом могут сказать: «Директор? Да пошел ты в жопу директор!».
#корпоративнаякультура #менеджмент
«Нам менеджер сказал не писать тесты и запилить эту фичу по-быстрому.»
«Мне сказали делать так, вот я и делаю»
Мне часто доводилось слышать такое, особо в случаях, когда руководитель без технического опыта управляет технической командой.
Получается, что авторитет и позиция в иерархии важнее компетентности в принятии решений. С другой стороны, понимаю такую покладистость со стороны разработчиков: ведь обычно мы не проверяем на собеседовании навыки переговоров, умение аргументировать, конфликт-менеджмент...
Если случайный разработчик завтра уйдет с проекта, сколько времени потребуется, чтобы найти нового? В моем опыте — 3 месяца от открытия вакансии до выхода человека, для синьоров — 6. Это только найти, а надо еще в специфику проекта вникнуть, понять как всё устроено. Это говорит о том, что у рядового разработчика достаточно много критических знаний о деталях работы системы, связях, рисках. Не обесценивайте их, проявляйте понимание, сдержанность и настойчивость. Не ходите туда, куда вас посылают, но и не посылайте в ответ. Не надо пугаться слова «менеджер» в названии позиции, как минимум, потому, что, когда ночью развалится продакшен, чинить его вам, а не вашему менеджеру.
Если вы менеджер, понимайте различие в том, кто несет ответственность за решения, и кто обладает необходимой экспертизой, чтобы принимать это решение. Это почти всегда разные люди! RACI-матрица в помощь.
Тут стоит привести контр-пример из западной разработки, где есть позиции principal и staff engineer. Это такие разработчики, которые принимают технические решения на уровне всей компании, участвуют в разработке стратегии, зачастую репортят напрямую CTO, и при этом пишут код. Они разработчики, у них нет подчиненных, но при этом могут сказать: «Директор? Да пошел ты в жопу директор!».
#корпоративнаякультура #менеджмент
Исследование об эффективности интервью
На заре карьеры, когда я начал участвовать в процессе собеседования как интервьюер, я совершенно не знал, что делать, и просто начал копировать то, что делают другие люди. Обучение, тренинги и собственные мысли пришли гораздо позже.
В каждой компании уверены, что они умеют проводить собеседования, нанимают “правильных” людей, а “неправильных” фильтруют через воронку собеседований.
Так ли это? Уже много лет исследования говорят — нет, это не ошибка! Тот процесс, который принят в бизнес-среде (когда кандидату задаются произвольные вопросы), не работает! Неструктурированные интервью значительно подвержены влиянию когнитивных искажений. Мы нанимаем тех, кто нам симпатичен как человек, но это не всегда говорит о способности выполнять работу.
В исследовании “Belief in the unstructured interview: The persistence of an illusion” от 2013 года авторы поставили следующий эксперимент: каждого из респондентов просили предсказать средний балл студента в текущем семестре, основываясь на его биографических сведениях и среднем балле за прошлый семестр. Исследователи дали вводную, что наиболее значимым фактором для предсказания является прошлое значение среднего балла студента.
Далее респондентов поделили на две группы: первая группа делала предсказания на основании предоставленной информации, во второй группе респонденты, в дополнение к имеющейся информации, проводили интервью со студентом перед тем, как сделать свой прогноз.
Кто был более точен в оценках? Прогнозы респондентов из второй группы (где было интервью) имели большее отклонение от реальной оценки, чем прогнозы, данные на основании биографии и среднего балла за прошлый семестр. Все статистические выкладки см. в исследовании.
Мало того, несмотря на вводную от организаторов, что прошлая оценка точнее всего предсказывает текущую, участники второй группы утверждали, что именно интервью дало им наибольшее количество информации для принятия решения (респондентов сначала опрашивали, а потом раскрывали, насколько совпал прогноз с оценкой).
Какие выводы?
1. Следует с большим скепсисом относиться к качеству отбора в процессе собеседования и оценивать людей на основании результатов работы.
2. В компании, где испытательный срок закрывается у 100% кандидатов, скорее всего работают случайные люди.
Ссылка на исследование: http://journal.sjdm.org/12/121130a/jdm121130a.pdf
#найм #менеджмент
На заре карьеры, когда я начал участвовать в процессе собеседования как интервьюер, я совершенно не знал, что делать, и просто начал копировать то, что делают другие люди. Обучение, тренинги и собственные мысли пришли гораздо позже.
В каждой компании уверены, что они умеют проводить собеседования, нанимают “правильных” людей, а “неправильных” фильтруют через воронку собеседований.
Так ли это? Уже много лет исследования говорят — нет, это не ошибка! Тот процесс, который принят в бизнес-среде (когда кандидату задаются произвольные вопросы), не работает! Неструктурированные интервью значительно подвержены влиянию когнитивных искажений. Мы нанимаем тех, кто нам симпатичен как человек, но это не всегда говорит о способности выполнять работу.
В исследовании “Belief in the unstructured interview: The persistence of an illusion” от 2013 года авторы поставили следующий эксперимент: каждого из респондентов просили предсказать средний балл студента в текущем семестре, основываясь на его биографических сведениях и среднем балле за прошлый семестр. Исследователи дали вводную, что наиболее значимым фактором для предсказания является прошлое значение среднего балла студента.
Далее респондентов поделили на две группы: первая группа делала предсказания на основании предоставленной информации, во второй группе респонденты, в дополнение к имеющейся информации, проводили интервью со студентом перед тем, как сделать свой прогноз.
Кто был более точен в оценках? Прогнозы респондентов из второй группы (где было интервью) имели большее отклонение от реальной оценки, чем прогнозы, данные на основании биографии и среднего балла за прошлый семестр. Все статистические выкладки см. в исследовании.
Мало того, несмотря на вводную от организаторов, что прошлая оценка точнее всего предсказывает текущую, участники второй группы утверждали, что именно интервью дало им наибольшее количество информации для принятия решения (респондентов сначала опрашивали, а потом раскрывали, насколько совпал прогноз с оценкой).
Какие выводы?
1. Следует с большим скепсисом относиться к качеству отбора в процессе собеседования и оценивать людей на основании результатов работы.
2. В компании, где испытательный срок закрывается у 100% кандидатов, скорее всего работают случайные люди.
Ссылка на исследование: http://journal.sjdm.org/12/121130a/jdm121130a.pdf
#найм #менеджмент
Cambridge Core
Belief in the unstructured interview: The persistence of an illusion | Judgment and Decision Making | Cambridge Core
Belief in the unstructured interview: The persistence of an illusion - Volume 8 Issue 5
Ошибки менеджера: не строить отношений
Рефлексируя свой опыт, хочется подумать над ошибками. Первое, что приходит на ум — не строить доверительных отношений. С кем? С людьми в команде, с другими руководителями, с ключевыми стейкхолдерами.
Почему это плохо?
Трудно проводить изменения
Без поддержки в команде даже хорошие начинания могут плохо закончиться: внедрение CI, code-review, ретроспективы. Всё это может встретить сопротивление. Имея хорошие отношения с людьми в команде, у вас появляются агенты изменений, которые помогают их «продать».
Отношения с командой деградируют
Слышали фразу «Люди приходят в компанию, а уходят от руководителя»? — отчасти из-за этого. Существуют и обратные примеры, когда целые департаменты уходили вслед за руководителем в другую компанию. Бывали в ситуации когда к вам приходит сотрудник с предложением другой компании на руках и говорит: “Я ухожу”. А почему он раньше не пришел, когда только задумался по сторонам посмотреть?
Перестаешь получать обратную связь
Конечно приятно думать, что делаешь всё хорошо, раз никто не утверждает обратного. Скорее всего это самообман, и вы просто не замечаете своих косяков. Без обратной связи происходит отрыв от реальности, и начинаешь работать в стиле «я так вижу». Так и появляются старожилы в компании, которые рьяно защищают свое наследие. На эту тему есть отдельный пост.
Счастье, если среди подчинённых окажется человек, способный называть вещи своими именами, но ведь и его можно проигнорировать. Розовые очки — надежный фильтр.
Слабая позиция в организации
Давайте будем честны: корпоративная среда — тот ещё «клубок змей». Можно уйти в отпуск, вернуться и не обнаружить своего департамента. Независимо от того, насколько вы хороший менеджер, в организации есть своя политика.Чем больше людей на разных уровнях понимают, что вы делаете и почему это важно, тем лучше для вашей команды.
Конечно IT индустрия богата интровертами, но не следует путать личные предпочтения с умением разговаривать.
Коммуникация — это навык, ему можно научится и он будет работать на вас.
Отношения — это хорошая инвестиция, и она начинает приносить «проценты» очень быстро.
#ошибкименеджера #менеджмент
Рефлексируя свой опыт, хочется подумать над ошибками. Первое, что приходит на ум — не строить доверительных отношений. С кем? С людьми в команде, с другими руководителями, с ключевыми стейкхолдерами.
Почему это плохо?
Трудно проводить изменения
Без поддержки в команде даже хорошие начинания могут плохо закончиться: внедрение CI, code-review, ретроспективы. Всё это может встретить сопротивление. Имея хорошие отношения с людьми в команде, у вас появляются агенты изменений, которые помогают их «продать».
Отношения с командой деградируют
Слышали фразу «Люди приходят в компанию, а уходят от руководителя»? — отчасти из-за этого. Существуют и обратные примеры, когда целые департаменты уходили вслед за руководителем в другую компанию. Бывали в ситуации когда к вам приходит сотрудник с предложением другой компании на руках и говорит: “Я ухожу”. А почему он раньше не пришел, когда только задумался по сторонам посмотреть?
Перестаешь получать обратную связь
Конечно приятно думать, что делаешь всё хорошо, раз никто не утверждает обратного. Скорее всего это самообман, и вы просто не замечаете своих косяков. Без обратной связи происходит отрыв от реальности, и начинаешь работать в стиле «я так вижу». Так и появляются старожилы в компании, которые рьяно защищают свое наследие. На эту тему есть отдельный пост.
Счастье, если среди подчинённых окажется человек, способный называть вещи своими именами, но ведь и его можно проигнорировать. Розовые очки — надежный фильтр.
Слабая позиция в организации
Давайте будем честны: корпоративная среда — тот ещё «клубок змей». Можно уйти в отпуск, вернуться и не обнаружить своего департамента. Независимо от того, насколько вы хороший менеджер, в организации есть своя политика.Чем больше людей на разных уровнях понимают, что вы делаете и почему это важно, тем лучше для вашей команды.
Конечно IT индустрия богата интровертами, но не следует путать личные предпочтения с умением разговаривать.
Коммуникация — это навык, ему можно научится и он будет работать на вас.
Отношения — это хорошая инвестиция, и она начинает приносить «проценты» очень быстро.
#ошибкименеджера #менеджмент
Математика продуктовой разработки
Как принимать экономически оптимальные решения для продукта? Какими метриками измерять команды и успех продукта? Сколько денег теряется из-за того, что задачи накапливаются в очереди?
Об этом и многом другом пишет Donald Reinertsen в своей книге “The principles of product development flow”.
Однако есть проблема. Дело в том, что, помимо умных мыслей, в книге еще интегралы, производные, статистика, распределения Пуассона, Марковские процессы — вот это вот всё.
То ли дело скрам: беклог, спринт, стори поинты и побежали.
В этом интервью автор на простых примерах рассказывает основные идеи книги:
- Чем отличается разработка софта от конвейерного производства.
- Что такое cost of delay и как эта метрика помогает приоритизации.
- Почему сокращать время цикла разработки не всегда полезно.
- Почему важно уделять внимание управлению очередями.
- Почему, несмотря на повальный agile, классическое проектное управление по-прежнему имеет ценность.
А также масса аналогий из других областей, которые могут быть применимы к процессу разработки.
Ссылка на интервью: https://www.youtube.com/playlist?list=PLTfbQtksxe-LBUdxuNR6cGG6Ve8Rx9D5L
#инструменты #менеджмент #видеопотеме
Как принимать экономически оптимальные решения для продукта? Какими метриками измерять команды и успех продукта? Сколько денег теряется из-за того, что задачи накапливаются в очереди?
Об этом и многом другом пишет Donald Reinertsen в своей книге “The principles of product development flow”.
Однако есть проблема. Дело в том, что, помимо умных мыслей, в книге еще интегралы, производные, статистика, распределения Пуассона, Марковские процессы — вот это вот всё.
То ли дело скрам: беклог, спринт, стори поинты и побежали.
В этом интервью автор на простых примерах рассказывает основные идеи книги:
- Чем отличается разработка софта от конвейерного производства.
- Что такое cost of delay и как эта метрика помогает приоритизации.
- Почему сокращать время цикла разработки не всегда полезно.
- Почему важно уделять внимание управлению очередями.
- Почему, несмотря на повальный agile, классическое проектное управление по-прежнему имеет ценность.
А также масса аналогий из других областей, которые могут быть применимы к процессу разработки.
Ссылка на интервью: https://www.youtube.com/playlist?list=PLTfbQtksxe-LBUdxuNR6cGG6Ve8Rx9D5L
#инструменты #менеджмент #видеопотеме
YouTube
Interview Don Reinertsen, Author and Lean Management Pioneer - YouTube
Share your videos with friends, family, and the world
Масштабирование разработки: что мы оптимизирует?
В период бурного роста компании масштабирование разработки обычно происходит по следующей схеме:
Надо выпускать фичи быстрее — давайте добавим людей в команду! Давайте сделаем больше команд!
Хаоса от этого становится больше, забот тоже. А так как time to market никто толком не измеряет, то на фоне общего шума появляться ощущение, что вроде бы стало быстрее.
В действительности увеличение пропускной способности редко приводит к уменьшению t2m. Почему так?
Разработка находится в середине процесса
Мы пытаемся масштабировать узел в середине процесса, не оценив, сколько предыдущий узел может производить и сколько следующий узел способен принять на вход. С упрощением деплоя и CI/CD, разработка зачастую — последний этап, но так ещё не везде. А вот с pre-production лучше не становится, и даже agile не помогает (миллион одновременных инициатив, непредсказуемое время поставки требований).
Параллельная работа требует синхронизации
Про оверхед на синхронизацию программистам хорошо известно. Это же применимо и к процессам. Ну будет 100500 фичей в разработке одновременно. Мерджить-то их все равно по очереди! Тестирование и коммуникация усложняются на порядок.
Приведу бытовой пример. Канализационная труба такая толстая, чтобы справляться с резким возрастанием объема входящего трафика, не создавая заторов, а не потому, что каждый запрос занимает весь канал.
Наращивать пропускную способность имеет смысл в том случае, когда специфика работы предполагает резкое увеличение объема работы, которую нужно выполнить, не создавая задержек (Правда для этого требуется, чтобы существенная часть людей была НЕ занята, но об этом как-нибудь потом).
Добавить людей — это не универсальное решение всех проблем. Ускориться за счёт расширения команды получится только в очень редких случаях (когда не требуется дополнительной синхронизации). Перед тем, как что-то менять, следует определиться с целью. Мы хотим увеличить пропускную способность или сократить время выпуска? Скорее всего, второе — time to market. В этом случае, в первую очередь, следует думать не о расширении команд. Тогда о чём же?
Проведите мысленный эксперимент: При текущих процессах, сколько времени потребуется на выпуск тривиальной фичи (однострочное изменение в коде)? Где теряется время? Каких задержек можно избежать?
Вот там и следует оптимизировать.
#менеджмент
В период бурного роста компании масштабирование разработки обычно происходит по следующей схеме:
Надо выпускать фичи быстрее — давайте добавим людей в команду! Давайте сделаем больше команд!
Хаоса от этого становится больше, забот тоже. А так как time to market никто толком не измеряет, то на фоне общего шума появляться ощущение, что вроде бы стало быстрее.
В действительности увеличение пропускной способности редко приводит к уменьшению t2m. Почему так?
Разработка находится в середине процесса
Мы пытаемся масштабировать узел в середине процесса, не оценив, сколько предыдущий узел может производить и сколько следующий узел способен принять на вход. С упрощением деплоя и CI/CD, разработка зачастую — последний этап, но так ещё не везде. А вот с pre-production лучше не становится, и даже agile не помогает (миллион одновременных инициатив, непредсказуемое время поставки требований).
Параллельная работа требует синхронизации
Про оверхед на синхронизацию программистам хорошо известно. Это же применимо и к процессам. Ну будет 100500 фичей в разработке одновременно. Мерджить-то их все равно по очереди! Тестирование и коммуникация усложняются на порядок.
Приведу бытовой пример. Канализационная труба такая толстая, чтобы справляться с резким возрастанием объема входящего трафика, не создавая заторов, а не потому, что каждый запрос занимает весь канал.
Наращивать пропускную способность имеет смысл в том случае, когда специфика работы предполагает резкое увеличение объема работы, которую нужно выполнить, не создавая задержек (Правда для этого требуется, чтобы существенная часть людей была НЕ занята, но об этом как-нибудь потом).
Добавить людей — это не универсальное решение всех проблем. Ускориться за счёт расширения команды получится только в очень редких случаях (когда не требуется дополнительной синхронизации). Перед тем, как что-то менять, следует определиться с целью. Мы хотим увеличить пропускную способность или сократить время выпуска? Скорее всего, второе — time to market. В этом случае, в первую очередь, следует думать не о расширении команд. Тогда о чём же?
Проведите мысленный эксперимент: При текущих процессах, сколько времени потребуется на выпуск тривиальной фичи (однострочное изменение в коде)? Где теряется время? Каких задержек можно избежать?
Вот там и следует оптимизировать.
#менеджмент
Две вещи, о которых забывают при выборе технологий
Выбор технологий зачастую является предметом вкусовщины: “angular стрёмный, react молодец!”, “react сложо, vue.js огонь!”, “Rust или C++”. Несомненно личные предпочтения важны, когда работаешь с технологией каждый день. Однако, вкусовщина не должна быть решающим фактором. Понимание, каким образом технология позволит снизить сложность проекта, и опыт работы с ней — ключевые факторы.
Помимо этого, есть ещё пара аспектов, которые часто забывают оценить при выборе технологий:
Время жизни технического решения
Сколько времени предполагается поддерживать кодовую базу? Месяц? Год? 5 лет? 10? Согласитесь, от этого многое зависит. Есть ли у технологии предсказуемый релизный цикл, гарантия обратной совместимости при обновлении? Проживет ли вообще технология тот срок, в котором вы рассчитываете ее использовать? Можно вспомнить массу плохих примеров из 2010х, когда абсолютно всё было принято делать на Ruby on Rails или Django, а потом бороться с обновлениями версий. Rust и GO — хорошие примеры, где при выходе новой версии языка можно обновить toolchain, не внося изменений в кодовую базу.
Возможности найма
Как мы будем нанимать людей для работы с этой технологией? Сколько их на рынке? В случае бурного роста, сможем ли мы в разумные сроки привлечь нужное количество людей? Возможно, действительно, closure, erlang или rust — это идеальные технологии для вашего проекта. Вот только сколько этих людей на рынке? А кого на них можно быстро переучить? Матерых плюсовиков с опытом 10+ лет? А где они работают? А к вам пойдут? Осилите по зарплатам?
Выбор технологий для ключевых компонентов может быть стратегическим решением, так как во многом будет определять размер и структуру команд разработки, а также подход к обучению людей.
#менеджмент
Выбор технологий зачастую является предметом вкусовщины: “angular стрёмный, react молодец!”, “react сложо, vue.js огонь!”, “Rust или C++”. Несомненно личные предпочтения важны, когда работаешь с технологией каждый день. Однако, вкусовщина не должна быть решающим фактором. Понимание, каким образом технология позволит снизить сложность проекта, и опыт работы с ней — ключевые факторы.
Помимо этого, есть ещё пара аспектов, которые часто забывают оценить при выборе технологий:
Время жизни технического решения
Сколько времени предполагается поддерживать кодовую базу? Месяц? Год? 5 лет? 10? Согласитесь, от этого многое зависит. Есть ли у технологии предсказуемый релизный цикл, гарантия обратной совместимости при обновлении? Проживет ли вообще технология тот срок, в котором вы рассчитываете ее использовать? Можно вспомнить массу плохих примеров из 2010х, когда абсолютно всё было принято делать на Ruby on Rails или Django, а потом бороться с обновлениями версий. Rust и GO — хорошие примеры, где при выходе новой версии языка можно обновить toolchain, не внося изменений в кодовую базу.
Возможности найма
Как мы будем нанимать людей для работы с этой технологией? Сколько их на рынке? В случае бурного роста, сможем ли мы в разумные сроки привлечь нужное количество людей? Возможно, действительно, closure, erlang или rust — это идеальные технологии для вашего проекта. Вот только сколько этих людей на рынке? А кого на них можно быстро переучить? Матерых плюсовиков с опытом 10+ лет? А где они работают? А к вам пойдут? Осилите по зарплатам?
Выбор технологий для ключевых компонентов может быть стратегическим решением, так как во многом будет определять размер и структуру команд разработки, а также подход к обучению людей.
#менеджмент
Реакция на инциденты. Часть 1 «Героизм»
На удивление, тема инцидент-менеджмента не особо поднимается в сообществах. Как в компании выстроены процессы, связанные с восстановлением своих сервисов, не особо обсуждается за ее пределами. Не могу припомнить каких-то best-practices, кроме SRE (Site Reliability Engineering) от Google. А что делают те, кто не гугл?
Типовой сценарий такой: команда усиленно работает, готовит продукт/сервис/компонент к выпуску. После первого публичного релиза обнаруживается много упущенных моментов. Разумеется, что-то начинает отваливаться, происходят отказы, сервис некоторое время недоступен. Растёт давление со стороны ключевых стейкхолдеров, все на взводе.
Каждый инцидент начинается с поиска людей, готовых подключиться к разрешению ситуации. Постепенно появляются «пожарные» чатики, в кулуарах обсуждают, в чем была проблема, кто «накосячил», а кто «затащил». Со временем формируется круг «героев», которые «приходят на помощь», когда все идет не по плану.
Так как инциденты быстро эскалируются, и о них узнает вся управленческая иерархия, «герои» попадают в поле зрения руководителей высокого уровня, начинают быть на хорошем счету, со временем зарабатывают репутацию в компании. Создается замкнутый круг: пожары — это плохо, тот, кто их тушит — молодец. Предотвращению же не уделяется должного внимания, так как хвалят за тушение, а не за предотвращение. Это формирует отношение к инцидентам как к чему-то, что нужно быстро разгрести и «восстановить мир и покой».
Отказ сервиса может случиться днем, ночью, на пике трафика, когда вложили чемодан денег в рекламу, когда «герой» в отпуске. Инцидент может иметь непредсказуемые финансовые последствия для бизнеса.
Это случайное событие, которое может произойти в любой момент и продлиться неопределенное количество времени.
Остается загадкой – почему многие компании не идут дальше этого уровня?
#менеджмент #рассуждения
На удивление, тема инцидент-менеджмента не особо поднимается в сообществах. Как в компании выстроены процессы, связанные с восстановлением своих сервисов, не особо обсуждается за ее пределами. Не могу припомнить каких-то best-practices, кроме SRE (Site Reliability Engineering) от Google. А что делают те, кто не гугл?
Типовой сценарий такой: команда усиленно работает, готовит продукт/сервис/компонент к выпуску. После первого публичного релиза обнаруживается много упущенных моментов. Разумеется, что-то начинает отваливаться, происходят отказы, сервис некоторое время недоступен. Растёт давление со стороны ключевых стейкхолдеров, все на взводе.
Каждый инцидент начинается с поиска людей, готовых подключиться к разрешению ситуации. Постепенно появляются «пожарные» чатики, в кулуарах обсуждают, в чем была проблема, кто «накосячил», а кто «затащил». Со временем формируется круг «героев», которые «приходят на помощь», когда все идет не по плану.
Так как инциденты быстро эскалируются, и о них узнает вся управленческая иерархия, «герои» попадают в поле зрения руководителей высокого уровня, начинают быть на хорошем счету, со временем зарабатывают репутацию в компании. Создается замкнутый круг: пожары — это плохо, тот, кто их тушит — молодец. Предотвращению же не уделяется должного внимания, так как хвалят за тушение, а не за предотвращение. Это формирует отношение к инцидентам как к чему-то, что нужно быстро разгрести и «восстановить мир и покой».
Отказ сервиса может случиться днем, ночью, на пике трафика, когда вложили чемодан денег в рекламу, когда «герой» в отпуске. Инцидент может иметь непредсказуемые финансовые последствия для бизнеса.
Это случайное событие, которое может произойти в любой момент и продлиться неопределенное количество времени.
Остается загадкой – почему многие компании не идут дальше этого уровня?
#менеджмент #рассуждения
Реакция на инциденты. Часть 2 Мониторинг
Во время героической борьбы с пожарами неизбежно начинают появляться зачатки мониторинга — всё-таки простои дорого обходятся. Критичные сервисы обрастают всевозможными проверками: скрипты для проверки доступности БД, периодические пинги сервисов, появляются первые графики и алерты.
Инициатива мониторинга может исходить с разных сторон: может инженеры спать по ночам хотят, а может топы надавили «можем мы про такую хрень не от пользователей узнавать, а как-нибудь сами?». Как правило, на этой стадии мониторинг реализован бессистемно – каждая команда использует разные инструменты, метрики называются как попало и для людей за пределами команды не имеют никакого смысла.
Даже такой подход лучше, чем голый героизм. По крайней мере, проблемы обнаруживаются раньше и есть хоть какой-то инструментарий диагностики.
Правда, на этой стадии легко скатиться обратно: те, кто пережил фазу героизма, перешли в другие команды/получили повышения/ушли из компании, на новый проект набрали новых людей «с горящими глазами и непоротой задницей». Опыт забыт, скрипты утеряны, так что новый проект ожидают те же грабли после первого релиза.
Избежать этого помогла бы систематизация мониторинга:
Определить стек технологий, используемых для сбора телеметрии. Это в 2010 не было графита с карбонами и прометеями, а для distributed tracing’а приходилось изобретать свои поделки. Сейчас это всё есть в open source, стандартизовано, миллион раз проверено в продакшене и несложно внедряется.
Сформулировать стандарт мониторинга. Какие метрики собирать, в каких единицах измерения, определить правила именования (позволит иметь унифицированные дашборды), по каким адресам и на каких портах висят healthcheck’и. Чтобы любой человек, не знакомый со спецификой сервиса, мог посмотреть утилизацию CPU, потребление памяти, нагрузку на сеть, подключения к БД и так далее. В идеале, такой стандарт должен быть не документом в wiki, а набором библиотек, чтобы каждый новый сервис получал все это без дополнительных усилий.
Если это так просто реализовать в 2020, почему этого нет везде? В первой части я упоминал, что в эпоху героизма инциденты воспринимаются как «пожар», который требуется быстро устранить, чтобы восстановить работу сервисов. Чтобы начать инвестировать усилия в мониторинг, следует признать: инциденты неизбежны, они будут происходить, и только от нас зависит, во сколько нам обойдется следующий. «Сколько мы теряем, когда сервис не работает?» – этот вопрос переводит мониторинг систем из категории инженерных забав в полезную фичу для продукта, которая позволяет сократить потери. Уверяю вас, крайне редко найдется более ценная фича, чем повышение доступности сервиса.
Продолжение следует...
#менеджмент #рассуждения #инструменты
Во время героической борьбы с пожарами неизбежно начинают появляться зачатки мониторинга — всё-таки простои дорого обходятся. Критичные сервисы обрастают всевозможными проверками: скрипты для проверки доступности БД, периодические пинги сервисов, появляются первые графики и алерты.
Инициатива мониторинга может исходить с разных сторон: может инженеры спать по ночам хотят, а может топы надавили «можем мы про такую хрень не от пользователей узнавать, а как-нибудь сами?». Как правило, на этой стадии мониторинг реализован бессистемно – каждая команда использует разные инструменты, метрики называются как попало и для людей за пределами команды не имеют никакого смысла.
Даже такой подход лучше, чем голый героизм. По крайней мере, проблемы обнаруживаются раньше и есть хоть какой-то инструментарий диагностики.
Правда, на этой стадии легко скатиться обратно: те, кто пережил фазу героизма, перешли в другие команды/получили повышения/ушли из компании, на новый проект набрали новых людей «с горящими глазами и непоротой задницей». Опыт забыт, скрипты утеряны, так что новый проект ожидают те же грабли после первого релиза.
Избежать этого помогла бы систематизация мониторинга:
Определить стек технологий, используемых для сбора телеметрии. Это в 2010 не было графита с карбонами и прометеями, а для distributed tracing’а приходилось изобретать свои поделки. Сейчас это всё есть в open source, стандартизовано, миллион раз проверено в продакшене и несложно внедряется.
Сформулировать стандарт мониторинга. Какие метрики собирать, в каких единицах измерения, определить правила именования (позволит иметь унифицированные дашборды), по каким адресам и на каких портах висят healthcheck’и. Чтобы любой человек, не знакомый со спецификой сервиса, мог посмотреть утилизацию CPU, потребление памяти, нагрузку на сеть, подключения к БД и так далее. В идеале, такой стандарт должен быть не документом в wiki, а набором библиотек, чтобы каждый новый сервис получал все это без дополнительных усилий.
Если это так просто реализовать в 2020, почему этого нет везде? В первой части я упоминал, что в эпоху героизма инциденты воспринимаются как «пожар», который требуется быстро устранить, чтобы восстановить работу сервисов. Чтобы начать инвестировать усилия в мониторинг, следует признать: инциденты неизбежны, они будут происходить, и только от нас зависит, во сколько нам обойдется следующий. «Сколько мы теряем, когда сервис не работает?» – этот вопрос переводит мониторинг систем из категории инженерных забав в полезную фичу для продукта, которая позволяет сократить потери. Уверяю вас, крайне редко найдется более ценная фича, чем повышение доступности сервиса.
Продолжение следует...
#менеджмент #рассуждения #инструменты
Реакция на инциденты. Часть 3 Дежурства
Подход “звонить одному человеку, когда что-то сломалось” не может долго существовать — человек выгорает, количество сервисов растет, на всё рук не хватит. В конце концов, люди в отпуска ходят! В итоге в компании происходит переход к посменным дежурствам. Хорошо если используется специальный софт, который позволяет настроить расписание дежурств, политики эскалации, отсылку алертов на телефон дежурному. Странно, но даже при цене базовой подписки ниже, чем затраты на печеньки в офисе, такое используется не везде.
Пожалуй, внедрение дежурств — это в некотором роде фазовый переход в управлении разработкой. Этот процесс требует комплексных действий от менеджмента, подход “организуйтесь как-нибудь” уже не сработает: нужно выстроить новые ожидания от ролей, что дежурить — это теперь часть работы; нужно организовать соответствующие доступы, чтобы дежурный реально мог что-то сделать; нужно как-то юридически оформить работу внеурочно; дежурства надо оплачивать, даже если ничего не произошло, человек же был наготове, планы свои отменил.
Для проведения изменений такого уровня, необходима поддержка и действия со стороны руководства. Стимулом к действиям по выстраиванию инцидент-менеджмента может послужить понимание цены простоя и ответ на вопрос “Готова ли компания платить эту цену в будущем?”.
Следующая проблема, которая вскрывается после внедрения дежурств — знания о работе систем распределены неравномерно. И это не только про тонкости работы сервиса, компонента или отдельной технологии. Есть вещи более банальные: не все знают, где лежат логи; какой синтаксис запросов в агрегаторе логов; какой из 30 графиков в Grafana показывает процент ошибок.
А главный вопрос — как новым в компании людям получить эти знания, чтобы со временем хорошая практика не выродилась?
Инцидент-менеджмент на этом уровне тесно связан с другими процессами в компании:
Как происходит обучение новичков — что должен узнать новый человек в компании, чтобы продуктивно работать; сколько времени занимает его подготовка.
Обмен знаниями внутри команды — знания о специфике работы сервиса, живущие только в одной голове, очень быстро становятся проблемой (bus factor).
Выбор технологий — то, как технологию потом поддерживать, и сколько людей умеют ее “готовить”, становится фактором при выборе.
Стандарты написания кода — писать логи и метрики для новых фичей так, чтобы их понимал каждый разработчик.
Подход к документации — что вообще делает сервис, насколько он критичен, какие API сервис предоставляет, как их вызывать, и насколько легко отправить тестовый запрос.
Таким образом, подход к реакции на инциденты многое говорит об устройстве процессов в компании в целом. Когда потенциальный работодатель на интервью спросит: “У вас есть вопросы?”. Непременно поинтересуйтесь: “Как устроена реакция на инциденты в компании?” и услышав стыдливый ответ… А впрочем решать вам.
#менеджмент #рассуждения
Подход “звонить одному человеку, когда что-то сломалось” не может долго существовать — человек выгорает, количество сервисов растет, на всё рук не хватит. В конце концов, люди в отпуска ходят! В итоге в компании происходит переход к посменным дежурствам. Хорошо если используется специальный софт, который позволяет настроить расписание дежурств, политики эскалации, отсылку алертов на телефон дежурному. Странно, но даже при цене базовой подписки ниже, чем затраты на печеньки в офисе, такое используется не везде.
Пожалуй, внедрение дежурств — это в некотором роде фазовый переход в управлении разработкой. Этот процесс требует комплексных действий от менеджмента, подход “организуйтесь как-нибудь” уже не сработает: нужно выстроить новые ожидания от ролей, что дежурить — это теперь часть работы; нужно организовать соответствующие доступы, чтобы дежурный реально мог что-то сделать; нужно как-то юридически оформить работу внеурочно; дежурства надо оплачивать, даже если ничего не произошло, человек же был наготове, планы свои отменил.
Для проведения изменений такого уровня, необходима поддержка и действия со стороны руководства. Стимулом к действиям по выстраиванию инцидент-менеджмента может послужить понимание цены простоя и ответ на вопрос “Готова ли компания платить эту цену в будущем?”.
Следующая проблема, которая вскрывается после внедрения дежурств — знания о работе систем распределены неравномерно. И это не только про тонкости работы сервиса, компонента или отдельной технологии. Есть вещи более банальные: не все знают, где лежат логи; какой синтаксис запросов в агрегаторе логов; какой из 30 графиков в Grafana показывает процент ошибок.
А главный вопрос — как новым в компании людям получить эти знания, чтобы со временем хорошая практика не выродилась?
Инцидент-менеджмент на этом уровне тесно связан с другими процессами в компании:
Как происходит обучение новичков — что должен узнать новый человек в компании, чтобы продуктивно работать; сколько времени занимает его подготовка.
Обмен знаниями внутри команды — знания о специфике работы сервиса, живущие только в одной голове, очень быстро становятся проблемой (bus factor).
Выбор технологий — то, как технологию потом поддерживать, и сколько людей умеют ее “готовить”, становится фактором при выборе.
Стандарты написания кода — писать логи и метрики для новых фичей так, чтобы их понимал каждый разработчик.
Подход к документации — что вообще делает сервис, насколько он критичен, какие API сервис предоставляет, как их вызывать, и насколько легко отправить тестовый запрос.
Таким образом, подход к реакции на инциденты многое говорит об устройстве процессов в компании в целом. Когда потенциальный работодатель на интервью спросит: “У вас есть вопросы?”. Непременно поинтересуйтесь: “Как устроена реакция на инциденты в компании?” и услышав стыдливый ответ… А впрочем решать вам.
#менеджмент #рассуждения
Реакция на инциденты. Часть 4 Предотвращение
Новым витком в развитии инцидент-менеджмента становится переход от быстрого тушения пожара к предотвращению. Возможно, скромный пожарный инспектор выглядит не так мужественно, как герои пожарной команды, но предотвращать негативные события обходится значительно дешевле, чем заниматься восстановлением.
Инциденты неизбежны: будет случаться что-то новое, ранее невиданное, и уметь быстро реагировать необходимо. А чтобы снизить вероятность повторений, следует научиться извлекать уроки из прошлых событий. Легко сказать и очень трудно реализовать. Вам доводилось участвовать в пост-мортемах — когда собираются все участники инцидента, чтобы разобраться в причинах произошедшего? Есть два расхожих анти-паттерна:
Игры в прокуроров — поиск виноватых, который скатывается в критику и обвинения в непрофессионализме.
Признание очевидного — «Ну да, место на диске закончилось, но мы сейчас на новое железо переедем, и все будет норм». Тут поиск причины незаметно подменяется простой констатацией случившегося, и никаких действий не предпринимается (например обмазать систему метриками и навесить алерты, которые будут срабатывать до наступления критической ситуации).
Постмортемы вообще очень большая тема и про них много написано, правда не в IT, а в тех областях, где цена ошибки очень высока — регулирование воздушного трафика, системы безопасности.
Полезность постмортемов во многом зависит от корпоративной культуры. Два важных аспекта, связанных с ней:
Blameless — не искать виноватых, а искать ошибки в системе, которые позволяют подобным ситуациям происходить.
Sanctionless — не наказывать людей, действия которых привели к ошибкам. Представляете, человек базу работающего сервиса на продакшене удалил: «Терминал перепутал, ошибочка вышла». За такое не наказывать?! Однако, если гонцам, принесшим плохую новость, рубить головы, вы просто перестанете о них узнавать, вот только такие события продолжат происходить. Таким образом, следующий человек, который совершит ошибку, может не сказать о ней, а замести тихонько под коврик... А проблема останется в слепой зоне тикающей бомбой.
Три вопроса, которые помогут сформулировать действия по предотвращению:
- Может ли инцидент повториться?
- Есть ли у нас триггер, чтобы узнать о наступлении проблемы?
- Есть ли у нас готовое решение в случае повторного возникновения?
Еще один вопрос, которым следует задаться: а почему инцидент не имел более серьёзных последствий? Кто-то, кто хорошо знает систему, был рядом и помог. У кого-то появилась идея, что поискать в логах. Кто-то вспомнил, какое изменение в коде могло вызвать проблему. В таких ситуациях проявляется целый пласт знаний о поведении системы, который не записан в документации, не отражен в архитектуре, а по-прежнему живет только в головах людей. И каждый раз всплывает что-то новое — это и делает нашу работу такой интересной.
#менеджмент #рассуждения
Новым витком в развитии инцидент-менеджмента становится переход от быстрого тушения пожара к предотвращению. Возможно, скромный пожарный инспектор выглядит не так мужественно, как герои пожарной команды, но предотвращать негативные события обходится значительно дешевле, чем заниматься восстановлением.
Инциденты неизбежны: будет случаться что-то новое, ранее невиданное, и уметь быстро реагировать необходимо. А чтобы снизить вероятность повторений, следует научиться извлекать уроки из прошлых событий. Легко сказать и очень трудно реализовать. Вам доводилось участвовать в пост-мортемах — когда собираются все участники инцидента, чтобы разобраться в причинах произошедшего? Есть два расхожих анти-паттерна:
Игры в прокуроров — поиск виноватых, который скатывается в критику и обвинения в непрофессионализме.
Признание очевидного — «Ну да, место на диске закончилось, но мы сейчас на новое железо переедем, и все будет норм». Тут поиск причины незаметно подменяется простой констатацией случившегося, и никаких действий не предпринимается (например обмазать систему метриками и навесить алерты, которые будут срабатывать до наступления критической ситуации).
Постмортемы вообще очень большая тема и про них много написано, правда не в IT, а в тех областях, где цена ошибки очень высока — регулирование воздушного трафика, системы безопасности.
Полезность постмортемов во многом зависит от корпоративной культуры. Два важных аспекта, связанных с ней:
Blameless — не искать виноватых, а искать ошибки в системе, которые позволяют подобным ситуациям происходить.
Sanctionless — не наказывать людей, действия которых привели к ошибкам. Представляете, человек базу работающего сервиса на продакшене удалил: «Терминал перепутал, ошибочка вышла». За такое не наказывать?! Однако, если гонцам, принесшим плохую новость, рубить головы, вы просто перестанете о них узнавать, вот только такие события продолжат происходить. Таким образом, следующий человек, который совершит ошибку, может не сказать о ней, а замести тихонько под коврик... А проблема останется в слепой зоне тикающей бомбой.
Три вопроса, которые помогут сформулировать действия по предотвращению:
- Может ли инцидент повториться?
- Есть ли у нас триггер, чтобы узнать о наступлении проблемы?
- Есть ли у нас готовое решение в случае повторного возникновения?
Еще один вопрос, которым следует задаться: а почему инцидент не имел более серьёзных последствий? Кто-то, кто хорошо знает систему, был рядом и помог. У кого-то появилась идея, что поискать в логах. Кто-то вспомнил, какое изменение в коде могло вызвать проблему. В таких ситуациях проявляется целый пласт знаний о поведении системы, который не записан в документации, не отражен в архитектуре, а по-прежнему живет только в головах людей. И каждый раз всплывает что-то новое — это и делает нашу работу такой интересной.
#менеджмент #рассуждения
Метрики для команд: Вступление
В разговорах с коллегами иногда обсуждаем такой вопрос: “А как ты понимаешь, что твоя команда работает хорошо?”. Какой “линейкой” измерять результативность команды? Каким требованиям должны удовлетворять используемые метрики? Давайте порассуждаем на эту тему.
Начнём с требований:
Предсказательная способность
Важно, чтобы на основании метрики можно было прогнозировать будущие результаты. Сидят, значит, фронтендер, бекендер и IOS-разработчик на планировании спринта, оценивают задачи в стори-поинтах, посчитали среднюю velocity по трем спринтам и говорят: “Ну, в этом спринте мы можем сделать 20 стори-поинтов”. Анекдот из реальной жизни. А если серьёзно, то velocity, основанная на стори-поинтах, не обладает предсказательной способностью. Стори-поинты — хороший инструмент для фасилитации обсуждения задач, но бесполезный для оценки команды. По этому же критерию отпадают все усреднения — среднее количество багов на фичу, количество ошибок на строчку кода (кто это придумал?). Все это не говорит о том, как будет дальше – усреднение съедает всю полезную информацию.
Устойчивость к шуму
Метрика не должна “скакать” от незначительных изменений. Иначе, из-за этого шума не получится увидеть тренд, а он нужен для пункта 1. Приведу контрпример: количество стори-поинтов за спринт – как только большая стори уезжает в следующий спринт, получается, что в этом спринте сделали мало, в следующем — много, а по факту задача задержалась на пару дней. Такая метрика не показывает никакого тренда, т.к. слишком сильно подвержена влиянию незначительных отклонений.
Возможность влиять на метрику
Метрика должна быть actionable, то есть изменения в работе команды должны влиять на метрику. Из контр-примеров могу привести попытки привязать бизнес-метрики к оценке работы всей команды – конверсия, количество бизнес-транзакций и прочее. Да, это то, что приносит деньги компании, и это, безусловно, важно измерять. Однако, далеко не всегда команда может напрямую влиять на эти показатели.
С требованиями к метрикам понятно, а что измерять? На мой взгляд, есть три категории, в которых следует измерять работу команды:
Delivery – то, как команда выпускает фичи, сколько на это уходит времени.
Реакция на инциденты – если что-то случается, как долго команда устраняет последствия.
Качество – насколько то, что команда выпускает, соответствует требованиям.
О каждой из этих категорий поговорим более подробно в последующих постах.
#метрики #менеджмент
В разговорах с коллегами иногда обсуждаем такой вопрос: “А как ты понимаешь, что твоя команда работает хорошо?”. Какой “линейкой” измерять результативность команды? Каким требованиям должны удовлетворять используемые метрики? Давайте порассуждаем на эту тему.
Начнём с требований:
Предсказательная способность
Важно, чтобы на основании метрики можно было прогнозировать будущие результаты. Сидят, значит, фронтендер, бекендер и IOS-разработчик на планировании спринта, оценивают задачи в стори-поинтах, посчитали среднюю velocity по трем спринтам и говорят: “Ну, в этом спринте мы можем сделать 20 стори-поинтов”. Анекдот из реальной жизни. А если серьёзно, то velocity, основанная на стори-поинтах, не обладает предсказательной способностью. Стори-поинты — хороший инструмент для фасилитации обсуждения задач, но бесполезный для оценки команды. По этому же критерию отпадают все усреднения — среднее количество багов на фичу, количество ошибок на строчку кода (кто это придумал?). Все это не говорит о том, как будет дальше – усреднение съедает всю полезную информацию.
Устойчивость к шуму
Метрика не должна “скакать” от незначительных изменений. Иначе, из-за этого шума не получится увидеть тренд, а он нужен для пункта 1. Приведу контрпример: количество стори-поинтов за спринт – как только большая стори уезжает в следующий спринт, получается, что в этом спринте сделали мало, в следующем — много, а по факту задача задержалась на пару дней. Такая метрика не показывает никакого тренда, т.к. слишком сильно подвержена влиянию незначительных отклонений.
Возможность влиять на метрику
Метрика должна быть actionable, то есть изменения в работе команды должны влиять на метрику. Из контр-примеров могу привести попытки привязать бизнес-метрики к оценке работы всей команды – конверсия, количество бизнес-транзакций и прочее. Да, это то, что приносит деньги компании, и это, безусловно, важно измерять. Однако, далеко не всегда команда может напрямую влиять на эти показатели.
С требованиями к метрикам понятно, а что измерять? На мой взгляд, есть три категории, в которых следует измерять работу команды:
Delivery – то, как команда выпускает фичи, сколько на это уходит времени.
Реакция на инциденты – если что-то случается, как долго команда устраняет последствия.
Качество – насколько то, что команда выпускает, соответствует требованиям.
О каждой из этих категорий поговорим более подробно в последующих постах.
#метрики #менеджмент
Иногда активная разработка нового продукта начинается ещё до того, как оформилась финальная концепция. Пара примеров из истории: фотохостинг flickr вырос из тулинга для многопользовательской онлайн игры. Twitter начинался как способ поделиться статусом с друзьями по sms (отсюда ограничение на 160 символов в сообщении). Проекты с такой степенью неопределенности возникают нередко: появилась инициатива, есть свободные разработчики — вот и оформилась команда. Правда, не всегда понятно, что конкретно делать…
В такой ситуации то, что в нормальных условиях является хорошей практикой, может помешать успеху. Например:
Приоритизированный беклог может привести к тому, что команда начнет игнорировать новую информацию и продолжать делать то, что написано в беклоге. Забыв про “Responding to change over following a plan”.
Выделение формальных ролей (как пример: архитектор, product-manager) приведёт к игнорированию сильных сторон отдельных людей, и может убить креативность в команде («ну разве может копирайтер или тестировщик знать о том, как делать игру?»).
В этом видео Fred George рассказывает про подход “Programmer Anarchy”, который как раз о том, как не убить гибкость на проектах на ранних стадиях:
Видео: https://youtu.be/Zop0wTPrbk8
#видеопотеме #менеджмент
В такой ситуации то, что в нормальных условиях является хорошей практикой, может помешать успеху. Например:
Приоритизированный беклог может привести к тому, что команда начнет игнорировать новую информацию и продолжать делать то, что написано в беклоге. Забыв про “Responding to change over following a plan”.
Выделение формальных ролей (как пример: архитектор, product-manager) приведёт к игнорированию сильных сторон отдельных людей, и может убить креативность в команде («ну разве может копирайтер или тестировщик знать о том, как делать игру?»).
В этом видео Fred George рассказывает про подход “Programmer Anarchy”, который как раз о том, как не убить гибкость на проектах на ранних стадиях:
Видео: https://youtu.be/Zop0wTPrbk8
#видеопотеме #менеджмент
YouTube
Managing Manager‐less Processes • Fred George • GOTO 2017
This presentation was recorded at GOTO Chicago 2017. #GOTOcon #GOTOchgo
http://gotochgo.com
Fred George - Early Adopter of OO & Agile, Advocating MicroServices & Programmer Anarchy
ABSTRACT
A new generation of Agile processes are emerging, frequently omitting…
http://gotochgo.com
Fred George - Early Adopter of OO & Agile, Advocating MicroServices & Programmer Anarchy
ABSTRACT
A new generation of Agile processes are emerging, frequently omitting…
Какие проблемы решает реорганизация?
Я видел довольно много реорганизаций в компаниях: перегруппировать команды, добавить слой мидл-менеджмента, поменять зоны ответственности и т.д. Некоторые из них имели смысл и были совершенно оправданны, некоторые скорее походили на “преставление кроватей” из анекдота, который я постеснялся вставить в качестве эпиграфа.
Примеры проблем, которые решаются реорганизацией:
Упростить процесс принятия решений
Лицо, принимающее решения, находится далеко в иерархии от команд, где известен контекст и информация, необходимая для решения. Такая структура приводит к появлению очереди из вещей, ожидающих согласования, новые инициативы стартуют медленно, а технически небольшое изменение может выродиться в месяц согласований. Вестником такого рода организационной неэффективности являются профессиональные изготовители слайдов для внутренних презентаций. У высоких менеджеров времени мало, контекста не хватает, а разобраться в проблеме хочется, вот и начинается показ презентаций с ожиданием решения.
Другой пример — управление бюджетами: тимбилдинг организовать, специальное оборудование закупить, на конференцию людей отправить (бывает, что цепочка согласований занимает дольше, чем время от старта продажи билетов до начала самой конференции). Для решения этих проблем реорганизация — хороший инструмент.
Улучшить коммуникацию между командами
Например, одна команда предоставляет API, а другая его использует. Эти команды находятся в разных департаментах и не очень дружат между собой, а их общий руководитель — настолько высоко, что в случае эскалации проблемы, у него совершенно не хватает контекста, чтобы конструктивно её решить, и все заканчивается фразой: “Ребята, вы же профессионалы, договоритесь как-нибудь”. Подобные ситуации часто возникают в матричной структуре: дизайнеры репортят верховному дизайнеру, тот, в свою очередь, арт-директору, у разработчиков своя иерархия, у product-manager’ов своя. Вроде все одно дело делают, но у каждой дисциплины свои метрики эффективности и взгляд на то, как надо работать. Руководители оторваны от контекста, говорят на разных языках, и каждый оптимизируется под свои метрики. В итоге страдает общий результат, и ни одна из локальных оптимизаций не помогает. Проблема в системе.
Сфокусировать усилия
Выделить отдельную команду для решения проблемы, которую не получается решить частичными усилиями. Например, выделить команду developer productivity, чтобы унифицировать подходы к разработке и напилить общих библиотек. Это может сработать, если проблема уже сформулирована, и решение понятно. Выделение команды для решения нечеткой проблемы может привести к бюрократизации без какого-либо результата.
Какие проблемы реструктуризация НЕ решает:
Найм и увольнение — в компании зачастую есть люди, которых в ней быть не должно. Не поможет менять тайтлы и ворошить команды в попытках избежать трудного разговора с таким человеком.
Обучение — если у людей не хватает знаний или навыков, не поможет менять тайтлы. Бесполезно переименовывать команду оперирования в DevOps (да, я знаю, что это движение и культура, а не роль. Но кто публикует эти вакансии на linkedin?)
Мотивация — если департамент выгорает, из команд уходят люди, а в процессах полный хаос. Переименование ролей и команд в стиле “тот же хрен только в другой руке” ударит по этой области еще сильнее, показав слепоту руководства к насущным проблемам и породив разговоры в кулуарах о полезности данного действия.
Прежде чем проводить изменения организационной структуры, следует убедиться, что проблема именно в ней. Большая работа — сформулировать цели и спланировать изменения, которые позволят решить проблемы, не сильно добавив новых. А главное — до проведения изменений ответить на вопрос: “Как мы поймем, что новая структура работает?”
#менеджмент #рассуждения
Я видел довольно много реорганизаций в компаниях: перегруппировать команды, добавить слой мидл-менеджмента, поменять зоны ответственности и т.д. Некоторые из них имели смысл и были совершенно оправданны, некоторые скорее походили на “преставление кроватей” из анекдота, который я постеснялся вставить в качестве эпиграфа.
Примеры проблем, которые решаются реорганизацией:
Упростить процесс принятия решений
Лицо, принимающее решения, находится далеко в иерархии от команд, где известен контекст и информация, необходимая для решения. Такая структура приводит к появлению очереди из вещей, ожидающих согласования, новые инициативы стартуют медленно, а технически небольшое изменение может выродиться в месяц согласований. Вестником такого рода организационной неэффективности являются профессиональные изготовители слайдов для внутренних презентаций. У высоких менеджеров времени мало, контекста не хватает, а разобраться в проблеме хочется, вот и начинается показ презентаций с ожиданием решения.
Другой пример — управление бюджетами: тимбилдинг организовать, специальное оборудование закупить, на конференцию людей отправить (бывает, что цепочка согласований занимает дольше, чем время от старта продажи билетов до начала самой конференции). Для решения этих проблем реорганизация — хороший инструмент.
Улучшить коммуникацию между командами
Например, одна команда предоставляет API, а другая его использует. Эти команды находятся в разных департаментах и не очень дружат между собой, а их общий руководитель — настолько высоко, что в случае эскалации проблемы, у него совершенно не хватает контекста, чтобы конструктивно её решить, и все заканчивается фразой: “Ребята, вы же профессионалы, договоритесь как-нибудь”. Подобные ситуации часто возникают в матричной структуре: дизайнеры репортят верховному дизайнеру, тот, в свою очередь, арт-директору, у разработчиков своя иерархия, у product-manager’ов своя. Вроде все одно дело делают, но у каждой дисциплины свои метрики эффективности и взгляд на то, как надо работать. Руководители оторваны от контекста, говорят на разных языках, и каждый оптимизируется под свои метрики. В итоге страдает общий результат, и ни одна из локальных оптимизаций не помогает. Проблема в системе.
Сфокусировать усилия
Выделить отдельную команду для решения проблемы, которую не получается решить частичными усилиями. Например, выделить команду developer productivity, чтобы унифицировать подходы к разработке и напилить общих библиотек. Это может сработать, если проблема уже сформулирована, и решение понятно. Выделение команды для решения нечеткой проблемы может привести к бюрократизации без какого-либо результата.
Какие проблемы реструктуризация НЕ решает:
Найм и увольнение — в компании зачастую есть люди, которых в ней быть не должно. Не поможет менять тайтлы и ворошить команды в попытках избежать трудного разговора с таким человеком.
Обучение — если у людей не хватает знаний или навыков, не поможет менять тайтлы. Бесполезно переименовывать команду оперирования в DevOps (да, я знаю, что это движение и культура, а не роль. Но кто публикует эти вакансии на linkedin?)
Мотивация — если департамент выгорает, из команд уходят люди, а в процессах полный хаос. Переименование ролей и команд в стиле “тот же хрен только в другой руке” ударит по этой области еще сильнее, показав слепоту руководства к насущным проблемам и породив разговоры в кулуарах о полезности данного действия.
Прежде чем проводить изменения организационной структуры, следует убедиться, что проблема именно в ней. Большая работа — сформулировать цели и спланировать изменения, которые позволят решить проблемы, не сильно добавив новых. А главное — до проведения изменений ответить на вопрос: “Как мы поймем, что новая структура работает?”
#менеджмент #рассуждения
Одна из причин, почему оценки не говорят о сроке завершения задачи
Оценивая задачу, мы пытаемся определить объем работы, необходимый для её завершения. Конечно точность оценки сильно зависит от уровня понимания системы, но, при определенных условиях, можно прикинуть, сколько времени потребуется на каждый из этапов: написать код, протестировать, подготовить релиз.
Однако, время на выполнение работы в рамках задачи — это только одна часть уравнения. Другой аспект зачастую упускается — время ожидания задачи между этапами работы: ожидание код-ревью, ожидание тестирования, ожидание в ветке до релиза.
Время ожидания в очередях не берется в расчёт при оценке, хотя именно оно и составляет существенную часть от общего времени выполнения. Полезная метрика эффективности процесса — отношение времени активной работы (когда кто-то реально что-то делает по задаче) ко времени цикла (фактическое время от старта работы до завершения).
Если логически разделить статусы в JIRA на те, где реально делается работа, и те, в которых задача просто ждёт, то посчитать это метрику будет несложно. А вот результат многих удивляет — хорошо, если это соотношение будет 0.5 (а может быть и меньше). Это значит, что, давая оценку, мы принимаем во внимание только 50% от реального времени и на основании этого пытаемся строим планы!
Хотите улучшить ваши оценки? Посмотрите, где скапливаются очереди задач, ожидающих следующего этапа разработки. До тех пор пока ожидание в очередях составляет существенную часть от времени цикла, работать над улучшением точности оценок бесполезно. А вот чтобы увеличить долю эффективного времени, следует переосмыслить сложившиеся процессы, сбалансировать загрузку людей, обеспечить доступность необходимых ресурсов и вот это вот всё, подразумеваемое под словом “менеджмент”.
#менеджмент #инструменты #оценимнеэтотскоуп
Оценивая задачу, мы пытаемся определить объем работы, необходимый для её завершения. Конечно точность оценки сильно зависит от уровня понимания системы, но, при определенных условиях, можно прикинуть, сколько времени потребуется на каждый из этапов: написать код, протестировать, подготовить релиз.
Однако, время на выполнение работы в рамках задачи — это только одна часть уравнения. Другой аспект зачастую упускается — время ожидания задачи между этапами работы: ожидание код-ревью, ожидание тестирования, ожидание в ветке до релиза.
Время ожидания в очередях не берется в расчёт при оценке, хотя именно оно и составляет существенную часть от общего времени выполнения. Полезная метрика эффективности процесса — отношение времени активной работы (когда кто-то реально что-то делает по задаче) ко времени цикла (фактическое время от старта работы до завершения).
Если логически разделить статусы в JIRA на те, где реально делается работа, и те, в которых задача просто ждёт, то посчитать это метрику будет несложно. А вот результат многих удивляет — хорошо, если это соотношение будет 0.5 (а может быть и меньше). Это значит, что, давая оценку, мы принимаем во внимание только 50% от реального времени и на основании этого пытаемся строим планы!
Хотите улучшить ваши оценки? Посмотрите, где скапливаются очереди задач, ожидающих следующего этапа разработки. До тех пор пока ожидание в очередях составляет существенную часть от времени цикла, работать над улучшением точности оценок бесполезно. А вот чтобы увеличить долю эффективного времени, следует переосмыслить сложившиеся процессы, сбалансировать загрузку людей, обеспечить доступность необходимых ресурсов и вот это вот всё, подразумеваемое под словом “менеджмент”.
#менеджмент #инструменты #оценимнеэтотскоуп
Важные мелочи: общие чаты
Иногда замечаю, как совершенно небольшие вещи приводят к большим трудностям.
Ну например, случилось такое, что требуется узнать что-то у команды, с которой ты активно не работаешь и никого там не знаешь. А куда писать? Кто там, в этой команде? Как про них узнать? Зачастую это приводит к появлению отдельных чатиков по каждому вопросу, ответы теряются в личных сообщениях, вопросы повторяются. Если подходящий контакт найти не удаётся, то начинается эскалация через менеджеров всех уровней. А теперь представьте неэффективность при масштабе в сотню команд...
Хорошо, когда на возникшую потребность, в компании есть готовый ответ, как это сделать. В случае с коммуникацией — например, открытый канал “название_команды_public” в slack/teams/чтоугодно. Хорошо, когда это не какое-то эзотерическое правило или креатив каждой отдельной команды, а понятный паттерн, зная который, любой человек в компании может его применить к любой команде. В идеале, зная какой-то факт (например, название команды), можно вывести необходимую информацию: например, название команды является тегом, которым помечены все репозитории команды в gitlab, все дашборды в grafana и так далее.
#важныемелочи #менеджмент
Иногда замечаю, как совершенно небольшие вещи приводят к большим трудностям.
Ну например, случилось такое, что требуется узнать что-то у команды, с которой ты активно не работаешь и никого там не знаешь. А куда писать? Кто там, в этой команде? Как про них узнать? Зачастую это приводит к появлению отдельных чатиков по каждому вопросу, ответы теряются в личных сообщениях, вопросы повторяются. Если подходящий контакт найти не удаётся, то начинается эскалация через менеджеров всех уровней. А теперь представьте неэффективность при масштабе в сотню команд...
Хорошо, когда на возникшую потребность, в компании есть готовый ответ, как это сделать. В случае с коммуникацией — например, открытый канал “название_команды_public” в slack/teams/чтоугодно. Хорошо, когда это не какое-то эзотерическое правило или креатив каждой отдельной команды, а понятный паттерн, зная который, любой человек в компании может его применить к любой команде. В идеале, зная какой-то факт (например, название команды), можно вывести необходимую информацию: например, название команды является тегом, которым помечены все репозитории команды в gitlab, все дашборды в grafana и так далее.
#важныемелочи #менеджмент
Архитектурные группы — бюрократия или полезный инструмент?
Такие группы образуются когда сложность проекта растет и появляется потребность в согласованности технических решений между несколькими командами. Название может отличаться от компании к компании – SAG (Solution Architects Group), Architecture Review Board. Суть остается прежней — группа технически грамотных людей, присматривающих за общей архитектурой. Такая группа может быть как основным драйвером трансформации, так и бесполезным уровнем бюрократии — всё зависит от того, как она организована и управляется. Далее я рассмотрю несколько анти-паттернов, которые доводилось встречать, а затем поделюсь своим опытом организации такой группы.
Союз ветеранов. Группу составляют старожилы компании, которые стояли у истоков системы. Само по себе это не плохо. Однако опасно, когда технический кругозор группы слегка отстает от текущих реалий. На дворе 2020, а про public cloud и Kubernetes не слышали. Такая группа будет излишне консервативной, инновации будет трудно продвигать (‘not invented here’), а у тех, кто будет взаимодействовать с этой группой, будет знатно “подгорать”.
Карьерный лифт. Архитектурные группы зачастую взаимодействуют с CTO или руководителем департамента — легко примелькаться и получить повышение/коэффициент к бонусу. Далеко не всегда, но всё же бывает, что люди идут в такие группы исключительно с целью удовлетворения карьерных амбиций.
Дискуссионный клуб “Пикейные жилеты”. Группа регулярно встречается, обсуждает глобальные проблемы, но не производит ничего наружу. Извне также непонятно, почему одни проблемы обсуждаются, а другие игнорируются.
Как избежать подобных исходов?
Обозначить цели и результаты
Чтобы не скатиться в дискуссионный клуб, следует проговорить, что считается хорошим результатом работы группы. Например: роадмап технических инициатив с зависимостями между командами, план итераций архитектурных изменений.
Набирать людей по компетентности
Составить список того, что нужно знать и уметь, чтобы попасть в группу. Так как список компетенций может быть трудно формализовать, взамен, можно использовать социальную валидацию: руководитель претендента и три человека не из его команды (число зависит от размера компании) считают, что этот человек будет полезен группе.
Согласовать баланс загрузки
Люди, которые входят в архитектурную группу, заняты на других проектах. Как вариант, договориться между руководителями, что один день в неделю (например четверг) сотрудник на полный день занят работой в технической группе. Если мы хотим решать общие проблемы, для этого должно быть время в календаре.
Ограничить членство по времени
Например, членство в архитектурной группе длится 6 месяцев. По истечении срока можно податься на продление на общих правилах. Стоит также собирать обратную связь от других членов группы на протяжении цикла. Это позволит отфильтровывать неактивных людей и обеспечит здоровую ротацию.
Любая организация людей требует комплексного подхода и выстраивания здоровых процессов. Если командам нужны руководители, то почему такие группы зачастую собраны по принципу “организуйтесь как-нибудь”?
#менеджмент #инструменты
Такие группы образуются когда сложность проекта растет и появляется потребность в согласованности технических решений между несколькими командами. Название может отличаться от компании к компании – SAG (Solution Architects Group), Architecture Review Board. Суть остается прежней — группа технически грамотных людей, присматривающих за общей архитектурой. Такая группа может быть как основным драйвером трансформации, так и бесполезным уровнем бюрократии — всё зависит от того, как она организована и управляется. Далее я рассмотрю несколько анти-паттернов, которые доводилось встречать, а затем поделюсь своим опытом организации такой группы.
Союз ветеранов. Группу составляют старожилы компании, которые стояли у истоков системы. Само по себе это не плохо. Однако опасно, когда технический кругозор группы слегка отстает от текущих реалий. На дворе 2020, а про public cloud и Kubernetes не слышали. Такая группа будет излишне консервативной, инновации будет трудно продвигать (‘not invented here’), а у тех, кто будет взаимодействовать с этой группой, будет знатно “подгорать”.
Карьерный лифт. Архитектурные группы зачастую взаимодействуют с CTO или руководителем департамента — легко примелькаться и получить повышение/коэффициент к бонусу. Далеко не всегда, но всё же бывает, что люди идут в такие группы исключительно с целью удовлетворения карьерных амбиций.
Дискуссионный клуб “Пикейные жилеты”. Группа регулярно встречается, обсуждает глобальные проблемы, но не производит ничего наружу. Извне также непонятно, почему одни проблемы обсуждаются, а другие игнорируются.
Как избежать подобных исходов?
Обозначить цели и результаты
Чтобы не скатиться в дискуссионный клуб, следует проговорить, что считается хорошим результатом работы группы. Например: роадмап технических инициатив с зависимостями между командами, план итераций архитектурных изменений.
Набирать людей по компетентности
Составить список того, что нужно знать и уметь, чтобы попасть в группу. Так как список компетенций может быть трудно формализовать, взамен, можно использовать социальную валидацию: руководитель претендента и три человека не из его команды (число зависит от размера компании) считают, что этот человек будет полезен группе.
Согласовать баланс загрузки
Люди, которые входят в архитектурную группу, заняты на других проектах. Как вариант, договориться между руководителями, что один день в неделю (например четверг) сотрудник на полный день занят работой в технической группе. Если мы хотим решать общие проблемы, для этого должно быть время в календаре.
Ограничить членство по времени
Например, членство в архитектурной группе длится 6 месяцев. По истечении срока можно податься на продление на общих правилах. Стоит также собирать обратную связь от других членов группы на протяжении цикла. Это позволит отфильтровывать неактивных людей и обеспечит здоровую ротацию.
Любая организация людей требует комплексного подхода и выстраивания здоровых процессов. Если командам нужны руководители, то почему такие группы зачастую собраны по принципу “организуйтесь как-нибудь”?
#менеджмент #инструменты
“В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности” — принцип Питера.
Как “принцип Питера” реализуется в больших компаниях.
Есть множество ролей, зоны ответственности которых трудно сформулировать: продакт-менеджеры, архитекторы, лиды команд. Нечетко определенная граница, приводит к ситуации, что карьерный путь к такой роли не очевиден, и на подобную позицию попадают люди с совершенно разным опытом и набором навыков.
Как может происходить процесс повышения в вымышленной компании: человек хорошо делает работу на своей текущей позиции, его замечают и повышают. Разработчик тащит фичу, старается найти компромиссы с продакт-менеджером, вкладывается в тестирование. Отличный работник! – Давайте сделаем его лидом команды!
И вот тут пропущен один важный шаг — подумать. А точно ли повышение — это уместная награда в данной ситуации? Если да, то какие функции в компании закрывает лид команды? Какие навыки ему для этого необходимы? Соответствует ли им претендент? Про это я уже писал вот тут: Leadership pipeline
В итоге человек повышается в роль без конкретных ожиданий от него, а заодно получает позитивное подкрепление: “я делал то, что я делал, за это меня повысили, значит я делаю свою работу хорошо”.
В масштабах небольшой компании такой подход не создает проблем — всё и так держиться на личных связях, и не важно, кто какую должность занимает. В большой же компании это приводит к полной реализации принципа Питера
Если многократно повторить процесс, описанный выше, то мы оказываемся в ситуации, что руководитель (его так же когда-то давно повысили за то, что он делал хорошо свою прошлую работу) не имеет четких ожиданий от роли, в которую повысили героя истории (который считает, что делает всё правильно, его же повысили). Так и получаются, что в компании все делают что-то “важное”, на местах всё выглядит прилично, а в масштабе компании получается цирк с конями и бюрократией. В итоге имеем: продакт-менеджеров, которые умеют только заводить митинги и клепать презентации; архитекторов, мастерски рисующих диаграммы, совершенно не знающих нужд стейкхолдеров; руководителей, которые умеют поддерживать текущую рутину, но не ведут команду к какой-то цели.
Повышать за былые заслуги — это, на мой взгляд, такое себе решение. За успехи в прошлом есть бонусы и премии, повышение же — это про реализацию потенциала человека в организации, и количество критериев, которые следует принимать во внимание, гораздо больше.
#ошибкименеджера #карьерныйпуть #менеджмент
Как “принцип Питера” реализуется в больших компаниях.
Есть множество ролей, зоны ответственности которых трудно сформулировать: продакт-менеджеры, архитекторы, лиды команд. Нечетко определенная граница, приводит к ситуации, что карьерный путь к такой роли не очевиден, и на подобную позицию попадают люди с совершенно разным опытом и набором навыков.
Как может происходить процесс повышения в вымышленной компании: человек хорошо делает работу на своей текущей позиции, его замечают и повышают. Разработчик тащит фичу, старается найти компромиссы с продакт-менеджером, вкладывается в тестирование. Отличный работник! – Давайте сделаем его лидом команды!
И вот тут пропущен один важный шаг — подумать. А точно ли повышение — это уместная награда в данной ситуации? Если да, то какие функции в компании закрывает лид команды? Какие навыки ему для этого необходимы? Соответствует ли им претендент? Про это я уже писал вот тут: Leadership pipeline
В итоге человек повышается в роль без конкретных ожиданий от него, а заодно получает позитивное подкрепление: “я делал то, что я делал, за это меня повысили, значит я делаю свою работу хорошо”.
В масштабах небольшой компании такой подход не создает проблем — всё и так держиться на личных связях, и не важно, кто какую должность занимает. В большой же компании это приводит к полной реализации принципа Питера
Если многократно повторить процесс, описанный выше, то мы оказываемся в ситуации, что руководитель (его так же когда-то давно повысили за то, что он делал хорошо свою прошлую работу) не имеет четких ожиданий от роли, в которую повысили героя истории (который считает, что делает всё правильно, его же повысили). Так и получаются, что в компании все делают что-то “важное”, на местах всё выглядит прилично, а в масштабе компании получается цирк с конями и бюрократией. В итоге имеем: продакт-менеджеров, которые умеют только заводить митинги и клепать презентации; архитекторов, мастерски рисующих диаграммы, совершенно не знающих нужд стейкхолдеров; руководителей, которые умеют поддерживать текущую рутину, но не ведут команду к какой-то цели.
Повышать за былые заслуги — это, на мой взгляд, такое себе решение. За успехи в прошлом есть бонусы и премии, повышение же — это про реализацию потенциала человека в организации, и количество критериев, которые следует принимать во внимание, гораздо больше.
#ошибкименеджера #карьерныйпуть #менеджмент
Вера в причины успеха
В компаниях, которые существуют давно и стали успешными, есть такой эффект – сотрудники (особенно стоявшие у истоков) объясняют успех компании именно своими действиями. “Мы писали на Java, и поэтому все получилось!”, “У нас была классная идея, и поэтому мы успешны”, “У нас талантливые сотрудники, и поэтому мы всего достигли”.
Такой же эффект проявляется на индивидуальном уровне: “Я уже 5 лет менеджу команды, делаю это хорошо, и по этому, я хороший менеджер!” (за “делаю это хорошо” как правило не стоит четких критериев).
На эту тему у меня есть история.
В 1956 году вышла книга-исследование Леона Фестингера “When Prophecy Fails” (“Когда пророчество не сбылось”, но перевода на русский кажется нет). В этом исследовании группа ученых наблюдала за религиозной сектой. Члены секты верили в то, что наступит конец света, мир затопит, а их, “истинно” верующих, заберут инопланетяне и отвезут в рай. Короче, стандартный бред про инопланетян и конец света, сюжет для провинциальной телепередачи.
Отличительной чертой данной религиозной организации было то, что её лидер называла конкретную дату, когда должен был случиться конец света: 21 декабря 1954 года. Исследователи задались вопросом – “Как поведут себя члены секты, когда наступит указанный день, а конца света не случится?”. Ожидалось, что члены секты, конечно, будут страдать от сломавшейся картины мира, но все же примут правду – конца света не случилось, НЛО не прилетел, мы были неправы.
Что же произошло на самом деле?
Разумеется, конца света не случилось, инопланетяне тоже не прилетели. Как же повели себя члены секты? Разошлись по домам? Ничего подобного! Ребята быстро “переобулись” и заявили: “Мы за всех молились, и поэтому конец света не случился! Мы всех спасли!”
В чем мораль истории? Если человек или группа людей во что-то верит, многим пожертвовали ради этого, они будут защищать свое убеждение всеми силами. Ни логика, ни здравый смысл не изменят убеждений. Не получится изменить убеждение одним днём.
Как с этим жить? На уровне организации, просто помнить, что требуется время, чтобы привыкнуть к новым вещам, если они конфликтуют с текущей картиной мира. Так что изменения, даже простые, требуют времени (например: “а давайте начнем писать тесты на свой код”).
На индивидуальном же уровне, важно самому уметь выходить из ловушки прошлого “успешного” опыта и задаваться вопросами: “А не фигню ли я делаю?”, “На основании чего я уверен, что действие Х приведет к результату У?”.
#рассуждения #менеджмент
В компаниях, которые существуют давно и стали успешными, есть такой эффект – сотрудники (особенно стоявшие у истоков) объясняют успех компании именно своими действиями. “Мы писали на Java, и поэтому все получилось!”, “У нас была классная идея, и поэтому мы успешны”, “У нас талантливые сотрудники, и поэтому мы всего достигли”.
Такой же эффект проявляется на индивидуальном уровне: “Я уже 5 лет менеджу команды, делаю это хорошо, и по этому, я хороший менеджер!” (за “делаю это хорошо” как правило не стоит четких критериев).
На эту тему у меня есть история.
В 1956 году вышла книга-исследование Леона Фестингера “When Prophecy Fails” (“Когда пророчество не сбылось”, но перевода на русский кажется нет). В этом исследовании группа ученых наблюдала за религиозной сектой. Члены секты верили в то, что наступит конец света, мир затопит, а их, “истинно” верующих, заберут инопланетяне и отвезут в рай. Короче, стандартный бред про инопланетян и конец света, сюжет для провинциальной телепередачи.
Отличительной чертой данной религиозной организации было то, что её лидер называла конкретную дату, когда должен был случиться конец света: 21 декабря 1954 года. Исследователи задались вопросом – “Как поведут себя члены секты, когда наступит указанный день, а конца света не случится?”. Ожидалось, что члены секты, конечно, будут страдать от сломавшейся картины мира, но все же примут правду – конца света не случилось, НЛО не прилетел, мы были неправы.
Что же произошло на самом деле?
Разумеется, конца света не случилось, инопланетяне тоже не прилетели. Как же повели себя члены секты? Разошлись по домам? Ничего подобного! Ребята быстро “переобулись” и заявили: “Мы за всех молились, и поэтому конец света не случился! Мы всех спасли!”
В чем мораль истории? Если человек или группа людей во что-то верит, многим пожертвовали ради этого, они будут защищать свое убеждение всеми силами. Ни логика, ни здравый смысл не изменят убеждений. Не получится изменить убеждение одним днём.
Как с этим жить? На уровне организации, просто помнить, что требуется время, чтобы привыкнуть к новым вещам, если они конфликтуют с текущей картиной мира. Так что изменения, даже простые, требуют времени (например: “а давайте начнем писать тесты на свой код”).
На индивидуальном же уровне, важно самому уметь выходить из ловушки прошлого “успешного” опыта и задаваться вопросами: “А не фигню ли я делаю?”, “На основании чего я уверен, что действие Х приведет к результату У?”.
#рассуждения #менеджмент
Patterns of Effective Teams
Познавательный доклад про то, какие паттерны можно использовать для повышения эффективности работ инженерных команд.
Несколько пунктов из доклада, которые мне откликнулись
* Продуктивность != эффективность.
Продуктивность - делать больше за единицу времени. Эффективность -- отношение результата к затраченному времени. Одна фича, решившая проблему, лучше, чем 10 бесполезных. Эти два понятия связаны, но не всегда там присутствует причинно-следственная связь.
* Дрейфусовская модель приобретения навыков - хороший инструмент для того, чтобы сформулировать план обучения, как для себя так и для всей команды
* Inverse Bus Factor - сколько людей надо выгнать из комнаты, чтоб работа была сделана 🙂
* Code Critique Pattern - хорошая практика, проводить ревью публично с пояснениями от создателя. Позволяет выстроить общий понятийный аппарат, а также найти оптимальное решение в сложных задачах, потому что
экспертиза, как бы мы ни хотели сконцентрирована в головах неравномерно 🙂
В выводе затронута общая проблема - иногда мы превращаем правильные активности в ритуалы, целью которых становится проведения ритуала по правилам, а не решения насущных проблем.
Перед тем, как вы проводите очередной stand-up, или ретроспективу, или любой другой митинг запишите на доске, чтоб все видели, какой цели вы хотите достигнуть к концу этой встречи.
#менеджмент #карьерныйпуть #инструменты
Познавательный доклад про то, какие паттерны можно использовать для повышения эффективности работ инженерных команд.
Несколько пунктов из доклада, которые мне откликнулись
* Продуктивность != эффективность.
Продуктивность - делать больше за единицу времени. Эффективность -- отношение результата к затраченному времени. Одна фича, решившая проблему, лучше, чем 10 бесполезных. Эти два понятия связаны, но не всегда там присутствует причинно-следственная связь.
* Дрейфусовская модель приобретения навыков - хороший инструмент для того, чтобы сформулировать план обучения, как для себя так и для всей команды
* Inverse Bus Factor - сколько людей надо выгнать из комнаты, чтоб работа была сделана 🙂
* Code Critique Pattern - хорошая практика, проводить ревью публично с пояснениями от создателя. Позволяет выстроить общий понятийный аппарат, а также найти оптимальное решение в сложных задачах, потому что
экспертиза, как бы мы ни хотели сконцентрирована в головах неравномерно 🙂
В выводе затронута общая проблема - иногда мы превращаем правильные активности в ритуалы, целью которых становится проведения ритуала по правилам, а не решения насущных проблем.
Перед тем, как вы проводите очередной stand-up, или ретроспективу, или любой другой митинг запишите на доске, чтоб все видели, какой цели вы хотите достигнуть к концу этой встречи.
#менеджмент #карьерныйпуть #инструменты
YouTube
Patterns of Effective Teams • Dan North • GOTO 2017
This presentation was recorded at GOTO Chicago 2017. #GOTOcon #GOTOchgo
http://gotochgo.com
Dan North - Originator of Behavior Driven Development (BDD) & Principal Consultant @daniel-terhorst-north
ABSTRACT
Some teams are orders of magnitude more effective…
http://gotochgo.com
Dan North - Originator of Behavior Driven Development (BDD) & Principal Consultant @daniel-terhorst-north
ABSTRACT
Some teams are orders of magnitude more effective…