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

Question

[Алексей Куликов]

Коллеги,

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

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

Сейчас происходит следующее:

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

Как проблемы слабых спецификаций решаются у вас?

Answer 1

[Алексей Уколов]

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

Answer 2

[Saboteur]

На седьмом пункте кто начинает говорить что все не так? ПМ или Клиент?

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

Кроме того, почему у вас тестировщик в самом конце?
Обычно requirements проверяет и пишет тестировщик, следовательно он должен быть
а) грамотным
б) присутствовать в пункте 2 или даже 1

Answer 3

[Wesson]

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

Answer 4

[Denis Gorbunov]

Два полюса - прототип и ТЗ с детальной спецификацией.
Посередине болтаются user story, но они ближе к прототипированию, хотя можно как первым этапом со спецификацией соединять.
Другое измерение - это частота, чем больше тем лучше.

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