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

8. Представьте, что вы работаете над проектом в середине этапа планирования. Никто не представил никакого прототипа, и в вашем распоряжении только письменные документы. Вы понимаете, что на некоторые вопросы невозможно получить ответы, используя лишь эти документы. Что вам делать? Изготавливать прототип самостоятельно? Привлечь к этой работе какого-нибудь другого специалиста команды? Кому вы покажете прототип? Какую реакцию вы от него ожидаете?

9. Представим, что в предыдущем упражнении вы решили изготовить прототип. Вы показали его команде, и он ей понравился. То есть он ей настолько понравился, что команда согласилась прекратить всю другую проектировочную работу и оснащение ради того единственного созданного вами прототипа. Вы знаете, что прототип создает массу предположений, требующих проверки, но их это мало волнует. Как убедить их в необходимости другого прототипа? Что можно сделать до показа прототипа, чтобы свести к минимуму шансы подобного развития событий?

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

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

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

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