Andrey
С инициативой всё просто - кому больше нужно, тот и проявляет инициативу. Если Вам надо качественно закрыть вакансию к концу февраля, то наверное это Вы должны больше проявлять инициативу :)
Зависит от детальности ваших ТЗ, конечно. Если предположить, что ТЗ у вас детальное, с точностью до каждого поля и развилки, то повторно это описывать смысла нет, разве что уточнить по итогу. В реальности же, как правило, в ТЗ бывает описано всё довольно крупноблочно, детали потом обсуждаются в каких-то переписках, а потом вообще устно. ИМХО, будет полезно, если кто-то в конце соберёт детальные итоговые требования в кучу. Наверное этот кто-то это рядовой разработчик, больше наверное некому. Хотя скорее это работа аналитика, на мой взгляд. Не знаю, есть ли у вас такие.
Не заметил у вас пункта о требованиях:
Что я считаю очень важным документировать для заказной разработки - это окончательные, детальные требования к приложению, то есть, как же в итоге должно быть. Если это не документировать, то очень сложно потом бывает что-то починить или не сломать при развитии, потому что знания об итоговых требованиях как назло оказываются в голове человека, которого с нами сейчас нет. Приходится читать код, изучать данные в базе и логах, что затратно и всё равно не гарантирует полного понимания всех требуемых вариантов использования.
По теории, это знание раскрывается тестами, но практика показывает, что всё тестами не покроешь по причине их затратности. Описать же 100% требований текстом вполне посильно, а при наличии шаблона и навыков - и недолго.
Идея писать документацию - хороша :)
Но из опыта скажу - серьёзная документация требует организационного решения:
- кто и когда должен писать какие разделы,
- как его этому обучить и на это мотивировать,
- кто и когда будет контролировать соответствие написанной документации реальности.
Описания этого решения в тексте явно не хватает :)
Причина 0: Вы неправильно (не полностью) определили стейкхолдеров и их критерии успеха проекта!
Качество разработки в первую очередь определяется качеством постановки задачи. Если постановку задачи делал малоопытный человек, то проблемы гарантированы и разработчики никакими своими процессами такой проект не спасут.
Огромное количество проблем современной разработки обусловлено именно падающей культурой определения требований.
Сколько слов-то!
А причина просто в том, что в компании негодный «технический директор» - тот, который «дорос из единственного программиста».
Нужен ХОРОШИЙ технический директор, и всё! :)