Comments 12
Отличная статья, давно ждал нечто подобное. Детально, строго и понятно. Спасибо.
Жаль, что не затронута обратная сторона проблемы: в ТЗ присутствуют детали, реализация которых приводит к существенному ухудшению результата, без какой-либо необходимости со стороны бизнеса, типа "хочу одну большую кнопку - всё готово". Или конкретнее: "сервис должен выдавать все теги описания сущности по запросу", в то время как по ТЗ видно, что Заказчику нужен только 1-2 параметра из 500. Тем более, что они вообще про иные задачи, иных коллективов и команд.
Спасибо за комментарий и за то, что подсветили этот интересный момент!
Согласна, что такая проблема тоже присутствует. Но это больше вопрос построения ТЗ и планирования разработки системы/ПО: определение целей, назначения, от назначения - функций, а от них уже функциональных и нефункциональных требований.
Также обратная сторона проблемы, указанная Вами, может возникнуть в случае разработки систем/ПО «из архива» или по референтным требованиям.
хорошо составленное, проработанное и детальное ТЗ может отменить кучу аджайл коучей... потерю времени на вечные совещания, уточнения и внесение изменений.
Делая такое тз, можно прорабатывать его столько, что необходимость в реализации уже утратиться. Мы прибегаем к совмещению способов - все тз очень укрупненно, блок, который реализовывается - максимально детально. Пока пилят этот блок - детализируешь следующий.
Но за несколько формулировок - прям респект, возьму на вооружение
Нормальное ТЗ на разработку прорабатывается не так уж и долго, если помнить про перечисленные моменты выше. Заодно, как правило, Заказчик начинает гораздо лучше понимать свои хотелки и часть из них волшебным образом преобразуется или отмирает в процессе прозрения. Писать релиз по хорошему ТЗ - одно удовольствие и можно начинать прямо с тестов.
Спасибо за комментарий и за оценку формулировок – это действительно важно!
Да, Вы правы, порядок детализации зависит от подхода к разработке и сферы деятельности. В IT-стартапах чаще используются гибкие подходы, тогда как в госсекторе обычно требуется полная детализация заранее. Ваш метод поэтапной детализации - отличный пример адаптации процесса под реальные нужды.
ТЗ обычно читают аналитики и тестировщики, по моему опыту. Если разработчик ушел читать ТЗ - значит скоро розовый снег пойдет. Редко видел что бы разработчики вообще хотели куда-то дальше описания в Jira ходить.
Как мне кажется, тут скорее вопрос к процессам в команде, кто делает декомпозицию на задачи. Если не аналитики, то 100% нужно детальное ТЗ. Если нужна качественная оценка трудозатрат -- то нужно проработанное ТЗ.
А порой ТЗ может быть как что-то с низкой детализацией, по нему строится роудмап. А детализация может быть в других артефактах. И это реально имеет смысл, когда у заказчика есть план на год например. Но он его активно корректирует и пересматривает. И например оказывается что половина фичей, которая была изначально запланирована - отклонена. А вместо них взяты другие. В таких случая как-то нет смысла изначально в ТЗ прорабатывать то, что с вероятностью 50% будет работой в стол. Это слишком дорого.
Спасибо за Ваш комментарий!
Соглашусь, что в некоторых проектах разработчики редко работают с ТЗ (требованиями). Это может привести к "дырам" в ТЗ из-за разрыва между документацией и реальными задачами (о чем также говорилось в статье). В таких случаях, возможно, решение — в более тесном взаимодействии: например, аналитик может проводить короткие сессии или семинары с разработчиками при декомпозиции требований, чтобы избежать недопонимания.
Кроме того, Вы правы: детализация ТЗ зависит от процессов. Если у команды есть доступ к аналитику для уточнений, требования могут быть лаконичнее. Но если разработчики получают задачи "из воздуха", подробности становятся критичными.
Удивительно, но у меня был ровно противополоный опыт, когда надо было описывать чисто программерские алгоритмы, о которых ни мне, ни заказчику знать совершенно необязательно.
Про требования, которые будут читать уже была статья: Простые способы улучшить читаемость функциональных требований
И добавьте, пожалуйста, заголовки про "нарушение метрик" - должно быть нагляднее.
Диаграммы не только улучшают понимание, но и помогают найти противоречия.
Вот этим пользуюсь регулярно, "рисовать" после текста очень полезно.
Мне кажется, хорошее ТЗ должно описывать не только то, что нужно сделать, но и зачем. Так всем проще: легче оценить, полезна ли фича для бизнеса или нет или вообще зачем она нужна. А то иногда читаешь документацию и не понимаешь: система должна делать то-то. А зачем она должна это делать? Загадка. Я обычно пишу так: у бизнеса есть проблема такая-то, решать её будем так-то. И дальше уже детальное описание. Плюс есть шанс что, понимая исходную задачу, разрабы или другие аналитики предложат решение получше
Требования vs Реальность: Почему в ТЗ находят «дыры» и как это исправить