Как корректно описывать задачи разработчику

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

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

В данной статье будет описано:

  • Постановка задачи на разработку фичи
  • Постановка бага разработчику

Постановка задачи на разработку фичи

Рассмотрим простой пример задачи:

Необходимо разработать генератор отчета в doc-формате для возможности его редактировать клиентом

Время на оценку - 20-30 минут. Длительность разработки 20-30 часов максимум. Программиста привлекают к проекту (локально у него даже нет проекта развернутого, стенда для разработки нет, задачу на развертывания никто не дает) и говорят оценить задачу. Разработчик говорит окей, 25 часов хватит. Прикручивает PHPWord, подключая его из композера (параллельно матерясь, что на проекте 5 composer.json). Разработчик проверяет все решение на Word и сдает задачу. И получает 30 багов… Потому что пользователи будут работать с libreoffice, а там есть свои проблемы с показами. Все недовольны сотрудничеством. Кто виноват?

  1. Разработчик должен был уточнить все-все досконально. Это логичный ответ, но к сожалению когда что-то горит, не всегда получается корректно задать вопросы, и получить ответы. На вопрос - а что должно быть получено в конце разработки от разработчика? Ответ - ну вот doc файлы ты должен сгенеририровать, в задаче же все описано. И получается “толи я дурак, толи лыжи не едут”(с).
  2. Лид разработки. Не проверил постановку задачи и дал ее разработчику. Не сделал дизайн-ревью, когда бы понял что разработчик не совсем погружен в предметную область (в которую по сути его должен лид был и погрузить).
  3. Аналитик, который поставил задачу. Он не описал как будет использоваться система, какие граничные условия есть в использовании. И, как обычно, не описал, но написал на постановку задачи 30 минут…

Поэтому я в бытность лидом пришел к простому решению описания задачи:

  1. Краткое описание, что мы делаем (Одно предложение, обобщающее, что и зачем мы делаем.)

Пример:

Сделать Rest Api для получения и создания компаний в Bitrix24, чтобы с ним работал 1с.

  1. Какие действия нужно сделать для достижения результата (Это нумерованный список тех конкретных действий, что нужно сделать линейному разработчику. Возможно с оценкой по времени.)

Пример:

  • Создать модуль для решения данной задачи
  • Создать событие для расширения стандартного REST API
  • Создать АТД (классы) для работы с сущностью компании
  • Создать систему логирования, для хранения логов ошибок
  1. Ожидаемый результат (ненумерованный чек-лист проверки задачи)

Пример:

  • При создании компании через API, он появляется в системе
  • При возникновении ошибок синхронизации, данные должны быть сохранены в системе

Постановка бага разработчику

При возникновении бага в системе, программисту логичнее всего поставить задачу следующим образом.

  1. Шаги воспроизведения (Нумерованный список)

    Пример:

    1. Авторизоваться под пользователем с ID=5
    2. Зайти на страницу https://site.ru/crm/deal/details/130/
  2. Ожидаемый результат:

    Пример:

    Загружается страницу сделки с корректными стилями.

  3. Фактический результат:

    Пример:

    Страница не загружается, ошибка 404. (Можно приложить картинку).