Искусство управления IT-проектами

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

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

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

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

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