Часть 2 увольнения вашей инженерной команды
Обеспечьте подотчетность своих команд
Взглянуть на свою команду инженеров - все равно что внимательно посмотреть на себя. Возможно, вам не нравится то, что вы видите, но как генеральный директор, это все вы. В конечном итоге вы должны отвечать за свои ошибки, а сами должны исправлять эти ошибки.
То, что мы начали в Части 1, было важным фундаментом для любой хорошей инженерной команды. Я показал вам, как анализировать три основные части: люди, процессы и инфраструктура. Теперь, когда вы знаете детали и принцип их работы, пришло время ожидать большего.
Обеспечьте подотчетность своих команд
Один из секретов успешной разработки программного обеспечения - это не инженерия. Все начинается с ожиданий относительно того, что будет производиться. Это начинается с лидерства, фильтруется по продукту, а затем возвращается к проектированию. Суть доставки продукта, чем занимается инженерия, происходит через процесс постановки целей и отслеживания.
Traction (книга, которую я упомянул в Части 1) имеет концепцию камней, которые по сути являются первоочередными целями. Поскольку я рекомендую следовать принципу Traction, я буду использовать те же термины, но шаги по постановке целей и их достижению одинаковы, как бы вы их ни называли.
Вот как вы можете организовать свои после того, как руководство установит основные ценности компании:
- Установите цели - перечислите все, что вы хотите достичь в ближайшие 90 дней; отбраковывайте и объединяйте, пока не получите только 10–20 штук.
- Сузьте свой список - обсуждайте и обсуждайте наиболее важные варианты, пока не дойдете до 3–7 лучших, которые вам необходимы.
- Установите даты, когда они должны быть выполнены - все они должны соответствовать 90 дням.
- Назначьте владельцев - у каждого камня должен быть один владелец; это очень важно для подотчетности.
- У каждого лидера есть свои камни - сюда входят предыдущие не завершенные камни и все камни, отброшенные на шаге 2; каждый лидер отвечает за 3–7 камней.
- Поместите все камни в список на следующие 90 дней - заморозьте! Добавлять камни нельзя.
- Поделитесь списком со всеми в компании.
- Попросите каждый отдел (продукт, разработка) создать свои собственные камни на 90 дней.
Любые новые идеи, возникающие в течение квартала, добавляются на следующие 90 дней.
Отслеживание прогресса и обеспечение выполнения работ - сложная дисциплина, потому что это доставляет людям дискомфорт.
«Что обычно сдерживает организацию, так это страх создать этот дискомфорт. Но у вас нет другого выбора, если вы хотите создать отличную компанию. Если вы примете тот факт, что на короткое время заставите людей чувствовать себя немного неудобно, решение на самом деле простое. Вам нужно реализовать две простые практики ».
- Джино Викман, «Тракшн»
Ваша продуктовая команда и жизненный цикл продукта
Как я упоминал в Части 1, продукт определяет стратегию, лежащую в основе того, что должно быть построено. Они смотрят на отзывы клиентов из службы поддержки и продаж и делают обоснованные предположения о том, что им понравится.
Вы можете ожидать, что Продукт будет включать отзывы о предлагаемых функциях и исправлениях. Вы также можете ожидать, что создаваемые ими задачи Jira будут полными и краткими. Инженер должен уметь прочитать заголовок и понять не менее 75% запроса. Подробное описание должно включать критерии приемки и все активы, необходимые для выполнения работы.
Примечание. Не позволяйте инженерам решать проблемы наугад, и они будут тратить меньше времени на получение разъяснений. Если вы этого не сделаете, они могут угадать и ошибиться!
По мере выполнения работы инженеры должны обновлять статусы своих заявок. Это пункты подотчетности, на которые вы можете рассчитывать - что каждый (особенно инженеры) будет держать других в курсе состояния своей работы.
Чтобы облегчить это, убедитесь, что ваша JIRA или другой инструмент управления проектами имеет следующие статусы:
- Задачи - приоритетные работы, которые еще не были выполнены (наиболее важные вверху).
- Выполняется - инженер принял заявку и сейчас работает над ней.
- Проверка кода: инженер считает, что работа выполнена, и работа проверяется коллегами.
- Готов к развертыванию - заявка одобрена и ожидает развертывания в производственной среде.
- В производстве - работа жива и используется клиентами!
У вас может быть больше статусов, чем указано, но они необходимы, чтобы знать, где лежит ответственность, и поэтому вы сможете лучше понять, как скоро это будет сделано.
Примечание. Если инженер по какой-либо причине заблокирован чем-либо, он должен сообщить об этом как можно скорее. Ожидание кого-то другого, не давая им знать, убивает продуктивность.
Общение - ключ к успеху
Коммуникация важна не только внутри продукта и разработки, но и между этой командой и остальной частью компании.
Помимо статуса заявок (см. Выше), инженерная команда должна проводить демонстрацию в конце каждого спринта. Здесь инженер, выполнивший работу, демонстрирует работу, которую они выполнили или делают, остальной части компании.
Их хвалят, другие команды знают, что происходит, а инженеры чувствуют ответственность за свою работу. То, что они делают, имеет значение, и будет большее чувство срочности в получении столь необходимой работы и исправления. Это обеспечивает подотчетность другим командам.
Сбалансированные команды
Организуйте свои команды вокруг конкретных продуктов, по принципу Pivotal Labs. По сути, вы создаете небольшую команду вокруг определенного продукта. Это позволяет им углубиться в один продукт, проводить исследования и создавать функции с тесно интегрированной обратной связью. Это определяется следующими характеристиками:
- Менеджер по продукту
- Дизайнер продукта
- Разработчик (один или несколько)
- Автономный
- Среда с высоким уровнем доверия (открыта для экспериментов)
«Эти роли являются частью основной команды, которая на все 100% посвящена продукту. Роли типа малых и средних предприятий существуют за пределами основной группы, включая аналитику, инфраструктуру, безопасность и т. Д. Эти роли обеспечивают поддержку основной группы в смягчении последствий выпуска, безопасности, инфраструктуры и других проблем ».
- Рахул Бхандари, Революция в разработке программного обеспечения: Dell использует уникальную гибкую методологию »
У вас могут быть подотчетные и автономные команды. Чтобы внести ясность, привлечение команд к ответственности не означает их микроменеджмента. Будьте прозрачны в отношении целей компании, когда они должны быть выполнены, и кто ими владеет ... затем проверьте. На самом деле, прозрачность дает вам преимущество отступить, потому что все знают, что нужно делать.
«Также жизненно важно, чтобы заинтересованные стороны доверяли самой команде. Принцип сбалансированной команды заключается в том, что те, кто ближе всего к продукту и его предполагаемым пользователям, автономны и уполномочены принимать все решения по продукту, дизайну и техническим решениям ».
Методология команды Pivotal Labs может работать не для каждого продукта или компании, но я видел, что она очень хорошо работает для многих.
Размер ваших билетов
Возвращаясь к нашей начальной истории, помните команду, которая выполняла примерно 20% каждого спринта? Инженеры знали свое дело, и большинство из них стремились внести свой вклад. Но оказалось, что билеты в JIRA совсем не по размеру и написаны не очень хорошо.
Примечание. Если вы не оцениваете билеты, вы на самом деле не знаете, сколько усилий или времени у вас затрачено, и, следовательно, ваша оценка времени - чушь.
Они регулярно совершали ошибки, на которые я здесь указывал. Никто не знал, когда появится важная функция. Связи с остальной компанией не было.
Служба поддержки и менеджеры по работе с клиентами изо всех сил старались сделать клиентов счастливыми, но они также потеряли надежду с разработкой. Продажи и генеральный директор отводили инженеров в сторону для собственных проектов. Поскольку соблюдение этого процесса было ненадежным, они хотели убедиться, что их потребности удовлетворены, поэтому они обходили процесс, а не исправляли его.
Остальная часть компании не знала, что происходит, и от этого команда инженеров выглядела хуже.
Помните, как генеральному директору было удобнее работать с двумя инженерами в сумме? Это потому, что он вспомнил победы, которых добился с небольшой командой много лет назад. Обстоятельства тогда были другие - ставки на выживание были выше. Теперь компании требовались более дисциплинированный подход и лучшая коммуникация.
После внедрения базовых блоков Agile Scrum и повышения ответственности разработчиков и продуктов, через пару месяцев мы достигли 100% нашего спринта. Генеральный директор был в восторге. Еще один поучительный момент: я предупреждал, что это не обязательно хорошо. Вы хотите, чтобы цели превышали 95%. Если вы можете позаботиться о 90–95% спринта, вы должны справиться с наиболее важными задачами.
Это было не идеально, но я определенно надеялся достичь этого. Мост доверия был восстановлен, и после некоторой работы он продолжал улучшаться.
В заключение
Когда все работает, это здорово, но это не волшебство.
Для этого нужны правильные люди на правильных местах, процессы, обеспечивающие подотчетность людей, и правильные инструменты для поддержки быстрого потока разработки и развертывания.
Скорее всего, если у вас возникнут проблемы с командой инженеров, это не потому, что они плохие люди - им просто нужна ваша помощь.
