Подумайте о супервайзере

Я где-то читал, что «управлять людьми труднее, чем программировать, поскольку добиться нужного от людей труднее, чем от компьютера». (Не обрушивайтесь на меня с критикой, если вы не согласны. Это просто цитата из неизвестного источника.)

Эта фраза никак не выходила у меня из головы, когда я недавно столкнулся с рядом проблем… назовем их проблемами с дисциплиной…

• Сотрудник отсутствует на совещании без предупреждения, при этом ранее он прислал подтверждение своего участия.

• Доска задач не поддерживается в актуальном состоянии и не отражает последнее состояние задач и пользовательских историй.

• Никто по собственной инициативе не проверяет, не перерасходован ли бюджет.

• Проблема, вызвавшая временную приостановку проекта, не решается в оговоренные сроки.

• Документация по проекту не попадает в общедоступный репозитарий.

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

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

То есть мы поняли, что такое быть людьми. Но как быть с проблемами?

Одно из часто предлагаемых решений – назначение супервайзера, в зону ответственности которого входило бы проведение инспекций. Такая мера выглядит как первый шаг к бюрократии, против которой так страстно выступают поклонники методологий Agile и Lean.

Например, Мэри и Том Поппендик считают, что инспекции, чья цель – обнаружение дефектов, это пустая трата времени. Они призывают вообще отказаться от инспекций. И утверждают, что ресурсы необходимо направлять на профилактику дефектов, а не на их исправление, потому что профилактика дешевле [Poppendieck 2007: 7].

В то же время Том и Кэй Гилб, прославившиеся именно своими работами по организации инспекций [Gilb 2003], проводят формальное обучение методам проверки проектной документации, направленным на выявление и измерение дефектов. Они даже вручают сертификаты с названиями вроде Inspection Leader и Inspection Process Owner!

Что вообще происходит? Как примирить эти точки зрения? Могу ли я получить сертификат за полный отказ от инспекций? Или мы стали свидетелями серьезной разборки между двумя самыми известными семейными парами, специализирующимися в области разработки ПО?

Я бы сказал, что их точки зрения – не более чем две стороны одной медали. Да, профилактика проблем дешевле, чем их исправление, но только в 98 % случаев. К тому же, как отмечалось многими, добиться полного отсутствия дефектов невозможно, поскольку превентивные меры с целью исключить последние 2 % дефектов стоят слишком дорого.

Призывы к «нулевому уровню дефектов» контрпродуктивны, статистически невозможны и абсолютно запрещены с точки зрения цены вопроса. Статистически нулевой уровень ошибок означает, что сигма уровня дефектов приобретает бесконечное значение, а это не представляется возможным. Говоря о нулевом уровне дефектов, люди в большинстве случаев имеют в виду проактивное отношение к совершенствованию производственных процессов, но буквально понимаемые призывы только вредят. Движение за «нулевой уровень дефектов» по умолчанию исходит из представления, что все дефекты одинаковы. Но это неверно. На практике в большинстве компаний и для большинства продуктов достаточно обнаружить и уделить первостепенное внимание обнаруженным дефектам и заниматься ими, начиная с самых важных и лишь затем переходя к наименее важным. Может даже иметь смысл вовсе не браться за дефекты, попавшие в конец списка приоритетов, а просто двигаться дальше[66].

Похоже, мы можем позволить некоторым проблемам переходить на следующие фазы процесса, где их обнаружение и исправление (или неисправление) может быть дешевле.

Одна из типичных форм инспекций – ассессмент. Существуют разнообразные инструменты, помогающие организациям проверить, насколько эффективно работают их Agile-команды [Cohn 2009: 430–438]. По существу, ассессменты будут инспекциями, поскольку они оценивают эффективность команд разработчиков после принятия ими Agile-практик. К сожалению, не существует способа внедрить Agile-методологии и не допустить при этом никаких ошибок, и это плохая новость для разработчиков, но хорошая для растущей индустрии консалтинга, включая семьи Гилб и Поппендик.

Компетентность достигается через самодисциплину, коучинг, сертификации, давление со стороны коллег, соответствующие инструменты и инспекции. В этом порядке. Почти всегда дешевле решать проблемы в начале этой цепочки. Проведение инспекций – последний шлюз, где дефекты можно обнаружить и предотвратить их доведение до менеджера или, хуже того… до покупателя. Чем меньше инспекций нам требуется, тем лучше. Но высокое качество без проведения инспекций столь же невозможно, как и стопроцентное покрытие кода. Это высокая цель, но на практике достичь ее нельзя, потому что в геометрической прогрессии растут затраты. Всегда будут участки, которые необходимо инспектировать, независимо от того, будут этим заниматься сертифицированные специалисты или нет. (Если вы не согласны, могу отослать вас к рецензентам этой книги. Им будет интересно узнать, как вы собираетесь снизить количество дефектов до нуля, не проводя инспекций.)