Позитивное упрямство при переходе на новый процесс

Часто ли вы привносили изменения в процесс работы своей компании или команды? Сталкивались ли вы с трудностями, связанными с переходом на новый процесс, когда команда/ваш менеджмент/заказчик говорят о том, что «улучшения не так хороши, как казались, и может быть стоит вернуться назад к старому подходу»?

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

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

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

Конечно же, после таких заявлений, очень тяжело удержаться от соблазна признать то, что система/процесс не подходят для команды и необходимо вернутся на старые «рельсы».

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

График внедрения изменений

По оси Х (горизонтально) отложено время. По оси Y (вертикально) – некий показатель, пусть для примера это будет velocity команды (хотя может быть и что-то другое, например степень удовлетворенности Заказчика). Так вот, с переходом на новый процесс (или систему) резко начинается снижение значения велосити. На это есть ряд объективных причин и это нормально. При этом чем кардинальнее изменения, тем «глубже» будет эта «яма» на графике. Но, самое интересное, что чем слабее позиция менеджмента, тем она будет «шире» и тут причины исключительно субъективные.

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

Руководитель должен верить в то, что новый процесс/система принесут пользу. Это позволит проявлять здоровую настойчивость и энтузиазм. Если руководитель не верит в то, что изменения принесут пользу, то новый процесс или система практически обречены на провал. Лучше и не начинать. Я называю это качество позитивным упрямством.

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

Сам по себе процесс или система редко бывают причиной недовольства команды/ менеджмента/ заказчика. Чаще всего настоящей причиной становится то, как нововведение изменило процесс работы. В случае с системой учета времени это наложило дополнительную обязанность «не забыть» каждый день заполнять карту. Руководитель проекта должен понимать реальную причину недовольства и устранять ее, а не следствия проблем.

Ухудшение показателей автоматически привлечет внимание менеджмента и других заинтересованных лиц (PMO, Account Management…). И самым очевидным их предложением  будет возврат к тому процессу, который приносил выгоду раньше. И задача руководителя проекта предоставить четкую картину того, что происходит, как устраняются основные проблемы и когда это закончится. И конечно же не сдаваться сразу!

Вероятнее всего, не стоит переходить на новый процесс или систему перед важной вехой (milestone) проекта. Ожидаемое падение производительности вряд ли поможет команде с честью встретить эту веху. Именно поэтому многие нововведения провалились – они просто стали «крайними», когда искали причины провала.

(Как мотиватор) Для перехода на новый процесс/систему всегда будет необходимо выработать привычку. Привычка, по результатам исследования ученых, вырабатывается примерно за 60 дней (кстати, так можно научиться вставать в 6 утра :)).

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

P.S. Как обычно, интересные мысли приходят при повторном прочтении статьи.

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

График формирования команды по Такману

(спасибо Славе Панкратову, редактору портала it4business.ru за картинку и соответствующую статью).

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

Jan 12th, 2011
  1. Jan 12th, 2011 at 09:40 | #1

    >>Так вот, я увидел, что график производительности команды уж
    >>оооочень похож на график, который я представил выше в статье

    что не удивительно, т.к. это просто кривая принятия изменения:
    http://www.westbrookstevens.com/Phase_5.htm (любого изменения)

    • Jan 12th, 2011 at 09:48 | #2

      а ещё это перекликается с моделью приобретения навыков Дрейфуса, которая в принципе тоже самое :)

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

    • Jan 12th, 2011 at 10:37 | #3

      ТО СОТОНА
      Спасибо большое за Линк.
      Почему так всегда, когда уверен, что что-то придумываешь, то обязательно выясняется, что это уже придумали другие умные люди :)

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

      • Jan 13th, 2011 at 13:30 | #4

        в гугле валом. я только картинку показал :)

Leave a comment