Недавно в комментариях прилетел вопрос:
А если постановки задач нет вообще, на проекте около 20 человек — это может работать или это заранее плохой процесс? В моём случае задачи шли напрямую от клиента к разработчикам, а менеджер только определял, что брать в работу и кому отдать.
Тема постановки задач настолько важна, что мне захотелось дать развёрнутый ответ.
Прямой контакт не равен хаосу
Сам по себе разговор клиента с разработчиком полезен: меньше искажений, быстрее появляются ответы, проще увидеть реальную потребность. Проблема начинается не из-за контакта, а из-за отсутствия системы вокруг него.
Если каждый клиентский запрос сразу превращается в задачу отдельному разработчику, обычно возникают три проблемы:
- нет общего контекста, и каждый член команды предоставлен сам себе;
- нет общей приоритизации, поэтому все задачи нужны «вчера»;
- размыта ответственность за то, что именно команда обещала сделать.
В итоге люди работают в постоянной фрустрации: задачи выполняются не в срок и не так, как ожидал клиент. Это ведёт к выгоранию и текучке либо к работе «на минималках», лишь бы от команды отстали.
Планирования, груминги и критерии готовности придумали не ради самих ритуалов. Они создают общий контекст и точку, в которой запрос проверяют, уточняют и ставят в один приоритетный поток.
Когда лёгкий процесс достаточен
В маленьком стартапе или личном проекте можно обойтись без тяжёлой бюрократии. Но вопросы всё равно остаются теми же: кто определяет приоритет, где зафиксировано ожидаемое поведение и кто отвечает за итоговое обещание клиенту.
Если ответы помещаются в короткий разговор — прекрасно. Если из-за разных трактовок уже возникают конфликты и переделки, процесс пора усиливать.
Что делать разработчику внутри такого процесса
Оказаться на проекте, где все задачи нужны вчера, а требования звучат как «пойди туда — не знаю куда», дико неприятно.
Если изменить процесс целиком пока невозможно, можно хотя бы уменьшить личный хаос: уточнить цель запроса, письменно зафиксировать договорённость и проверить приоритет у человека, который распределяет работу. Это не снимает ответственность с менеджера и не делает разработчика владельцем всего входящего потока. Но помогает не начинать работу с двадцатью разными версиями ожидаемого результата.
Главный вопрос здесь не в том, разговаривает ли разработчик с клиентом напрямую. Вопрос в том, существует ли единый способ превратить эти разговоры в понятные и согласованные обязательства команды.