Pull to refresh

Comments 21

Минимально достаточное ТЗ должно: полностью, чётко… описывать будущий программный продукт


Интересно, где тот шкаф через который можно попасть в то измерение, в котором существуют такие ТЗ. Там наверное, ещё единороги водятся и есть работа для ведьмака…
Теоретически бывают такие bread-and-butter / getting-things-done области разработки, где программа просто-таки ложится в переданное описание функционала. В области mission-critical / line-of-business приложений таких ситуаций значительно меньше. В современном мире, мне кажется, неизвестных столько, что проще начать разработку по минимальному черновику и корректировать ход в процессе, нежели потратить сотни страниц, которые потом всё равно придётся корректировать, т.к. они были построены из слегка не тех предположений.
Большое спасибо за статью! Отличный и подробный пример того, как не надо делать, если вы планируете получить на выходе конкурентноспособный и актуальный продукт.
А можете пояснить почему «не надо» делать?
И как делаете вы в случае работы по fixed price и требованиям ДИТ заказчика сдавать документы по госту?
Так делать не надо, поскольку, ТЗ на систему сложнее калькулятора:
1) НЕ позволяет объективно оценить стоимость и время разработки программного продукта
2) НЕ исключает потери времени и денег на ненужные действия, вынужденные доработки, длительное согласование
3) НЕ позволяет избежать разногласий и неудоволетворенности клиента и исполнителя

Однако прекрасно позволяет:
1) Потратить неведомую кучу времени на проработку документа, который превратится в устаревшую макулатуру, как только вы нажмете на кнопку «Печать»
2) Связать заказчику руки, который, на момент написания ТЗ, имеет только набор гипотез и догадок, которые вы, любезно, поможете ему упаковать в артефакт, отражающий ваши совместные галлюцинации относительно продукта, пользователей и сценариев использования и, тем более, касательно нагрузки и производительности
3) Получить иллюзию понимания сроков и стоимости проекта
4) Сделать, в итоге, совсем не то, что реально было нужно заказчику, при этом узнать об этом в самом конце.
5) Посчитать заказчика мудаком и дать ему все основания считать мудаком вас.
5) Понять, наконец, что современная разработка ПО не имеет ничего общего с постройкой зданий, и что единственной постоянным элементом требований будет только одно — их непрерывное изменение в процессе реализации.
Простите, но причём тут ТЗ?
По вашим НЕ:
1. ТЗ не является документов оценивающим стоимость и время проекта.
2. не исключает, а что исключает? Например, сменился стекхолдер, который отвечает на письма команды раз в месяц, а проект\этап нужно сдавать?
3. Это всегда может быть. Вообще не представляю, как этого можно избежать в условиях fixed price.
Как вы эти вопросы решаете?

По остальным пунктам:
1. Если ТЗ пишут люди далёкие от сути дел, или заказчик сам не знает, что хочет, то ок. но тут ничего поможет.
2. Для этого делается предпроектное исследование. Чтобы при проектировании решения учесть максим факторов.
3. Ок, а как получить не иллюзию?
4. Ну это уже кто как проектам управляет.
5. — 5. непрерывное изменение путь к большому количеству говнокода, потому что мы бежим на поводу у заказчика и допиливаем фичи, которые изначально не была заложены, в итоге любой чих выливается в недели тестирования.
Также это ведёт к отсутствию понимания заказчиком сроков выхода его продукта, не пониманием бюджета.

Давайте, чтобы не спорить, расскажите, сколько проектов вы сделали выиграв тендер на конкурентном рынке с таким подходом?

По-моему опыту я видел десятки проектов стоимостью от сотен тысяч до десятков миллионов, которые разваливались и клались в коробку, как раз по причине это гибкости и готовности команды делать изменения идя на поводу заказчика.
По-моему вы что-то недоговариваете.

www.edsd.ru/ru/proekty/razrabotka_po
Заказчик: Крупнейшая Российская библиотека.
Период: С сентября 2007.

8 лет продолжаете работать по одной и той же спеке? Крупнейшая российская библиотека решила отправить книги на Марс?
Занятно, нас так в университете учат проектировать информационные системы. После фразы «свою схему проектирования» хотелось увидеть что-то действительно новое.
Но все равно спасибо за статью и, особенно, за пример ТЗ.
Жалко РГБ в Vivaldi так и не работает :-( Bad Gateway на Нгинксе.
Прошлый век ;))
госкорпорациям понравится ;)
Ребят, вас десять лет назад заморозили в криогене, что-ли? Откуда водопад в разработке ПО в 2015-ом году? Так и напишите: мы делаем большие, неповоротливые продукты, с циклом развития в несколько лет, а потом их выкидываем и делаем заново, потому что таким способом нашим заказчикам более удобно пилить корпоративные бюджеты.

По крайней мере, будет честно.
Водопад имеет право на жизнь. К аджайлу должен быть готов прежде всего сам заказчик, а если не готов, то какие варианты?
Здесь излагается как написать программу. А вот этого как раз никогда и не требуется. Требуется нечто иное. Надергать разных библиотек, всяких там баз данных и собрать из них то, что нужно. Или напротив, написать движок для игрушек, банков, бухгалтерий. А этот движок кому то понравится? Ну, сперва написать простенький. Или на движке нарисовать свою дизайнерскую реализацию. А в процессе выяснится, что использованные средства никуда не годятся, и их нужно поменять на подходящие. Результат таков: нам удалось на платформе такой-то добиться вот такой крутизны. Если я рисую квадратики на экране, то я никогда не использую эти квадратики, а если я использую эти квадратики, то я их всяко не рисую, и не умею. Если я домо-строитель, то я уж никак не машино-строитель.
Было бы неплохо увидеть примеры ТЗ от других компаний или команд ( из комментариев), по которым были завершены проекты, с цифрами. Или ссылку на ресурс, где такое собирают для расширения кругозора и анализа желающим. Как по успешным кейсам, так и провальным. С комментариями и пояснениями.
Двадцать лет назад меня в институте учили именно так подходить к проектированию программного обеспечения. Однако времена изменились, «водопад» в большинстве случаев не подходит для современных условий. Пора обновить методику, пора…
По доброй традиции хаба «Клиентская оптимизация» поинтересуюсь:
— автор, вам известно значение термина, давшего название упомянутому хабу?
— какое отношение этот топик имеет к предметной области, описываемой этим термином?

Описанный подход является ни чем иным, как моделью водопада и используется с прошлого века. Современные подходы к разработке по ортогонально отличаются. Аджайл появился не просто так, а именно в связи с проблемами, которые возникают в случае с описанной выше моделью.

Sign up to leave a comment.