Одна из самых частых проблем при выдаче и приемке задач, что задача банально плохо описана. Из-за этого разработчик делает «не то», автор злится, сроки плывут, и каждый валит на другого.

Человек, который выдает задачу, в голове все понимает. Но как только нужно объяснить это другому, начинается квест. Появляются умные слова и надежда что и так все понятно. И ноль конкретики.

Порой кажется, что чем умнее звучит формулировка задачи, тем она лучше. «Улучшить понятность вывода отчета по продажам» звучит солиднее, чем простое «Добавить колонку «Контактное лицо» в отчет по продажам».

Но за умной фразой легко спрятать бесконечный объем работы. Добавить колонку - это 5 минут работы, а вот улучшать понятность вывода можно неделями, подключая аналитиков и устраивая A/В тестирование.

И даже если мы честно написали «Добавить колонку «Контактное лицо» в отчет по продажам», задача все равно не идеальна. Из нее не видно, какую вообще проблему мы решаем и зачем это поле нужно.

• Если менеджеру нужно быстро связаться с человеком, то в отчете полезно видеть еще и телефон/почту
• Если нужно отбирать продажи по незаполненным контактным лицам, то подойдет отдельная обработка или другой отчет
• Если нужно анализировать, какие контактные лица закреплены за конкретными менеджерами, то добавляем еще и «Ответственный менеджер по контакту»
• Если важно понимать, кто чаще согласует сделки на стороне клиента, включаем «Должность» контактного лица
• Если задача контролировать, с какими контактами давно не было активности, в отчет выводим дату последней продажи или последнего контакта

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

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