В.: Наша компания всегда говорит, что стремится к качеству, но когда доходит до дела, оказывается, что все сводится к более дешевым и быстрым решениям, а качество отходит на второй план. Ваши предложения?
О.: Беда состоит в том, что во многих компаниях стремление к качеству ограничивается только декларациями, но на деле они ничем не поддерживаются. Другие компании действительно ценят качество, но не понимают, что их деятельность никак не поддерживает это самое качество. Есть два типа людей в компании, постарайтесь их определить. Если в вашей компании не ценят качество, то вам предстоят серьезные сражения, хотя вы можете с успехом объяснить, как вредно плохое качество для компании — прямо и косвенно.
Если ваша компания действительно ценит качество, но в ее практике есть процессы и процедуры, которые принижают качество, то у вас есть больше шансов достичь позитивных перемен в компании. Делайте шаги постепенно и начните с внедрения процессов и процедур в ваши собственных IT-проектах, которые обеспечивают качество. Поскольку планирование качества всегда стоит меньше (времени и денег), чем попытка исправить его в дальнейшем, результаты ваших проектов будут говорить сами за себя. Вы можете разработать даже бизнес-план для качества, а затем стараться изменить процессы и процедуры в вашей компании, которые отрицательно влияют на качество. Начните с малого, но старайтесь создать импульс движения. Просто внедряя описанную методологию управления IT-проектами, вы можете улучшить ваши результаты настолько, что люди будут приходить к вам и спрашивать, как вы этого добились. Разве можно проще пропагандировать приверженность к переменам?
В.: Мне очень нравится идея сначала планировать, а потом — писать программу, но что мне делать с программистами до тех пор, пока я буду готов предоставить им этот самый план? Я совсем не хочу, чтобы они были заняты на другом проекте или маялись от безделья, пока я не смогу предложить им ничего конкретного для разработки. Есть какие-то идеи на этот счет?
О.: Вы совершенно правы в своем беспокойстве о том, что ваша группа должна быть занята полезной работой, пока ее часть будет собирать требования и разрабатывать план будущего проекта. Постарайтесь озадачить разработчиков созданием тестовых планов для проверки того, что требования клиентов будут удовлетворены. Здесь есть две большие выгоды: во-первых, разработчики начинают понимать общую картину происходящего и у них могут возникнуть хорошие идеи и путях улучшения процесса, а во-вторых, посадив ваших разработчиков за написание планов тестирования вы можете быть уверены, что написанные программы будут удовлетворять требованиям клиентов. Если ваши разработчики будут по-прежнему недовольны, постарайтесь дать им ее одно занятие, пока проектная группа не будет полностью занята своей работой, попросите их помочь разработать методы отслеживания найденных проблем, но будьте внимательны: вы совсем не хотите создать проект внутри проекта по отслеживанию ошибок, поскольку у вашей компании наверняка есть работающие инструменты для этого.