NK
Впрочем, всеодно будешь бесконечно прав
Size: a a a
2016 August 09
SR
Всё всегда нужно документировать.
NK
Угу. Нужно
NK
Лично был свидетелем того, как несколько раз ТЗ писалось после программы
NK
И то только потому, что заказчик был бюджетником
SR
Это же как решение задачи подгонять под ответ
SR
Ну и смысл?
NK
Смысл в том, что все надо документировать, иначе этого не делалось вовсе
NK
ТЗ - отдельная сложная работа. За всю свою жизнь, я дай бог штуки 3 более менее нормальные видел... Остальные только мешали работать
EE
Вам лень писать документацию. Отвечайте тогда просто "мы используем scrum" )))) вспомнился анекдот
NK
:)
EE
Я 3 года Аналитиком в сбербанке работал. Часто написать внятно тз не возможно так как требования меняются каждую секунду))
EE
А так нас конечно в IBM учили как надо по уму. Но в жизни то так не выходит.
NK
1. Плохо представляет что ему нужно
2. Специалистов у заказчика скорее всего нет, иначе он бы сам все реализовал
3. ТЗ надо писать специалисту, а еще лучше самому разработчику в прямом содействии с заказчиком
4. Многи п3 пропускают, ибо в все и пишется в процессе обсуждения ТЗ
5. Заказчику надо все и сразу, а платить за разработку ТЗ он не хочет
2. Специалистов у заказчика скорее всего нет, иначе он бы сам все реализовал
3. ТЗ надо писать специалисту, а еще лучше самому разработчику в прямом содействии с заказчиком
4. Многи п3 пропускают, ибо в все и пишется в процессе обсуждения ТЗ
5. Заказчику надо все и сразу, а платить за разработку ТЗ он не хочет
NK
6. Очень часто бюджетники любят маскировать разработку под покупку, так гимора меньше
NK
Но так со временем у разработчика напряг
МС
Не-не, не разработчик должен писать ТЗ, а ПМ.
EE
Тз должен писать или продуктолог или аналитик
NK
Ну я говорю с учетом имеющегося опыта, который был наработан достаточно крупной компанией, не будем ее светить
EE
На крайняк пм