Pull to refresh

Comments 17

Проект, выполненный в полном соотвествии с ТЗ обычно заканчивется новыми требованиями заказчика
Проект, выполненный в полном соотвествии с ТЗ обычно заканчивется суицидом заказчика
Проект постоянно переделываемый «по мелочи» при неограниченном сроке — суицид программистов.
При ограниченном сроке — суицид ПМ.
Проект, начатый с адекватного ТЗ имеет шанс быть законченным.
Написание адекватного ТЗ — это отдельный вид работ, а платить за него не хотят.
Это так, и это правильно. Отсюда появляется процесс управления изменениями. Новые требования=новые условия. Это может быть отражено на сроках, стоимости и других ресурсах.
По мнению заказчика «Новые требования=должны были быть с самого начала=входят в первоначальный бюджет ».
Так это классика! С этим мнением нужно учиться работать. А иначе любой проект будет стремиться либо к провалу либо к убытку
Поэтому, «Новые требования<>новые условия»? Либо тонем в спорах с заказчиком…
Нет, не так. Новые требования=новые условия!!! И в спораз тонуть не нужно.
При согласовании ТЗ нужно включать:
1. Умени выявлять требования
2. Умение формулировать требования
3. Навыки проведения рабочих встреч и ведения переговоров
4. Ну и опыт…

Вижу тема актуальная для Вас? Вот если организовать такой семинар на тему ТЗ, много желающих найдется?

Webinar точно будет интересен. С обменом примеров ТЗ :)
Статья толковая. Мне лично, семинар был бы интересен. Но, вебинар удобнее, дешевле по времени и затратам на организацию.
Подумайте над его проведением. Как минимум сможете оценить фидбэк.
Процесс УИ превращает ТЗ в нечто похожее на свод законов — каждая строчка содержит кучу версий и правок, при этом документ теряет простоту понимания.
Первая статья выглядит какой-то Search оптимизированной
В половине случаев принимать проект будет некому, т.к. команда проекта часто меняется )
Новая команда анулирует половину требований в ТЗ, и добавляет новых
Sign up to leave a comment.

Articles