Требования к качеству

Я не святой. В программных продуктах, за которые мне приходилось прямо или косвенно отвечать, бывали ужасные проблемы с качеством. Нет, я не был непосредственно виноват в том, что электронное сообщение было отправлено 1 000 000 адресатов вместо 10 000 зарегистрированных пользователей. И это не я повредил базу данных с адресами нескольких тысяч интернет-покупателей, в результате чего их приобретения не смогли быть доставлены. Я также не имел никакого отношения к ошибке программирования, которая позволяла 9 из 10 участников лотереи выигрывать основной приз. Я с удовольствием расскажу вам о совершенных лично мной ошибках (разумеется, при условии, что вы расскажете мне о своих).

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

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

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

Думать об ограничениях, налагаемых на самоорганизующиеся команды, – одна из ваших функций как менеджера. Вы будете не только систематически получать то, о чем просили, но и не получать того, о чем не просили. Менеджеры слишком часто забывают установить четкие требования, касающиеся качества продуктов. И если вы не сформулируете эти требования, то и не получите то, о чем не просили. (Мы вернемся к этой теме в главе 11 «Развитие компетенций».)