Как писать задачи

Небольшой лайфхак. Разработчиками надо рулить, надо ставить таски.
Путь проджекта, ПМа, лида предполагает, что на входе у вас появляется что-то очень абстрактное вида "надо вот такую вундервафлю запилить и к нам привернуть, надо вчера«, а разработчик и конечный исполнитель (и вся команда) хочет что-то конкретное, вида копания от А до Б с предсказуемым результатом.

Надо как-то первое со вторым срастить.

Какие моменты следует помнить, на входе, чтобы проще жилось

• постановка задач — это тоже задача
• понимание неопределенностей — это тоже задача
• исследование решений, поиски ответов — это тоже задача
• оценка получившегося, интеграция — это тоже задача, и не одна
• на технические вопросы отвечают технические специалисты; ПМ, ПО и проджект просто не в состоянии выдумать все аспекты за них

Еще неплохо бы вспомнить про критерии постановки целей и задач — в технической среде больше любят https://ru.wikipedia.org/wiki/SMART (так-то подходов в избытке, см OODA, GROW, PDCA и даже ТРИЗ в малой части).

Технический путь от фантазий к реализациям
несложно логически разбить на 4 этапа:

• анализ (как вообще можно/следует нам это делать)
• декомпозиция (какие конкретные шаги следует предпринять)
• выполнение (прохождение шагов с прошлого этапа)
• интеграция/синтез (оценка результата и доступность реализации для вышестоящей задачи/цели)

Ключевым словом задачи является слово «надо». В вариантах «надо сделать», или «надо, чтобы». Не абстрактная «документация», не сборник KPI или OKR-целей, не наборы мокапов, и т. п. Перевод формализации в форму «надо» уже является первым и значительным шагом. Надо-то что?

Сам лайфхак:

1. Описываем, что нам надо получить (суть задачи)
2. Описываем, зачем нам это надо
3. Описываем, что для этого надо сделать
4. Описываем, как мы будем это делать
5. Описываем, как надо представить результат

Что здесь важно: на первые два вопроса вполне может дать ответ не самый технический человек — product owner, проджект, ПМ, заказчик, бизнес-аналитик (если есть). Первых двух пунктов достаточно для старта!

Остальные ответы технический исполнитель вполне может найти и предложить сам. Для разработчиков высокого уровня вполне корректный вопрос «предложи удобное решение, вот для таких вводных». Более того, хороших и дорогих разработчиков ценят и любят как раз за то, что у них есть ответы на вопросы «как сделать то или иное хорошо». Не надо изобретать в той сфере, где вы сами не разбираетесь, и подсказывать неоптимальные ходы, это иногда даже вредно и местами бесит людей.

В ситуации, когда ПМ нарезает задачи команде на дистанцию вперед, не надо стесняться описывать только начальные пункты. Аспекты реализации и их оценка на этом этапе не важна, не усложняйте процесс.

Когда придет время, для понимания недостающего можно выделить отдельные задачи на исследования и прототипы. Или наоборот, запустить исследования и прототипы заранее, в параллель, чтобы потенциальные грабли проанализировать — тут смотрите сами.

Важно: поскольку «задачи на поиск ответов» это тоже задачи, к ним такие же требования по результатам — результат должен быть представлен в объективной форме. Изучал варианты — дай сводную, что смотрел и почему. Выбрал подходящий — напиши кратко, почему. Собирал прототип или мокап — покажи прототип. Любой таск-трекер позволяет добавить материалы в задачу почти в любой форме.

Пример

1. Суть: сделать сбор и аналитику данных (вот этих)
2. Зачем: чтобы группа аналитики могла собирать выводы, а группа мониторинга настроить алерты

— на этом этапе задача уже поставлена, но не проанализирована, и не декомпозирована

3. Используем вот такой механизм, надо впихнуть его вот сюда и сюда

— мы провели анализ (возможно спросили у умного технического гуру)

4. Как сделать: привернуть вот эту либу вот туда, настроить подключение вот тут, написать прослойку вот здесь, и вон те операции тоже вот таким механизмом

— мы провели начальную декомпозицию. Этапы 3 и 4 можно, а иногда нужно, поручать самим исполнителям. Даже с защитой решения: а почему выбран именно такой механизм? а почему нам подходит именно это?

На корню исключает проблему «я так сделал, потому что мне так сказали».
Шаги 3 и 4 могут вырасти в отдельный пул более мелких подзадач, это нормально. В этом и состоит суть декомпоза.

Шаги этапа 4 могут прямо так и стать заголовками подзадач. И те, в свою очередь, тоже: проекты бывают сложными.

5. В итоге: что потребуется сделать, чтобы запустить решение? Проверить/протестировать вот так, включить в проект вот здесь, написать инструкцию для людей (см. п.2), включить, настроить, оценить.

— этот пункт (интеграция/синтез) проверочный. Никому обычно не нужны решения, которые сделаны, но не используются. Задача _не_ решена, пока решение нельзя потрогать, а заинтересованные стороны не получили результат.

Развлекайтесь.

Материалы на посмотреть:

• https://en.wikipedia.org/wiki/Problem_solving
• https://en.wikipedia.org/wiki/Problem_structuring_methods
• https://en.wikipedia.org/wiki/Category:Problem_solving_methods

PS. Логическому финту со «словом надо» меня научил один хороший человек примерно в 2009-м. Постановка задач людям — отдельный навык, который надо усердно качать. Я тогда был хоть и начальником, но молод и зелен. Так вот: различные «сделайте, пожалуйста» и «пойдите разберитесь» это вялая херня, которая таит в себе массу возможностей не сделать, сделать не то, не тогда, и просто пролюбить полимеры.

Либо ты можешь внятно сказать, что тебе надо (проверочное слово!) на данном уровне проработки, тогда просто скажи. Либо ты не можешь, тогда выплюнь морковку найди к задаче человека, который сюда скажет, что надо, и как надо лучше. Немножко армейский тон, но дело того стоит.

Добавлено позже:

• обратите внимание на полезное отличие задачи от хотелки, которое дополнительно описывает путь от «хочу» до упомянутого «надо»