История изменений

Можно только примерно при:

1. наличии известной тебе команды, знакомой с техническими инструментами и скиллами, которые тебе известны (кто на что способен в деле, а не на словах);

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

Самое паршивое, что ничего из этого может не быть. Т.е. ТЗ может существовать от какого-нибудь архитекта, но для другой системы, а для данной системы надо половину ТЗ переписывать. Ответственный тимплид или манагер от заказчика может быть сам новичком на проекте, и нифига не знать специфики того, что хочется реализовать, а глобальный концепт либо не раскрывает, либо сам не знает, какая фича важнее.

Рядовые молодые нифига не знают, что и как делать. Максимум, можно рассчитывать, что капитаны неплохо разбираются в конкретном ЯП и ОС, но не обязательно в нужных фреймворке, библиотеках, протоколах. А джунов надо еще доучивать в процессе, писать им инструкции детальные, как что делать, чтобы от них вообще была какая-то польза.

И вот такая вот команда одновременно осваивает матчасть, уточняет ТЗ, пробует прототипы, выясняет, что, например, реализовывать смысла нет, и надо заказчику разжевать, почему, и предложить варианты выхода из тупика. Вот на эти все сношения и прототипы/эксперименты уходит время. И самое хреновое, что многие полковники не понимают, что некоторые задачи не решаются атакой в лоб кавалерийским наскоком, и требуется пересмотр концепции, стратегии тестирования, планирования сроков реализации фич и т.д.

Можно только примерно при:

1. наличии известной тебе команды, знакомой с техническими инструментами и скиллами, которые тебе известны (кто на что способен в деле, а не на словах);

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

Самое паршивое, что ничего из этого может не быть. Т.е. ТЗ может существовать от какого-нибудь архитекта, но для другой системы, а для данной системы надо половину ТЗ переписывать. Ответственный тимплид или манагер от заказчика может быть сам новичком на проекте, и нифига не знать специфики того, что хочется реализовать, а глобальный концепт либо не раскрывает, либо сам не знает, какая фича важнее.

Рядовые молодые нифига не знают, что и как делать. Максимум, можно рассчитывать, что капитаны неплохо разбираются в конкретном ЯП и ОС, но не обязательно в нужных фреймворке, библиотеках, протоколах. А джунов надо еще доучивать в процессе, писать им инструкции детальные, как что делать, чтобы от них вообще был какая-то польза.

И вот такая вот команда одновременно осваивает матчасть, уточняет ТЗ, пробует прототипы, выясняет, что, например, реализовывать смысла нет, и надо заказчику разжевать, почему, и предложить варианты выхода из тупика. Вот на эти все сношения и прототипы/эксперименты уходит время. И самое хреновое, что многие полковники не понимают, что некоторые задачи не решаются атакой в лоб кавалерийским наскоком, и требуется пересмотр концепции, стратегии тестирования, планирования сроков реализации фич и т.д.