3 главных компонента эффективного управления

На связи технический директор Calltouch Роман Хохлов. Роман несколько лет исследовал методологию управления процессами в компании. За это время он сформулировал перечень базовых элементов организации командной работы, и в этой статье Роман готов поделиться своими наблюдениями.

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

Командообразование

За любыми процессами разработки и производства продуктов стоят люди. Приступая к управленческой работе, вам придется учитывать возможности своей команды. Эффективность работы напрямую зависит от вашего умения выстраивать взаимодействия внутри коллектива. Если умеете – команда продуктивно трудится. Не умеете – всё идет вразнос.

Основные проблемы и барьеры

Слабые звенья. Первая причина – в команде собраны неравноценные специалисты. Вторая – участники не задействуют свои сильные стороны. В любом случае коллективный процесс спотыкается о человеческий фактор.

Непонимание масштабов. Группы из 5, 25 и 100 человек – это совершенно разные структуры. У каждой такой команды свое восприятие целей и условий их достижения. Если руководитель не учитывает законы развития своей группы, начинаются перекосы. Например, механизмы, свойственные крупным компаниям, внедряются в малые коллективы. Обратный пример, попытки сплотить десяток департаментов корпорации через тимбилдинги.

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

Практический опыт решения

Два года назад перед компанией встала задача оптимизации процессов. Начали с кадров.

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

Второй шаг. Ротация. Оказалось, что некоторые разработчики лучше справляются с задачами, от которых были удалены длительное время. Мы перенаправили одного способного программиста с багфиксинга на передовую разработки. Что это дало? За 2 месяца создали модуль распознавания пола по звонкам и заявкам. Один из мощных и передовых в экосистеме Calltouch.

Ротация – это незаменимый инструмент, который помогает:

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

Здесь мы подходим к вопросам масштаба и личной составляющей процессов. В нашем коллективе численностью до 20 человек мы можем себе позволить:

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

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

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

Что следует помнить:

• Есть интерес сотрудника – найдется работа для него. Отсутствие навыков не проблема – научим. Нет интереса сотрудника – извини, нам не по пути.
• Сотрудник – не узкоспециализированная машина. Он хочет, может и должен учиться новому.
• Процесс обучения и взаимопомощи – это естественная возможность повысить сплоченность коллектива, компетентность сотрудников. 
• Необходимо учитывать основы групповой динамики. Для компаний разного размера работают свои принципы постановки и достижения целей.

Механика рабочего процесса. Приоритизация задач

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

Основные проблемы и барьеры

Отсутствие планирования. Без четкого плана и приоритетов, команда выполняет задачи несогласованно. Как результат – нестыковки в проекте, хаос в работе сотрудников. В нашем случае можно выделить три источника задач:

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

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

Отсюда проистекают попытки сделать всё и сразу. Без серьезного планирования и расстановки приоритетов. В итоге от такой работы получается скоп недоделанных модулей и критических ошибок.

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

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

Бесконечные итерации. Когда у руководителя нет внятного плана работы над проектом, страдает вся команда. Сотрудникам ставятся неверные приоритеты, даются беспорядочные указания. Разработчикам подкидывают новые «хотелки» менеджеров раз в час. В итоге проект буксует.

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

Практический опыт решения

Как мы поступили.

Разгребли мусор. Первым делом – прибрались в багтрекере. Процесс разработки прилично ускорился. Со стороны казалось, что мы налегли на новые разработки, забросив работу над ошибками. Всё ровно наоборот. Драйвером роста стало то, что мы избавились от груза ошибок.  

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

Обозначили свои возможности другим отделам. Далее – договорились с продакт-менеджерами о соблюдении четкого алгоритма взаимодействия. У нас есть свой четкий распорядок. Доработки без критического статуса – терпеливо ждут очереди.

Процесс разработки подчиняется концепции таймфреймов:

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

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

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

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

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

Культура и концепция управления

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

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

Забудьте про KPI. Здесь важно соблюдать меру. Не нужно отказываться от измеримости бизнеса. Напротив, эффективно управлять без измерений результатов невозможно. Но любые измерения должны быть адаптивны и соответствовать реальности.

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

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

Нет явных оценок времени и трудозатрат. Вместо жестких дедлайнов, мы управляем изменениями. Самоорганизация и быстрая реакция помогает нам корректировать процессы на ходу. Например, завтра разработчик Фёдор под настроение зафиналит проект, на который отводилась неделя. А Пётр вдруг заболеет и не выдаст новое обновление в срок. Тогда остальные участники подхватят буксующий процесс. Так или иначе, на выходе мы получим рабочий продукт точно по графику.

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

Результаты

За первый год мы улучшили на 80% показатели планирования сроков. Согласно статистике в JIRA:

• В июне 2017 закрыто 96 багов, 85 тасков
• В июне 2018 закрыто 99 багов, 147 тасков
• В июне 2019 закрыто 105 багов, 213 тасков 

До анализа данных, нам казалось, что ошибок за год стало меньше. Но JIRA свидетельствует об обратном.

• Это обусловлено возросшим количеством новых продуктов. Однако в пересчете на один продукт багов стало меньше.
• Мы разгребали «мусор» багов за прошлый год.
• Приоритизация приносит свои плоды. Мы четко поняли, в каком порядке работать с ошибками. Стали устранять баги быстрее.
• Базовые меры по командообразованию позволили повысить качество исполнения проектов.

На текущий момент, устранение багов занимает один день в неделю из пяти.    

В бэклоге значительно уменьшилось количество задач по сравнению с первым годом. Если в 2017-м там было более 350 задач, то в 2019-м их около 180. При этом оба года наблюдается рост компании. Мы выпускаем больше продуктов.

Для сравнения. По состоянию на 2 квартал 2017 года мы не выполнили ничего, чтобы стабильно работало. За 2 квартал 2018 году создали около 30 новых задач различной степени сложности. Одним из драйверов успеха стала работа продакт-менеджеров. Они стали заблаговременно прорабатывать и ставить задачи, что сильно улучшило общий процесс.

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