В теме 3 ответа, и 2 участника, последнее обновление сделано пользователем 
Андрей Беняш 12 г, 3 мес. назад.
-
Сообщения
-
Пытался структурировать, но опишу как есть:
Наша команда ведет разработку продукта. Продукт большой и сложный. Продукт внедрен у двух заказчиков, внедрен он на условиях того, что разработчики будут по мере необходимости дописывать продукт под требования заказчика.
Раз в год, в апреле начальник отдела разработки начинает посевную) — рассылается файл в Excel менеджерам других подразделений, бизнес-аналитикам, тестировщикам и прочим. Каждый из них высказывает пожеланий того, что он хочет видеть в функционале продукта через год. Все предложения сводятся в единый документ, который опять рассылается с предложением оценить по каждой позиции приоритет. На основе приоритета и «на глаз» трудоемкости реализации, позиция попадает в план работ.
При этом возникали проблемы:
а) Если требование не попадало в план работ, с большой долей вероятности оно могло уже никогда туда не попасть.
б) После того, как отдел разработки «уведомлял всех о тех позициях над которыми он пожелал работать» наступал длительный период согласований и изменений. Согласование плана работ растягивалось на месяцы. Работы «просачивались» в месячные планы исполнителям и работы по ним велись, хотя само требование могу быть изменено.
в) Не было гарантии того, что требование заказчика было реализовано должным образом. Процесс уточнения был достаточно скрытым.
Я начал разрабатывать систему, которая помогла бы избежать описанных выше проблем, и прошу совета у опытных читателей.
Рабочие заданий фиксируются у нас в Redmine () и я создал отдельную ветку «Требования». В этой ветке содержатся все запросы заинтересованных лиц, когда-либо попадавшие в excel’евский файлик. Кроме того, любой участник (в том, числе не входящий в список тех, кто влияет на планы работ) может внести свое требование или дополнить существующие. Т.е. получается такой своеобразный архив, в котором собраны дополнительные материалы, шаблоны отчетов, переписка с заказчиками, записи совещаний и т.д.
По мере включения требования в план работ на него открывается т.н. «мини-проект». Мини-проект получает 3-5 подзадач: анализ, разработка, тестирование. Если в реализации мини проекта участвуют несколько разработчиков и тестировщиков. Задача анализа состоит в том, чтобы подготовить и согласовать техзадание. Техзадание согласовывается со всеми участниками. В виду того, что число участников проекта небольшое (помимо аналитика 2-4 человека) согласование происходит быстро.
Из реализованного пока всё.Советов в чем именно вы хотите услышать? Что вам надо сделать? :) Это вам пока что виднее.Я бы вам посоветовал как минимум следующее — чтобы понимать, чего вам надо от СУТ, сделайте анализ «Проблема — Решение»:
1. Текущий процесс (как делается сейчас)
2. Какая проблема возникает
3. Каким образом её будет решать разрабатываемая вами системаНапример:
1. Как есть: Требования фиксируются раз год в апреле
2. Проблема: В другие месяцы появляющиеся требования не фиксируются (или невозможно добавить новые требования)
3. Как будет решаться: Требования можно будет добавить всегда, для таких требований будет специальный статус, указывающий, что они не в scope текущего года.Количество пунктов можно расширять. Количество решений может быть больше 1го.
Спасибо за ответ, постараюсь сделать пост от то как у нас все дальше развивалосьпост о том*
Вы должны авторизироваться для ответа в этой теме.
