Скрытые демотиваторы: мелочи, мешающие эффективной работе команды

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

Мы собрали ТОП список из вещей, в которых чаще всего буксуют процессы и реальные примеры из практики.

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

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

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

При реализации той или иной функциональности нужно согласовать требования. Попытки найти сотрудников, ответственных за отдельные составляющие системы не приводят к успеху. Процесс сбора требований затягивается. Аналитик ходит по кругу, пытаясь собрать информацию. Люди перекладывают ответственность друг на друга. Как итог - теряется всякая инициатива.

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

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

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

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

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

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

Пример: компания выпускает новую релизную политику. Определены, но не задокументированы этапы проведения релиза и сценарии возможного поведения. Сотрудники теряются в зонах ответственности и путаются в процессе.

Как можно действовать: быстрый 60‑минутный созвон и запись инструкции с дальнейшим размещением на wiki/в Confluence.

Проект живёт по новым правилам каждый понедельник. У людей нет опоры, ощущение бессмысленности растёт.

Пример: еженедельно меняется приоритизация задач. Сначала определен один список задач, но в середине спринта он может резко измениться.

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

В заключение стоить отметить, что любые изменения должны опираться на конкретные слабые стороны процесса. Улучшения ради улучшений - бессмысленны. Любое изменение всегда предполагает переходный период и адаптацию всех задействованных в процессе лиц и на первых этапах улучшения будут едва ли заметны. Стоит помнить и том, что если процесс уже поставлен на рельсы и едет, лучше не трогать его без объективных на то причин, т. к. изменения могут привести и к негативным последствиям, от которых пострадает как команда, так и результат.