5 ошибок в управлении процессами, которые только добавят хаоса работе

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

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

Ошибка 1. Неправильно выбрана методология для управления работой команды

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

Как одна команда потеряла много денег и времени

В 2017 году команда Романа занималась созданием нового личного кабинета на сайте компании. Суть проекта была в том, чтобы перенести функции, уже существовавшие на сайте, в новый дизайн и улучшить юзабилити. Для работы новая команда выбрала Scrum. Это оказалось большой ошибкой.

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

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

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

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

Как не допустить ошибку

Главный совет — подробно изучайте инструмент для управления и потребности своей команды. Не торопитесь. Обсудите разные методики с работниками, пообщайтесь с коллегами из других компаний. Если фреймворк популярен, это не значит, что он вам подходит. Иногда традиционные методы управления проектами, например Waterfall, могут сработать лучше, чем Scrum или Kanban.

Ошибка 2. Не учитываются взаимозависимости между командами

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

• дублирование функций,
• перенос сроков выпуска продуктов,
• неподдерживаемый код.

Как не допустить ошибку

Используйте инструменты для организации бизнес-процессов. Например, OKR поможет определить единые бизнес-цели для всех команд и построить систему их взаимодействия.

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

Мы как-то собирались с разработчиками (158 человек) и строили граф взаимозависимостей. Некоторые команды даже не догадывались, что между ними существует какая-то связь.

Ошибка 3. Мнимое изменение

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

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

Как-то в компании, где я работал, внедряли OKR (Objectives and Key Results). В рамках этой методики нужно отслеживать KPI (ключевые показатели эффективности) и постоянно проводить Check-In — встречи, где определяются результаты работы и степень достижения цели.

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

Как не допустить ошибку

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

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

Ошибка 4. Отсутствие стандартов

Отсутствие стандартов в кодировании, архитектуре, оформлении документации и требований безопасности ведет к разнообразным проблемам.

Если ваши виртуальные продукты не соответствуют стандартам безопасности, рано или поздно вашу компанию взломают и украдут персональные данные.

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

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

Как не допустить ошибку

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

Ошибка 5. Одержимость команд созданием новых функций

Команда общается с пользователями и узнает их пожелания по развитию продукта. Из этих требований формируется бэклог. Если продукт существует уже много лет, то и функций будет всё больше и больше. Отсюда появляется 3 проблемы:

1. Команде будет трудно поддерживать многофункциональный продукт.
2. Разрабатываемые функции интересны ограниченному кругу потребителей. То есть их бизнес-ценность будет очень низкой.
3. Сам продукт станет сложным для пользователей.

Как не допустить ошибку

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

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

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

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

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

👉Что такое корпоративная культура