Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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