Часто бывает, что компании испытывают трудности с разработкой технического задания или же просто постановкой задачи разработчикам. Безусловно, каждый проект уникален, индивидуален, но есть как минимум три совета, следование которым может снизить риск получения не того результата, который представлял себе заказчик. Рассказывает сооснователь сервиса
promkod.ru Андрей Приображенский.
Scrum - одна из наиболее популярных и гибких методологий разработки программного обеспечения. Она в первую очередь ориентирована на клиента и позволяет ему корректировать требования в любой момент времени. К тому же, методология достаточно проста в изучении и, в принципе, правильная ее реализация способствует тому, чтобы в конце каждого Sprint'а (фиксированный временной интервал по завершению которого решается какая-то задача) получить потенциально рабочий продукт. Всем скептикам, кто говорит, что она не работает, отвечу, читайте инструкцию.
После каждого спринта проводится ретроспектива - мероприятие направленное на улучшение процесса, в ходе которого в команде задаются и обсуждаются 3 вопроса:
Иными словами, и клиент, и разработчик должны подойти к обсуждению задачи и будущего проекта. Максимально подробно разберите техническое задание и уточните все моменты, которые вызывают сомнения. Помочь в этом может сделать бизнес-аналитик, который может собрать требования клиента и команды разработки, согласовывать интересы всех стейкхолдеров.
Чтобы помочь ему вписаться в тот микромир, который он сам создал своей оценкой, нужны тайм-лайны по проекту, хотя бы дата начала и окончания, но желательно всё же структурировать проект по фазам и прописать дедлайны изначально.
Используйте специальные методологии разработки
Постановка задачи разработчику - это малая часть большого вопроса, и в этом процессе идеально использовать специальные методологии разработки, которые описывают фреймворк (структуру/концепцию) и правила игры. Например, Scrum. Правила игры нужны, они дисциплинируют и обязывают выполнять определенные ежедневные действия.Scrum - одна из наиболее популярных и гибких методологий разработки программного обеспечения. Она в первую очередь ориентирована на клиента и позволяет ему корректировать требования в любой момент времени. К тому же, методология достаточно проста в изучении и, в принципе, правильная ее реализация способствует тому, чтобы в конце каждого Sprint'а (фиксированный временной интервал по завершению которого решается какая-то задача) получить потенциально рабочий продукт. Всем скептикам, кто говорит, что она не работает, отвечу, читайте инструкцию.
После каждого спринта проводится ретроспектива - мероприятие направленное на улучшение процесса, в ходе которого в команде задаются и обсуждаются 3 вопроса:
- что мы сделали хорошо и продолжим делать;
- что мы прекращаем делать;
- что нам нужно оставить и улучшить.
Подключите бизнес-аналитика, который поможет согласовать бизнес-интересы стейкхолдеров
При постановке задачи разработчикам, нужно сделать ее понятной с точки зрения бизнес-требований. Разработчик должен участвовать в ее формировании, закрывая компетенцию технических требований. Он с самого начала должен понимать, какую бизнес-задачу должен решать продукт или какие ограничения/проблемы устранять, стоимость и сроки проекта и изначальную готовность заказчика менять в компании какие-то процессы, если этого потребует предлагаемое решение.Иными словами, и клиент, и разработчик должны подойти к обсуждению задачи и будущего проекта. Максимально подробно разберите техническое задание и уточните все моменты, которые вызывают сомнения. Помочь в этом может сделать бизнес-аналитик, который может собрать требования клиента и команды разработки, согласовывать интересы всех стейкхолдеров.
Структурируйте проект по фазам и ставьте разработчику тайм-лайны
Разработчики довольно болезненно относятся к оценкам, которые за них сделал кто-то другой, у них нет внутреннего чувства согласия, и при любой ситуации они это будут показывать, например, провалом сроков. Когда же он сам дает оценку, даже если провальную (я сейчас про адекватных разработчиков), то чувствует ответственность за это, поэтому у него есть мотивация это исправить.Чтобы помочь ему вписаться в тот микромир, который он сам создал своей оценкой, нужны тайм-лайны по проекту, хотя бы дата начала и окончания, но желательно всё же структурировать проект по фазам и прописать дедлайны изначально.
