Постановка задачи программисту. Как ставить задачу разработчику

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

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

В целом, зачем нужно тратить время на постановку задачи? Что это дает владельцу проекта:

Постановка задачи программистам в общем похожа на постановку задач другим людям, но необходимо сразу учитывать специфику работы веб-проектов (или программ). Программист работает в своей системе координат, в своих терминах. Желательно учитывать это при постановке задачи.

В общем случае программист может двигаться по следующему алгоритму:

Очевидный вывод - если неясно прописано, то будет много уточняющих вопросов. Программист не может создавать функционал "в общем". Он работает на максимально конкретном уровне. И мышление программистов всегда требует конкретики, а не общих фраз "сделать, чтобы работало, как надо".

Избегайте обобщений и других искажений языка. Все должно быть максимально точно прописано.

Никогда не вписывайте в задачу свои рассуждения, мысли, опасения и т.д. Только ЧТО СДЕЛАТЬ. Иначе программисту придется тратить время на то, чтобы понять что нужно делать, а что является просто мыслями вслух.

Всегда прописывайте для веб-проектов в задачах следующие детали - URL страницы, логин пользователя, скрин (это сильно помогает для понимания, что же имел в виду автор задачи).

Без этого, он будет вас дополнительно тормошить вопросами, отвлекать от текущей деятельности. Сразу это все прописывайте, даже если нет понимания зачем это ему потребуется.

Чем точнее вы описываете процесс (например, нажали кнопку Оформить заказ), тем точнее по описанию сделает программист.

Почему критерий "проще"? Да потому, что это потребует меньше времени для разработки, будет надежнее работать и тем легче будет отладка. Но для бизнеса необходимо делать ПРАВИЛЬНО, а не ПРОЩЕ (хотя и это безусловно очень важно для IT системы). Поэтому обязательно прописывайте значимые детали процесса и все ветки бизнес-логики (например, а что если товара нет на складе? если у товара стоит признак Заблокирован и т.д.).

Если в проекте в техническом задании (ТЗ) есть согласованная терминология, то придерживайтесь строго ее. Если у вас есть Заявка, то не называйте ее Проект, Заказ или Запись.

Если программист увидит новый термин, это его может поставить в ступор.

Еще пример, Товар (перечень названий товаров), Экземпляр товара поставщика (такой-то товар в целом есть у поставщика) и Товар на складе (конкретный физический товар на таком-то складе). Не путайте их при постановке задачи и строго придерживайтесь единой терминологии.

Ну и конечно, это конкретные коды, а не названия словами. Если хотите поправить телефон на странице Наши контакты, не нужно писать "А можете поправить наш телефон на странице контактов?", лучше написать "Необходимо сменить телефон на ХХХХХХ на странице https://site.ru/contacts". Второе он гораздо лучше поймет без дополнительных уточнений.

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

Что это может быть:

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

Не тратьте внимание (энергию, время) программиста на то, чтобы оседлать ваш поток сознания. Если делаете видеоскрин, то не надо заходить издали или делать что-то малозначащее для задачи.

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

На практике бывают 3 типа задач - решение проблем и правки ошибок, новая возможность, оптимизация-шлифовка.

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

Как лучше всего описать ошибку: записать видеоскрин с указанием URL, времени ошибки, логина. В видео можно показать консоль браузера (F12 / Console). Также хорошо бы дать ожидаемый результат (особенно когда неверно что-то рассчиталось). В этом случае программисту проще будет понять, когда получается неверный результат и где именно идет нестыковка.

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

Если это шлифовка внешнего вида, то лучше всего описывать это скринами - сделали скрин экрана и показали стрелками и текстом на нем, как вы хотите изменить экран.

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

Название делаем коротким, лаконичным, понятным в директивном стиле "Сделать то-то".

В тексте указываем:

Постановка задачи влияет на результат. Если плохо на входе, то ничего хорошего на выходе скорее всего не получится. Оценка сроков проекта обычно не оценивает затраты на задержки при взаимодействиях по задаче и переделкам в случае неточностей при реализации (хотя ошибка была в неточной исходной постановке задачи).

Для автора задачи хорошая постановка задачи упрощает жизнь: меньше очевидных вопросов от разработчиков и тестеров + на описание задач можно потом задействовать при создании документации по проекту.

Источник: