Метрики команд. Качество
Прежде чем браться измерять качество, следует договориться о том, что мы включаем в это понятие. Очевидно, что когда очередной релиз разваливает продакшен, это проблема качества. При всей сложности функционального тестирования — это наиболее измеримый и понятный аспект качества. Количество неудачных релизов или пост-релизных дефектов вполне себе метрика. Разумеется, нужно оценивать совместно — общее количество релизов в единицу времени и долю неудачных — чтобы понимать, что команда производит, фичи или инциденты?
Это релевантно даже на той стадии разработки, когда речь еще не идет о публичном релизе. Если не уметь выкладывать изменения сервиса без пользователей, то с реальными пользователями будет только хуже.
Сложнее становится с нефункциональными требованиями, так как их часто упускают во время разработки. Приведу пример: если страница загружается за 3 секунды, это нормально или нет? За 5? А за 10? В конечном итоге это тоже становится вопросом качества, лучше раньше чем позже. Тут важно сформулировать заранее, что критично, зафиксировать атрибуты качества и определить Service Level Objectives (SLO). Собирать метрики и настроить алёрты — не проблема. Проблема — договориться о том, как на них реагировать. Особенно остро это проявляется в фазе активной разработки до публичного релиза: надо фичи делать, некогда думать о производительности, времени ответа и потреблении ресурсов. А потом всплывает: “Почему так медленно работает?”, “Почему так дорого за железо/облако платим?”. Про то, как выстроить цикл обратной связи для тестирования нефункциональных требований во время активной разработки, есть целая книжка — “Building Evolutionary Architectures”.
В итоге, очевидная метрика — процент неудачных релизов — имеет небольшой нюанс: что считать неудачным релизом, а что пост-продакшен дефектом? Ответ сильно зависит от качества мониторинга и скорости обнаружения ошибок в системе. Пожалуй, для нефункциональных требований, обязательная метрика — время ответа сервиса. Остальное определяется спецификой проекта.
#метрики
Прежде чем браться измерять качество, следует договориться о том, что мы включаем в это понятие. Очевидно, что когда очередной релиз разваливает продакшен, это проблема качества. При всей сложности функционального тестирования — это наиболее измеримый и понятный аспект качества. Количество неудачных релизов или пост-релизных дефектов вполне себе метрика. Разумеется, нужно оценивать совместно — общее количество релизов в единицу времени и долю неудачных — чтобы понимать, что команда производит, фичи или инциденты?
Это релевантно даже на той стадии разработки, когда речь еще не идет о публичном релизе. Если не уметь выкладывать изменения сервиса без пользователей, то с реальными пользователями будет только хуже.
Сложнее становится с нефункциональными требованиями, так как их часто упускают во время разработки. Приведу пример: если страница загружается за 3 секунды, это нормально или нет? За 5? А за 10? В конечном итоге это тоже становится вопросом качества, лучше раньше чем позже. Тут важно сформулировать заранее, что критично, зафиксировать атрибуты качества и определить Service Level Objectives (SLO). Собирать метрики и настроить алёрты — не проблема. Проблема — договориться о том, как на них реагировать. Особенно остро это проявляется в фазе активной разработки до публичного релиза: надо фичи делать, некогда думать о производительности, времени ответа и потреблении ресурсов. А потом всплывает: “Почему так медленно работает?”, “Почему так дорого за железо/облако платим?”. Про то, как выстроить цикл обратной связи для тестирования нефункциональных требований во время активной разработки, есть целая книжка — “Building Evolutionary Architectures”.
В итоге, очевидная метрика — процент неудачных релизов — имеет небольшой нюанс: что считать неудачным релизом, а что пост-продакшен дефектом? Ответ сильно зависит от качества мониторинга и скорости обнаружения ошибок в системе. Пожалуй, для нефункциональных требований, обязательная метрика — время ответа сервиса. Остальное определяется спецификой проекта.
#метрики
Какие проблемы решает реорганизация?
Я видел довольно много реорганизаций в компаниях: перегруппировать команды, добавить слой мидл-менеджмента, поменять зоны ответственности и т.д. Некоторые из них имели смысл и были совершенно оправданны, некоторые скорее походили на “преставление кроватей” из анекдота, который я постеснялся вставить в качестве эпиграфа.
Примеры проблем, которые решаются реорганизацией:
Упростить процесс принятия решений
Лицо, принимающее решения, находится далеко в иерархии от команд, где известен контекст и информация, необходимая для решения. Такая структура приводит к появлению очереди из вещей, ожидающих согласования, новые инициативы стартуют медленно, а технически небольшое изменение может выродиться в месяц согласований. Вестником такого рода организационной неэффективности являются профессиональные изготовители слайдов для внутренних презентаций. У высоких менеджеров времени мало, контекста не хватает, а разобраться в проблеме хочется, вот и начинается показ презентаций с ожиданием решения.
Другой пример — управление бюджетами: тимбилдинг организовать, специальное оборудование закупить, на конференцию людей отправить (бывает, что цепочка согласований занимает дольше, чем время от старта продажи билетов до начала самой конференции). Для решения этих проблем реорганизация — хороший инструмент.
Улучшить коммуникацию между командами
Например, одна команда предоставляет API, а другая его использует. Эти команды находятся в разных департаментах и не очень дружат между собой, а их общий руководитель — настолько высоко, что в случае эскалации проблемы, у него совершенно не хватает контекста, чтобы конструктивно её решить, и все заканчивается фразой: “Ребята, вы же профессионалы, договоритесь как-нибудь”. Подобные ситуации часто возникают в матричной структуре: дизайнеры репортят верховному дизайнеру, тот, в свою очередь, арт-директору, у разработчиков своя иерархия, у product-manager’ов своя. Вроде все одно дело делают, но у каждой дисциплины свои метрики эффективности и взгляд на то, как надо работать. Руководители оторваны от контекста, говорят на разных языках, и каждый оптимизируется под свои метрики. В итоге страдает общий результат, и ни одна из локальных оптимизаций не помогает. Проблема в системе.
Сфокусировать усилия
Выделить отдельную команду для решения проблемы, которую не получается решить частичными усилиями. Например, выделить команду developer productivity, чтобы унифицировать подходы к разработке и напилить общих библиотек. Это может сработать, если проблема уже сформулирована, и решение понятно. Выделение команды для решения нечеткой проблемы может привести к бюрократизации без какого-либо результата.
Какие проблемы реструктуризация НЕ решает:
Найм и увольнение — в компании зачастую есть люди, которых в ней быть не должно. Не поможет менять тайтлы и ворошить команды в попытках избежать трудного разговора с таким человеком.
Обучение — если у людей не хватает знаний или навыков, не поможет менять тайтлы. Бесполезно переименовывать команду оперирования в DevOps (да, я знаю, что это движение и культура, а не роль. Но кто публикует эти вакансии на linkedin?)
Мотивация — если департамент выгорает, из команд уходят люди, а в процессах полный хаос. Переименование ролей и команд в стиле “тот же хрен только в другой руке” ударит по этой области еще сильнее, показав слепоту руководства к насущным проблемам и породив разговоры в кулуарах о полезности данного действия.
Прежде чем проводить изменения организационной структуры, следует убедиться, что проблема именно в ней. Большая работа — сформулировать цели и спланировать изменения, которые позволят решить проблемы, не сильно добавив новых. А главное — до проведения изменений ответить на вопрос: “Как мы поймем, что новая структура работает?”
#менеджмент #рассуждения
Я видел довольно много реорганизаций в компаниях: перегруппировать команды, добавить слой мидл-менеджмента, поменять зоны ответственности и т.д. Некоторые из них имели смысл и были совершенно оправданны, некоторые скорее походили на “преставление кроватей” из анекдота, который я постеснялся вставить в качестве эпиграфа.
Примеры проблем, которые решаются реорганизацией:
Упростить процесс принятия решений
Лицо, принимающее решения, находится далеко в иерархии от команд, где известен контекст и информация, необходимая для решения. Такая структура приводит к появлению очереди из вещей, ожидающих согласования, новые инициативы стартуют медленно, а технически небольшое изменение может выродиться в месяц согласований. Вестником такого рода организационной неэффективности являются профессиональные изготовители слайдов для внутренних презентаций. У высоких менеджеров времени мало, контекста не хватает, а разобраться в проблеме хочется, вот и начинается показ презентаций с ожиданием решения.
Другой пример — управление бюджетами: тимбилдинг организовать, специальное оборудование закупить, на конференцию людей отправить (бывает, что цепочка согласований занимает дольше, чем время от старта продажи билетов до начала самой конференции). Для решения этих проблем реорганизация — хороший инструмент.
Улучшить коммуникацию между командами
Например, одна команда предоставляет API, а другая его использует. Эти команды находятся в разных департаментах и не очень дружат между собой, а их общий руководитель — настолько высоко, что в случае эскалации проблемы, у него совершенно не хватает контекста, чтобы конструктивно её решить, и все заканчивается фразой: “Ребята, вы же профессионалы, договоритесь как-нибудь”. Подобные ситуации часто возникают в матричной структуре: дизайнеры репортят верховному дизайнеру, тот, в свою очередь, арт-директору, у разработчиков своя иерархия, у product-manager’ов своя. Вроде все одно дело делают, но у каждой дисциплины свои метрики эффективности и взгляд на то, как надо работать. Руководители оторваны от контекста, говорят на разных языках, и каждый оптимизируется под свои метрики. В итоге страдает общий результат, и ни одна из локальных оптимизаций не помогает. Проблема в системе.
Сфокусировать усилия
Выделить отдельную команду для решения проблемы, которую не получается решить частичными усилиями. Например, выделить команду developer productivity, чтобы унифицировать подходы к разработке и напилить общих библиотек. Это может сработать, если проблема уже сформулирована, и решение понятно. Выделение команды для решения нечеткой проблемы может привести к бюрократизации без какого-либо результата.
Какие проблемы реструктуризация НЕ решает:
Найм и увольнение — в компании зачастую есть люди, которых в ней быть не должно. Не поможет менять тайтлы и ворошить команды в попытках избежать трудного разговора с таким человеком.
Обучение — если у людей не хватает знаний или навыков, не поможет менять тайтлы. Бесполезно переименовывать команду оперирования в DevOps (да, я знаю, что это движение и культура, а не роль. Но кто публикует эти вакансии на linkedin?)
Мотивация — если департамент выгорает, из команд уходят люди, а в процессах полный хаос. Переименование ролей и команд в стиле “тот же хрен только в другой руке” ударит по этой области еще сильнее, показав слепоту руководства к насущным проблемам и породив разговоры в кулуарах о полезности данного действия.
Прежде чем проводить изменения организационной структуры, следует убедиться, что проблема именно в ней. Большая работа — сформулировать цели и спланировать изменения, которые позволят решить проблемы, не сильно добавив новых. А главное — до проведения изменений ответить на вопрос: “Как мы поймем, что новая структура работает?”
#менеджмент #рассуждения
Для чего нужна оценка задач?
Оцениванием задач, пожалуй, занимались все; не знаю, существуют ли компании, где не принято оценивать задачи. А зачем мы это делаем? В чем вообще смысл оценивания чего-либо?
На мой взгляд, оценки нужны только в одном случае — когда нет возможности получить реальное значение показателя в тот момент, когда это требуется для принятия решения. Тогда мы заменяем реальное значение оценкой. Приведу пример: планирование бюджета на железо/облако.
Определенно нет возможности узнать точное значение, т.к. платить за него мы будем в будущем. Однако, на основании динамики роста трафика, количества свободных ресурсов, планируемых к запуску проектов, мы можем сделать допущение о том, сколько требуется заложить в бюджет. В данном примере существует конкретное решение, для принятия которого и проводится оценка, — размер бюджета на железо.
Важный момент — наличие решения, которое зависит от результатов оценки. В противном случае, оценивание превращается в ритуал, исполняемый без цели.
Какие решения будут приниматься на основании оценки сроков завершения задач? Есть несколько стереотипных ответов:
Понимать стоимость фичей — возможно это релевантно в заказной разработке, у меня нет опыта в этой области. Однако в продуктовых компаниях затраты на разработку, в основном, постоянные — независимо от количества фичей, все получают зарплату.
Решение о приоритетах задач — те задачи, которые имеют максимальное соотношение ценности ко времени на разработку, должны делаться в первую очередь. Это называется WSJF – Weighted Shortest Job First. Только, чтобы эта штука работала, надо уметь считать ценность задач. Иначе мы делим что-то неизвестное на что-то неточное — в итоге решения о приоритетах принимаются совсем по другим критериям.
Планирование ресурсов – надо назначить людей на проекты, чтобы распараллелить работу. Вообще, 100%-я утилизация — это очень плохо, но об этом как-нибудь потом. В этой ситуации возникает вопрос точности оценок — а её, скорее всего, будет недостаточно, чтобы планировать загрузку по людям. Это может привести к “эффекту домино”: сдвиг одного элемента по срокам повлечёт за собой череду дальнейших изменений.
Еще два плохих варианта использования оценок в организации:
Создать ложный эффект контроля, чтобы не управлять рисками — когда у людей есть оценка, им, видимо, как-то спокойнее живется. Сказали большому менеджеру “Будет готово в 4-м квартале следующего года”, он и пропал до 4-го квартала. На самом деле, часто, получив оценку сроков, ключевые стейкхолдеры, вместо того, чтобы помогать своими ресурсами двигать проект к завершению, теряют к проекту интерес, как будто оценка гарантирует результат.
Инструмент давления на команду — “Вы же говорили, что это займет три недели; уже 2-е прошло, а еще и половины не сделано. Давайте успевайте, по выходным поработайте, например”. Любая дата или отрезок времени, обозначенный в оценке, легко трансформируется в обязательство. Даже в тех случаях, когда отклонение от этой оценки не влечёт никаких финансовых или репутационных потерь для компании.
Этот пункт обычно используется совместно с предыдущим: сначала, получив оценку, самоустраниться из проекта, затем в конце срока вернуться с претензиями.
Конечно есть вещи с жестким дедлайном — Новый год, черная пятница, проплаченная кампания с анонсированной датой старта... В таких случаях следует комплексно подходить к управлению проектом, а не полагаться на одни лишь оценки, чтобы успеть к назначенной дате.
Давая какие-либо оценки, очень важно понимать, какие решения будут приниматься на основании этих оценок. Что поменяется в планах, если оценка удвоится или утроится? Какие решения потребуется изменить, если реальность окажется совсем не такой, как её оценили? А главное помнить, что оценка не является гарантией исполнения в срок, это, скорее, прогноз; и более важен второй аспект — вероятность реализации этого прогноза.
#оценимнеэтотскоуп
Оцениванием задач, пожалуй, занимались все; не знаю, существуют ли компании, где не принято оценивать задачи. А зачем мы это делаем? В чем вообще смысл оценивания чего-либо?
На мой взгляд, оценки нужны только в одном случае — когда нет возможности получить реальное значение показателя в тот момент, когда это требуется для принятия решения. Тогда мы заменяем реальное значение оценкой. Приведу пример: планирование бюджета на железо/облако.
Определенно нет возможности узнать точное значение, т.к. платить за него мы будем в будущем. Однако, на основании динамики роста трафика, количества свободных ресурсов, планируемых к запуску проектов, мы можем сделать допущение о том, сколько требуется заложить в бюджет. В данном примере существует конкретное решение, для принятия которого и проводится оценка, — размер бюджета на железо.
Важный момент — наличие решения, которое зависит от результатов оценки. В противном случае, оценивание превращается в ритуал, исполняемый без цели.
Какие решения будут приниматься на основании оценки сроков завершения задач? Есть несколько стереотипных ответов:
Понимать стоимость фичей — возможно это релевантно в заказной разработке, у меня нет опыта в этой области. Однако в продуктовых компаниях затраты на разработку, в основном, постоянные — независимо от количества фичей, все получают зарплату.
Решение о приоритетах задач — те задачи, которые имеют максимальное соотношение ценности ко времени на разработку, должны делаться в первую очередь. Это называется WSJF – Weighted Shortest Job First. Только, чтобы эта штука работала, надо уметь считать ценность задач. Иначе мы делим что-то неизвестное на что-то неточное — в итоге решения о приоритетах принимаются совсем по другим критериям.
Планирование ресурсов – надо назначить людей на проекты, чтобы распараллелить работу. Вообще, 100%-я утилизация — это очень плохо, но об этом как-нибудь потом. В этой ситуации возникает вопрос точности оценок — а её, скорее всего, будет недостаточно, чтобы планировать загрузку по людям. Это может привести к “эффекту домино”: сдвиг одного элемента по срокам повлечёт за собой череду дальнейших изменений.
Еще два плохих варианта использования оценок в организации:
Создать ложный эффект контроля, чтобы не управлять рисками — когда у людей есть оценка, им, видимо, как-то спокойнее живется. Сказали большому менеджеру “Будет готово в 4-м квартале следующего года”, он и пропал до 4-го квартала. На самом деле, часто, получив оценку сроков, ключевые стейкхолдеры, вместо того, чтобы помогать своими ресурсами двигать проект к завершению, теряют к проекту интерес, как будто оценка гарантирует результат.
Инструмент давления на команду — “Вы же говорили, что это займет три недели; уже 2-е прошло, а еще и половины не сделано. Давайте успевайте, по выходным поработайте, например”. Любая дата или отрезок времени, обозначенный в оценке, легко трансформируется в обязательство. Даже в тех случаях, когда отклонение от этой оценки не влечёт никаких финансовых или репутационных потерь для компании.
Этот пункт обычно используется совместно с предыдущим: сначала, получив оценку, самоустраниться из проекта, затем в конце срока вернуться с претензиями.
Конечно есть вещи с жестким дедлайном — Новый год, черная пятница, проплаченная кампания с анонсированной датой старта... В таких случаях следует комплексно подходить к управлению проектом, а не полагаться на одни лишь оценки, чтобы успеть к назначенной дате.
Давая какие-либо оценки, очень важно понимать, какие решения будут приниматься на основании этих оценок. Что поменяется в планах, если оценка удвоится или утроится? Какие решения потребуется изменить, если реальность окажется совсем не такой, как её оценили? А главное помнить, что оценка не является гарантией исполнения в срок, это, скорее, прогноз; и более важен второй аспект — вероятность реализации этого прогноза.
#оценимнеэтотскоуп
Ward Cunningham, соавтор подхода Extreme Programming, рассказывает про аналогию, из которой впоследствии появился термин technical debt. Сейчас техническим долгом зачастую называют то, что на деле является непрофессионализмом: пренебрежение базовыми практиками (например, тестами), код в спагетти-стиле и беспечный подход к разработке, который может обернуться существенными рисками для компании.
Ключевая идея в работе над устранением технического долга — отражать в структуре приложения знания, накопленные в процессе разработки. Приложение следует воспринимать не просто как набор фичей, а еще и как модель предметной области. Степень адекватности модели напрямую влияет на скорость добавления новой функциональности. Оперируя неадекватной моделью предметной области, мы вынуждены выплачивать некоторый процент, выражающийся во времени разработки.
Видео на 4 минуты. Ссылка: https://youtu.be/pqeJFYwnkjE
#видеопотеме
Ключевая идея в работе над устранением технического долга — отражать в структуре приложения знания, накопленные в процессе разработки. Приложение следует воспринимать не просто как набор фичей, а еще и как модель предметной области. Степень адекватности модели напрямую влияет на скорость добавления новой функциональности. Оперируя неадекватной моделью предметной области, мы вынуждены выплачивать некоторый процент, выражающийся во времени разработки.
Видео на 4 минуты. Ссылка: https://youtu.be/pqeJFYwnkjE
#видеопотеме
YouTube
Debt Metaphor
Ward Cunningham reflects on the history, motivation and common misunderstanding of the "debt metaphor" as motivation for refactoring.
Фундаментальная ошибка планирования и немного философии
Основная проблема планирования — после того, как мы дали оценку, мы начинаем в неё верить.
Мы отчего-то уверены, что оценка это тот стандарт, к которому следует стремиться.
В ситуации, когда проект не укладывается в изначальную оценку, мы начинаем предпринимать действия, чтобы вернуть проект к намеченному плану: докинуть людей, порезать скоуп, выписать премий за овератаймы по выходным.
Вот только остается неотвеченным вопрос: На основании чего мы уверены, что вернуть проект к планируемому расписанию — это более прибыльно для компании, чем продолжить разработку в текущем темпе, забыв про изначальные оценки?
Мне буквально несколько раз за десять лет доводилось видеть взвешенное принятие решения с учетом рисков, затрат на ускорение и потерь в случае задержек. В большинстве же случаев это даже не обсуждалось — надо, чтобы всё шло по плану!
Почему так? Почему в какой-то момент происходит отрыв от реальности, и люди перестают различать карту и реальный ландшафт? Возможно, это происходит в связи с тем, что в индустрии разработки софта мы работаем с нематериальными объектами. Легко не заметить различия между “это факт” и “я думаю, что это так”, особенно когда работаешь с информацией, а не с физическими объектами.
Действительно, есть множество вещей, в существовании которых мы не сомневаемся, хотя материально они не представлены: границы государств, законы, процессы в операционной системе, файлы. В некоторых книжках по системному анализу это называется “модели условного подобия”. В нашей индустрии очень много таких вещей.
Кстати, в близкой к нам и гораздо более зрелой индустрии, системной инженерии, различают два понятия: “описание системы”(system definition) и “воплощение системы”(system realization).
В индустрии разработки софта пока нет терминологии, которая позволяет разделить эти категории. Оценка задачи не означает исполнения, план проекта не является его реализацией, документация и диаграммы не являются архитектурой. Карта не является территорией — стоит об этом помнить.
#рассуждения #оценимнеэтотскоуп
Основная проблема планирования — после того, как мы дали оценку, мы начинаем в неё верить.
Мы отчего-то уверены, что оценка это тот стандарт, к которому следует стремиться.
В ситуации, когда проект не укладывается в изначальную оценку, мы начинаем предпринимать действия, чтобы вернуть проект к намеченному плану: докинуть людей, порезать скоуп, выписать премий за овератаймы по выходным.
Вот только остается неотвеченным вопрос: На основании чего мы уверены, что вернуть проект к планируемому расписанию — это более прибыльно для компании, чем продолжить разработку в текущем темпе, забыв про изначальные оценки?
Мне буквально несколько раз за десять лет доводилось видеть взвешенное принятие решения с учетом рисков, затрат на ускорение и потерь в случае задержек. В большинстве же случаев это даже не обсуждалось — надо, чтобы всё шло по плану!
Почему так? Почему в какой-то момент происходит отрыв от реальности, и люди перестают различать карту и реальный ландшафт? Возможно, это происходит в связи с тем, что в индустрии разработки софта мы работаем с нематериальными объектами. Легко не заметить различия между “это факт” и “я думаю, что это так”, особенно когда работаешь с информацией, а не с физическими объектами.
Действительно, есть множество вещей, в существовании которых мы не сомневаемся, хотя материально они не представлены: границы государств, законы, процессы в операционной системе, файлы. В некоторых книжках по системному анализу это называется “модели условного подобия”. В нашей индустрии очень много таких вещей.
Кстати, в близкой к нам и гораздо более зрелой индустрии, системной инженерии, различают два понятия: “описание системы”(system definition) и “воплощение системы”(system realization).
В индустрии разработки софта пока нет терминологии, которая позволяет разделить эти категории. Оценка задачи не означает исполнения, план проекта не является его реализацией, документация и диаграммы не являются архитектурой. Карта не является территорией — стоит об этом помнить.
#рассуждения #оценимнеэтотскоуп
Одна из причин, почему оценки не говорят о сроке завершения задачи
Оценивая задачу, мы пытаемся определить объем работы, необходимый для её завершения. Конечно точность оценки сильно зависит от уровня понимания системы, но, при определенных условиях, можно прикинуть, сколько времени потребуется на каждый из этапов: написать код, протестировать, подготовить релиз.
Однако, время на выполнение работы в рамках задачи — это только одна часть уравнения. Другой аспект зачастую упускается — время ожидания задачи между этапами работы: ожидание код-ревью, ожидание тестирования, ожидание в ветке до релиза.
Время ожидания в очередях не берется в расчёт при оценке, хотя именно оно и составляет существенную часть от общего времени выполнения. Полезная метрика эффективности процесса — отношение времени активной работы (когда кто-то реально что-то делает по задаче) ко времени цикла (фактическое время от старта работы до завершения).
Если логически разделить статусы в JIRA на те, где реально делается работа, и те, в которых задача просто ждёт, то посчитать это метрику будет несложно. А вот результат многих удивляет — хорошо, если это соотношение будет 0.5 (а может быть и меньше). Это значит, что, давая оценку, мы принимаем во внимание только 50% от реального времени и на основании этого пытаемся строим планы!
Хотите улучшить ваши оценки? Посмотрите, где скапливаются очереди задач, ожидающих следующего этапа разработки. До тех пор пока ожидание в очередях составляет существенную часть от времени цикла, работать над улучшением точности оценок бесполезно. А вот чтобы увеличить долю эффективного времени, следует переосмыслить сложившиеся процессы, сбалансировать загрузку людей, обеспечить доступность необходимых ресурсов и вот это вот всё, подразумеваемое под словом “менеджмент”.
#менеджмент #инструменты #оценимнеэтотскоуп
Оценивая задачу, мы пытаемся определить объем работы, необходимый для её завершения. Конечно точность оценки сильно зависит от уровня понимания системы, но, при определенных условиях, можно прикинуть, сколько времени потребуется на каждый из этапов: написать код, протестировать, подготовить релиз.
Однако, время на выполнение работы в рамках задачи — это только одна часть уравнения. Другой аспект зачастую упускается — время ожидания задачи между этапами работы: ожидание код-ревью, ожидание тестирования, ожидание в ветке до релиза.
Время ожидания в очередях не берется в расчёт при оценке, хотя именно оно и составляет существенную часть от общего времени выполнения. Полезная метрика эффективности процесса — отношение времени активной работы (когда кто-то реально что-то делает по задаче) ко времени цикла (фактическое время от старта работы до завершения).
Если логически разделить статусы в JIRA на те, где реально делается работа, и те, в которых задача просто ждёт, то посчитать это метрику будет несложно. А вот результат многих удивляет — хорошо, если это соотношение будет 0.5 (а может быть и меньше). Это значит, что, давая оценку, мы принимаем во внимание только 50% от реального времени и на основании этого пытаемся строим планы!
Хотите улучшить ваши оценки? Посмотрите, где скапливаются очереди задач, ожидающих следующего этапа разработки. До тех пор пока ожидание в очередях составляет существенную часть от времени цикла, работать над улучшением точности оценок бесполезно. А вот чтобы увеличить долю эффективного времени, следует переосмыслить сложившиеся процессы, сбалансировать загрузку людей, обеспечить доступность необходимых ресурсов и вот это вот всё, подразумеваемое под словом “менеджмент”.
#менеджмент #инструменты #оценимнеэтотскоуп
Исследование причин отказа распределенных систем
В 2014 году вышла публикация “Simple Testing Can Prevent Most Critical Failures. An Analysis of Production Failures in Distributed Data-intensive Systems”.
Исследователи из университета Торонто искали причины событий, которые приводили к отказу распространенных open source решений: Casandra, HDFS, Hbase, MapReduce и Redis.
Статья, для научной, читается довольно легко, и мне показалась полезной. Вот несколько выдержек из публикации:
- 92% отказов были вызваны некорректной обработкой некритичных ошибок.
- 77% отказов происходили при совпадении двух и более событий в определенном порядке.
- В 58% случаев отказы системы можно было воспроизвести юнит-тестами.
- 35% отказов были вызваны пренебрежением к базовым практикам (привет FIXME и TODO в коде, который должен был обрабатывать исключения).
Исследование использует данные из open source, его результаты не следует напрямую переносить на коммерческую разработку. В коммерческой разработке, как правило, зависимостей больше, вероятность отказа выше, при этом отношение к рискам весьма поверхностное:
- Happy path работает, потом никогда-нибудь разберемся как работать с ошибками.
- Test-coverage высокий — значит всё хорошо.
- Да такого точно никогда не случится, не будем сейчас запариваться.
Где-то видел подход — писать тесты на внешние зависимости. Используете активно какую-нибудь Kafka, возьмите библиотеку для работы с ней для вашего языка и напишите тесты на то, как работает библиотека. Можно проверить, какие ошибки возникают и как их обрабатывать, почитать код библиотеки, симулировать ситуации, которые могут возникнуть при эксплуатации. А главное — такие тесты помогут найти проблемы при обновлении версии зависимости.
Ссылка на исследование: https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_osdi14.pdf
#инструменты
В 2014 году вышла публикация “Simple Testing Can Prevent Most Critical Failures. An Analysis of Production Failures in Distributed Data-intensive Systems”.
Исследователи из университета Торонто искали причины событий, которые приводили к отказу распространенных open source решений: Casandra, HDFS, Hbase, MapReduce и Redis.
Статья, для научной, читается довольно легко, и мне показалась полезной. Вот несколько выдержек из публикации:
- 92% отказов были вызваны некорректной обработкой некритичных ошибок.
- 77% отказов происходили при совпадении двух и более событий в определенном порядке.
- В 58% случаев отказы системы можно было воспроизвести юнит-тестами.
- 35% отказов были вызваны пренебрежением к базовым практикам (привет FIXME и TODO в коде, который должен был обрабатывать исключения).
Исследование использует данные из open source, его результаты не следует напрямую переносить на коммерческую разработку. В коммерческой разработке, как правило, зависимостей больше, вероятность отказа выше, при этом отношение к рискам весьма поверхностное:
- Happy path работает, потом никогда-нибудь разберемся как работать с ошибками.
- Test-coverage высокий — значит всё хорошо.
- Да такого точно никогда не случится, не будем сейчас запариваться.
Где-то видел подход — писать тесты на внешние зависимости. Используете активно какую-нибудь Kafka, возьмите библиотеку для работы с ней для вашего языка и напишите тесты на то, как работает библиотека. Можно проверить, какие ошибки возникают и как их обрабатывать, почитать код библиотеки, симулировать ситуации, которые могут возникнуть при эксплуатации. А главное — такие тесты помогут найти проблемы при обновлении версии зависимости.
Ссылка на исследование: https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_osdi14.pdf
#инструменты
Важные мелочи: общие чаты
Иногда замечаю, как совершенно небольшие вещи приводят к большим трудностям.
Ну например, случилось такое, что требуется узнать что-то у команды, с которой ты активно не работаешь и никого там не знаешь. А куда писать? Кто там, в этой команде? Как про них узнать? Зачастую это приводит к появлению отдельных чатиков по каждому вопросу, ответы теряются в личных сообщениях, вопросы повторяются. Если подходящий контакт найти не удаётся, то начинается эскалация через менеджеров всех уровней. А теперь представьте неэффективность при масштабе в сотню команд...
Хорошо, когда на возникшую потребность, в компании есть готовый ответ, как это сделать. В случае с коммуникацией — например, открытый канал “название_команды_public” в slack/teams/чтоугодно. Хорошо, когда это не какое-то эзотерическое правило или креатив каждой отдельной команды, а понятный паттерн, зная который, любой человек в компании может его применить к любой команде. В идеале, зная какой-то факт (например, название команды), можно вывести необходимую информацию: например, название команды является тегом, которым помечены все репозитории команды в gitlab, все дашборды в grafana и так далее.
#важныемелочи #менеджмент
Иногда замечаю, как совершенно небольшие вещи приводят к большим трудностям.
Ну например, случилось такое, что требуется узнать что-то у команды, с которой ты активно не работаешь и никого там не знаешь. А куда писать? Кто там, в этой команде? Как про них узнать? Зачастую это приводит к появлению отдельных чатиков по каждому вопросу, ответы теряются в личных сообщениях, вопросы повторяются. Если подходящий контакт найти не удаётся, то начинается эскалация через менеджеров всех уровней. А теперь представьте неэффективность при масштабе в сотню команд...
Хорошо, когда на возникшую потребность, в компании есть готовый ответ, как это сделать. В случае с коммуникацией — например, открытый канал “название_команды_public” в slack/teams/чтоугодно. Хорошо, когда это не какое-то эзотерическое правило или креатив каждой отдельной команды, а понятный паттерн, зная который, любой человек в компании может его применить к любой команде. В идеале, зная какой-то факт (например, название команды), можно вывести необходимую информацию: например, название команды является тегом, которым помечены все репозитории команды в gitlab, все дашборды в grafana и так далее.
#важныемелочи #менеджмент
Ментальные модели — как отделять формулировку проблемы от самой проблемы
В тех областях, где люди работают не с физическими объектами, а с информацией, легко спутать факты и их интерпретации, домыслить связи, которых нет, или, наоборот, упустить существенные связи. Во второй половине двадцатого века, в ответ на возрастающую сложность, появилась наука о системах и первые попытки сформулировать подход к решению проблемных ситуаций. Начали развиваться подходы к моделированию систем, и, в частности, появился термин “ментальная модель”. То, как человек думает о какой-то системе, это и есть его ментальная модель данной системы.
Например, то, как мы думаем о поведении системы в продакшене — это наша ментальная модель. У других людей, работающих с этой же системой, модель будет другая, они выделяют другие компоненты и другие связи считают существенными. Еще один пример — самолёт: все видели самолёт, знают, что это такое. Однако, если попросить техника, бортпроводника и пилота описать, из чего состоит самолёт, они будут выделять разные компоненты и связи между ними. Таким образом, с одной стороны, системы объективны (самолеты, работающий софт), с другой стороны, компоненты и связи субъективны.
Если вы дочитали до этого места, то, возможно, вас беспокоит вопрос ”и что?”. Дело в том, что способ размышления о проблеме во многом определяет нашу способность решить эту проблему. Но, зачастую, сталкиваясь с проблемой, мы пытаемся её решать, не сильно разбираясь в том, как она сформулирована и в не думаем о степени понимания этой проблемы.
Предмет разговора очень абстрактный, я попробую привести пример из жизни. С ранней школы мы научились совершать базовые арифметические операции: умеем складывать, делить, умножать, вычитать, воспринимаем это как должное и не удивляемся. Одна из причин, почему мы так легко это делаем — позиционная система счисления (десятичная). Не верите? Попробуйте умножить два числа в римской записи: XVII * IX. Сколько получится? Дело в том, что в позиционной системе записи, где позиция цифры определяет разряд, арифметические операции легко алгоритмизируются (помните в школе учили умножение в столбик?), а в другой, например, римской нотации — нет. А теперь представьте, каким достижением было доказать теорему Пифагора без позиционной записи. Это был rocket-science.
Сама форма записи числа и то, как мы думаем о числах вообще, влияет на нашу способность совершать операции с ними. Иными словами, та ментальная модель, в рамках которой мы формулируем проблему, определяет пространство возможных решений.
Если переложить эти рассуждения на наши реалии, то крайне важно уделить достаточно времени и сил формулированию проблемы, прежде чем бросаться её решать: убедиться, что проблема действительно существует (в реальности, а не голове); согласовать понимание проблемы между людьми, которых она затрагивает.
Короче, прежде чем проводить реструктуризацию/проектировать архитектуру/внедрять скрам и т.д., следует критически осмыслить свою ментальную модель и сверить её с реальностью.
В тех областях, где люди работают не с физическими объектами, а с информацией, легко спутать факты и их интерпретации, домыслить связи, которых нет, или, наоборот, упустить существенные связи. Во второй половине двадцатого века, в ответ на возрастающую сложность, появилась наука о системах и первые попытки сформулировать подход к решению проблемных ситуаций. Начали развиваться подходы к моделированию систем, и, в частности, появился термин “ментальная модель”. То, как человек думает о какой-то системе, это и есть его ментальная модель данной системы.
Например, то, как мы думаем о поведении системы в продакшене — это наша ментальная модель. У других людей, работающих с этой же системой, модель будет другая, они выделяют другие компоненты и другие связи считают существенными. Еще один пример — самолёт: все видели самолёт, знают, что это такое. Однако, если попросить техника, бортпроводника и пилота описать, из чего состоит самолёт, они будут выделять разные компоненты и связи между ними. Таким образом, с одной стороны, системы объективны (самолеты, работающий софт), с другой стороны, компоненты и связи субъективны.
Если вы дочитали до этого места, то, возможно, вас беспокоит вопрос ”и что?”. Дело в том, что способ размышления о проблеме во многом определяет нашу способность решить эту проблему. Но, зачастую, сталкиваясь с проблемой, мы пытаемся её решать, не сильно разбираясь в том, как она сформулирована и в не думаем о степени понимания этой проблемы.
Предмет разговора очень абстрактный, я попробую привести пример из жизни. С ранней школы мы научились совершать базовые арифметические операции: умеем складывать, делить, умножать, вычитать, воспринимаем это как должное и не удивляемся. Одна из причин, почему мы так легко это делаем — позиционная система счисления (десятичная). Не верите? Попробуйте умножить два числа в римской записи: XVII * IX. Сколько получится? Дело в том, что в позиционной системе записи, где позиция цифры определяет разряд, арифметические операции легко алгоритмизируются (помните в школе учили умножение в столбик?), а в другой, например, римской нотации — нет. А теперь представьте, каким достижением было доказать теорему Пифагора без позиционной записи. Это был rocket-science.
Сама форма записи числа и то, как мы думаем о числах вообще, влияет на нашу способность совершать операции с ними. Иными словами, та ментальная модель, в рамках которой мы формулируем проблему, определяет пространство возможных решений.
Если переложить эти рассуждения на наши реалии, то крайне важно уделить достаточно времени и сил формулированию проблемы, прежде чем бросаться её решать: убедиться, что проблема действительно существует (в реальности, а не голове); согласовать понимание проблемы между людьми, которых она затрагивает.
Короче, прежде чем проводить реструктуризацию/проектировать архитектуру/внедрять скрам и т.д., следует критически осмыслить свою ментальную модель и сверить её с реальностью.
Bonus-Driven Development — обратная сторона годовых ревью
Под конец года в компаниях наступает оживление — всё, что откладывалось и игнорировалось на протяжении всего года, пытаются успеть сделать в последние месяцы. Особенно если в компании есть годовые ревью, особенно если оценка в конце года влияет на размер бонуса.
Годовые ревью и постановка целей для сотрудников — дело хорошее. Правда иногда бывают перегибы, когда глобальные изменения пытаются вписывать в цели людям, у которых нет полномочий их выполнить. Например: вывести из эксплуатации старую БД, на которую завязаны десятки команд; внедрить политики безопасности для SOx/GDPR/CMA-compliance; смигрировать всей компанией на новую систему контроля версий, CI-систему или API стандарт; выстроить процесс найма и т.д. Отдельный вопрос, почему люди соглашаются на годовые цели, не обладая полномочиями для их выполнения. (Отчасти, тут уместно процитировать анекдот: “либо ишак сдохнет, либо падишах помрет”, про это будет отдельный пункт в конце).
Типичный сценарий подобных проектов такой: в начале года происходит несколько встреч с коллегами из смежных подразделений; становится понятно, что проблема сложнее, чем казалась; проект вытесняется краткосрочными задачами и постепенно уходит на второй план. А под конец года начинается чехарда и попытки на скорую руку провести глобальное изменение, хуже всего, когда это получается — чтобы внедрить политики безопасности по-быстрому, надо всего-то забрать у всех разработчиков доступ к продакшену. Мелочь… Что может пойти не так?
Интереснее всего, что происходит, когда цель выполнить не получается, а бонус получить хочется: начинаются бравурные посты на внутренних ресурсах о том, как это важно и трудно, презентации на all-hands митингах, картины светлого будущего и другие продвинутые техники фасадо-строительства. Главное показать прогресс и доказать, что изначально оговоренный результат в этом году получить нереально, но вот в следующем — точно, и по этому сроки нужно перенести на следующий год. Короче, начинает работать принцип: вспотел — покажись начальству.
В итоге непонятно, чего больше —вреда или пользы — от годовых целей сотрудников.
Однако в компаниях такие правила игры, и с ними приходится считаться. Несколько выводов о постановке целей:
Назначить ответственного не гарантирует исполнения. Если политики безопасности и соответствие требованиям регуляторов действительно нужны в организации, то и управлять этим следует руководителю соответствующего уровня. Распространенный анти-паттернт: copy-paste целей через все уровни иерархии до линейных руководителей, без попыток декомпозиции.
Отказываться от целей, на которые вы не можете повлиять. Если руководство всё же давит, то имеет смысл сделать декомпозицию такой цели и классифицировать получившееся: могу сделать сам; могу повлиять, но не могу контролировать; не могу повлиять. Если всё же не получится отказаться, то это хотя бы позволит договориться, чтобы вас оценивали на основании того, что вы можете контролировать.
Не вписываться в глобальные инициативы, если не собираетесь оставаться в компании.
Это как минимум неэтично, а также может негативно повлиять на профессиональную репутацию. Мало ли что люди обсуждают со знакомыми за пивом и у кого собирают рекомендации на кандидата. В итоге красивая строчка в резюме после проверки через цепочку знакомых превращается в красный флаг.
#рассуждения
Под конец года в компаниях наступает оживление — всё, что откладывалось и игнорировалось на протяжении всего года, пытаются успеть сделать в последние месяцы. Особенно если в компании есть годовые ревью, особенно если оценка в конце года влияет на размер бонуса.
Годовые ревью и постановка целей для сотрудников — дело хорошее. Правда иногда бывают перегибы, когда глобальные изменения пытаются вписывать в цели людям, у которых нет полномочий их выполнить. Например: вывести из эксплуатации старую БД, на которую завязаны десятки команд; внедрить политики безопасности для SOx/GDPR/CMA-compliance; смигрировать всей компанией на новую систему контроля версий, CI-систему или API стандарт; выстроить процесс найма и т.д. Отдельный вопрос, почему люди соглашаются на годовые цели, не обладая полномочиями для их выполнения. (Отчасти, тут уместно процитировать анекдот: “либо ишак сдохнет, либо падишах помрет”, про это будет отдельный пункт в конце).
Типичный сценарий подобных проектов такой: в начале года происходит несколько встреч с коллегами из смежных подразделений; становится понятно, что проблема сложнее, чем казалась; проект вытесняется краткосрочными задачами и постепенно уходит на второй план. А под конец года начинается чехарда и попытки на скорую руку провести глобальное изменение, хуже всего, когда это получается — чтобы внедрить политики безопасности по-быстрому, надо всего-то забрать у всех разработчиков доступ к продакшену. Мелочь… Что может пойти не так?
Интереснее всего, что происходит, когда цель выполнить не получается, а бонус получить хочется: начинаются бравурные посты на внутренних ресурсах о том, как это важно и трудно, презентации на all-hands митингах, картины светлого будущего и другие продвинутые техники фасадо-строительства. Главное показать прогресс и доказать, что изначально оговоренный результат в этом году получить нереально, но вот в следующем — точно, и по этому сроки нужно перенести на следующий год. Короче, начинает работать принцип: вспотел — покажись начальству.
В итоге непонятно, чего больше —вреда или пользы — от годовых целей сотрудников.
Однако в компаниях такие правила игры, и с ними приходится считаться. Несколько выводов о постановке целей:
Назначить ответственного не гарантирует исполнения. Если политики безопасности и соответствие требованиям регуляторов действительно нужны в организации, то и управлять этим следует руководителю соответствующего уровня. Распространенный анти-паттернт: copy-paste целей через все уровни иерархии до линейных руководителей, без попыток декомпозиции.
Отказываться от целей, на которые вы не можете повлиять. Если руководство всё же давит, то имеет смысл сделать декомпозицию такой цели и классифицировать получившееся: могу сделать сам; могу повлиять, но не могу контролировать; не могу повлиять. Если всё же не получится отказаться, то это хотя бы позволит договориться, чтобы вас оценивали на основании того, что вы можете контролировать.
Не вписываться в глобальные инициативы, если не собираетесь оставаться в компании.
Это как минимум неэтично, а также может негативно повлиять на профессиональную репутацию. Мало ли что люди обсуждают со знакомыми за пивом и у кого собирают рекомендации на кандидата. В итоге красивая строчка в резюме после проверки через цепочку знакомых превращается в красный флаг.
#рассуждения
Архитектурные группы — бюрократия или полезный инструмент?
Такие группы образуются когда сложность проекта растет и появляется потребность в согласованности технических решений между несколькими командами. Название может отличаться от компании к компании – 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
В итоге человек повышается в роль без конкретных ожиданий от него, а заодно получает позитивное подкрепление: “я делал то, что я делал, за это меня повысили, значит я делаю свою работу хорошо”.
В масштабах небольшой компании такой подход не создает проблем — всё и так держиться на личных связях, и не важно, кто какую должность занимает. В большой же компании это приводит к полной реализации принципа Питера
Если многократно повторить процесс, описанный выше, то мы оказываемся в ситуации, что руководитель (его так же когда-то давно повысили за то, что он делал хорошо свою прошлую работу) не имеет четких ожиданий от роли, в которую повысили героя истории (который считает, что делает всё правильно, его же повысили). Так и получаются, что в компании все делают что-то “важное”, на местах всё выглядит прилично, а в масштабе компании получается цирк с конями и бюрократией. В итоге имеем: продакт-менеджеров, которые умеют только заводить митинги и клепать презентации; архитекторов, мастерски рисующих диаграммы, совершенно не знающих нужд стейкхолдеров; руководителей, которые умеют поддерживать текущую рутину, но не ведут команду к какой-то цели.
Повышать за былые заслуги — это, на мой взгляд, такое себе решение. За успехи в прошлом есть бонусы и премии, повышение же — это про реализацию потенциала человека в организации, и количество критериев, которые следует принимать во внимание, гораздо больше.
#ошибкименеджера #карьерныйпуть #менеджмент
Про технологические инициативы и стратегию "любой ценой"
Пару недель назад мы обсуждали перевод статьи про то, как в Uber решили пересмотреть архитектуру своего клиентского приложения, потому что старое стало попросту нестабильным, возросла сложность, кол-во патчей и хотфиксов.
Причина хаоса в старом — бурный рост. Кто его не переживал, просто скажу, что в таких условиях концентрация людей, которые знают, как развивать разработку и архитектуру всего приложения близка к концентрации действующих веществ в гомеопатических препаратах.
Таких людей мало и они зачастую заняты другими “более важными вещами”. Это приводит к тому, что у каждой фичи свой особый технологический путь и в один момент ты становишься настолько нестабильным, что каждая следующая фича требует в три раза больше времени на регрессию, чем на разработку, а потом еще пары десятков патчей, чтоб привести ее к рабочему виду. (В моей практике была фича на которую мы выпустили больше 30 патчей. В мотивации к фиче тоже было “Необходимо переписать с нуля”)
В общем, решили ребята “переписать приложение с нуля”. Собрали небольшую группу из архитекторов, разработчиков и дизайнеров, которая должна была разработать новую архитектуру. Погрузились с головой в работу.
В процессе пересмотра архитектуры команда сменила основную технологию разработки с Objective-C на Swift. Стали использовать реактивную парадигму разработки. В общем, как говорит один мой знакомый: “Разошлись на все бабки”. И это дало свои результаты.
Цитата из статьи:
“С небольшим количеством инженеров удалось разработать отличную функциональность за короткое время. Большая часть продукта готова. Руководство довольно”
Но, если бы было все так сладко, то и статьи бы не было.
Не буду погружаться в детали, советую вам самим прочитать этот лонг рид. Наверняка некоторые из вас сталкивались со схожими проблемами.
Вся соль этой истории, на мой взгляд, заключается в том, что управленческая вертикаль инженерии шла на эту авантюру без плана Б и объяснения всем окружающим, что переход на early adopt технологию сопряжен с огромным риском, но у нас есть план Б и вот вехи на которых мы будем принимать решение о дальнейшем движении.
В ситуации, когда проблемы стали настолько серьезными, что игнорировать их было невозможно, использовали стратегию “любой ценой”, потому что менеджеры не могут ошибаться и надо только чуть-чуть поднажать. А тут включается еще и корпоративная культура. На сколько сложно признать свою ошибку внутри компании?
Главная подпитка позиции "затащить любой ценой" заключается в том, что тебя зачмырят/понизят/уволят. В таких условиях ты будешь добиваться результата, чтоб доказать свою правоту, при этом убивая компанию на стратегическом направлении. И твоя инициатива, как менеджера превращается из стратегической в фасадо-строительную.
Какой вывод?
Я считаю, что задача SEM/TD/VP/CTO на каждом из уровней доносить не только "как и зачем мы будем внедрять ту, или иную технологию”, но еще и акцентировать внимание собравшихся, которые зачастую далеки от разработки, на том, что это будет сложный путь и не факт, что мы его пройдем.
Это звучит, как common sense, но это очень сложная работа, которая требует от SEM(я тут объединяю всю вертикаль инженерного управления) понимания технологий, их состояния и подготовок чек листа, который может сказать: "Ребята, сворачиваем! Не туда копаем"
P.S. Ну, а про переписывать с нуля, я задаю себе один вопрос, когда в моей голове появляется такая идея: “Что я дам нового пользователям взамен утерянной функциональности?”
Переписывание с нуля — это релиз нового, а не переделка старого. При переписывании теряется некоторая часть функциональности, зачастую даже не задокументированной, но уже привычной пользователям.
Пару недель назад мы обсуждали перевод статьи про то, как в Uber решили пересмотреть архитектуру своего клиентского приложения, потому что старое стало попросту нестабильным, возросла сложность, кол-во патчей и хотфиксов.
Причина хаоса в старом — бурный рост. Кто его не переживал, просто скажу, что в таких условиях концентрация людей, которые знают, как развивать разработку и архитектуру всего приложения близка к концентрации действующих веществ в гомеопатических препаратах.
Таких людей мало и они зачастую заняты другими “более важными вещами”. Это приводит к тому, что у каждой фичи свой особый технологический путь и в один момент ты становишься настолько нестабильным, что каждая следующая фича требует в три раза больше времени на регрессию, чем на разработку, а потом еще пары десятков патчей, чтоб привести ее к рабочему виду. (В моей практике была фича на которую мы выпустили больше 30 патчей. В мотивации к фиче тоже было “Необходимо переписать с нуля”)
В общем, решили ребята “переписать приложение с нуля”. Собрали небольшую группу из архитекторов, разработчиков и дизайнеров, которая должна была разработать новую архитектуру. Погрузились с головой в работу.
В процессе пересмотра архитектуры команда сменила основную технологию разработки с Objective-C на Swift. Стали использовать реактивную парадигму разработки. В общем, как говорит один мой знакомый: “Разошлись на все бабки”. И это дало свои результаты.
Цитата из статьи:
“С небольшим количеством инженеров удалось разработать отличную функциональность за короткое время. Большая часть продукта готова. Руководство довольно”
Но, если бы было все так сладко, то и статьи бы не было.
Не буду погружаться в детали, советую вам самим прочитать этот лонг рид. Наверняка некоторые из вас сталкивались со схожими проблемами.
Вся соль этой истории, на мой взгляд, заключается в том, что управленческая вертикаль инженерии шла на эту авантюру без плана Б и объяснения всем окружающим, что переход на early adopt технологию сопряжен с огромным риском, но у нас есть план Б и вот вехи на которых мы будем принимать решение о дальнейшем движении.
В ситуации, когда проблемы стали настолько серьезными, что игнорировать их было невозможно, использовали стратегию “любой ценой”, потому что менеджеры не могут ошибаться и надо только чуть-чуть поднажать. А тут включается еще и корпоративная культура. На сколько сложно признать свою ошибку внутри компании?
Главная подпитка позиции "затащить любой ценой" заключается в том, что тебя зачмырят/понизят/уволят. В таких условиях ты будешь добиваться результата, чтоб доказать свою правоту, при этом убивая компанию на стратегическом направлении. И твоя инициатива, как менеджера превращается из стратегической в фасадо-строительную.
Какой вывод?
Я считаю, что задача SEM/TD/VP/CTO на каждом из уровней доносить не только "как и зачем мы будем внедрять ту, или иную технологию”, но еще и акцентировать внимание собравшихся, которые зачастую далеки от разработки, на том, что это будет сложный путь и не факт, что мы его пройдем.
Это звучит, как common sense, но это очень сложная работа, которая требует от SEM(я тут объединяю всю вертикаль инженерного управления) понимания технологий, их состояния и подготовок чек листа, который может сказать: "Ребята, сворачиваем! Не туда копаем"
P.S. Ну, а про переписывать с нуля, я задаю себе один вопрос, когда в моей голове появляется такая идея: “Что я дам нового пользователям взамен утерянной функциональности?”
Переписывание с нуля — это релиз нового, а не переделка старого. При переписывании теряется некоторая часть функциональности, зачастую даже не задокументированной, но уже привычной пользователям.
Хабр
Как Uber переписал приложение iOS на Swift
Итак, друзья, садитесь в кружок и послушайте историю самой большой инженерной катастрофы, в которой я участвовал. Это история о политике, архитектуре и логической ошибке невозвратных затрат (вы уж...
Управленческие антипаттерны
Юный радиолюбитель.
Такое происходит, когда, начитавшись книжек и насмотревшись видео с конференций, адепт без опыта управления начинает внедрять всё увиденное. Тут сразу начинается: скрам всем командам, портфолио-канбан борд, value-стримы, chaos engineering, trunk-based development, TDD. Всё это по отдельности — полезные инструменты; проблема в том, что все это начинает внедряться одновременно, создавая хаос и отторжение у остальной части организации. Лечится хорошим ментором и обратной связью.
Почему анти-паттерн так называется? Потому что главное правило радиста: “не крути все ручки сразу”.
Оператор социальной системы.
Проявляется, когда человек вырос в руководителя в компании и продолжает долгое время работать в хорошо знакомой среде. Прекрасно знает, с кем и как договариваться, прекрасно знает, где воткнуть костыль, чтобы запустить новую фичу. Однако кругозор не пополняется информацией из внешнего мира. Про контейнеры, кубернетес, облака и аджайл не слышали, и так нормально работаем! В итоге опыт человека релевантен только этой компании и не имеет никакой ценности за её пределами (На мой взгляд, вообще полезно задумываться “имеют ли ценность мои навыки за пределами компании?”). Лечится конференциями, воркшопами, притоком свежих кадров в орагинизацию.
Стратег-визионер.
Оторванный от реальности и не погруженный в контекст руководитель. Рисует красочные картины будущего о том, как всё организовать и как классно все будет работать. Однако, чтобы прийти из точки А в точку Б, нужно знать не только желаемое состояние, но также и текущее положение дел, возможности, ресурсы. В результате, стратегии и далеко идущие планы скорее напоминают письма Деду Морозу: “Хочу на новый год continuous delivery во всех командах и высокое качество продукта. Серёжа, 43 года”. Такое положение дел зачастую вызвано непониманием текущих ограничений и отсутствием обратной связи о реальном положении дел. Широко распространено в больших компаниях с длинной цепочкой иерархии.
Данные анти-паттерны не являются ярлыками, которыми следует клеймить людей. Скорее это состояния, в которых каждый из нас (я так точно) может оказаться. Важно уметь замечать себя в подобном состоянии, критически осмыслять и корректировать свои действия.
#менеджмет #рассуждения
Юный радиолюбитель.
Такое происходит, когда, начитавшись книжек и насмотревшись видео с конференций, адепт без опыта управления начинает внедрять всё увиденное. Тут сразу начинается: скрам всем командам, портфолио-канбан борд, value-стримы, chaos engineering, trunk-based development, TDD. Всё это по отдельности — полезные инструменты; проблема в том, что все это начинает внедряться одновременно, создавая хаос и отторжение у остальной части организации. Лечится хорошим ментором и обратной связью.
Почему анти-паттерн так называется? Потому что главное правило радиста: “не крути все ручки сразу”.
Оператор социальной системы.
Проявляется, когда человек вырос в руководителя в компании и продолжает долгое время работать в хорошо знакомой среде. Прекрасно знает, с кем и как договариваться, прекрасно знает, где воткнуть костыль, чтобы запустить новую фичу. Однако кругозор не пополняется информацией из внешнего мира. Про контейнеры, кубернетес, облака и аджайл не слышали, и так нормально работаем! В итоге опыт человека релевантен только этой компании и не имеет никакой ценности за её пределами (На мой взгляд, вообще полезно задумываться “имеют ли ценность мои навыки за пределами компании?”). Лечится конференциями, воркшопами, притоком свежих кадров в орагинизацию.
Стратег-визионер.
Оторванный от реальности и не погруженный в контекст руководитель. Рисует красочные картины будущего о том, как всё организовать и как классно все будет работать. Однако, чтобы прийти из точки А в точку Б, нужно знать не только желаемое состояние, но также и текущее положение дел, возможности, ресурсы. В результате, стратегии и далеко идущие планы скорее напоминают письма Деду Морозу: “Хочу на новый год continuous delivery во всех командах и высокое качество продукта. Серёжа, 43 года”. Такое положение дел зачастую вызвано непониманием текущих ограничений и отсутствием обратной связи о реальном положении дел. Широко распространено в больших компаниях с длинной цепочкой иерархии.
Данные анти-паттерны не являются ярлыками, которыми следует клеймить людей. Скорее это состояния, в которых каждый из нас (я так точно) может оказаться. Важно уметь замечать себя в подобном состоянии, критически осмыслять и корректировать свои действия.
#менеджмет #рассуждения
Вера в причины успеха
В компаниях, которые существуют давно и стали успешными, есть такой эффект – сотрудники (особенно стоявшие у истоков) объясняют успех компании именно своими действиями. “Мы писали на Java, и поэтому все получилось!”, “У нас была классная идея, и поэтому мы успешны”, “У нас талантливые сотрудники, и поэтому мы всего достигли”.
Такой же эффект проявляется на индивидуальном уровне: “Я уже 5 лет менеджу команды, делаю это хорошо, и по этому, я хороший менеджер!” (за “делаю это хорошо” как правило не стоит четких критериев).
На эту тему у меня есть история.
В 1956 году вышла книга-исследование Леона Фестингера “When Prophecy Fails” (“Когда пророчество не сбылось”, но перевода на русский кажется нет). В этом исследовании группа ученых наблюдала за религиозной сектой. Члены секты верили в то, что наступит конец света, мир затопит, а их, “истинно” верующих, заберут инопланетяне и отвезут в рай. Короче, стандартный бред про инопланетян и конец света, сюжет для провинциальной телепередачи.
Отличительной чертой данной религиозной организации было то, что её лидер называла конкретную дату, когда должен был случиться конец света: 21 декабря 1954 года. Исследователи задались вопросом – “Как поведут себя члены секты, когда наступит указанный день, а конца света не случится?”. Ожидалось, что члены секты, конечно, будут страдать от сломавшейся картины мира, но все же примут правду – конца света не случилось, НЛО не прилетел, мы были неправы.
Что же произошло на самом деле?
Разумеется, конца света не случилось, инопланетяне тоже не прилетели. Как же повели себя члены секты? Разошлись по домам? Ничего подобного! Ребята быстро “переобулись” и заявили: “Мы за всех молились, и поэтому конец света не случился! Мы всех спасли!”
В чем мораль истории? Если человек или группа людей во что-то верит, многим пожертвовали ради этого, они будут защищать свое убеждение всеми силами. Ни логика, ни здравый смысл не изменят убеждений. Не получится изменить убеждение одним днём.
Как с этим жить? На уровне организации, просто помнить, что требуется время, чтобы привыкнуть к новым вещам, если они конфликтуют с текущей картиной мира. Так что изменения, даже простые, требуют времени (например: “а давайте начнем писать тесты на свой код”).
На индивидуальном же уровне, важно самому уметь выходить из ловушки прошлого “успешного” опыта и задаваться вопросами: “А не фигню ли я делаю?”, “На основании чего я уверен, что действие Х приведет к результату У?”.
#рассуждения #менеджмент
В компаниях, которые существуют давно и стали успешными, есть такой эффект – сотрудники (особенно стоявшие у истоков) объясняют успех компании именно своими действиями. “Мы писали на Java, и поэтому все получилось!”, “У нас была классная идея, и поэтому мы успешны”, “У нас талантливые сотрудники, и поэтому мы всего достигли”.
Такой же эффект проявляется на индивидуальном уровне: “Я уже 5 лет менеджу команды, делаю это хорошо, и по этому, я хороший менеджер!” (за “делаю это хорошо” как правило не стоит четких критериев).
На эту тему у меня есть история.
В 1956 году вышла книга-исследование Леона Фестингера “When Prophecy Fails” (“Когда пророчество не сбылось”, но перевода на русский кажется нет). В этом исследовании группа ученых наблюдала за религиозной сектой. Члены секты верили в то, что наступит конец света, мир затопит, а их, “истинно” верующих, заберут инопланетяне и отвезут в рай. Короче, стандартный бред про инопланетян и конец света, сюжет для провинциальной телепередачи.
Отличительной чертой данной религиозной организации было то, что её лидер называла конкретную дату, когда должен был случиться конец света: 21 декабря 1954 года. Исследователи задались вопросом – “Как поведут себя члены секты, когда наступит указанный день, а конца света не случится?”. Ожидалось, что члены секты, конечно, будут страдать от сломавшейся картины мира, но все же примут правду – конца света не случилось, НЛО не прилетел, мы были неправы.
Что же произошло на самом деле?
Разумеется, конца света не случилось, инопланетяне тоже не прилетели. Как же повели себя члены секты? Разошлись по домам? Ничего подобного! Ребята быстро “переобулись” и заявили: “Мы за всех молились, и поэтому конец света не случился! Мы всех спасли!”
В чем мораль истории? Если человек или группа людей во что-то верит, многим пожертвовали ради этого, они будут защищать свое убеждение всеми силами. Ни логика, ни здравый смысл не изменят убеждений. Не получится изменить убеждение одним днём.
Как с этим жить? На уровне организации, просто помнить, что требуется время, чтобы привыкнуть к новым вещам, если они конфликтуют с текущей картиной мира. Так что изменения, даже простые, требуют времени (например: “а давайте начнем писать тесты на свой код”).
На индивидуальном же уровне, важно самому уметь выходить из ловушки прошлого “успешного” опыта и задаваться вопросами: “А не фигню ли я делаю?”, “На основании чего я уверен, что действие Х приведет к результату У?”.
#рассуждения #менеджмент
Разница культур. Amazon и игры
Пару дней назад Bloomberg опубликовал статью-расследование о том, как обстоят дела в игровом направлении Amazon.
Основной тезис заключается в том, что даже наличие бесконечных ресурсов, и доступ к хантингу рок-звезд индустрии не дает вам гарантии сделать великую игру.
Вину в провале возложили на главу подразделения, который в играх не шарит, а знает только про KPI амазоновские. Отчасти это так, но есть еще пара, на мой взгляд важных моментов.
На мой взгляд, основной проблемой явилась разница культур разработки сервисов в Амазоне и того, как делаются игры в тысячах студий. А так же, как следует из статьи, нежелание адаптироваться к тому, что люди, которые придут делать игры в Амазоне в первую очередь придут делать игры, а уж вторым пунктом будет Амазон. Хотя за всех сказать не могу.
В геймдеве за все эти годы привыкли к другому подходу.
Задача с эстимейтом в три месяца, которую делает один человек полгода -- нормально. В контексте той культуры, которая уже сложилась. Попытка распилить задачу обычно заканчивается великим фейлом и катастрофическим рассинхроном между отделами.
Кранчить месяцами -- что здесь такого? “Так делаются все великие игры”. Вера в этот тезис сидит настолько глубоко в мозгах, что иногда испытываешь физический дискомфорт, когда уходишь в отпуск, а мог бы еще чуть-чуть поработать.
Переобуваться в воздухе и переделывать все к чертовой матери за две недели до релиза - легко. Потому что “вдруг” поняли, что это не тот пользовательский опыт, который мы хотим доставить нашим игрокам.
Минимум документов - максимум общения и тонны прототипов, большая часть из которых никуда не пойдет. На этой хрупкой договоренности строится огромная часть разработки, особенно на старте продукта. Невозможно выдать новую крутую механику на бумаге.
Все это выглядит, как набор анти-паттернов управления. И это действительно так. Но как только волевым решением менеджмента ломается привычная для многих культура происходит паралич производства на всех уровнях. Люди оказываются в абсолютно новой среде без привычных методов решения простых вопросов. И то, что “в хаосе” делалось за полгода, в новой среде перестает делаться в принципе.
Весь этот пассаж был ровно к тому, что когда вы приходите в новую культуру с целью ее изменить, то будьте готовы к тому, что скорее всего вам придется смириться с тем, что часть из ваших подходов будет отвергнута напрочь, а часть модифицирована под те условия в которых вы находитесь. Как пример, 25 декабря не имеет ничего общего с днем рождения Христа, а относится к языческому празднику зимнего солнцестояния. Вот такая вот интеграция культур 🙂
#мысли #культура #рассуждения
Пару дней назад Bloomberg опубликовал статью-расследование о том, как обстоят дела в игровом направлении Amazon.
Основной тезис заключается в том, что даже наличие бесконечных ресурсов, и доступ к хантингу рок-звезд индустрии не дает вам гарантии сделать великую игру.
Вину в провале возложили на главу подразделения, который в играх не шарит, а знает только про KPI амазоновские. Отчасти это так, но есть еще пара, на мой взгляд важных моментов.
На мой взгляд, основной проблемой явилась разница культур разработки сервисов в Амазоне и того, как делаются игры в тысячах студий. А так же, как следует из статьи, нежелание адаптироваться к тому, что люди, которые придут делать игры в Амазоне в первую очередь придут делать игры, а уж вторым пунктом будет Амазон. Хотя за всех сказать не могу.
В геймдеве за все эти годы привыкли к другому подходу.
Задача с эстимейтом в три месяца, которую делает один человек полгода -- нормально. В контексте той культуры, которая уже сложилась. Попытка распилить задачу обычно заканчивается великим фейлом и катастрофическим рассинхроном между отделами.
Кранчить месяцами -- что здесь такого? “Так делаются все великие игры”. Вера в этот тезис сидит настолько глубоко в мозгах, что иногда испытываешь физический дискомфорт, когда уходишь в отпуск, а мог бы еще чуть-чуть поработать.
Переобуваться в воздухе и переделывать все к чертовой матери за две недели до релиза - легко. Потому что “вдруг” поняли, что это не тот пользовательский опыт, который мы хотим доставить нашим игрокам.
Минимум документов - максимум общения и тонны прототипов, большая часть из которых никуда не пойдет. На этой хрупкой договоренности строится огромная часть разработки, особенно на старте продукта. Невозможно выдать новую крутую механику на бумаге.
Все это выглядит, как набор анти-паттернов управления. И это действительно так. Но как только волевым решением менеджмента ломается привычная для многих культура происходит паралич производства на всех уровнях. Люди оказываются в абсолютно новой среде без привычных методов решения простых вопросов. И то, что “в хаосе” делалось за полгода, в новой среде перестает делаться в принципе.
Весь этот пассаж был ровно к тому, что когда вы приходите в новую культуру с целью ее изменить, то будьте готовы к тому, что скорее всего вам придется смириться с тем, что часть из ваших подходов будет отвергнута напрочь, а часть модифицирована под те условия в которых вы находитесь. Как пример, 25 декабря не имеет ничего общего с днем рождения Христа, а относится к языческому празднику зимнего солнцестояния. Вот такая вот интеграция культур 🙂
#мысли #культура #рассуждения
Bloomberg.com
Amazon Can Make Just About Anything—Except a Good Video Game
The company produces successful movies, TV shows, e-readers and speakers, but gaming has proven difficult to crack.
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…
Встречи один на один
6 лет назад мне в календарь пришел инвайт на митинг со странным заголовком “1:1 P.M.” Организатором был мой менеджер. Как настоящий программист я сразу же пошел писать в чатик менеджеру, что это он от меня хочет и зачем этот митинг? Точного ответа не помню, но из разъяснений я узнал, что P.M. -- мои инициалы, а не Project Manager, а встреча предназначена для того, чтобы я мог поделиться своими проблемами, вопросами и вообще о чем угодно поговорить с руководителем. Для меня это был шок. Регулярная встреча, где я могу официально бомбить и говорить все что думаю. В моей голове всплыл Картмэн произносящий фразу: “Щикарно”
Через некоторое время я сам стал ресурсным руководителем и продолжил практику проведения встреч один на один с сотрудниками. И все шло хорошо ровно до одного момента, как в какой-то момент, я понял, что обсуждать с людьми особо уже и нечего. Ничего не горит, народ успокаивается и все, вроде бы, хорошо. Я задумался, а все ли я правильно делаю и стал заколебывать своих коллег с которыми провожу 1:1, что же не так с этими встречами. Не знаю почему не забил, просто пятой точкой чувствовал, что что-то не так. По итогу этих встреч, рефлексии, чтения умных книг и статей у меня появился список правил для проведения 1:1
* Записывать не только результаты встреч, но и свои мысли с пояснением к этой встрече. Как проходила встреча, как я воспринимаю ту, или иную ситуацию. Это позволяет, через большое кол-во времени вспомнить не только договоренность, но и контекст в котором эту договоренность приняли.
* Доступ к записям должен быть у меня и сотрудника, чтоб он мог в любой момент увидеть о чем мы договорились по результату.
* Не начинать встречу с вопроса: “Ну че? Как дела? Как сам(а)?”. Small Talk на отвлеченную тему в начале встречи дает людям возможность расслабиться и быть чуть более откровенными.
* Слушать и не перебивать. Большую часть встречи должен говорить мой визави. Я, как менеджер, хочу услышать мнение коллеги о моей работе и о делах внутри юнита, а не выдавать тонны обратной связи на протяжении всей встрече. Поговорить-то я люблю.
* Не воспринимать работу человека, как само собой разумеющееся. Всегда говорить спасибо за отдельные моменты в работе.
* Корректирующая обратная связь (куда ж без нее) должна быть с фактами и возможными альтернативными действиями, которые мог бы предпринять человек. гуглить по (STAR/AR)
* Добавлять due date к Action Point-ам, которые выработали на встрече.
* Всех своих менеджеров приучать делать то же самое 🙂
По ссылке вы можете прочитать статью, которая примерно про то же, что и я написал, только интереснее 🙂
https://medium.com/@chris.g.chiu/engineering-management-distilled-a-guide-to-one-on-ones-5b6cceb095b7
#инструменты #ошибкименеджера
6 лет назад мне в календарь пришел инвайт на митинг со странным заголовком “1:1 P.M.” Организатором был мой менеджер. Как настоящий программист я сразу же пошел писать в чатик менеджеру, что это он от меня хочет и зачем этот митинг? Точного ответа не помню, но из разъяснений я узнал, что P.M. -- мои инициалы, а не Project Manager, а встреча предназначена для того, чтобы я мог поделиться своими проблемами, вопросами и вообще о чем угодно поговорить с руководителем. Для меня это был шок. Регулярная встреча, где я могу официально бомбить и говорить все что думаю. В моей голове всплыл Картмэн произносящий фразу: “Щикарно”
Через некоторое время я сам стал ресурсным руководителем и продолжил практику проведения встреч один на один с сотрудниками. И все шло хорошо ровно до одного момента, как в какой-то момент, я понял, что обсуждать с людьми особо уже и нечего. Ничего не горит, народ успокаивается и все, вроде бы, хорошо. Я задумался, а все ли я правильно делаю и стал заколебывать своих коллег с которыми провожу 1:1, что же не так с этими встречами. Не знаю почему не забил, просто пятой точкой чувствовал, что что-то не так. По итогу этих встреч, рефлексии, чтения умных книг и статей у меня появился список правил для проведения 1:1
* Записывать не только результаты встреч, но и свои мысли с пояснением к этой встрече. Как проходила встреча, как я воспринимаю ту, или иную ситуацию. Это позволяет, через большое кол-во времени вспомнить не только договоренность, но и контекст в котором эту договоренность приняли.
* Доступ к записям должен быть у меня и сотрудника, чтоб он мог в любой момент увидеть о чем мы договорились по результату.
* Не начинать встречу с вопроса: “Ну че? Как дела? Как сам(а)?”. Small Talk на отвлеченную тему в начале встречи дает людям возможность расслабиться и быть чуть более откровенными.
* Слушать и не перебивать. Большую часть встречи должен говорить мой визави. Я, как менеджер, хочу услышать мнение коллеги о моей работе и о делах внутри юнита, а не выдавать тонны обратной связи на протяжении всей встрече. Поговорить-то я люблю.
* Не воспринимать работу человека, как само собой разумеющееся. Всегда говорить спасибо за отдельные моменты в работе.
* Корректирующая обратная связь (куда ж без нее) должна быть с фактами и возможными альтернативными действиями, которые мог бы предпринять человек. гуглить по (STAR/AR)
* Добавлять due date к Action Point-ам, которые выработали на встрече.
* Всех своих менеджеров приучать делать то же самое 🙂
По ссылке вы можете прочитать статью, которая примерно про то же, что и я написал, только интереснее 🙂
https://medium.com/@chris.g.chiu/engineering-management-distilled-a-guide-to-one-on-ones-5b6cceb095b7
#инструменты #ошибкименеджера
Medium
Engineering Management Distilled: A guide to one-on-ones
From inspirational principle to prescriptive mechanics. Based on experience and the writing of some of the greats in engineering…
Этот канал заброшен, новых публикаций не ожидается.
Тем временем, я начал писать вот тут: https://www.tgoop.com/ManageAndLead
Присоединяйтесь!
Тем временем, я начал писать вот тут: https://www.tgoop.com/ManageAndLead
Присоединяйтесь!
Telegram
Manage things, lead people
Истории про управление разработкой софта в больших компаниях.