Comments 8
Как аналитик со стажем больше 4 лет могу уверенно сказать что понятие «Актуальная документация» это как горизонт - условная линия между небом и землей, которая отдаляется по мере приближения.
Все ТЗ и прочие документы, как бы хороши ни были всегда можно доработать, а с учетом прогресса скиллов более старые документы вызывают желание их переделать.
Да, именно об этом и речь. Поэтому нельзя прятаться за формальной готовностью. Не готовность, а договорённость о понимании и совместных усилиях.
В итоге все сводиться к тому что нужно сделать как можно быстрее и так, чтобы программист, который будет это читать, не плакал.
Это верно. Потому что скорость - чрезвычайно важна как для бизнеса, так и показатель вашего профессионализма. На втором месте - это готовность урегулировать все вопросы и с программистами, и с остальными стейкхолдерами - уже в процессе. Доработать требования, подправить, уточнить, если необходимо. Не ждать мифической «готовности», а делать проект. В agile разработке это так.
А если это заказная разработка то все немного меняется
и какие-то критерии готовности все-таки приходится вводить
и изменения за рамками "Готовности" приводят к изменению сроков и денег
и становится немного сложнее оценивать "готовность" и "готовность к изменениям"
Да, конечно. Но это всё равно предмет договорённости, как по форме (например, глоссарий есть, сценарии use case описаны, тестовые примеры приложены , мокапы интерфейсов приложены, все элементы интерфейса описаны, use case, sequence, state диаграммы прилагаются), так и по сути. А может быть просто быстрая формулировка задачи в контексте текущего понимания.
Даже договариваясь по форме, никто не гарантирует, что диаграммы правильные и понятные. Идея валидации, казалось бы разумная, но кто это будет делать? Пока не приступили к реализации, всегда будет много неясностей. Поэтому совместная работа важнее - в соответствии с Agile.
Готовность Спецификаций это достаточно проработанная тема в инженерии требований.
Мои старые материалы ушли в небытие, но у Натальи Желновой должны остаться
Пример классической школы Requirements Enginering
https://habr.com/ru/articles/231961/
Agile и 100% готовность в принципе плохо совместимы. Так что да, только гибкость и итеративные улучшения.
Когда ваши требования готовы?