Когда говорят 'Сделай хорошо': Рекомендации для разработчиков по улучшению процесса
Недавно встречались с руководителями разработки ПО из нескольких компаний. Встреча неформальная, тем не менее, не обошлось без обсуждения рабочих моментов. В ходе беседы с коллегой коснулись «болевой точки» — постановки задач. Типичная ситуация, когда задача звучит как «Добавь раздел Оповещения», «Сделай фильтрацию на странице», или «Сделай хорошо». В предыдущей статье о критериях отмены задачи в комментариях разработчики подымали проблемы вызванные неправильной постановки задач. Если задача поставлена грамотно, то работа будет выполнена быстро. Проблема распространена, и неграмотная постановка приводит к курьезам, но чаще к увеличению сроков из-за расширения объема работы.
Сложность в том, что продуктовые менеджеры зачастую не подчиняются руководителю разработки, и у них разные цели. Последствия плохо сформулированной задачи часто не очевидны продуктовому менеджеру, как и тот факт, что задачи непонятны команде.
Пример из практики: я провел детальный анализ процесса работы над задачами, выяснилось, что все начинается с того, что разработчики берут задачу в работу, а затем сразу звонят менеджеру за разъяснениями. Получается, что вопрос не в том, чтобы звонить, если что-то непонятно, а в том, что звонить приходится всегда. При более глубоком анализе стало очевидно, что уточнения требуются не только на начальном этапе работы над задачей, но и на протяжении всего процесса её выполнения. Для менеджера это означало потерю нескольких десятков минут, но в действительности последствия были гораздо более значительными. Менеджер, потратив минут 30 на обстоятельное обдумывание как сформулировать задачи экономил бы на много больше. Потери разработчиков в среднем составляли 3 часа на подготовку к старту.
У нас Agile
Я попытался донести до менеджера эту проблему и что причина — слишком расплывчатая формулировка задач. В ответ последовало нечто в духе: «Зачем придираться? Мы всегда так работаем, и все прекрасно понимают, что от них требуется. У нас же Agile, мы ценим общение выше документации».
В итоге, даже если в описании задачи что-то важное есть, оно не читается. Менеджер удивляется, когда что-то оказывается упущено: «Как так, ведь все написано?». Открою неприятную правду для менеджеров: если выдаете задачи, требующие уточнения, не ждите, что описание будут читать. Из всего текста будет использоваться только название задачи, чтобы на нее ссылаться.
Вот еще забавный момент. Менеджер создал баг, который казался ему критически важным, и назначал его на определённого разработчика, с описанием в духе «ну ты сам знаешь, где ошибка». Я уже упоминал, наши подразделения работают независимо, и наш тим лид не координирует графики отпусков с продуктовой командой. У нас любой разработчик может взяться за исправление любого бага, так как мы ценим гибкость в планировании отдыха, и это также выгодно для бизнеса, поскольку не создаётся зависимости от одного сотрудника. Это ситуация, в которой все выигрывают. Достаточно делать хорошие описания. Конкретно в этой ситуации последствий не было, т.к. это произошло в момент внедрения пристального ревью описаний сразу после создания на каждодневной основе.
Вот ту мы плавно переходим от примеров когда менеджеры плохо ставят задачи к проблеме, а почему со стороны команд разработки это принимается? В комментариях к предыдущему посту было много возмущения по поводу того, что тим лидам не хватает решимости, чтобы справиться с этой проблемой.
Проблема редко решается усилиями одного человека. Вы можете об этом не знать, но может оказаться, кто-то уже работает над этим. Задачи при этом продолжают поступать, и их постановка оставляет желать лучшего. Часто разработчики предпочитают принять задачу и решить вопросы по ходу дела.
Важно осознавать, что если команда берет в работу нечетко сформулированную задачу, проблема переходит на их сторону. Это как если бы на конвейере вы взяли бракованную заготовку и попытались выполнить свою часть работы, в итоге получив некачественный продукт. Или как если бы вы взяли деталь, которая не прошла предыдущую обработку, и теперь вам придется приложить дополнительные усилия, чтобы довести ее до ума. Это, скорее всего, займет больше времени, чем ожидается, и может потребовать многократных исправлений.
Так что, когда вы принимаете задачу и не полностью понимаете её границы и ожидания, вы берёте на себя риск. Вы можете влиять на процесс постановки задач только косвенно через общение и ретроспективы. Менеджер даже может согласиться, что нужно изменить подход к постановке, но его согласие не гарантирует, что задачи сразу станут лучше. Этот процесс находится вне вашего контроля. Контроль переходит к вам, когда задача попадает в ваш бэклог.
Вы всё равно тратите время на разбирательство в процессе, поэтому лучше уделите эти усилия определению задачи с самого начала. Начинайте подготовку до того, как придёт время переводить задачу в статус «Active». Кто-то может сказать, что проблема не на их стороне, но учтите: когда вы берётесь за работу, вы принимаете эту проблему на себя. Не начинайте работу, пока не станет ясно, что именно от вас требуется. Уточняйте детали, декомпозируйте задачу или хотя бы договоритесь о конкретном первом шаге. Из общего «сделай хорошо» можно выделить первый шаг — добавить надпись «Тут хорошо».
Предположим, вы освоили подход к организации работы, при котором вы тратите время на глубокий анализ задачи до её начала. Этот этап является фундаментальным и способствует последующему прогрессу.
Для того чтобы получать задачи, уже чётко сформулированные на старте, важно добиться общего понимания и согласия по проблеме. Если же согласие не достигается в ходе обсуждения, целесообразно провести анализ и оценить текущие затраты, связанные с существующей проблемой и её формулировкой.
Для анализа необходимо разбить весь процесс работы над отдельной задачей на несколько этапов и оценить затраты времени на каждом из них. Определить время затрачиваемое как непосредственно на выполнение работы, так и время ожидания. Не нужно быть тим лидом, можно выполнить его самостоятельно. Для начала, надо разбить ваш процесс работы на этапы. Вот примерный набор:
Взятие задачи и уточнение требований до готовности к разработке. Здесь вы оцениваете, сколько времени уходит на то, чтобы понять задачу и уточнить все детали, необходимые для начала работы. Например, если вы взяли задачу, но менеджер сможет обсудить требования только через 3 часа, и сам разговор займет 15 минут, то общее время этой стадии составит 3 часа 15 минут, из которых 3 часа — время ожидания (wait time), а 15 минут — непосредственная работа.
Разработка. Этот этап включает в себя непосредственно программирование, ревью кода и приведение задачи к состоянию, соответствующему первоначальной постановке. Эффективность разработки не обсуждается в данной статье, но к ней также применим подход оценки времени.
Уточнение «что еще нужно» и доработка после уточнений. Этот шаг часто возникает неформально, когда в процессе работы выясняется, что требуется дополнительный функционал или изменения, которые не были оговорены изначально. Измеряем время непосредственно на уточнения и доработку, а так же время на ожидание.
Время на фиксы и проблемы, которые можно было предотвратить. Здесь вы оцениваете, сколько времени уходит на исправление ошибок, которые могли быть выявлены ВАМИ на более ранних этапах.
Время на фиксы проблем и доработки, о которых не было известно на момент постановки задачи. Это время, затраченное на решение неожиданных проблем, которые возникли из-за недостаточной детализации задачи. Измеряем время на уточнение и ожидание.
Проведите такой анализ для нескольких задач, лучше всего, если это сделает вся команда, чтобы получить качественные усредненные данные. Если вы обнаружите, что этапы 1, 3 и 5 занимают значительное время, особенно время ожидания, это указывает на проблемы с постановкой задач. Обсудите это с менеджером на ретроспективе.
Если вы пришли к согласию о наличии проблемы, крайне важно, чтобы и продуктовый менеджер также признал её. Основным показателем его согласия будет готовность инвестировать своё время и усилия в реальные изменения. Простое формальное «да, я согласен, придумайте что-нибудь, а я поддержку» может означать, что вы его не убедили, или он не видит задержки в работе как проблему для себя. Возможно, он считает, что его участие и вложения не оправданы потенциальной экономией времени и ресурсов, и предпочитает, чтобы команда самостоятельно находила решения. В таком случае не стоит тратить время на переход к следующему этапу. Вам нужно будет дополнительно работать над анализом проблемы, чтобы она стала актуальной и для менеджера, и чтобы он по-настоящему захотел её решить.
Если продуктовый менеджер признает проблему и готов вносить изменения, пора переходить к поиску решений. Правильная формулировка требований — это тема не одной статьи, и ключевым моментом здесь является то, что каждая задача должна решать одну конкретную проблему и быть сформулированной чётко и проверяемо.
В рамках ретроспективы важно уделить внимание не только ожидаемому результату задачи, но и критериям её готовности. Необходимо прийти к общему пониманию, что попадание задачи в бэклог или, тем более, в спринт ещё не означает, что она готова к выполнению. Разработчики должны иметь возможность подтвердить готовность задачи на основе чётко определённых и понятных всем критериев.
Важно также договориться о процедуре действий в случае, если задача оказывается не готова к работе. Необходимо установить механизмы, позволяющие определять неготовность задачи заранее, а не в момент, когда разработчик уже должен начать над ней работать. Это может включать в себя предварительные обсуждения задачи с командой, ревью требований перед их утверждением, а также регулярные синхронизации статуса задач в бэклоге.
Таким образом, чёткая и конкретная постановка задач позволит минимизировать время, тратимое на уточнения и исправления, и сфокусировать усилия команды на качественной разработке. Это, в свою очередь, повысит эффективность работы команды и принесёт разработчикам удовлетворение от их труда, поскольку они смогут видеть реальный вклад своей работы в успех проекта и развитие компании.
Здравствуйте! Меня зовут Леонид Нетребский. Я руковожу разработкой и проектами с 2013 года. У меня есть опыт управления командами разработчиков до нескольких десятков человек. Есть опыт управления разработкой в компаниях с полной анархией, пропитанной пилением бюджетов, до адептов метрик производительности. Я тот руководитель, кто выстраивает процесс комплексно, включая CI/CD, автоматизацию тестирования, архитектуру, SRE. При необходимости я также могу написать код, чтобы продемонстрировать пример или что-то попробовать.
Когда-то я хотел писать в блог, чтобы сказать что-нибудь. Теперь мне есть что сказать и очень рад делиться своим опытом и наблюдениями в области управления разработкой ПО.
