clops
@clops
Rocket Scientist

Как написать хорошие спецификации для разработки чтобы избежать постоянных доработок?

Коллеги,

есть проблема.

У нас — небольшая компания. В разработке завязано около 40 человек, где–то столько же руководителей проектов. Пять человек занимаются "Продуктом". В JIRA у нас висит два отдельных процесса: для функциональных спецификаций и для технических. Первый процесс постепенно перетекает во второй и оттуда уплывает в разработку. Однако, практически постоянно происходит такой "нежданчик", что клиент хотел квадратную табуретку, а ему в итоге пытаются впарить круглый стул. Функцию ведь выполняет :)

Сейчас происходит следующее:
  1. Клиент говорит ПМу, что за функционал нужен.
  2. ПМ делает "запрос" в виде пары предложений у Продукт Менеджера.
  3. Продукт "разжёвывает" этот запрос на функциональные составляющие.
  4. Дальше Тим–Лид из разработки обсуждает их с продуктом и составляет Jira Stories для разработчиков.
  5. Разраб всё сделал, отправил тестеру.
  6. Тестер всё проверил и отправил ПМу.
  7. И тут периодически начинается лютый пинг–понг из серии: "не–не–не, мне нужно другое" "ой, я ещё забыл вот это" "а можно мне перламутровые пуговицы" > как итог куча трения и потеря времени. Спринт запорот.


Как проблемы слабых спецификаций решаются у вас?
  • Вопрос задан
  • 434 просмотра
Пригласить эксперта
Ответы на вопрос 4
Самое разумное - делать прототипы. В этом случае какие бы слабые спецификации ни были, клиент в итоге получит то, что хотел за относительно разумные деньги (по сравнению с переделкой готового функционала).
Всё описать никогда не выйдет, особенно при таком длинном процессе и большом количестве ответственных звеньев.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev
software engineer
На седьмом пункте кто начинает говорить что все не так? ПМ или Клиент?

Если Клиент, то ПМ-а на мыло, раз он не может понять что хочет клиент, и передает дальше испорченные данные.

Кроме того, почему у вас тестировщик в самом конце?
Обычно requirements проверяет и пишет тестировщик, следовательно он должен быть
а) грамотным
б) присутствовать в пункте 2 или даже 1
Ответ написан
Комментировать
@Wesson
Несколько итераций обсуждения с заказчиком его хотелок могут помочь. Лучше, чтобы это делал человек, который делает требования.
Ответ написан
Комментировать
denisgorbunovmsc
@denisgorbunovmsc
руковожу проектным офисом
Два полюса - прототип и ТЗ с детальной спецификацией.
Посередине болтаются user story, но они ближе к прототипированию, хотя можно как первым этапом со спецификацией соединять.
Другое измерение - это частота, чем больше тем лучше.

Могут сильно помочь сценарии тестирования (те же user stories, по факту): детальные шаги как будем проверять разработку, что должно быть на выходе, как будет проверять пользователь. Этим по идее снимаем большую часть рисков.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы