Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Статью написал Дмитрий Курдюмов в рамках набора на курс "Team Lead".
Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.
На просторах интернета мы часто можем встретить дискуссии о том, что должен делать разработчик и чем ограничена его роль.
То ли этот человек просто пишет код по четко написанному ТЗ — исполнитель.
То ли этот человек должен быть способен придумать решение самостоятельно, исходя из четко поставленной бизнес-задачи — герой.
То ли вообще должен быть способен разобраться в проблеме клиента, уточнить вопросы и придумать наилучшее решение — суперзвезда.
Делюсь своим опытом как эксперт и консультант по работе с Agile-командами. На своем опыте я встречал разных разработчиков и все три типа были в разных контекстах и разных компаниях.
Давайте разберемся в плюсах и минусах каждого из категорий разработчиков:
Тот, кто просто пишет код по четко поставленному ТЗ — исполнитель
Обычно такие разработчики хорошие исполнители, они действительно фокусируются на ТЗ и выполняют задачи так, как там написано. Но здесь кроется одна большая проблема — как правило, такие разработчики совсем не думают и не знают о потребностях пользователей, и поэтому механическое выполнение ТЗ в итоге может привести к низкому качеству продукта с точки зрения бизнеса и пользователей.
В компаниях, в которых присутствует такая культура разработки, разработчик в итоге не несет ответственность за результат, а скорее всего, переложит ее на того, кто принес ТЗ, со словами: «В ТЗ же так написано». Соответственно, тот человек, который делал ТЗ, переложит ответственность на того, у кого он уточнял это ТЗ. Также при передаче документов теряется смысл и информация, невозможно все положить в ТЗ. Как минимум, требуется регулярная коммуникация, чтобы качественно сделать задачу.
В общем, культура размытия ответственности порождает низкое качество и долгие сроки разработки, так как чтобы передать, нужно заново пройти цепочку.
Вывод из этого таков — подобная культура разработки имеет смысл в тех проектах, где результат заранее понятен, где можно четко написать ТЗ и сделать по нему. Но там, где мы создаем что-то новое, такая модель будет приводить к долгим срокам разработки и созданию некачественного продукта.
2. Тип разработчика — герой
Это разработчики, готовые придумывать решение самостоятельно, без четкого ТЗ со стороны системного анализа, но все еще не настолько проактивные, чтобы коммуницировать с бизнесом напрямую и уточнять задачу. Плюс здесь в том, что мы даем пространство разработчику действительно включить весь свой опыт и навыки и придумать простое решение проблемы клиента. Это поможет снизить стоимость решения, так как можно сделать проще и руки у разработчика развязаны. Но в то же время существует риск: разработчики склонны к тому, чтобы сразу сделать круто, и тут стоимость решения может быть выше. В этом случае разработчиков стоит обучать принципам lean (бережливого создания продукта): сначала сделали базовую версию, потом улучшили, потом сделали круто. Также в этом типе разработчика все еще нет проактивности и проактивной и прямой коммуникации с бизнесом. То есть если у разработчика возникнет вопрос в ходе разработки, он может сделать так, как посчитает нужным или спросит у того, кто принес ему бизнес-требование. И коммуникация здесь может быть рваная.
3. Тип разработчика — суперзвезда
Это те разработчики, которые не просто получили четкое описание бизнес-требований, но мыслят проактивно и готовы самостоятельно созвониться с бизнесом, если в начале и в ходе разработки возникают вопросы, чтобы лучше понять проблему клиента и предложить лучшее решение. Такие разработчики не требуют посредников, которые являются передатчиками информации от бизнеса. Такой разработчик — не просто кодер, а специалист, который создает решение под потребности клиента. Это важно в продуктовой разработке, где мы создаем новый продукт или улучшаем метрики текущего продукта, и где есть много неопределенностей.
Это также снизит количество документации, которая пишется на входе для первого типа разработчика, на которую уходит много времени, в попытке учесть все детали. Улучшит качество готового решения, поскольку не будет теряться контекст из-за передачи из рук в руки, и благодаря полному пониманию разработчиком того, что хочет бизнес.
В итоге в структуре продуктовой команды частично или полностью роль аналитика может быть в самом разработчике, так как он придумывает и уточняет требования у бизнеса или владельца продукта самостоятельно. Это уменьшает время на коммуникации и улучшает их качество. Требования разработчики фиксируют в письменном виде для сохранения знаний.
Также во втором и третьем варианте разработчика важны следующие детали:
Проверка качества. Разработчик должен удостовериться в качестве того, что он делает, а не просто кодить и передавать в тестирование. Поэтому разработчики могут проводить все виды тестирования самостоятельно. Каждый отвечает за то, что выходит в прод.
Часто замечал, что роль тестирования во многих командах является узким горлышком. Все просто — тестировщиков в команде всегда меньше, чем разработчиков, плюс передачи от разработки в тестирование и обратно создают большие задержки. Зачем? Если в качестве может удостоверяться сам разработчик и на ходу исправлять все баги. Качество и скорость благодаря этому только улучшатся.
Также хорошей практикой является парная работа разработчика с тестировщиком — тестировщик тестирует, разработчик сразу же исправляет, что ускоряет время выполнения
Демонстрация готового продукта пользователям и бизнесу и ведение прямого диалога с ними. Этот пункт важен потому, что разработчики должны слышать обратную связь от бизнеса напрямую, а не через посредников, это позволит им лучше понимать потребности бизнеса и придумывать лучшие решения.
На практике каждый спринт команда должна показывать работающий продукт, который они доработали за спринт. На обзоре спринта (демо) происходит демонстрация и обсуждение готового кусочка продукта. Важно, чтобы разработчики сами демонстрировали и фиксировали обратную связь, слышали голос заказчиков и пользователей.
В чем же задача тим лида в такой структуре?
Развивать культуру ответственности и самоорганизации.
Растить зрелость разработчика и помогать выйти ему на следующий уровень.
Устранять барьеры и препятствия (например, в общении с пользователями и бизнесом).
Растить инженерную культуру и лидировать это направление.
Всех желающих приглашаем на открытый урок «Как правильно увольнять человека». Увольнения — сложная тема, поэтому научимся работать с увольнениями как с нормальной частью менеджерской деятельности. Обсудим:
- Кого и почему надо увольнять?
- Причины увольнения; законодательная основа; сроки увольнения.
- Увольнение по инициативе сотрудника — как предотвратить.
Регистрация по ссылке.
