Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

На просторах интернета мы часто можем встретить дискуссии о том, что должен делать разработчик и чем ограничена его роль.

• То ли этот человек просто пишет код по четко написанному ТЗ — исполнитель.

• То ли этот человек должен быть способен придумать решение самостоятельно, исходя из четко поставленной бизнес-задачи — герой.

• То ли вообще должен быть способен разобраться в проблеме клиента, уточнить вопросы и придумать наилучшее решение — суперзвезда.

Делюсь своим опытом как эксперт и консультант по работе с Agile-командами. На своем опыте я встречал разных разработчиков и все три типа были в разных контекстах и разных компаниях.

Давайте разберемся в плюсах и минусах каждого из категорий разработчиков:

1. Тот, кто просто пишет код по четко поставленному ТЗ — исполнитель

Обычно такие разработчики хорошие исполнители, они действительно фокусируются на ТЗ и выполняют задачи так, как там написано. Но здесь кроется одна большая проблема — как правило, такие разработчики совсем не думают и не знают о потребностях пользователей, и поэтому механическое выполнение ТЗ в итоге может привести к низкому качеству продукта с точки зрения бизнеса и пользователей.

В компаниях, в которых присутствует такая культура разработки, разработчик в итоге не несет ответственность за результат, а скорее всего, переложит ее на того, кто принес ТЗ, со словами: «В ТЗ же так написано». Соответственно, тот человек, который делал ТЗ, переложит ответственность на того, у кого он уточнял это ТЗ. Также при передаче документов теряется смысл и информация, невозможно все положить в ТЗ. Как минимум, требуется регулярная коммуникация, чтобы качественно сделать задачу. 

В общем, культура размытия ответственности порождает низкое качество и долгие сроки разработки, так как чтобы передать, нужно заново пройти цепочку.

Вывод из этого таков — подобная культура разработки имеет смысл в тех проектах, где результат заранее понятен, где можно четко написать ТЗ и сделать по нему. Но там, где мы создаем что-то новое, такая модель будет приводить к долгим срокам разработки и созданию некачественного продукта.

2. Тип разработчика — герой

Это разработчики, готовые придумывать решение самостоятельно, без четкого ТЗ со стороны системного анализа, но все еще не настолько проактивные, чтобы коммуницировать с бизнесом напрямую и уточнять задачу. Плюс здесь в том, что мы даем пространство разработчику действительно включить весь свой опыт и навыки и придумать простое решение проблемы клиента. Это поможет снизить стоимость решения, так как можно сделать проще и руки у разработчика развязаны. Но в то же время существует риск: разработчики склонны к тому, чтобы сразу сделать круто, и тут стоимость решения может быть выше. В этом случае разработчиков стоит обучать принципам lean (бережливого создания продукта): сначала сделали базовую версию, потом улучшили, потом сделали круто. Также в этом типе разработчика все еще нет проактивности и проактивной и прямой коммуникации с бизнесом. То есть если у разработчика возникнет вопрос в ходе разработки, он может сделать так, как посчитает нужным или спросит у того, кто принес ему бизнес-требование. И коммуникация здесь может быть рваная.

3. Тип разработчика — суперзвезда

Это те разработчики, которые не просто получили четкое описание бизнес-требований, но мыслят проактивно и готовы самостоятельно созвониться с бизнесом, если в начале и в ходе разработки возникают вопросы, чтобы лучше понять проблему клиента и предложить лучшее решение. Такие разработчики не требуют посредников, которые являются передатчиками информации от бизнеса. Такой разработчик — не просто кодер, а специалист, который создает решение под потребности клиента. Это важно в продуктовой разработке, где мы создаем новый продукт или улучшаем метрики текущего продукта, и где есть много неопределенностей. 

Это также снизит количество документации, которая пишется на входе для первого типа разработчика, на которую уходит много времени, в попытке учесть все детали. Улучшит качество готового решения, поскольку не будет теряться контекст из-за передачи из рук в руки, и благодаря полному пониманию разработчиком того, что хочет бизнес.

В итоге в структуре продуктовой команды частично или полностью роль аналитика может быть в самом разработчике, так как он придумывает и уточняет требования у бизнеса или владельца продукта самостоятельно. Это уменьшает время на коммуникации и улучшает их качество. Требования разработчики фиксируют в письменном виде для сохранения знаний.

Также во втором и третьем варианте разработчика важны следующие детали: 

Проверка качества. Разработчик должен удостовериться в качестве того, что он делает, а не просто кодить и передавать в тестирование. Поэтому разработчики могут проводить все виды тестирования самостоятельно. Каждый отвечает за то, что выходит в прод. 

Часто замечал, что роль тестирования во многих командах является узким горлышком. Все просто — тестировщиков в команде всегда меньше, чем разработчиков, плюс передачи от разработки в тестирование и обратно создают большие задержки. Зачем? Если в качестве может удостоверяться сам разработчик и на ходу исправлять все баги. Качество и скорость благодаря этому только улучшатся. 

Также хорошей практикой является парная работа разработчика с тестировщиком — тестировщик тестирует, разработчик сразу же исправляет, что ускоряет время выполнения

Демонстрация готового продукта пользователям и бизнесу и ведение прямого диалога с ними. Этот пункт важен потому, что разработчики должны слышать обратную связь от бизнеса напрямую, а не через посредников, это позволит им лучше понимать потребности бизнеса и придумывать лучшие решения. 

На практике каждый спринт команда должна показывать работающий продукт, который они доработали за спринт. На обзоре спринта (демо) происходит демонстрация и обсуждение готового кусочка продукта. Важно, чтобы разработчики сами демонстрировали и фиксировали обратную связь, слышали голос заказчиков и пользователей.

В чем же задача тим лида в такой структуре? 

• Развивать культуру ответственности и самоорганизации.

• Растить зрелость разработчика и помогать выйти ему на следующий уровень.

• Устранять барьеры и препятствия (например, в общении с пользователями и бизнесом).

• Растить инженерную культуру и лидировать это направление.

Всех желающих приглашаю на открытый урок «Как правильно увольнять человека». Увольнения — сложная тема, поэтому научимся работать с увольнениями как с нормальной частью менеджерской деятельности. Обсудим:

- Кого и почему надо увольнять?
- Причины увольнения; законодательная основа; сроки увольнения.
- Увольнение по инициативе сотрудника — как предотвратить.

Регистрация доступна по ссылке.

А если вам понравилась статья, жду в своем телеграмм канале и на сайте.