То есть мы поняли, что такое быть людьми. Но как быть с проблемами?
Одно из часто предлагаемых решений – назначение супервайзера, в зону ответственности которого входило бы проведение инспекций. Такая мера выглядит как первый шаг к бюрократии, против которой так страстно выступают поклонники методологий Agile и Lean.
Например, Мэри и Том Поппендик считают, что инспекции, чья цель – обнаружение дефектов, это пустая трата времени. Они призывают вообще отказаться от инспекций. И утверждают, что ресурсы необходимо направлять на профилактику дефектов, а не на их исправление, потому что профилактика дешевле [Poppendieck 2007: 7].
В то же время Том и Кэй Гилб, прославившиеся именно своими работами по организации инспекций [Gilb 2003], проводят формальное обучение методам проверки проектной документации, направленным на выявление и измерение дефектов. Они даже вручают сертификаты с названиями вроде Inspection Leader и Inspection Process Owner!
Что вообще происходит? Как примирить эти точки зрения? Могу ли я получить сертификат за полный отказ от инспекций? Или мы стали свидетелями серьезной разборки между двумя самыми известными семейными парами, специализирующимися в области разработки ПО?
Я бы сказал, что их точки зрения – не более чем две стороны одной медали. Да, профилактика проблем дешевле, чем их исправление, но только в 98 % случаев. К тому же, как отмечалось многими, добиться полного отсутствия дефектов невозможно, поскольку превентивные меры с целью исключить последние 2 % дефектов стоят слишком дорого.
Призывы к «нулевому уровню дефектов» контрпродуктивны, статистически невозможны и абсолютно запрещены с точки зрения цены вопроса. Статистически нулевой уровень ошибок означает, что сигма уровня дефектов приобретает бесконечное значение, а это не представляется возможным. Говоря о нулевом уровне дефектов, люди в большинстве случаев имеют в виду проактивное отношение к совершенствованию производственных процессов, но буквально понимаемые призывы только вредят. Движение за «нулевой уровень дефектов» по умолчанию исходит из представления, что все дефекты одинаковы. Но это неверно. На практике в большинстве компаний и для большинства продуктов достаточно обнаружить и уделить первостепенное внимание обнаруженным дефектам и заниматься ими, начиная с самых важных и лишь затем переходя к наименее важным. Может даже иметь смысл вовсе не браться за дефекты, попавшие в конец списка приоритетов, а просто двигаться дальше
[66].
Похоже, мы можем позволить некоторым проблемам переходить на следующие фазы процесса, где их обнаружение и исправление (или неисправление) может быть дешевле.
Одна из типичных форм инспекций – ассессмент. Существуют разнообразные инструменты, помогающие организациям проверить, насколько эффективно работают их Agile-команды [Cohn 2009: 430–438]. По существу, ассессменты будут инспекциями, поскольку они оценивают эффективность команд разработчиков после принятия ими Agile-практик. К сожалению, не существует способа внедрить Agile-методологии и не допустить при этом никаких ошибок, и это плохая новость для разработчиков, но хорошая для растущей индустрии консалтинга, включая семьи Гилб и Поппендик.
Компетентность достигается через самодисциплину, коучинг, сертификации, давление со стороны коллег, соответствующие инструменты и инспекции. В этом порядке. Почти всегда дешевле решать проблемы в начале этой цепочки. Проведение инспекций – последний шлюз, где дефекты можно обнаружить и предотвратить их доведение до менеджера или, хуже того… до покупателя. Чем меньше инспекций нам требуется, тем лучше. Но высокое качество без проведения инспекций столь же невозможно, как и стопроцентное покрытие кода. Это высокая цель, но на практике достичь ее нельзя, потому что в геометрической прогрессии растут затраты. Всегда будут участки, которые необходимо инспектировать, независимо от того, будут этим заниматься сертифицированные специалисты или нет. (Если вы не согласны, могу отослать вас к рецензентам этой книги. Им будет интересно узнать, как вы собираетесь снизить количество дефектов до нуля, не проводя инспекций.)
Проводите встречи с глазу на глаз
В предыдущих разделах я описал шесть уровней компетенций. Седьмой обеспечивается менеджерами. Возможно, вы и есть такой менеджер.
В своей книге «За закрытыми дверями» Джоанна Ротман и Эстер Дерби описывают, как нужно проводить индивидуальные встречи с сотрудниками [Rothman, Derby 11, 150]. C системной точки зрения регулярные встречи с глазу на глаз полностью оправданны. Они стимулируют обмен информацией в системе и ускоряют получение обратной связи.
Я не считаю нужным повторять здесь великолепные рекомендации, которые дают Ротман и Дерби. Просто советую прочитать их книгу. Но хотелось бы отметить, что многим менеджерам, включая меня, соблюдение графика встреч с сотрудниками дается с трудом. Как и в случае с другими важными видами деятельности, которые трудно поддерживать, есть только одно решение – воспользоваться четырьмя приемами самодисциплины:
1. Осознайте важность проведения встреч с глазу на глаз. Именно поэтому я выделяю для них специальный раздел в этой главе, а вы его читаете.
2. Решите проблему управления своим временем, зарезервировав в своем графике фиксированное время для этих встреч, например по полчаса на одного сотрудника. Проводите индивидуальные встречи в один и тот же день раз в две недели. По моему опыту, так легче не дать другим срочным делам вмешаться в ваши планы.
3. Мой опыт говорит, что о проведении таких встреч практически невозможно забыть. В тех редких случаях, когда со мной это происходило, сотрудники приходили ко мне в кабинет сами.
4. Мотивируйте себя, организуя индивидуальные встречи в разных интересных форматах. Например, можно сходить вместе с сотрудником в кафетерий во время обеденного перерыва, заняться с ним парным программированием и даже обмениваться текстовыми сообщениями, если вам вдруг приходится участвовать в безумно скучном совещании.
Если захотеть, любую рутинную задачу можно превратить в интересную. Но что бы вы ни делали, не игнорируйте необходимость проводить частые индивидуальные встречи – ведь именно сотрудники заставляют биться пульс вашей компании.
Встречи для обсуждения оценок 360°
Из упоминаемого в главе 4 закона требуемого разнообразия следует, что простые метрики никогда не смогут правильно оценить сложную систему. А принцип непрозрачности системы, описанный в главе 6 «Базовые принципы самоорганизации», объясняет, почему менеджер никогда не в состоянии точно оценивать сотрудников. Но тогда как же это делать?
Деминг и другие эксперты по управлению качеством подвергают сомнению объективность оценок работы членов команды с иных позиций. Они утверждают, что невозможно подобрать набор параметров, который охватывал бы все многообразие моделей поведения, которые нужны организации от ее сотрудников. ‹…› Эмпирические исследования показывают, что менеджеры не способны давать надежные оценки эффективности своих подчиненных в динамике
[67].
