Используйте адаптируемые инструменты

Когда разговор касается самоорганизующихся команд и результативности, часто забывают еще один доступный ресурс.

Я имею в виду инструменты.

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

Инструменты могут играть важную роль в повышении дисциплины в компании. Приверженцы Lean-методологий настаивают, что инструменты должны быть сконфигурированы таким образом, чтобы это позволяло максимально защитить процессы от ошибок (метод также известен как «защита от дурака») и тем самым затруднить выпуск программного обеспечения, содержащего дефекты [Poppendieck 2007: 196]. Меры по превентивному исключению ошибок можно считать техническим эквивалентом коучинга, который также помогает повысить дисциплину разработки.

На моей последней работе я, помимо прочего, отвечал за создание приложения, которое должно было выполнять ряд важных контрольных функций: присылать менеджерам уведомления о перерасходе бюджета; требовать, чтобы все данные, вводимые в журнал учета времени, предварительно проверялись двумя заинтересованными лицами; рассылать уведомления, если введенные в журнал учета времени часы неверно суммировались в рамках недели, и проактивно проверять, что списки команд и активных проектов находятся в актуальном состоянии. Да, некоторых это раздражало. Но еще больше жалоб поступало, когда приложение сбоило.

Люди и процессы — сердце вашей компании, к этой же категории относятся и инструменты. Это значит, что, подобно людям и процессам, инструменты должны быть тщательно подобраны и адаптированы под потребности вашего бизнеса. Никогда не меняйте свой бизнес под свои инструменты. Как однажды написал Джоэл Спольски:

Если речь идет о критически важной для вашего бизнеса функции — выполните ее сами, чего бы это ни стоило[65].

Я думаю, этот тезис с небольшими оговорками может быть распространен и на используемые инструменты:

Если инструмент очень важен для вашего бизнеса — разработайте его сами, чего бы это ни стоило.

Не поймите меня превратно. Я никого не призываю создавать свой личный Visual Studio или Eclipse. Но вы должны выбирать для себя столь же адаптируемые программные продукты, какими являются Visual Studio и Eclipse. Не выбирайте настраиваемые инструменты. Чаще всего под настраиваемостью понимается возможность изменить набор пунктов меню, поменять их местами и выбрать ваш любимый цвет. Это не то, что я имею в виду под адаптируемостью. Точно так же не думайте, что вы в порядке, если пользуетесь инструментами, в названии которых есть слово Agile. Его обычно применяют с маркетинговыми целями, и его присутствие в названии продукта совсем не означает, что он имеет соответствующую архитектуру. Мне приходилось видеть так называемые гибкие инструменты, в которых было столько же гибкости, сколько в Ким Чен Ире, помещенном в ледник.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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