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

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

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

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

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

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

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

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

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

В предыдущих разделах я описал шесть уровней компетенций. Седьмой обеспечивается менеджерами. Возможно, вы и есть такой менеджер.

В своей книге «За закрытыми дверями» Джоанна Ротман и Эстер Дерби описывают, как нужно проводить индивидуальные встречи с сотрудниками [Rothman, Derby 11, 150]. C системной точки зрения регулярные встречи с глазу на глаз полностью оправданны. Они стимулируют обмен информацией в системе и ускоряют получение обратной связи.

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

1. Осознайте важность проведения встреч с глазу на глаз. Именно поэтому я выделяю для них специальный раздел в этой главе, а вы его читаете.

2. Решите проблему управления своим временем, зарезервировав в своем графике фиксированное время для этих встреч, например по полчаса на одного сотрудника. Проводите индивидуальные встречи в один и тот же день раз в две недели. По моему опыту, так легче не дать другим срочным делам вмешаться в ваши планы.

3. Мой опыт говорит, что о проведении таких встреч практически невозможно забыть. В тех редких случаях, когда со мной это происходило, сотрудники приходили ко мне в кабинет сами.

4. Мотивируйте себя, организуя индивидуальные встречи в разных интересных форматах. Например, можно сходить вместе с сотрудником в кафетерий во время обеденного перерыва, заняться с ним парным программированием и даже обмениваться текстовыми сообщениями, если вам вдруг приходится участвовать в безумно скучном совещании.

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

Из упоминаемого в главе 4 закона требуемого разнообразия следует, что простые метрики никогда не смогут правильно оценить сложную систему. А принцип непрозрачности системы, описанный в главе 6 «Базовые принципы самоорганизации», объясняет, почему менеджер никогда не в состоянии точно оценивать сотрудников. Но тогда как же это делать?