Гибкое управление проектами и продуктами - читать онлайн книгу. Автор: Борис Вольфсон cтр.№ 12

Согласно теории X, люди работают, только чтобы получать зарплату. Думаю, все сталкивались с такими сотрудниками: пришел с утра, посидел до обеда, потом потерпел до вечера и домой. Они не работают, а отбывают положенное время. Для них работа измеряется часами, а не достигнутыми результатами.

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

Теория Y гласит, что люди в принципе высокомотивированы на достижение результатов и сама работа приносит им удовольствие. Опять же всем нам знаком типаж людей с большой самомотивацией. У них и вокруг них всегда кипит работа (передаю привет моей команде), они успевают за день сделать не одно дело, и их производительность труда намного выше среднего.

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

Обычно руководитель работает на стыке обеих теорий, используя тот или иной подход в зависимости от ситуации. В общем случае надо стараться работать по принципу теории Y, зажигая людей, в крайнем – прибегать к методам теории X, четко объясняя, в чем именно проблема.

Для работы в рамках Scrum команда должна состоять в основном из людей, которые больше соответствуют теории Y, иначе команда не будет самоорганизованной и эффективной.

Скажи, как ты будешь измерять мою эффективность, и я скажу, как я буду себя вести.

Э. Гольдратт

Самые важные вещи нельзя измерить.

У. Деминг

Чтобы узнать, посолен ли борщ, достаточно опустить в него два электрода, а затем пустить по ним ток. Если появится запах хлора, значит, борщ уже посолен.

В физике есть такое понятие, как эффект наблюдателя: если над системой ведется наблюдение, оно вносит изменение в ее поведение. Очень интересно этот эффект проявляется в организации работы команд разработчиков (да и в любых производственных процессах). Как только мы начинаем считать любые метрики, мы вносим изменения в поведение команды и отдельных ее членов.

С точки зрения управления мерить в численном виде (вводить метрику) – идея, на первый взгляд, очень здравая. Мы получаем точные данные и на их основе производим необходимые действия. Однако, к сожалению, не все так просто: как только мы вводим метрику, поведение команды начинает меняться. Команда и каждый ее член начинают подстраиваться под введенную нами метрику.

Далеко за примерами ходить не надо. Все знают понятие «индусский код»: как только разработчикам начинают платить за количество написанных строчек кода, они начинают писать больше кода, зачастую бессмысленного, забывают о рефакторинге, так как его делать становится невыгодно, и т. д. Таким образом, наше начинание по замеру производительности оборачивается против нас.

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

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

Вывод из приведенных выше примеров простой: при введении метрик необходимо руководствоваться прежде всего принципом «Не навреди».

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

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

При внедрении метрик, как и любых других инноваций, хорошо использовать цикл Деминга Plan-Do-Check-Act («планирование-действие-проверка-корректировка»), чтобы у вас была возможность получить обратную связь от команды и внести изменения в случае необходимости.

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

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

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

А между тем это, как ни парадоксально, очень точная метрика. Два программиста в команде правят примерно одинаковое количество строчек за один и тот же промежуток времени. Конечно, необходимо много условий (схожие задачи, наличие стандартов кодирования, например максимальная длина метода, отсутствие дублирования, рефакторинг и т. д.), но все же метрика достаточно точная… если не использовать ее как оценку производительности.