Читать книгу - "Искусство управления IT-проектами - Скотт Беркун"

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

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

Но многие известные мне опытные специалисты попадались в ловушку, будучи уверены, что есть лишь один способ подготовки технических условий (как бы они их ни называли): использование ранее накопленного опыта. Иногда эта цепочка повторений уводила их к самым первым разработкам. Они считали, если эти проекты не были полным провалом, значит, способ составления технических условий (или игнорирование других способов) положительно повлиял на конечный результат. Данное утверждение без каких-либо исследований может быть в равной степени как верным, так и ошибочным (то есть проект, возможно, оказался успешным, хотя процесс составления технических условий был неправильным). Хуже того, если не были подняты резонные вопросы о том, как и зачем написаны эти технические условия, никто в команде так и не поймет, плох или хорош был процесс их подготовки или каков их вклад в работу команды. (Здесь прослеживается полная аналогия с тем, как отсутствие толковых вопросов относительно создания качественного программного кода не позволяет понять, насколько этот код хорош или плох на самом деле.)

Моей целью в данной главе является объяснение ряда ценных идей. Во-первых, что технические условия должны принести проекту тройную пользу: гарантировать, что создается именно то, что было задумано, предоставить график поэтапной работы, которым завершается стадия планирования проекта, и дать возможность основательно рассмотреть курс реализации проекта и получить о нем отзывы различных специалистов. Значение всех трех составляющих трудно переоценить, и вряд ли какой-нибудь другой процесс, кроме составления технических условий, обеспечит все это одновременно. Лишь поэтому я считаю себя ярым сторонником составления технических условий. Во-вторых, большинство претензий, предъявляемых к техническим условиям, легко устранимы при условии, что авторы разбираются в типовых просчетах, допускаемых при подготовке таких условий, и понимают, ради чего они создаются.