Недостаточные обязательства по качеству
Последняя причина существования ошибок в проектах, по моему мнению, наиболее серьезна. Любой разработчик скажет, что он выполняет обязательства по качеству. К сожалению, обязательства по качеству не всегда достаточно реальны. Стремясь к получению надежного и работоспособного продукта, необходимо уделить внимание всем компонентам разработки, а не только самым эффектным. Кроме того, из всех возможных алгоритмов следует выбрать наиболее простой и приложить максимум усилий, чтобы как можно лучше его протестировать. В конце концов, заказчик не покупает алгоритмы, а только высококачественные программные продукты. В основе ..спеха тех фирм-производителей программного обеспечения и индивидуальных разработчиков, которые заботятся о качестве, лежат следующие компоненты: тщательное предварительное планирование, персональная ответственность, жесткий контроль качества и превосходные коммуникативные способности. Многие решают крупные задачи разработки программного обеспечения (т. е. задачи планирования, программирования и т. д.), но только те, кто обращают внимание на детали, сдают продукты вовремя и : высоким качеством.
Хорошим примером правильного подхода к решению проблемы качества является практика, принятая в NuMega при составлении сотрудниками ежегодных обзоров. Одна из ключевых частей обзора должна содержать запись о том, сколько ошибок зарегистрировано в продукте. Учет ошибок является жизненной частью поддержания качества программного продукта, никакая другая компания, в которой работал автор, даже не проверяла настолько очевидные вещи. Разработчики знают, где присутствуют ошибки, но для учета последних нужен стимул. В NuMega нашли такой подход. Узнав, что ошибки учитываются как часть полезной работы, разработчики регистрировали их независимо от того, насколько они были тривиальными. Благодаря этому соревнованию по регистрации ошибок лишь самые диковинные из них "проскользнули" в готовый продукт. Что более важно, это дает реалистическую картину того, в какой точке проекта разработчики находятся в любой заданный момент.
Руководя проектом, автор установил правило, согласно которому каждый член команды должен был согласиться, что продукт готов к переходу на следующий этап разработки. Если хотя бы один человек чувствовал, что продукт не готов к этому, то переход не выполнялся. Исправлялись даже незначительные ошибки, а весь следующий день отводился на тестирование. Это не только гарантировало уверенность каждого члена команды в качестве продукта, но также помогало определить вклад каждого из них в конечный результат. Интересно, что никто никогда не пытался остановить выпуск из-за чьей-то ошибки (это всегда делал автор ошибки).
Обязательства компании по качеству устанавливают настрой для полной мобилизации усилий на разработку. Эти обязательства начинаются с найма работников и в конечном счете гарантируют качество окончательной версии программного продукта. Каждая компания заявляет о своем желании нанять лучших людей, но немногие умеют их привлечь. Кроме того, некоторые компании не желают обеспечивать разработчиков инструментами и оборудованием, необходимыми для создания высококачественных продуктов. К сожалению, очень часто вместо того, чтобы потратить $500 на инструмент, который исправит опасную ошибку аварийного останова за минуты, компании "выбрасывают" тысячи долларов на оплату труда разработчиков, неделями устраняющих одну и ту же ошибку.
Повернуть компанию к сознательной организации качественных разработок непросто. Для достижения цели необходимы усилия и менеджеров, и инженеров.
