-
Образовательно-развлекательный блог про управление разработкой. Личный опыт, рефлексия прочитанных книг, ссылки на исследования.
Управленческие антипаттерны
Юный радиолюбитель.
Такое происходит, когда, начитавшись книжек и насмотревшись видео с конференций, адепт без опыта управления начинает внедрять всё увиденное. Тут сразу начинается: скрам всем командам, портфолио-канбан борд, value-стримы, chaos engineering, trunk-based development, TDD. Всё это по отдельности — полезные инструменты; проблема в том, что все это начинает внедряться одновременно, создавая хаос и отторжение у остальной части организации. Лечится хорошим ментором и обратной связью.
Почему анти-паттерн так называется? Потому что главное правило радиста: “не крути все ручки сразу”.
Оператор социальной системы.
Проявляется, когда человек вырос в руководителя в компании и продолжает долгое время работать в хорошо знакомой среде. Прекрасно знает, с кем и как договариваться, прекрасно знает, где воткнуть костыль, чтобы запустить новую фичу. Однако кругозор не пополняется информацией из внешнего мира. Про контейнеры, кубернетес, облака и аджайл не слышали, и так нормально работаем! В итоге опыт человека релевантен только этой компании и не имеет никакой ценности за её пределами (На мой взгляд, вообще полезно задумываться “имеют ли ценность мои навыки за пределами компании?”). Лечится конференциями, воркшопами, притоком свежих кадров в орагинизацию.
Стратег-визионер.
Оторванный от реальности и не погруженный в контекст руководитель. Рисует красочные картины будущего о том, как всё организовать и как классно все будет работать. Однако, чтобы прийти из точки А в точку Б, нужно знать не только желаемое состояние, но также и текущее положение дел, возможности, ресурсы. В результате, стратегии и далеко идущие планы скорее напоминают письма Деду Морозу: “Хочу на новый год continuous delivery во всех командах и высокое качество продукта. Серёжа, 43 года”. Такое положение дел зачастую вызвано непониманием текущих ограничений и отсутствием обратной связи о реальном положении дел. Широко распространено в больших компаниях с длинной цепочкой иерархии.
Данные анти-паттерны не являются ярлыками, которыми следует клеймить людей. Скорее это состояния, в которых каждый из нас (я так точно) может оказаться. Важно уметь замечать себя в подобном состоянии, критически осмыслять и корректировать свои действия.
#менеджмет #рассуждения
“В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности” — принцип Питера.
Как “принцип Питера” реализуется в больших компаниях.
Есть множество ролей, зоны ответственности которых трудно сформулировать: продакт-менеджеры, архитекторы, лиды команд. Нечетко определенная граница, приводит к ситуации, что карьерный путь к такой роли не очевиден, и на подобную позицию попадают люди с совершенно разным опытом и набором навыков.
Как может происходить процесс повышения в вымышленной компании: человек хорошо делает работу на своей текущей позиции, его замечают и повышают. Разработчик тащит фичу, старается найти компромиссы с продакт-менеджером, вкладывается в тестирование. Отличный работник! – Давайте сделаем его лидом команды!
И вот тут пропущен один важный шаг — подумать. А точно ли повышение — это уместная награда в данной ситуации? Если да, то какие функции в компании закрывает лид команды? Какие навыки ему для этого необходимы? Соответствует ли им претендент? Про это я уже писал вот тут: Leadership pipeline
В итоге человек повышается в роль без конкретных ожиданий от него, а заодно получает позитивное подкрепление: “я делал то, что я делал, за это меня повысили, значит я делаю свою работу хорошо”.
В масштабах небольшой компании такой подход не создает проблем — всё и так держиться на личных связях, и не важно, кто какую должность занимает. В большой же компании это приводит к полной реализации принципа Питера
Если многократно повторить процесс, описанный выше, то мы оказываемся в ситуации, что руководитель (его так же когда-то давно повысили за то, что он делал хорошо свою прошлую работу) не имеет четких ожиданий от роли, в которую повысили героя истории (который считает, что делает всё правильно, его же повысили). Так и получаются, что в компании все делают что-то “важное”, на местах всё выглядит прилично, а в масштабе компании получается цирк с конями и бюрократией. В итоге имеем: продакт-менеджеров, которые умеют только заводить митинги и клепать презентации; архитекторов, мастерски рисующих диаграммы, совершенно не знающих нужд стейкхолдеров; руководителей, которые умеют поддерживать текущую рутину, но не ведут команду к какой-то цели.
Повышать за былые заслуги — это, на мой взгляд, такое себе решение. За успехи в прошлом есть бонусы и премии, повышение же — это про реализацию потенциала человека в организации, и количество критериев, которые следует принимать во внимание, гораздо больше.
#ошибкименеджера #карьерныйпуть #менеджмент
Bonus-Driven Development — обратная сторона годовых ревью
Под конец года в компаниях наступает оживление — всё, что откладывалось и игнорировалось на протяжении всего года, пытаются успеть сделать в последние месяцы. Особенно если в компании есть годовые ревью, особенно если оценка в конце года влияет на размер бонуса.
Годовые ревью и постановка целей для сотрудников — дело хорошее. Правда иногда бывают перегибы, когда глобальные изменения пытаются вписывать в цели людям, у которых нет полномочий их выполнить. Например: вывести из эксплуатации старую БД, на которую завязаны десятки команд; внедрить политики безопасности для SOx/GDPR/CMA-compliance; смигрировать всей компанией на новую систему контроля версий, CI-систему или API стандарт; выстроить процесс найма и т.д. Отдельный вопрос, почему люди соглашаются на годовые цели, не обладая полномочиями для их выполнения. (Отчасти, тут уместно процитировать анекдот: “либо ишак сдохнет, либо падишах помрет”, про это будет отдельный пункт в конце).
Типичный сценарий подобных проектов такой: в начале года происходит несколько встреч с коллегами из смежных подразделений; становится понятно, что проблема сложнее, чем казалась; проект вытесняется краткосрочными задачами и постепенно уходит на второй план. А под конец года начинается чехарда и попытки на скорую руку провести глобальное изменение, хуже всего, когда это получается — чтобы внедрить политики безопасности по-быстрому, надо всего-то забрать у всех разработчиков доступ к продакшену. Мелочь… Что может пойти не так?
Интереснее всего, что происходит, когда цель выполнить не получается, а бонус получить хочется: начинаются бравурные посты на внутренних ресурсах о том, как это важно и трудно, презентации на all-hands митингах, картины светлого будущего и другие продвинутые техники фасадо-строительства. Главное показать прогресс и доказать, что изначально оговоренный результат в этом году получить нереально, но вот в следующем — точно, и по этому сроки нужно перенести на следующий год. Короче, начинает работать принцип: вспотел — покажись начальству.
В итоге непонятно, чего больше —вреда или пользы — от годовых целей сотрудников.
Однако в компаниях такие правила игры, и с ними приходится считаться. Несколько выводов о постановке целей:
Назначить ответственного не гарантирует исполнения. Если политики безопасности и соответствие требованиям регуляторов действительно нужны в организации, то и управлять этим следует руководителю соответствующего уровня. Распространенный анти-паттернт: copy-paste целей через все уровни иерархии до линейных руководителей, без попыток декомпозиции.
Отказываться от целей, на которые вы не можете повлиять. Если руководство всё же давит, то имеет смысл сделать декомпозицию такой цели и классифицировать получившееся: могу сделать сам; могу повлиять, но не могу контролировать; не могу повлиять. Если всё же не получится отказаться, то это хотя бы позволит договориться, чтобы вас оценивали на основании того, что вы можете контролировать.
Не вписываться в глобальные инициативы, если не собираетесь оставаться в компании.
Это как минимум неэтично, а также может негативно повлиять на профессиональную репутацию. Мало ли что люди обсуждают со знакомыми за пивом и у кого собирают рекомендации на кандидата. В итоге красивая строчка в резюме после проверки через цепочку знакомых превращается в красный флаг.
#рассуждения
Важные мелочи: общие чаты
Иногда замечаю, как совершенно небольшие вещи приводят к большим трудностям.
Ну например, случилось такое, что требуется узнать что-то у команды, с которой ты активно не работаешь и никого там не знаешь. А куда писать? Кто там, в этой команде? Как про них узнать? Зачастую это приводит к появлению отдельных чатиков по каждому вопросу, ответы теряются в личных сообщениях, вопросы повторяются. Если подходящий контакт найти не удаётся, то начинается эскалация через менеджеров всех уровней. А теперь представьте неэффективность при масштабе в сотню команд...
Хорошо, когда на возникшую потребность, в компании есть готовый ответ, как это сделать. В случае с коммуникацией — например, открытый канал “название_команды_public” в slack/teams/чтоугодно. Хорошо, когда это не какое-то эзотерическое правило или креатив каждой отдельной команды, а понятный паттерн, зная который, любой человек в компании может его применить к любой команде. В идеале, зная какой-то факт (например, название команды), можно вывести необходимую информацию: например, название команды является тегом, которым помечены все репозитории команды в gitlab, все дашборды в grafana и так далее.
#важныемелочи #менеджмент
Одна из причин, почему оценки не говорят о сроке завершения задачи
Оценивая задачу, мы пытаемся определить объем работы, необходимый для её завершения. Конечно точность оценки сильно зависит от уровня понимания системы, но, при определенных условиях, можно прикинуть, сколько времени потребуется на каждый из этапов: написать код, протестировать, подготовить релиз.
Однако, время на выполнение работы в рамках задачи — это только одна часть уравнения. Другой аспект зачастую упускается — время ожидания задачи между этапами работы: ожидание код-ревью, ожидание тестирования, ожидание в ветке до релиза.
Время ожидания в очередях не берется в расчёт при оценке, хотя именно оно и составляет существенную часть от общего времени выполнения. Полезная метрика эффективности процесса — отношение времени активной работы (когда кто-то реально что-то делает по задаче) ко времени цикла (фактическое время от старта работы до завершения).
Если логически разделить статусы в JIRA на те, где реально делается работа, и те, в которых задача просто ждёт, то посчитать это метрику будет несложно. А вот результат многих удивляет — хорошо, если это соотношение будет 0.5 (а может быть и меньше). Это значит, что, давая оценку, мы принимаем во внимание только 50% от реального времени и на основании этого пытаемся строим планы!
Хотите улучшить ваши оценки? Посмотрите, где скапливаются очереди задач, ожидающих следующего этапа разработки. До тех пор пока ожидание в очередях составляет существенную часть от времени цикла, работать над улучшением точности оценок бесполезно. А вот чтобы увеличить долю эффективного времени, следует переосмыслить сложившиеся процессы, сбалансировать загрузку людей, обеспечить доступность необходимых ресурсов и вот это вот всё, подразумеваемое под словом “менеджмент”.
#менеджмент #инструменты #оценимнеэтотскоуп
Ward Cunningham, соавтор подхода Extreme Programming, рассказывает про аналогию, из которой впоследствии появился термин technical debt. Сейчас техническим долгом зачастую называют то, что на деле является непрофессионализмом: пренебрежение базовыми практиками (например, тестами), код в спагетти-стиле и беспечный подход к разработке, который может обернуться существенными рисками для компании.
Ключевая идея в работе над устранением технического долга — отражать в структуре приложения знания, накопленные в процессе разработки. Приложение следует воспринимать не просто как набор фичей, а еще и как модель предметной области. Степень адекватности модели напрямую влияет на скорость добавления новой функциональности. Оперируя неадекватной моделью предметной области, мы вынуждены выплачивать некоторый процент, выражающийся во времени разработки.
Видео на 4 минуты. Ссылка: https://youtu.be/pqeJFYwnkjE
#видеопотеме
Какие проблемы решает реорганизация?
Я видел довольно много реорганизаций в компаниях: перегруппировать команды, добавить слой мидл-менеджмента, поменять зоны ответственности и т.д. Некоторые из них имели смысл и были совершенно оправданны, некоторые скорее походили на “преставление кроватей” из анекдота, который я постеснялся вставить в качестве эпиграфа.
Примеры проблем, которые решаются реорганизацией:
Упростить процесс принятия решений
Лицо, принимающее решения, находится далеко в иерархии от команд, где известен контекст и информация, необходимая для решения. Такая структура приводит к появлению очереди из вещей, ожидающих согласования, новые инициативы стартуют медленно, а технически небольшое изменение может выродиться в месяц согласований. Вестником такого рода организационной неэффективности являются профессиональные изготовители слайдов для внутренних презентаций. У высоких менеджеров времени мало, контекста не хватает, а разобраться в проблеме хочется, вот и начинается показ презентаций с ожиданием решения.
Другой пример — управление бюджетами: тимбилдинг организовать, специальное оборудование закупить, на конференцию людей отправить (бывает, что цепочка согласований занимает дольше, чем время от старта продажи билетов до начала самой конференции). Для решения этих проблем реорганизация — хороший инструмент.
Улучшить коммуникацию между командами
Например, одна команда предоставляет API, а другая его использует. Эти команды находятся в разных департаментах и не очень дружат между собой, а их общий руководитель — настолько высоко, что в случае эскалации проблемы, у него совершенно не хватает контекста, чтобы конструктивно её решить, и все заканчивается фразой: “Ребята, вы же профессионалы, договоритесь как-нибудь”. Подобные ситуации часто возникают в матричной структуре: дизайнеры репортят верховному дизайнеру, тот, в свою очередь, арт-директору, у разработчиков своя иерархия, у product-manager’ов своя. Вроде все одно дело делают, но у каждой дисциплины свои метрики эффективности и взгляд на то, как надо работать. Руководители оторваны от контекста, говорят на разных языках, и каждый оптимизируется под свои метрики. В итоге страдает общий результат, и ни одна из локальных оптимизаций не помогает. Проблема в системе.
Сфокусировать усилия
Выделить отдельную команду для решения проблемы, которую не получается решить частичными усилиями. Например, выделить команду developer productivity, чтобы унифицировать подходы к разработке и напилить общих библиотек. Это может сработать, если проблема уже сформулирована, и решение понятно. Выделение команды для решения нечеткой проблемы может привести к бюрократизации без какого-либо результата.
Какие проблемы реструктуризация НЕ решает:
Найм и увольнение — в компании зачастую есть люди, которых в ней быть не должно. Не поможет менять тайтлы и ворошить команды в попытках избежать трудного разговора с таким человеком.
Обучение — если у людей не хватает знаний или навыков, не поможет менять тайтлы. Бесполезно переименовывать команду оперирования в DevOps (да, я знаю, что это движение и культура, а не роль. Но кто публикует эти вакансии на linkedin?)
Мотивация — если департамент выгорает, из команд уходят люди, а в процессах полный хаос. Переименование ролей и команд в стиле “тот же хрен только в другой руке” ударит по этой области еще сильнее, показав слепоту руководства к насущным проблемам и породив разговоры в кулуарах о полезности данного действия.
Прежде чем проводить изменения организационной структуры, следует убедиться, что проблема именно в ней. Большая работа — сформулировать цели и спланировать изменения, которые позволят решить проблемы, не сильно добавив новых. А главное — до проведения изменений ответить на вопрос: “Как мы поймем, что новая структура работает?”
#менеджмент #рассуждения
Иногда активная разработка нового продукта начинается ещё до того, как оформилась финальная концепция. Пара примеров из истории: фотохостинг flickr вырос из тулинга для многопользовательской онлайн игры. Twitter начинался как способ поделиться статусом с друзьями по sms (отсюда ограничение на 160 символов в сообщении). Проекты с такой степенью неопределенности возникают нередко: появилась инициатива, есть свободные разработчики — вот и оформилась команда. Правда, не всегда понятно, что конкретно делать…
В такой ситуации то, что в нормальных условиях является хорошей практикой, может помешать успеху. Например:
Приоритизированный беклог может привести к тому, что команда начнет игнорировать новую информацию и продолжать делать то, что написано в беклоге. Забыв про “Responding to change over following a plan”.
Выделение формальных ролей (как пример: архитектор, product-manager) приведёт к игнорированию сильных сторон отдельных людей, и может убить креативность в команде («ну разве может копирайтер или тестировщик знать о том, как делать игру?»).
В этом видео Fred George рассказывает про подход “Programmer Anarchy”, который как раз о том, как не убить гибкость на проектах на ранних стадиях:
Видео: https://youtu.be/Zop0wTPrbk8
#видеопотеме #менеджмент
Метрики для команд: Delivery
Основная часть недовольств в отношении команды со стороны ключевых стейкхолдеров зачастую умещается в одной фразе: “Когда будет фича? Почему так долго?”. Обоснованно ответить на оба вопроса помогают исторические данные.
Полезная метрика — время от старта работы над задачей до её выхода в релиз. И хотя про её полезность написано много умных статей, никаких деталей о том, что конкретно следует делать, не освещается: «Мыши, вам надо стать ёжиками». Поэтому опишу свои попытки реализации.
Первый возникающий вопрос: что считать стартом работы? В зависимости от специфики, стартом работы может быть первый коммит или перевод задачи в соответствующий статус.
Проверим эту метрику по требованиям из прошлого поста, а заодно посмотрим на детали реализации.
Предсказательная способность: Исторические данные показывают направление тренда, что позволяет предполагать, как пойдут дела в будущем. Это верно в случае, если не было значительных изменений – полная смена команды, переход на новый язык и т.д. Также стоит учитывать, что подход к разработке может отличатся для разных подсистем: старый legacy-сервис, где нет CI, и что-то новое, где всё классно; фронтенд и бекенд; мобильная разработка. Везде, где процесс разработки сильно отличается, следует собирать метрики раздельно, иначе получим среднюю температуру по больнице. То есть задачи надо как-то отделять: можно решить отдельными компонентами в JIRA или форматом сообщения к коммиту.
Устойчивость к шуму: Конечно есть задачи, которые завершаются за час, а есть те, что за месяц. Важно смотреть общий тренд во временной динамике. Можно использовать медиану и перцентили. При хорошей выборке это позволяет давать верхнеуровневые оценки. Пример: В команде один iOS разработчик. По историческим данным, половина задач завершается менее чем за 3 дня, 80% задач завершаются менее чем за 6 дней. Сколько займёт сделать фичу, состоящую, например, из 10 задач? С уверенностью 50% — месяц, с уверенностью 80% — два.
Возможность влиять на метрику: Конечно возможны случаи, когда команда не влияет на деплой или отдельные этапы разработки (например, внешнее тестирование). В остальных случаях изменения в команде будут напрямую влиять на метрику: оптимизировать очереди при передаче работы между этапами, автоматизировать ручные действия, снизить время на регрессионное тестирование.
С теорией все понятно, а как собрать информацию? На самом деле, данные о затраченном времени уже есть в таск-менеджере или системе контроля версий:
Если своевременно двигать в JIRA задачи по статусам, то информация о времени нахождения задачи в каждом из статусов сохраняется в истории.
В случае с git есть время первого коммита, есть релизный тег, можно соотнести в какой релиз попал коммит. Правда нужно уметь связать коммит с задачей, что решается сообщениями к коммиту.
Остается открытый вопрос по визуализации.
А есть ли вообще простые способы это делать?! Отчеты в JIRA не помогают, плагины не покрывают потребностей и их не всегда можно подключить из-за корпоративных политик. К сожалению, хорошего инструмента для визуализации я не нашел. Пришлось самому нарукожопить скрипт. По оси X — даты рабочих дней, по оси Y — время завершения задачи в днях. Точка (x,y) говорит, что задача завершилась в дату X и заняла Y дней. Это позволяет видеть тренд, оценивать влияние изменений и оперативно реагировать в случае перекосов. Конечно, поделка на коленке, но работает...
#метрики #инструменты
Реакция на инциденты. Часть 4 Предотвращение
Новым витком в развитии инцидент-менеджмента становится переход от быстрого тушения пожара к предотвращению. Возможно, скромный пожарный инспектор выглядит не так мужественно, как герои пожарной команды, но предотвращать негативные события обходится значительно дешевле, чем заниматься восстановлением.
Инциденты неизбежны: будет случаться что-то новое, ранее невиданное, и уметь быстро реагировать необходимо. А чтобы снизить вероятность повторений, следует научиться извлекать уроки из прошлых событий. Легко сказать и очень трудно реализовать. Вам доводилось участвовать в пост-мортемах — когда собираются все участники инцидента, чтобы разобраться в причинах произошедшего? Есть два расхожих анти-паттерна:
Игры в прокуроров — поиск виноватых, который скатывается в критику и обвинения в непрофессионализме.
Признание очевидного — «Ну да, место на диске закончилось, но мы сейчас на новое железо переедем, и все будет норм». Тут поиск причины незаметно подменяется простой констатацией случившегося, и никаких действий не предпринимается (например обмазать систему метриками и навесить алерты, которые будут срабатывать до наступления критической ситуации).
Постмортемы вообще очень большая тема и про них много написано, правда не в IT, а в тех областях, где цена ошибки очень высока — регулирование воздушного трафика, системы безопасности.
Полезность постмортемов во многом зависит от корпоративной культуры. Два важных аспекта, связанных с ней:
Blameless — не искать виноватых, а искать ошибки в системе, которые позволяют подобным ситуациям происходить.
Sanctionless — не наказывать людей, действия которых привели к ошибкам. Представляете, человек базу работающего сервиса на продакшене удалил: «Терминал перепутал, ошибочка вышла». За такое не наказывать?! Однако, если гонцам, принесшим плохую новость, рубить головы, вы просто перестанете о них узнавать, вот только такие события продолжат происходить. Таким образом, следующий человек, который совершит ошибку, может не сказать о ней, а замести тихонько под коврик... А проблема останется в слепой зоне тикающей бомбой.
Три вопроса, которые помогут сформулировать действия по предотвращению:
- Может ли инцидент повториться?
- Есть ли у нас триггер, чтобы узнать о наступлении проблемы?
- Есть ли у нас готовое решение в случае повторного возникновения?
Еще один вопрос, которым следует задаться: а почему инцидент не имел более серьёзных последствий? Кто-то, кто хорошо знает систему, был рядом и помог. У кого-то появилась идея, что поискать в логах. Кто-то вспомнил, какое изменение в коде могло вызвать проблему. В таких ситуациях проявляется целый пласт знаний о поведении системы, который не записан в документации, не отражен в архитектуре, а по-прежнему живет только в головах людей. И каждый раз всплывает что-то новое — это и делает нашу работу такой интересной.
#менеджмент #рассуждения
Реакция на инциденты. Часть 3 Дежурства
Подход “звонить одному человеку, когда что-то сломалось” не может долго существовать — человек выгорает, количество сервисов растет, на всё рук не хватит. В конце концов, люди в отпуска ходят! В итоге в компании происходит переход к посменным дежурствам. Хорошо если используется специальный софт, который позволяет настроить расписание дежурств, политики эскалации, отсылку алертов на телефон дежурному. Странно, но даже при цене базовой подписки ниже, чем затраты на печеньки в офисе, такое используется не везде.
Пожалуй, внедрение дежурств — это в некотором роде фазовый переход в управлении разработкой. Этот процесс требует комплексных действий от менеджмента, подход “организуйтесь как-нибудь” уже не сработает: нужно выстроить новые ожидания от ролей, что дежурить — это теперь часть работы; нужно организовать соответствующие доступы, чтобы дежурный реально мог что-то сделать; нужно как-то юридически оформить работу внеурочно; дежурства надо оплачивать, даже если ничего не произошло, человек же был наготове, планы свои отменил.
Для проведения изменений такого уровня, необходима поддержка и действия со стороны руководства. Стимулом к действиям по выстраиванию инцидент-менеджмента может послужить понимание цены простоя и ответ на вопрос “Готова ли компания платить эту цену в будущем?”.
Следующая проблема, которая вскрывается после внедрения дежурств — знания о работе систем распределены неравномерно. И это не только про тонкости работы сервиса, компонента или отдельной технологии. Есть вещи более банальные: не все знают, где лежат логи; какой синтаксис запросов в агрегаторе логов; какой из 30 графиков в Grafana показывает процент ошибок.
А главный вопрос — как новым в компании людям получить эти знания, чтобы со временем хорошая практика не выродилась?
Инцидент-менеджмент на этом уровне тесно связан с другими процессами в компании:
Как происходит обучение новичков — что должен узнать новый человек в компании, чтобы продуктивно работать; сколько времени занимает его подготовка.
Обмен знаниями внутри команды — знания о специфике работы сервиса, живущие только в одной голове, очень быстро становятся проблемой (bus factor).
Выбор технологий — то, как технологию потом поддерживать, и сколько людей умеют ее “готовить”, становится фактором при выборе.
Стандарты написания кода — писать логи и метрики для новых фичей так, чтобы их понимал каждый разработчик.
Подход к документации — что вообще делает сервис, насколько он критичен, какие API сервис предоставляет, как их вызывать, и насколько легко отправить тестовый запрос.
Таким образом, подход к реакции на инциденты многое говорит об устройстве процессов в компании в целом. Когда потенциальный работодатель на интервью спросит: “У вас есть вопросы?”. Непременно поинтересуйтесь: “Как устроена реакция на инциденты в компании?” и услышав стыдливый ответ… А впрочем решать вам.
#менеджмент #рассуждения
Реакция на инциденты. Часть 1 «Героизм»
На удивление, тема инцидент-менеджмента не особо поднимается в сообществах. Как в компании выстроены процессы, связанные с восстановлением своих сервисов, не особо обсуждается за ее пределами. Не могу припомнить каких-то best-practices, кроме SRE (Site Reliability Engineering) от Google. А что делают те, кто не гугл?
Типовой сценарий такой: команда усиленно работает, готовит продукт/сервис/компонент к выпуску. После первого публичного релиза обнаруживается много упущенных моментов. Разумеется, что-то начинает отваливаться, происходят отказы, сервис некоторое время недоступен. Растёт давление со стороны ключевых стейкхолдеров, все на взводе.
Каждый инцидент начинается с поиска людей, готовых подключиться к разрешению ситуации. Постепенно появляются «пожарные» чатики, в кулуарах обсуждают, в чем была проблема, кто «накосячил», а кто «затащил». Со временем формируется круг «героев», которые «приходят на помощь», когда все идет не по плану.
Так как инциденты быстро эскалируются, и о них узнает вся управленческая иерархия, «герои» попадают в поле зрения руководителей высокого уровня, начинают быть на хорошем счету, со временем зарабатывают репутацию в компании. Создается замкнутый круг: пожары — это плохо, тот, кто их тушит — молодец. Предотвращению же не уделяется должного внимания, так как хвалят за тушение, а не за предотвращение. Это формирует отношение к инцидентам как к чему-то, что нужно быстро разгрести и «восстановить мир и покой».
Отказ сервиса может случиться днем, ночью, на пике трафика, когда вложили чемодан денег в рекламу, когда «герой» в отпуске. Инцидент может иметь непредсказуемые финансовые последствия для бизнеса.
Это случайное событие, которое может произойти в любой момент и продлиться неопределенное количество времени.
Остается загадкой – почему многие компании не идут дальше этого уровня?
#менеджмент #рассуждения
Как теряются знания о проекте и что с этим делать
Несмотря на то, что “Engineering is about trade offs”, мы часто не помним, как проект пришёл к тому состоянию, в котором находится. Из личного опыта помню несколько примеров, когда подключаясь к новому проекту, начинал вникать в технические детали, и обнаруживал, что один и тот же сервис одновременно использует и Memcache и Redis. В такие моменты чувствуешь себя детективом-археологом – находишь по истории что было добавлено последним и кто автор; автор уже не работает в компании; спрашиваешь у команды «а почему отказались от одного и перешли на другое?”». Тупик! Никто уже не помнит!
Разумеется, вместо Redis и Memcache, могут быть драйверы для работы с БД, планировщики задач, или что угодно. В такой ситуации, когда неизвестна история принятия решения, и требуется внести изменения в код, оказываешься на развилке: либо слепо поверить, что текущее решение «хорошее», либо рискнуть изменить его, не обладая полной информацией. Есть, конечно, третий путь – проверить, но это не всегда возможно и может занять много времени.
В итоге имеем: «работает, не трогай!». В экстремальном случае, когда старая кодовая база сменила нескольких владельцев, может оказаться, что критичный сервис поддерживается на уровне исполнения ритуалов и церемоний, без понимания сути. Как в романе у Азимова священники обслуживали атомные реакторы.
На тему истории технических решений Michael Nygard (автор книги про оперирование “Release It!”) описал подход, который называется “Architecture decision record”. Суть идеи:
Создаем прямо в репозитории папку, куда будем писать все решения.
Каждое решение — отдельный текстовый файл с порядковым номером. Например: ADR-42.txt
В каждом файле простая структура:
Заголовок: о чем это вообще, можно добавить авторов и другую метаинформацию
Статус: “proposed”, “approved”, “deprecated”
Контекст: свободным языком описываются обстоятельства, имеющие место на момент принятие решения – технические, организационные факторы, события на проекте.
Решение: Какие альтернативы были рассмотрены, как они оценивались, что в итоге выбрали.
Последствия: что произошло после реализации решения.
А какие решения записывать? Те, что влияют на общую структуру проекта, атрибуты качества, зависимости, API. Лучше записать что-то неважное, чем пропустить что-то важное. Со временем команды калибруются и начинают ориентироваться, что действительно стоит записывать.
Конечно это требует дисциплины: приучить команду записывать, периодически просматривать и обновлять, делать кросс-командные ревью.
Из плюсов: История мигрирует вместе с репозиторием, проводить ревью архитектуры становятся легче, знания о причинах изменений сохраняются.
На github даже консольная утилита есть: https://github.com/npryce/adr-tools
#инструменты
Делать больше, чем от тебя ждут?
Underpromise, overdeliver — эту мантру каждый хотя бы однажды слышал как квинтэссенцию трудовой благодетели.
Давайте нарисуем картину того, как она могла бы выглядеть в жизни применительно к конкретному человеку (мы ж архитекторы матрицы и инженеры человеческих душ 😎).
Так вот, пусть нашим героем будет рядовой программист из небольшой команды, не лид, но соображающий, неравнодушный и с праведным огнем в глазах. Рано или поздно наш паладин окажется в ситуации, когда релиз (фича, спринт, нужное подчеркнуть) под угрозой, а ответственный человек не уследил (в отпуске, проморгал, разгребает другие конюшни). Из чувства ответственности перед заказчиком и защищая честь команды, он начинает подбирать разбитое стекло: посидел пару ночей на работе сам, уговорил нескольких коллег напрячься, побегал по QA и девопсам и — о чудо! — релиз спасен. Герой скромно стоит в сторонке, команда довольна (затащили!), руководитель, закончив с конюшнями, достает из кармана премию и тюбик полироли для доспехов нашего воина. Идеально.
Время идет, паладин скучает и вспоминает подвиг, серотонин падает, кортизол растет, а повода вновь надеть доспехи все нет и нет. В какой-то момент наш герой подсознательно решает, что у самурая нет цели, есть только путь и начинает наносить непоправимое добро везде, куда может дотянуться: топит за инженерную культуру, следит за бэклогом, приносит новые практики. Что-то приживается, что-то нет, но в целом все идет на пользу проекту и команде, руководитель изредка подкидывает премию и регулярно снабжает средством для удаления ржавчины с доспехов (потенциальный лид же растет).
Со временем паладин находит очередное разбитое стекло и яростно начинает его подбирать. Только сейчас он чувствует себя уже увереннее: уговоры плавно приобретают тон распоряжений, а переговоры с лидом QA про выход людей в выходные иногда скатываются в ультиматумы (если не выйдут, то мы все умрем). Это начинает раздражать коллег, потому что пожара на самом деле может и не быть, а паладин явно топчется по чужим полянам. В результате воина света перестают звать на митинги по планированию и начинают подсознательно ограничивать его активность, но наш герой только удваивает усилия...
Зачастую такая ситуация заканчивается разочарованием и, как модно сейчас говорить — выгоранием. В итоге высока вероятность потерять воина, да и команде будет нанесен серьезный урон. А все почему: потому что упущен ровно один важный момент — договориться об ожиданиях и выработать социальный контракт. Например, после первого подвига, у паладина с руководителем мог бы состояться такой вот разговор:
— Привет! Спасибо, что поддержал и подстраховал ситуацию, я ее упустил, май бэд.
— Привет. Да ничего, я просто не мог ничего не сделать.
— Отлично. У меня к тебе просьба: в такой ситуации в следующий раз сразу говори. Обсудим, что за проблема, что с ней делать, дам тебе ресурсов если нужно и помогу, чтобы было попроще, ок?
— Да, договорились, спасибо! Мне действительно интересны подобные задачи и я хотел бы уметь это делать лучше. Могу я попросить привлекать меня в случае чего?
— Понял, буду иметь это в виду.
Это дало бы руководителю брейкпоинт, в котором можно отрегулировать ситуацию, направить и поддержать паладина, помочь ему пройти сложный путь, удержать от ошибок и борьбы с ветряными мельницами, предотвратить урон команде.
Если вы руководитель, то рекомендую внимательно следить за такими паладинами, потому что они случаются не только среди линейных сотрудников, где потенциальный ущерб относительно невелик, но и среди некоторых руководителей, где цена ошибки растет экспоненциально и может оказаться фатальной. Они же — ваш управленческий ресурс и потенциальные саксессоры, если вы сумеете правильно их подготовить.
Если же вы узнаете себя в герое этой сказки, то... а впрочем, нет, продолжайте. Помнится, в то время я бы просто рассмеялся в ответ.
#ошибкименеджера #карьера
Инструмент оценки кандидатов, доступный абсолютно всем – испытательный срок.
В моём опыте, во многих компаниях к ИС было отношение как к стоп-крану в поезде. Должно произойти что-то очень серьёзное, чтобы кандидату не закрыли ИС – подраться в офисе, уйти в запой, абсолютно забивать на работу. Такие вещи как раз и можно проверить на интервью и этапе сбора информации о кандидате (конечно ошибки тоже возможны).
А тем временем испытательный срок — это продолжение процесса найма. Если он закрывается у 100% кандидатов, в системе найма что-то не так. Каждый этап должен быть фильтром. Нанимаете разработчиков без знания вашего стека технологий? Сколько времени требуется, чтобы начать в нем ориентироваться, закрывать простые задачи, не требующие доменных знаний? Пожалуй, за 3 месяца вполне можно.
Без сформулированных критериев вся оценка будет скатываться к фразе: “Вроде норм”. И это очень опасно: в долгосрочном периоде мелкие недочеты будут аккумулироваться и снижать планку для всей команды. Поясню идею примером из математики:
0.99^100 = 0.37
1.01^100 = 2.7
(^ — возведение в степень)
0.99 и 1.01 — довольно близкие значения, однако на длинной дистанции разница становится существенной. Сравнивая эффективность людей в команде, следует смотреть не на то, как дело было вчера и сегодня, а анализировать картину в динамике. Для этого и нужны перформанс-ревью в компании, если, конечно, не подходить к ним как к формальности.
Четкие критерии оценки, обозначенные ожидания и своевременная обратная связь как раз и позволяют понять, отвечает ли кандидат требованиям компании.
Испытательный срок — такой же фильтр при найме, как и все этапы собеседования. Это также страховка от неожиданностей, но в первую очередь — возможность посмотреть человека в деле.
#найм
Про технологические инициативы и стратегию "любой ценой"
Пару недель назад мы обсуждали перевод статьи про то, как в Uber решили пересмотреть архитектуру своего клиентского приложения, потому что старое стало попросту нестабильным, возросла сложность, кол-во патчей и хотфиксов.
Причина хаоса в старом — бурный рост. Кто его не переживал, просто скажу, что в таких условиях концентрация людей, которые знают, как развивать разработку и архитектуру всего приложения близка к концентрации действующих веществ в гомеопатических препаратах.
Таких людей мало и они зачастую заняты другими “более важными вещами”. Это приводит к тому, что у каждой фичи свой особый технологический путь и в один момент ты становишься настолько нестабильным, что каждая следующая фича требует в три раза больше времени на регрессию, чем на разработку, а потом еще пары десятков патчей, чтоб привести ее к рабочему виду. (В моей практике была фича на которую мы выпустили больше 30 патчей. В мотивации к фиче тоже было “Необходимо переписать с нуля”)
В общем, решили ребята “переписать приложение с нуля”. Собрали небольшую группу из архитекторов, разработчиков и дизайнеров, которая должна была разработать новую архитектуру. Погрузились с головой в работу.
В процессе пересмотра архитектуры команда сменила основную технологию разработки с Objective-C на Swift. Стали использовать реактивную парадигму разработки. В общем, как говорит один мой знакомый: “Разошлись на все бабки”. И это дало свои результаты.
Цитата из статьи:
“С небольшим количеством инженеров удалось разработать отличную функциональность за короткое время. Большая часть продукта готова. Руководство довольно”
Но, если бы было все так сладко, то и статьи бы не было.
Не буду погружаться в детали, советую вам самим прочитать этот лонг рид. Наверняка некоторые из вас сталкивались со схожими проблемами.
Вся соль этой истории, на мой взгляд, заключается в том, что управленческая вертикаль инженерии шла на эту авантюру без плана Б и объяснения всем окружающим, что переход на early adopt технологию сопряжен с огромным риском, но у нас есть план Б и вот вехи на которых мы будем принимать решение о дальнейшем движении.
В ситуации, когда проблемы стали настолько серьезными, что игнорировать их было невозможно, использовали стратегию “любой ценой”, потому что менеджеры не могут ошибаться и надо только чуть-чуть поднажать. А тут включается еще и корпоративная культура. На сколько сложно признать свою ошибку внутри компании?
Главная подпитка позиции "затащить любой ценой" заключается в том, что тебя зачмырят/понизят/уволят. В таких условиях ты будешь добиваться результата, чтоб доказать свою правоту, при этом убивая компанию на стратегическом направлении. И твоя инициатива, как менеджера превращается из стратегической в фасадо-строительную.
Какой вывод?
Я считаю, что задача SEM/TD/VP/CTO на каждом из уровней доносить не только "как и зачем мы будем внедрять ту, или иную технологию”, но еще и акцентировать внимание собравшихся, которые зачастую далеки от разработки, на том, что это будет сложный путь и не факт, что мы его пройдем.
Это звучит, как common sense, но это очень сложная работа, которая требует от SEM(я тут объединяю всю вертикаль инженерного управления) понимания технологий, их состояния и подготовок чек листа, который может сказать: "Ребята, сворачиваем! Не туда копаем"
P.S. Ну, а про переписывать с нуля, я задаю себе один вопрос, когда в моей голове появляется такая идея: “Что я дам нового пользователям взамен утерянной функциональности?”
Переписывание с нуля — это релиз нового, а не переделка старого. При переписывании теряется некоторая часть функциональности, зачастую даже не задокументированной, но уже привычной пользователям.
Архитектурные группы — бюрократия или полезный инструмент?
Такие группы образуются когда сложность проекта растет и появляется потребность в согласованности технических решений между несколькими командами. Название может отличаться от компании к компании – SAG (Solution Architects Group), Architecture Review Board. Суть остается прежней — группа технически грамотных людей, присматривающих за общей архитектурой. Такая группа может быть как основным драйвером трансформации, так и бесполезным уровнем бюрократии — всё зависит от того, как она организована и управляется. Далее я рассмотрю несколько анти-паттернов, которые доводилось встречать, а затем поделюсь своим опытом организации такой группы.
Союз ветеранов. Группу составляют старожилы компании, которые стояли у истоков системы. Само по себе это не плохо. Однако опасно, когда технический кругозор группы слегка отстает от текущих реалий. На дворе 2020, а про public cloud и Kubernetes не слышали. Такая группа будет излишне консервативной, инновации будет трудно продвигать (‘not invented here’), а у тех, кто будет взаимодействовать с этой группой, будет знатно “подгорать”.
Карьерный лифт. Архитектурные группы зачастую взаимодействуют с CTO или руководителем департамента — легко примелькаться и получить повышение/коэффициент к бонусу. Далеко не всегда, но всё же бывает, что люди идут в такие группы исключительно с целью удовлетворения карьерных амбиций.
Дискуссионный клуб “Пикейные жилеты”. Группа регулярно встречается, обсуждает глобальные проблемы, но не производит ничего наружу. Извне также непонятно, почему одни проблемы обсуждаются, а другие игнорируются.
Как избежать подобных исходов?
Обозначить цели и результаты
Чтобы не скатиться в дискуссионный клуб, следует проговорить, что считается хорошим результатом работы группы. Например: роадмап технических инициатив с зависимостями между командами, план итераций архитектурных изменений.
Набирать людей по компетентности
Составить список того, что нужно знать и уметь, чтобы попасть в группу. Так как список компетенций может быть трудно формализовать, взамен, можно использовать социальную валидацию: руководитель претендента и три человека не из его команды (число зависит от размера компании) считают, что этот человек будет полезен группе.
Согласовать баланс загрузки
Люди, которые входят в архитектурную группу, заняты на других проектах. Как вариант, договориться между руководителями, что один день в неделю (например четверг) сотрудник на полный день занят работой в технической группе. Если мы хотим решать общие проблемы, для этого должно быть время в календаре.
Ограничить членство по времени
Например, членство в архитектурной группе длится 6 месяцев. По истечении срока можно податься на продление на общих правилах. Стоит также собирать обратную связь от других членов группы на протяжении цикла. Это позволит отфильтровывать неактивных людей и обеспечит здоровую ротацию.
Любая организация людей требует комплексного подхода и выстраивания здоровых процессов. Если командам нужны руководители, то почему такие группы зачастую собраны по принципу “организуйтесь как-нибудь”?
#менеджмент #инструменты
Ментальные модели — как отделять формулировку проблемы от самой проблемы
В тех областях, где люди работают не с физическими объектами, а с информацией, легко спутать факты и их интерпретации, домыслить связи, которых нет, или, наоборот, упустить существенные связи. Во второй половине двадцатого века, в ответ на возрастающую сложность, появилась наука о системах и первые попытки сформулировать подход к решению проблемных ситуаций. Начали развиваться подходы к моделированию систем, и, в частности, появился термин “ментальная модель”. То, как человек думает о какой-то системе, это и есть его ментальная модель данной системы.
Например, то, как мы думаем о поведении системы в продакшене — это наша ментальная модель. У других людей, работающих с этой же системой, модель будет другая, они выделяют другие компоненты и другие связи считают существенными. Еще один пример — самолёт: все видели самолёт, знают, что это такое. Однако, если попросить техника, бортпроводника и пилота описать, из чего состоит самолёт, они будут выделять разные компоненты и связи между ними. Таким образом, с одной стороны, системы объективны (самолеты, работающий софт), с другой стороны, компоненты и связи субъективны.
Если вы дочитали до этого места, то, возможно, вас беспокоит вопрос ”и что?”. Дело в том, что способ размышления о проблеме во многом определяет нашу способность решить эту проблему. Но, зачастую, сталкиваясь с проблемой, мы пытаемся её решать, не сильно разбираясь в том, как она сформулирована и в не думаем о степени понимания этой проблемы.
Предмет разговора очень абстрактный, я попробую привести пример из жизни. С ранней школы мы научились совершать базовые арифметические операции: умеем складывать, делить, умножать, вычитать, воспринимаем это как должное и не удивляемся. Одна из причин, почему мы так легко это делаем — позиционная система счисления (десятичная). Не верите? Попробуйте умножить два числа в римской записи: XVII * IX. Сколько получится? Дело в том, что в позиционной системе записи, где позиция цифры определяет разряд, арифметические операции легко алгоритмизируются (помните в школе учили умножение в столбик?), а в другой, например, римской нотации — нет. А теперь представьте, каким достижением было доказать теорему Пифагора без позиционной записи. Это был rocket-science.
Сама форма записи числа и то, как мы думаем о числах вообще, влияет на нашу способность совершать операции с ними. Иными словами, та ментальная модель, в рамках которой мы формулируем проблему, определяет пространство возможных решений.
Если переложить эти рассуждения на наши реалии, то крайне важно уделить достаточно времени и сил формулированию проблемы, прежде чем бросаться её решать: убедиться, что проблема действительно существует (в реальности, а не голове); согласовать понимание проблемы между людьми, которых она затрагивает.
Короче, прежде чем проводить реструктуризацию/проектировать архитектуру/внедрять скрам и т.д., следует критически осмыслить свою ментальную модель и сверить её с реальностью.
Исследование причин отказа распределенных систем
В 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
#инструменты
Фундаментальная ошибка планирования и немного философии
Основная проблема планирования — после того, как мы дали оценку, мы начинаем в неё верить.
Мы отчего-то уверены, что оценка это тот стандарт, к которому следует стремиться.
В ситуации, когда проект не укладывается в изначальную оценку, мы начинаем предпринимать действия, чтобы вернуть проект к намеченному плану: докинуть людей, порезать скоуп, выписать премий за овератаймы по выходным.
Вот только остается неотвеченным вопрос: На основании чего мы уверены, что вернуть проект к планируемому расписанию — это более прибыльно для компании, чем продолжить разработку в текущем темпе, забыв про изначальные оценки?
Мне буквально несколько раз за десять лет доводилось видеть взвешенное принятие решения с учетом рисков, затрат на ускорение и потерь в случае задержек. В большинстве же случаев это даже не обсуждалось — надо, чтобы всё шло по плану!
Почему так? Почему в какой-то момент происходит отрыв от реальности, и люди перестают различать карту и реальный ландшафт? Возможно, это происходит в связи с тем, что в индустрии разработки софта мы работаем с нематериальными объектами. Легко не заметить различия между “это факт” и “я думаю, что это так”, особенно когда работаешь с информацией, а не с физическими объектами.
Действительно, есть множество вещей, в существовании которых мы не сомневаемся, хотя материально они не представлены: границы государств, законы, процессы в операционной системе, файлы. В некоторых книжках по системному анализу это называется “модели условного подобия”. В нашей индустрии очень много таких вещей.
Кстати, в близкой к нам и гораздо более зрелой индустрии, системной инженерии, различают два понятия: “описание системы”(system definition) и “воплощение системы”(system realization).
В индустрии разработки софта пока нет терминологии, которая позволяет разделить эти категории. Оценка задачи не означает исполнения, план проекта не является его реализацией, документация и диаграммы не являются архитектурой. Карта не является территорией — стоит об этом помнить.
#рассуждения #оценимнеэтотскоуп
Для чего нужна оценка задач?
Оцениванием задач, пожалуй, занимались все; не знаю, существуют ли компании, где не принято оценивать задачи. А зачем мы это делаем? В чем вообще смысл оценивания чего-либо?
На мой взгляд, оценки нужны только в одном случае — когда нет возможности получить реальное значение показателя в тот момент, когда это требуется для принятия решения. Тогда мы заменяем реальное значение оценкой. Приведу пример: планирование бюджета на железо/облако.
Определенно нет возможности узнать точное значение, т.к. платить за него мы будем в будущем. Однако, на основании динамики роста трафика, количества свободных ресурсов, планируемых к запуску проектов, мы можем сделать допущение о том, сколько требуется заложить в бюджет. В данном примере существует конкретное решение, для принятия которого и проводится оценка, — размер бюджета на железо.
Важный момент — наличие решения, которое зависит от результатов оценки. В противном случае, оценивание превращается в ритуал, исполняемый без цели.
Какие решения будут приниматься на основании оценки сроков завершения задач? Есть несколько стереотипных ответов:
Понимать стоимость фичей — возможно это релевантно в заказной разработке, у меня нет опыта в этой области. Однако в продуктовых компаниях затраты на разработку, в основном, постоянные — независимо от количества фичей, все получают зарплату.
Решение о приоритетах задач — те задачи, которые имеют максимальное соотношение ценности ко времени на разработку, должны делаться в первую очередь. Это называется WSJF – Weighted Shortest Job First. Только, чтобы эта штука работала, надо уметь считать ценность задач. Иначе мы делим что-то неизвестное на что-то неточное — в итоге решения о приоритетах принимаются совсем по другим критериям.
Планирование ресурсов – надо назначить людей на проекты, чтобы распараллелить работу. Вообще, 100%-я утилизация — это очень плохо, но об этом как-нибудь потом. В этой ситуации возникает вопрос точности оценок — а её, скорее всего, будет недостаточно, чтобы планировать загрузку по людям. Это может привести к “эффекту домино”: сдвиг одного элемента по срокам повлечёт за собой череду дальнейших изменений.
Еще два плохих варианта использования оценок в организации:
Создать ложный эффект контроля, чтобы не управлять рисками — когда у людей есть оценка, им, видимо, как-то спокойнее живется. Сказали большому менеджеру “Будет готово в 4-м квартале следующего года”, он и пропал до 4-го квартала. На самом деле, часто, получив оценку сроков, ключевые стейкхолдеры, вместо того, чтобы помогать своими ресурсами двигать проект к завершению, теряют к проекту интерес, как будто оценка гарантирует результат.
Инструмент давления на команду — “Вы же говорили, что это займет три недели; уже 2-е прошло, а еще и половины не сделано. Давайте успевайте, по выходным поработайте, например”. Любая дата или отрезок времени, обозначенный в оценке, легко трансформируется в обязательство. Даже в тех случаях, когда отклонение от этой оценки не влечёт никаких финансовых или репутационных потерь для компании.
Этот пункт обычно используется совместно с предыдущим: сначала, получив оценку, самоустраниться из проекта, затем в конце срока вернуться с претензиями.
Конечно есть вещи с жестким дедлайном — Новый год, черная пятница, проплаченная кампания с анонсированной датой старта... В таких случаях следует комплексно подходить к управлению проектом, а не полагаться на одни лишь оценки, чтобы успеть к назначенной дате.
Давая какие-либо оценки, очень важно понимать, какие решения будут приниматься на основании этих оценок. Что поменяется в планах, если оценка удвоится или утроится? Какие решения потребуется изменить, если реальность окажется совсем не такой, как её оценили? А главное помнить, что оценка не является гарантией исполнения в срок, это, скорее, прогноз; и более важен второй аспект — вероятность реализации этого прогноза.
#оценимнеэтотскоуп
Метрики команд. Качество
Прежде чем браться измерять качество, следует договориться о том, что мы включаем в это понятие. Очевидно, что когда очередной релиз разваливает продакшен, это проблема качества. При всей сложности функционального тестирования — это наиболее измеримый и понятный аспект качества. Количество неудачных релизов или пост-релизных дефектов вполне себе метрика. Разумеется, нужно оценивать совместно — общее количество релизов в единицу времени и долю неудачных — чтобы понимать, что команда производит, фичи или инциденты?
Это релевантно даже на той стадии разработки, когда речь еще не идет о публичном релизе. Если не уметь выкладывать изменения сервиса без пользователей, то с реальными пользователями будет только хуже.
Сложнее становится с нефункциональными требованиями, так как их часто упускают во время разработки. Приведу пример: если страница загружается за 3 секунды, это нормально или нет? За 5? А за 10? В конечном итоге это тоже становится вопросом качества, лучше раньше чем позже. Тут важно сформулировать заранее, что критично, зафиксировать атрибуты качества и определить Service Level Objectives (SLO). Собирать метрики и настроить алёрты — не проблема. Проблема — договориться о том, как на них реагировать. Особенно остро это проявляется в фазе активной разработки до публичного релиза: надо фичи делать, некогда думать о производительности, времени ответа и потреблении ресурсов. А потом всплывает: “Почему так медленно работает?”, “Почему так дорого за железо/облако платим?”. Про то, как выстроить цикл обратной связи для тестирования нефункциональных требований во время активной разработки, есть целая книжка — “Building Evolutionary Architectures”.
В итоге, очевидная метрика — процент неудачных релизов — имеет небольшой нюанс: что считать неудачным релизом, а что пост-продакшен дефектом? Ответ сильно зависит от качества мониторинга и скорости обнаружения ошибок в системе. Пожалуй, для нефункциональных требований, обязательная метрика — время ответа сервиса. Остальное определяется спецификой проекта.
#метрики
Метрики для команд: Вступление
В разговорах с коллегами иногда обсуждаем такой вопрос: “А как ты понимаешь, что твоя команда работает хорошо?”. Какой “линейкой” измерять результативность команды? Каким требованиям должны удовлетворять используемые метрики? Давайте порассуждаем на эту тему.
Начнём с требований:
Предсказательная способность
Важно, чтобы на основании метрики можно было прогнозировать будущие результаты. Сидят, значит, фронтендер, бекендер и IOS-разработчик на планировании спринта, оценивают задачи в стори-поинтах, посчитали среднюю velocity по трем спринтам и говорят: “Ну, в этом спринте мы можем сделать 20 стори-поинтов”. Анекдот из реальной жизни. А если серьёзно, то velocity, основанная на стори-поинтах, не обладает предсказательной способностью. Стори-поинты — хороший инструмент для фасилитации обсуждения задач, но бесполезный для оценки команды. По этому же критерию отпадают все усреднения — среднее количество багов на фичу, количество ошибок на строчку кода (кто это придумал?). Все это не говорит о том, как будет дальше – усреднение съедает всю полезную информацию.
Устойчивость к шуму
Метрика не должна “скакать” от незначительных изменений. Иначе, из-за этого шума не получится увидеть тренд, а он нужен для пункта 1. Приведу контрпример: количество стори-поинтов за спринт – как только большая стори уезжает в следующий спринт, получается, что в этом спринте сделали мало, в следующем — много, а по факту задача задержалась на пару дней. Такая метрика не показывает никакого тренда, т.к. слишком сильно подвержена влиянию незначительных отклонений.
Возможность влиять на метрику
Метрика должна быть actionable, то есть изменения в работе команды должны влиять на метрику. Из контр-примеров могу привести попытки привязать бизнес-метрики к оценке работы всей команды – конверсия, количество бизнес-транзакций и прочее. Да, это то, что приносит деньги компании, и это, безусловно, важно измерять. Однако, далеко не всегда команда может напрямую влиять на эти показатели.
С требованиями к метрикам понятно, а что измерять? На мой взгляд, есть три категории, в которых следует измерять работу команды:
Delivery – то, как команда выпускает фичи, сколько на это уходит времени.
Реакция на инциденты – если что-то случается, как долго команда устраняет последствия.
Качество – насколько то, что команда выпускает, соответствует требованиям.
О каждой из этих категорий поговорим более подробно в последующих постах.
#метрики #менеджмент
Trunk-based development
В 2008 году появился GitHub, уже выросло поколение разработчиков, которые ничего, кроме git, не видели. Подход к разработке в ветках тоже стал подходом по умолчанию. Однако та модель, которая хорошо работает для open source, где много контрибьюторов в разных часовых поясах, не всегда хорошо подходит для разработки внутри компании. Возникает merge-hell, когда несколько конфликтующих изменений вливаются в основную ветку. Становится трудно делать рефакторинг. Общее время выпуска фичей замедляется из-за больших затрат на синхронизацию.
Про альтернативный подход к организации работы в репозитории рассказывает Sam Newman (автор книги “Building Microservices”):
- Об истории возникновения feature branch подхода и его минусах.
- О дисциплине, необходимой для trunk-based development.
- О подходе к большим рефакторингам в обоих подходах.
Видео: https://youtu.be/lqRQYEHAtpk
#видеопотеме
Реакция на инциденты. Часть 2 Мониторинг
Во время героической борьбы с пожарами неизбежно начинают появляться зачатки мониторинга — всё-таки простои дорого обходятся. Критичные сервисы обрастают всевозможными проверками: скрипты для проверки доступности БД, периодические пинги сервисов, появляются первые графики и алерты.
Инициатива мониторинга может исходить с разных сторон: может инженеры спать по ночам хотят, а может топы надавили «можем мы про такую хрень не от пользователей узнавать, а как-нибудь сами?». Как правило, на этой стадии мониторинг реализован бессистемно – каждая команда использует разные инструменты, метрики называются как попало и для людей за пределами команды не имеют никакого смысла.
Даже такой подход лучше, чем голый героизм. По крайней мере, проблемы обнаруживаются раньше и есть хоть какой-то инструментарий диагностики.
Правда, на этой стадии легко скатиться обратно: те, кто пережил фазу героизма, перешли в другие команды/получили повышения/ушли из компании, на новый проект набрали новых людей «с горящими глазами и непоротой задницей». Опыт забыт, скрипты утеряны, так что новый проект ожидают те же грабли после первого релиза.
Избежать этого помогла бы систематизация мониторинга:
Определить стек технологий, используемых для сбора телеметрии. Это в 2010 не было графита с карбонами и прометеями, а для distributed tracing’а приходилось изобретать свои поделки. Сейчас это всё есть в open source, стандартизовано, миллион раз проверено в продакшене и несложно внедряется.
Сформулировать стандарт мониторинга. Какие метрики собирать, в каких единицах измерения, определить правила именования (позволит иметь унифицированные дашборды), по каким адресам и на каких портах висят healthcheck’и. Чтобы любой человек, не знакомый со спецификой сервиса, мог посмотреть утилизацию CPU, потребление памяти, нагрузку на сеть, подключения к БД и так далее. В идеале, такой стандарт должен быть не документом в wiki, а набором библиотек, чтобы каждый новый сервис получал все это без дополнительных усилий.
Если это так просто реализовать в 2020, почему этого нет везде? В первой части я упоминал, что в эпоху героизма инциденты воспринимаются как «пожар», который требуется быстро устранить, чтобы восстановить работу сервисов. Чтобы начать инвестировать усилия в мониторинг, следует признать: инциденты неизбежны, они будут происходить, и только от нас зависит, во сколько нам обойдется следующий. «Сколько мы теряем, когда сервис не работает?» – этот вопрос переводит мониторинг систем из категории инженерных забав в полезную фичу для продукта, которая позволяет сократить потери. Уверяю вас, крайне редко найдется более ценная фича, чем повышение доступности сервиса.
Продолжение следует...
#менеджмент #рассуждения #инструменты
Парное программирование неэффективно расходует время?
Обычно менеджеры, услышав, что над одной задачей будут работать два человека, приходят в бешенство: “Ресурсы разбазариваете! Могли делать две задачи, а будут делать одну! И так разработчиков не хватает!”. Давайте отправим менеджеров на википедию читать про закон Литтла, а сами разберем, справедливы ли их замечания.
Приведу пример: есть маленькая задача на пару часов. Через какое время она будет залита в релизную ветку? Допустим, изменение в коде, действительно, небольшое и будет сделано за час. Затем код-ревью — кто-то из коллег должен посмотреть изменения. Однако, все работают над своими задачами и прямо сейчас не могут посмотреть. А потом митинг, а потом на обед сходить надо...
Когда каждый разработчик занят работой над своей задачей, это создает очередь из готовых задач на ревью. Даже небольшое изменение будет застревать в этой очереди: “Приду с обеда и посмотрю”, “Завтра с утра гляну”. Знакомо?
При таком подходе количество задач, выполняемых одновременно, конечно, будет больше. Только какой в этом смысл? Общее время завершения задач возрастает. Деньги компании приносит не количество открытых merge-request’ов, а код, который работает на проде.
Что мы имеем при подходе с парным программированием? В каждый момент, когда появляется новый merge-request, гарантированно есть свободный человек, чтобы его посмотреть. Нет проблемы очередей! Процесс ревью тоже становится короче за счет того, что контекст уже понятен, а существенные замечания устраняются на раннем этапе.
Парное программирование позволяет сократить время на завершение задачи, а также может увеличить пропускную способность всей команды. Занять всех работой, чтобы делать больше – может казаться “очевидным” решением, но на деле это делает только хуже.
#инструменты #метрики
Как появился scrum
Муж заметил, чтo жена пepeд варкой обрезает кончики y сосисок.
– Зaчeм ты тaк делаешь?
– Я не знaю, моя мама всегда так делает.
Муж позвонил тёще:
– Тaк варила eщё мoя бабушка.
Прабабушка встрепенулась, услышав разговор:
– А вы чтo, до сих пор варите в моей маленькой кастрюльке?
Обычно на выходных я публикую ссылки на видео. У всех этих роликов есть общая черта — люди в них — авторы методологий, фреймворков, написали не одну книгу… И, как правило, у ролика всего несколько тысяч просмотров, а имя спикера не то чтобы широко известно. Уже появились последователи у последователей, которые когда-то были на тренинге у человека, который учился у самого автора. Короче, испорченный телефон, а идеи изначально вложенные в инструмент уже забыты.
Еще одно видео из этой серии, на котором Джеф Сазерленд (создатель Scrum, один из авторов Manifesto for Agile Software Development) рассказывает про то, как он летал на истребителе над Вьетнамом и придумал основные концепции scrum.
- Про историю появления самого популярного agile-фреймворка.
-О том, что качество и инженерные практики необходимы для того, чтобы иметь предсказуемые результаты каждой итерации. (Об этом забыли рассказать agile-коучи)
- Про идею planning poker – значительно сократить время на оценку, не сильно потеряв в точности.
- Как постепенно появились митинги и инструменты, используемые в Scrum.
Ссылка на интервью: https://youtube.com/watch?v=1yZ3J8C4MK0&list=PLDFC1AB8AA7B44F5C&index=1
#история #видеопотеме
Что проверять на code review?
Стандартная переписка в командном чатике:
– Привет! Посмотрите мой MR <ссылка>.
– Глянул, вроде норм. Заапрувил!
Что происходит между этими двумя моментами? Что конкретно требуется посмотреть и на что обратить внимание? Процесс будет зависеть опыта конкретного человека. Однако, есть масса вещей, которые на code review можно упустить.
На эту тему я подсмотрел один инструмент в open-soure проектах – чеклисты для merge request’ов. Что конкретно должно входить в чеклист, зависит от команды. Лучше всего организовать обсуждение с коллегами и проговорить: что мы ожидаем от code review, на что смотреть, какие вещи часто упускали раньше?
У меня есть заготовка чеклиста, на которую впоследствии накручивается командная специфика. В нем два раздела: для автора и для тех, кто будет смотреть.
Для автора:
- Сообщения к коммитам оформлены по стандартам. (например, писать номер задачи в первой строке)
- Мой MR не конфликтует с target веткой.
- Я запускал свой код и проверил основные сценарии.
Для ревьюера:
- В новом коде обрабатываются ошибки и исключения.
- Исключительные ситуации пишутся в логи.
- В логах сохраняется вся необходимая для отладки информация (ID сущностей, время, названия таблиц).
- Инициализированные ресурсы освобождаются после использования (подключения к БД, мьютексы вот это всё).
Цель этого инструмента — сделать процесс более воспроизводимым и менее зависящим от исполнителя. Таким образом, любой из посмотревших снижает вероятность возникновения типовых ошибок. В gitlab и github можно настроить шаблон, который автоматически будет добавляться к каждому MR. Есть ещё много вещей, которые важно проверять на ревью, но их не засунуть в чеклист. Ну так мы и не пытаемся одним инструментом решить все проблемы.
#инструменты
Подход к интервью в компаниях-лидерах индустрии
Несмотря на большое количество исследований, связанных с процессом найма, в индустрии пока не сложилось best-practices о том, как же следует нанимать людей. Компании изобретают свой велосипед или копируют подход гигантов индустрии. Из гигантов количеством открытой информации особенно выделяется Google.
Например, они исследовали, насколько каждое дополнительное собеседование повышает точность оценки кандидата. В итоге появилось “The Rule of Four”: четыре собеседования дают 86% уверенности. Каждое последующее несущественно влияет на эту цифру, однако заметно добавляет к сложности процесса.
Ещё одним решением, основанным на данных, был отказ от использования головоломок на интервью. Под головоломками имеются в виду вопросы типа: “Вам нужно отмерить ровно 4 литра воды, но у вас есть только 3‑х и 5-ти литровые банки, как это сделать?”, “Почему канализационные люки круглые?” и так далее. Оказалось, что способность решать такие задачи не коррелирует с дальнейшими успехами в работе. Взамен начали использовать структурированные интервью для оценки job-related skills. В случае с разработчиками это coding и system design. Обычные интервью по-прежнему используются, но не для оценки навыков, а для оценки культурного соответствия — сможет ли кандидат прижиться в сложившейся культуре.
А почему, если структурированные интервью такие классные, их не используют все компании? Дело том, что внедрение требует больших усилий – надо научить интервьюеров, надо протестировать вопросы, надо мониторить и обновлять базу вопросов (ответы сливают в сеть).
Тот процесс интервью, который принят в компаниях-лидерах индустрии, требует огромных ресурсов для поддержки и развития. Так что не стоит повторять один в один то, что делают в google, amazon или facebook. А вот подсматривать, осмыслять и адаптировать можно.
Кстати Google опубликовали свой гайд по использованию структурированных интервью в открытый доступ.
Ссылка: https://rework.withgoogle.com/guides/hiring-use-structured-interviewing/steps/introduction/
#найм