Люди и взаимодействие важнее процессов и инструментов
Именно этой строкой начинается Agile манифест. И вроде бы это очевидно: сотрудники - главный ресурс любой компании. Однако на практике очень часто приоритеты сдвигаются в другую сторону и на первое место выходят: метрики, релизы, цели, задачи, события.
А как же люди? Ведь именно их отношение к работе, их мотивация и определяет итоговый результат.
Связь мотивации и эффективности очевидна: мотивированный сотрудник способен более длительное время удерживать фокус внимания на объекте своей деятельности. Он проявляет больше упорства в преодолении различных трудностей, более охотно принимает ответственность за результаты своей деятельности.
Поэтому один из пунктов Agile манифеста и гласит: над продуктом должна работать команда замотивированных профессионалов.
Окей, уровень профессиональных компетенций можно определить путем различных видов тестирования. И развивать их за счет внутреннего и внешнего обучения. А как быть с мотивацией? Много ли компаний оценивают на входе мотивационных профиль своих сотрудников?
Забегая немного вперед, сразу хочу сказать, что мотивация, по сравнению с другими различными профессиональными характеристиками, - структура весьма динамичная. И перемены ее уровня могут происходить скачкообразно как вверх, так и вниз. Как и изменение самой структуры мотивации.
Как правило, при устройстве на работу, мотивация сотрудника сильно детерминирована материальными факторами: уровнем зарплаты, социальным обеспечением, стабильностью, перспективами роста и т.д.
И тут вроде все понятно: есть ДМС, инструменты премирования по ключевым показателям эффективности, карьерный гайд, печеньки к кофе. Чего еще надо? Однако все это относится к инструментам мотивирования (стимулирования), а не к мотивации.
А на одном внешнем стимулировании, без учета внутренних факторов далеко не уедешь. Особенно в области, где постоянно требуется решение творческих задач, а не простая однообразная деятельность.
Так, при удовлетворении «гигиенических» факторов по Герцбергу (достижения определенного уровня материального насыщения), происходит резкое снижение влияния внешних материальных факторов и условий труда на мотивацию сотрудников (в сторону ее увеличения, по крайней мере). И дальше уже вступают в силу факторы внутренней мотивации.
Появляется потребность в причастности к определённым внутренним кругам, признании, профессиональном развитии, самореализации.
Так как же стабильно поддерживать мотивацию на уровне, необходимом для успешной командной работы?
Давайте добавим немного классики и рассмотрим базовые теории мотивации. Условно их можно разделить на две категории.
Первая - теории структурной мотивации, где в качестве объекта изучения рассматриваются различные цели и результаты деятельности. И,как уже было сказано, структура этих целей постоянно меняется. Хотя, как правило, вся система мотивирования (стимулирования) в организациях направлена именно на эту группу мотивов.
Вторая категория — это процессуальные теории мотивации, где в качестве мотивирующего фактора рассматривается сам процесс.
Лучший пример высокой процессуальной мотивации – это игры. Как правило, играя в игры, людям интереснее сам процесс, а не размер вознаграждения за потраченное время.
Было бы здорово, превратить любую профессиональную деятельности в игру. Что может быть лучше и эффективней, чем работа команды, в которой каждый сотрудник настолько увлечен своей деятельностью, что получают от нее столько же удовольствия, как любимого хобби?
Hidden text
Поэтому игрофикация - весьма перспективное направление для развития мотивации труда и внедрения в любых сферах деятельности (об этом вскоре будет другая статья)
Но существуют и другие факторы, напрямую влияющие на процессуальную мотивацию.
Исследователи мотивации Ричард Хекман и Грег Олдхэм ещё в начале 70-х годов выделили пять основных характеристик содержания трудового процесса, которые оказывают непосредственное влияние на формирование мотивации трудовой деятельности. И ввели понятие мотивационного потенциала работы (МПР).
МПР рассчитывается по следующей формуле:
МПР = (ЗР + РР + OP) / 3 x АР х ОС
ЗР – Значимость работы. То, как сам сотрудник чувствует важность своей роли. Насколько его отсутствие скажется на результатах деятельности трудового коллектива.
РР – Разнообразие работы. То есть сложность деятельность и наличие в ней различных операций.
ОР – отождествление своей работы с конкретным результатом. Видимость результатов своего труда в конечном продукте.
АР – автономность работы. Чем больше контроля, тем меньше свободы в принятии промежуточных решений.
ОС – обратная связь. Информация об оценке результатов работы, полученная из разных источников.
Как видно, в структуре мотивации трудовой деятельности нет ни денег, ни статуса, ни перспектив карьерного роста, ни даже печенек.
То есть ни одного элемента стимулирования, которые так широко распространены в современных системах классического менеджмента.
А можно ли организовать рабочий процесс так, чтобы он включал в себя все необходимые элементы для поддержания высокого МПР?
Давайте рассмотрим один из самых известных и основополагающих Agile фреймворков – Scrum. Который широко используется для организации разработки программных продуктов. Но, в принципе, может быть применен и в любой другой сфере.
Scrum – это эмпирический фреймворк, который позволяет работать в условиях быстро изменяющейся внешней среды и оперативно реагировать на все запросы рынка.
Основная идея данного фреймворка заключается в организации работы небольших команд (до 10 человек) над небольшими задачами. Для решения которых требуется не более одного месяца с целю получить на выходе минимальный жизнеспособный продукт (MVP).
Одним из основных правил Scrum является полная автономия работы команды на этапе производственного цикла (спринта). Только команда может решить, как именно ей делать ее работу и сколько времени на это потребуется. То есть критерий автономности выполняется в полном объеме.
В конце каждого спринта команда представляет продукт своей деятельности непосредственным пользователям для получения от них полноценной обратной связи.
Также регулярно проводится ретроспектива - командная встреча на которой оценивается текущий уровень эффективности работы. Оцениваются факторы, которые на нее повлияли и принимаются решения, направленные на ее улучшение.
Scrum-команда является полностью самодостаточной. В ней нет кадровой избыточности и отдельных административных ролей. Поэтому от результатов работы каждого сотрудника зависит и командный результат в целом.
Работа Scrum-команды опирается на принцип T-shape, который предполагает участие сотрудников в решении вопросов смежных специализации в рамках одной команды. Данный подход дает не только разнообразие решаемых задач, но и отлично расширяет профессиональный кругозор.
Таким образом видно, что Scrum включает в себя абсолютно все элементы мотивации трудовой деятельности. Что и необходимо для эффективной командной работы!
Комментарии (14)
serjeant
06.09.2022 09:40+3Если у команды разработки убрать scrum и позволить им самим организовать свою работу, то и проблем с мотивацией не будет. Scrum удобен менеджерам для имитации бурной деятельности, большенству разработчиков удобней работать по своим правилам. Так же популярны kanban или waterfall.
koba_dmitry Автор
06.09.2022 10:12-1Scrum и менеджмент - различные вещи с точки зрения подхода. Попытка совмещения приводит к "карго-скраму". Цель данного фреймворка именно в самостоятельной организации работы и принятия решений.
Другой вопрос, что команда, как коллектив, - это всегда набор различных мнений и "своих правил". Так что для эффективной работы команды (особенно на начальном этапе) необходимо принять определённые рамки (фреймы) в пределах которых и будет проходить процесс совместной деятельности.serjeant
06.09.2022 11:13+3Давайте будем честными, когда разработчикам разрешали самим выбирать фреймворк для орагнизации работы? Чаще всего в компании уже есть scrum-мастера, agile-коучи и прочие сектанты, которые будут просто не нужны, если разработчики самостоятельно организуются.
И чтобы не потерять свою работы и теплое место, agile-сектанты начинают принудительно заставлять разработчиков работать по тому же scrum. Даже если сам проект этого не требует, а в штате 2 разаработчкиа, но зато есть скрам-мастер, продакт менеджер, продактоунер, бизнес анлитик, аджайл-коуч и т.д. И вместе работы все занимаются дейликами,груммингами,покер-планированием, кикофми,демо,ретро и т.д. а вместо продукта заказчику можно показывать красивые графики сгоряния задач в jira.koba_dmitry Автор
06.09.2022 11:41Артем, как-то у вас все в кучу смешалось. Прежде всего Agile - это философия, которая как раз и идет вразрез с принципами классического менеджмента и директивного управления.
Поэтому в Scrum и нет такой роли, как продакт-менеджер. Есть владелец продукта, который осуществляет поставку входящих задач и скрам-мастер, задача которого не управлять командой, а помогать ей. В том числе и с соблюдением всех необходимых событий, которые и определяют те самые рамки (фреймы).
Ежедневные встречи как раз и должны занимать не более 15 минут, чтобы не отвлекать разработчиков от их работы без надобности. Так же основной смысл Agile и Scrum, в частности, в регулярной демонстрации именно продукта, а не графиков. Для того чтобы команда могла напрямую получить обратную связь от пользователей продукта.
Наверное, было бы неплохо, если вы расскажите о своем личном опыте. Исходя из которого вы судите о Scrum в целом. Возможно это внесет какую-то ясность.serjeant
06.09.2022 11:49+2К сожалению это не у меня в кучу смешалось, это суровая отечественная действительность. Я работал в разных компаниях и в каждой готовили scrum по разному. Кто во что гораз и как он это понимает. Как пример - sbergile (на хабре есть статья).
По-этому, я рассказываю из опыта разработчика. Я видел как увольнялись целиком команды,только из-за того что внедрялся scrum и разработка превращалась в соблюдение scrum-церемоний вместо написание кода.
Извините конечно, но у вас больше теоретические рассуждения,как это должно быть. Печальная действительность совсем другая.koba_dmitry Автор
06.09.2022 12:11Scrum гайд - это всего 16 страниц текста. С точки зрения процессов он прост и понятен. Другой вопрос, как вы правильно заметили, его применение (внедрение) на практике. Если делать это топорно, пытаясь совмещать скрам с устоявшимся директивным менеджментом, тем самым снижать значимость вышеуказанных факторов, то ничего хорошего из этого естественно не выйдет. Но хочу подчеркнуть, что проблема здесь не в скраме, а именно в способах его применения.
serjeant
06.09.2022 12:39+1Вот эти шаблонные фразы : "проблема здесь не в скраме, а в способах его применения","мы гибкие" и "соблюдение церемоний повышает продуктивность" постоянно и слышу от скрам-сектантов. Да и вообще они всегда только шаблонными фразами из книг и манифестов общаются.
Возникает вопрос - а зачем этот скрам вообще нужен,если от него столько проблем и негатива? Может стоит или чётко прописать все правила или вообще его не применять? Сейчас вы пытаетесь защитить скрам,перекладывая ответственность за реализацию на кого угодно,только не на самих адептов скрама )))Есть kanban и waterfall. Разработчикам с ними комфортно, зачем натягивать сову на глобус?
koba_dmitry Автор
06.09.2022 13:09-1Артем, говоря о неправильном применении, я совершенно не пытаюсь снять ответственность с тех, кто должен заниматься правильной организацией всех скрам процессов. Как раз наоборот!
И чтобы из скарма не получился карго-скрам, как раз им и стоит внимательно учитывать все, что написано в Agile манифесте.
Кстати, вы его читали? Мало какой разработчик будет не согласен с тем, что там написано.
Как и с тем, что автономия в работе и в принятии решений, осознание важности своего вклада и наличие обратной связи положительно сказывается на ее эффективности.Кстати, ничего не имею против Канбан - отличный метод, позволяющий хорошо визуализировать и оптимизировать все процессы. В котором есть все те же роли, что и в скрам и примерно тот же набор событий (встреч).
Очень часто половина команд в рамках одной компании работает по канбан, а половина по скрам. Были даже попытки интеграции этих моделей)
А вот движение по водопадной структуре с связке с классическим управлением, в свое время у меня привело к очень большим издержкам. Что и послужило поиску альтернативных методов реализации проектов.serjeant
06.09.2022 13:27Agile-манифест читал, и не только его: книги, митапы. Плотно знакомился с вопросом, чтобы продуктивно спорить с scrum-сектантами.
За роли и события в kanban не согласен. Всё таки их существенно меньше. Но вот если kanban внедряет scrum-сектант, то получаются те же яйца,только в профиль.
Спасибо за продуктивный спор, интересно было послушать вашу точку зрения!koba_dmitry Автор
06.09.2022 13:40По ролям в скрам и канбан (без учета команды разработки), давайте посчитаем вместе:
* Scrum: Product Owner, Scrum master - итого 2;
* Kanban: Service Request Manager, Service Delivery Manager - итого 2;
Вроде ничья )
Спасибо за беседу, Артем! Да, было интересно )serjeant
06.09.2022 14:47+1Опять же это в вашем радужном мире теории. На практике в канбане нет Service Request Manager, Service Delivery Manager. А есть команда разработки и тимлид команды, который рулит созданием задач и приоритетами.
https://scrumtrek.ru/blog/kanban/5796/kanban-scrum-agile-otlichiya/
Обратите внимание на раздел "Разница с точки зрения предусловий"
koba_dmitry Автор
06.09.2022 15:13-1Артем, есть Scrum, есть Kanban - выверенные и хорошо описанные фреймворки, в которых есть свои роли, их количество и определённые события.
Да, Kanban более эволюционный путь, чем Scrum. Позволяя наращивать функционал по чуть-чуть. И поэтому он вызывает меньше сопротивления.
Но то, что в вашей практике, вы ограничивались частичным использованием каких-то отдельных элементов, как например, только канбан-доски, вовсе не означает, что это предел его эффективности. Возможно, только в вашем случае, при определённом размере вашей команды и их количестве. Совмещение ролей тоже возможно до определенного этапа (у меня уже был негативный опыт совмещения ролей владельца продукта и скрам-мастера). Но при увеличении масштаба решаемых задач все упрощения сразу станут проявляться не самым лучшем образом.
Это как рассуждать по поводу правил дорожного движения: наличие светофора в населённом пункте из двух дорог тоже может показаться избыточным, но это не значит что на "практике" они не эффективны )
dididididi
За теорию мотивации спасибо, но когда вы попытались натянуть на неё скрам, стало смешно.
koba_dmitry Автор
Буду рад, если вы поясните свою позицию )