Когда я только начинал свою карьеру в IT (а было это лет 25 назад), вопрос о том - писать или не писать ТЗ не стоял. Но с постепенным проникновением всех этих гибких методологий, аджайлов, канбанов и прочей спринтовой системой, все чаще стал вставать вопрос - так нужно писать ТЗ или нет? Как его поддерживать в актуальном состоянии, когда требования к проекту меняются со скоростью света? Если не писать ТЗ, то как вообще тогда синхронизировать ожидания заказчика с разработкой?

Написали небольшую статью с нашим взглядом с провокативным заголовком на vc.ru. Мы занимаемся веб-разработкой, поэтому здесь рассматривается подход именно к нашей проектной документации. Так что, в первую очередь, статья будет полезна нашим коллегам. Но будет интересна и заказчикам для того, чтобы понимать, как организовать процесс, чтобы сохранить управляемость проекта, с одной стороны и не утонуть в бюрократии с другой.

P.S. Ну и поскольку это наши первые шаги на vc.ru, мы очень нуждаемся в вашей поддержке. Поэтому, если вам понравится статья, плюсаните нас там пожалуйста 😉

https://vc.ru/u/551196-studiya-valeriya-komyagina/151103-tz-zlo