А нужна ли вообще эта "аналитика"?

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

По каким соображениям изначально не вводили выделенного аналитика? Что изменилось?

Так как команда никогда не была большой (в пределах 2-3 разработчиков) и полностью размещалась на территории заказчика, нужды фиксации требований не было — все вопросы решались оперативно. Спустя время выяснилось, заказчик не доволен объемом документации на оплату. Чтобы как-то систематизировать этот процесс и закрыть долг по документации решили найти аналитика.

Звучит так, что по сути для команды не стояло и нет на данный момент проблемы в требованиях. Вся задача только в создании исчерпывающей документации, удовлетворяющей заказчика. Так?

В целом, примерно так и есть. Я слышу от команды рассказы о том, что где-то с этим лучше, что наличие документации полезно, что хорошо, когда есть где посмотреть "как должно работать". Но на мой взгляд, для текущей работы это не требуется. Необходимый минимум для текущей работы — это постановка задачи, в которой будет сказано какую проблему мы решаем и как. Документация нужна заказчику, смежным подразделениям, новым людям в проекте, будущим поколениям и немного нам в тот момент, когда мы сами забудем как там все устроено.

1. По твоему мнению, какие условия на проекте должны быть, чтобы тех. документация была must have?

2. В твоем утверждении нет противоречия твоему желанию иметь на проекте тех. спеки на все микросервисы?

1. Когда состав команды не постоянный и если это именно проект, который начали и закончили. Когда это продукт, который живёт и развивается не один год, когда команда более-менее статична, требования по наличию документации сильно ниже.

2. Тех.спеками я закрываю потребность банка и нас рассчитаться за проделанную работу + пытаюсь теми же документами иметь возможность в любой момент ответить на вопрос как работает сервис.

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

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

Какие 3 основные момента должны быть в задаче обязательно?

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

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

Далее - проработка решения, результатом которой должен стать одноименный раздел (Solution). Этот раздел важен в первую очередь разработчикам. Детализация проработки решения зависит от уровня команды и, иногда, от конкретного исполнителя. В сильной, погруженной в контекст, знакомой с фреймворком, команды достаточно описать идею решения. Если в команде есть новички или джуны, идеи не достаточно, нужно больше конкретики. Кроме того, нужно обозначить какие есть ограничения (доступность, ожидаемая нагрузка и т.п.).

Этих двух разделов должно быть достаточно чтобы задачу брать в работу. Однако чаще всего недостаточно для передачи в тестирование. Для тестирования важно понимать как будет проводиться приёмка, какие есть крайние случаи, какое поведение ожидается при негативных сценариях. Поэтому в третьей части нужно отразить критерии приемки, показать примеры реальных данных, ожидания по нагрузке.

Я помню, что изначально тебе не очень нравилась идея acceptance criteria в задачах, т.к. это требует дополнительного времени. Ты изменил мнение?

Скорее я не смог сходу идентифицировать ту часть постановки как критерии приёмки. После твоих разъяснений все встало на свои места. Я согласен с тем, что наличие критериев приемки в задаче полезно. Но так как в них много конкретики, есть риск, что по мере реализации их придётся обильно корректировать, что создаёт дополнительную работу. Работа как всегда порождает работу.

Давай обсудим кейс, когда команда разработки неоднородная. Как бы ты советовал аналитику формулировать постановки в таком случае?

Подход должен быть рациональным. Я за результат при наименьших затратах. Если джунов мало, то я бы точечно детализировал постановку в задачах перед передачей в разработку джуну.

Спасибо за интервью!