How to
RedLab
11 часов назад
ADPASS рекомендует материал к прочтению
Falcon Space
Постановка задачи программисту. Как ставить задачу разработчику
Статья для менеджеров проектов и владельцев продукта, которые имеют потребность ставить задачи напрямую своим программистам.
Введение
Пишу эту статью для менеджеров проектов и владельцев продукта, которые имеют потребность ставить задачи напрямую своим программистам.
Я сам являюсь разработчиком, и это взгляд на постановку задачи именно со стороны разработки, то есть, что я бы хотел видеть на входе для реализации задачи.
Зачем нужна хорошая постановка задач?
В целом, зачем нужно тратить время на постановку задачи? Что это дает владельцу проекта:
-
Задачи быстрее делаются;
-
Меньше требуется доработок после исполнения;
-
Меньше ненужных взаимодействий между разработчиком и автором задачи по выяснению деталей;
-
Задачу проще проверять (можно проверку делегировать другим людям).
Постановка задачи программистам в общем похожа на постановку задач другим людям, но необходимо сразу учитывать специфику работы веб-проектов (или программ). Программист работает в своей системе координат, в своих терминах. Желательно учитывать это при постановке задачи.
Как решает задачу программист
В общем случае программист может двигаться по следующему алгоритму:
-
Анализ задачи на пробелы или отсутствие понимания (есть ли белые места в задаче?). Если такие места есть, то идет череда вопросов по задаче.
-
Мысленное выполнение задачи и анализ ограничений. То есть выстраивается дорожка, как это все будет работать и есть ли какие-то ограничения. Если есть проблемы, то опять идет обсуждение.
-
Подготовка структуры данных. Изменения в базе данных для реализации задачи. Иными словами — это подготовка окружения для выполнения задачи.
-
Реализация задачи. Создаем необходимый функционал.
-
Тестирование задачи. Тестер проверяет задачу на основе начальной постановки задачи.
-
Поставка задачи. Если используется GIT, ветки кода и разделение dev/prod — то идет заливка в нужную ветку, слияние с основной веткой и так далее. В целом, это уже тех детали не нужны для темы статьи.
Очевидный вывод — если неясно прописано, то будет много уточняющих вопросов. Программист не может создавать функционал «в общем». Он работает на максимально конкретном уровне. И мышление программистов всегда требует конкретики, а не общих фраз «сделать, чтобы работало, как надо».
Что важно учесть в плане постановки задачи
Конкретные предложения в формате «Что сделать»
Избегайте обобщений и других искажений языка. Все должно быть максимально точно прописано.
Формат текста задачи должен быть директивный и отвечать на вопрос что сделать.
Никогда не вписывайте в задачу свои рассуждения, мысли, опасения и так далее. Только что делать. Иначе программисту придется тратить время на то, чтобы понять что нужно делать, а что является просто мыслями вслух.
Детали окружения
Всегда прописывайте для веб-проектов в задачах следующие детали — URL страницы, логин пользователя, скрин (это сильно помогает для понимания, что же имел в виду автор задачи).
Без этого, он будет вас дополнительно тормошить вопросами, отвлекать от текущей деятельности. Сразу это все прописывайте, даже если нет понимания зачем это ему потребуется.
Последовательность действий и учет разных веток алгоритма
Чем точнее вы описываете процесс (например, нажали кнопку Оформить заказ), тем точнее по описанию сделает программист.
Если вы чего-то не описали — он либо будет долбить вас вопросами, либо, что хуже, сделает так, как ему кажется проще сделать (именно ПРОЩЕ, а не как правильно для бизнеса).
Почему критерий «проще»? Да потому, что это потребует меньше времени для разработки, будет надежнее работать и тем легче будет отладка. Но для бизнеса необходимо делать правильно, а не проще (хотя и это безусловно очень важно для IT системы). Поэтому обязательно прописывайте значимые детали процесса и все ветки бизнес-логики (например, а что если товара нет на складе? если у товара стоит признак Заблокирован и так далее).
Учитывайте язык разработчика
Если в проекте в техническом задании (ТЗ) есть согласованная терминология, то придерживайтесь строго ее. Если у вас есть Заявка, то не называйте ее Проект, Заказ или Запись.
Если программист увидит новый термин, это его может поставить в ступор.
Еще пример, Товар (перечень названий товаров), Экземпляр товара поставщика (такой-то товар в целом есть у поставщика) и Товар на складе (конкретный физический товар на таком-то складе). Не путайте их при постановке задачи и строго придерживайтесь единой терминологии.
Ну и конечно, это конкретные коды, а не названия словами. Если хотите поправить телефон на странице Наши контакты, не нужно писать «А можете поправить наш телефон на странице контактов?», лучше написать «Необходимо сменить телефон на ХХХХХХ на странице https://site.ru/contacts». Второе он гораздо лучше поймет без дополнительных уточнений.
Учитывайте служебные действия
Помимо основных бизнес-действий, например, создание заказа, может быть сделано множество мелких служебных действий. Очень хорошо будет, если вы сразу это можете учитывать.
Что это может быть:
-
Логирование операции (прописывайте какие данные логировать).
-
Уведомление (кого уведомить, какой текст и ссылка в уведомлении).
-
Проверка доступа (кто имеет доступ на выполнение данной операции. Что делать, если не имеет доступ?).
-
Проверка ввода пользователя, проверка форматов ввода (указание форматов телефона, какие поля обязательны, какие специфичные проверки надо сделать для приема данных формы).
Обозначать общий контекст задачи (кратко)
Если человек понимает, зачем нужен и как используется результат его задачи, то он лучше будет понимать значимость и важность своей задачи, а также примет правильные решения в непрописанных ситуациях. Поэтому кратко поясните зачем нужна эта задача для проекта.
Убрать всю воду
Не тратьте внимание (энергию, время) программиста на то, чтобы оседлать ваш поток сознания. Если делаете видеоскрин, то не надо заходить издали или делать что-то малозначащее для задачи.
Не нужно в задачу вставлять вводные обороты (на мой взгляд, боюсь что, вроде бы и так далее). Чем суше и конкретнее вы пишете, тем лучше для дела.
Типы задач для программистов
На практике бывают 3 типа задач — решение проблем и правки ошибок, новая возможность, оптимизация-шлифовка.
Решение проблемы и правка ошибок
Тут крайне важно добиться того, чтобы программист мог воспроизвести ошибку. А для этого необходимо ему дать все необходимые данные по данной ошибке. Очень сложно решать ошибку, когда у тебя она не воспроизводится.
Как лучше всего описать ошибку: записать видеоскрин с указанием URL, времени ошибки, логина. В видео можно показать консоль браузера (F12 / Console). Также хорошо бы дать ожидаемый результат (особенно когда неверно что-то рассчиталось). В этом случае программисту проще будет понять, когда получается неверный результат и где именно идет нестыковка.
Новая возможность
В целом, вся эта статья именно про подобные задачи. Требуется создать новую возможность для проекта. Используем пункты из предыдущего раздела.
Оптимизация, шлифовка
Если это шлифовка внешнего вида, то лучше всего описывать это скринами — сделали скрин экрана и показали стрелками и текстом на нем, как вы хотите изменить экран.
Самый дурацкий вариант -это просто текстом без конкретики описывать, что надо изменить. В эти моменты мозг программиста просто взрывается — пытается понять, что где нужно поменять, что имеет в виду автор задачи и не получается это сделать.
Так как ставить задачу?
Название делаем коротким, лаконичным, понятным в директивном стиле «Сделать то-то».
В тексте указываем
-
Конкретику по окружению (URL, роль или логин пользователя);
-
Как должно работать;
-
Какие служебные действия должны производиться;
-
Ограничения бизнес-логики;
-
Кратко поясняем, зачем это нужно (для пользователя или для бизнеса);
-
+100 бонусов в карму за скрин с комментариями, стрелками по сути задачи.
Заключение
Постановка задачи влияет на результат. Если плохо на входе, то ничего хорошего на выходе скорее всего не получится. Оценка сроков проекта обычно не оценивает затраты на задержки при взаимодействиях по задаче и переделкам в случае неточностей при реализации (хотя ошибка была в неточной исходной постановке задачи).
Для автора задачи хорошая постановка задачи упрощает жизнь: меньше очевидных вопросов от разработчиков и тестеров + на описание задач можно потом задействовать при создании документации по проекту.
Лучшее в блогах
Вам понравится
Nethouse
13.09.2024
Конструкторы Wix и Ecwid ушли из России. Каким конструктором сайтов его заменить
![]()
Wix и Ecwid, популярные конструкторы сайтов, прекратили свою работу и поддержку существующих пользователей на территории России. Это коснулось всех: доступ был заблокирован для аккаунтов как на бесплатном, так и на премиум-тарифах.
HINT
13.09.2024
The Gate
26.08.2024
Новости 
Кейсы 
Интервью и дискуссии 
Маркетинговые исследования 
Просто о сложном 
Проверено ADPASS 
Рекламные кампании 