Прежде всего, надо определить кто пишет и с какой целью.
ПМ (руководитель проекта) пишет документацию с точки зрения управления. Т.е. ПМ оценивает какие стадии у проекта, их трудоемкость и предварительную стоимость.
Для этого ПМ должен очень хорошо представлять что именно будет сделано, поэтому его оценка основывается на аналитических документах.
К аналитическим документам относятся:
ПМ (руководитель проекта) пишет документацию с точки зрения управления. Т.е. ПМ оценивает какие стадии у проекта, их трудоемкость и предварительную стоимость.
Для этого ПМ должен очень хорошо представлять что именно будет сделано, поэтому его оценка основывается на аналитических документах.
К аналитическим документам относятся:
- Business vision. В этом документе кратко обозначается цели и задачи проекта, для кого он делается и какой примерной функционал будет реализован в проекте. Здесь же может указываться как проект будет развиваться.
- Системная документация (ТЗ, пояснительные записки, функциональная и нефункциональная спецификация). Выбор формы и типов документа зависит от целей проекта, предпочитаемой методологии (ГОСТ, RUP, MSF)
- Прототип, если он создается. Необходимость создания прототипа сильно зависит от проекта, его сложности и предпочтений команды разработки.
Документ, который составляют очень редко, но я не видела проекта, в котором он был бы не нужен - guide line (руководство по стилю). В этом документе указываются рекомендованные цвета, виды кнопок и управляющих элементов, шрифты и их размеры. Этот документ нужен для того, чтобы проект не страдал от смены дизайнера или от смены его цветовых предпочтений.
После создания аналитической документации наступает очередь документов проектировщика/архитектора. Проектировщик может разрабатывать документацию по классам/объектам, которые необходимо будет сделать в рамках объекта, прописывает их взаимодействие.
Архитектор подбирает и описывает техническое решение.
Одновременно с проектировщиком/архитектором может начинаться работа по созданию тестовой документации. Сюда входят тест-сеты, тест-планы и так далее.
Также может создавать пользовательская документация: руководство пользователя, руководство разработчика, руководство администратора системы, руководство модератора и так далее.
Также может создавать пользовательская документация: руководство пользователя, руководство разработчика, руководство администратора системы, руководство модератора и так далее.
Чем грозит пропуск отдельных документов и целых блоков?
И ничем и всем сразу.
Если проект маленький и выполняется "на коленке" одним человеком, то можно вообще ничего не писать.
Но если проект чуть больше, чем создание своей странички в социальной сети, пропуск стадии создания документации приведет к тому, что часть задумок и идей будет не реализована или реализована неправильно и/или с нарушением сроков и бюджета.