Почему важно не забывать про процессы взаимодействия между командами и к чему может привести их отсутствие?

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

У нас встречалось достаточно кейсов, когда говорили: “хотим выстроить HR-процессы надолго”, а при их пересмотре оценивали это как некомпетентность специалиста, мол с первого раза что ли не смогли нормально сделать? В целом неудивительно, что все хотят сделать раз и навсегда, кому лишний раз хочется пересматривать процессы: объяснять участникам новые “правила игры”, контролировать ее ход, выявлять читеров и т.д. Это сложно, особенно в первый месяц, так как паттерны поведения будут сохраняться.

Введем понятие “гигиена процессов”. За гигиеной ведь надо следить, правда? Так и за процессами, особенно когда увеличивается число участников, пользователей, в целом есть изменения. Стоит возвращаться и перепроверить, актуально ли это на текущей стадии развития бизнеса? Это касается процессов в любых командах, будь это HR, разработка, саппорт или даже финансы.

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

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

Итак, почему важно не забывать об этом?

Это снижает мотивацию сотрудников. “Я работаю один” появляется в сознании сотрудников, которые не понимают, что делает сосед. Как правило, если человек не получает обратную связь по задаче, скорость реакции на его результат от коллеги медленная или в целом игнорирование, кажется, что его труд никому не нужен. Как результат, демотивация, снижение перформанса, увольнение.
Это препятствует расширению кругозора и знаниям о проекте и, как следствие, повышению экспертизы. Работает как с насмотренностью: что-то где-то увидел / услышал, заинтересовался, почитал подробнее или вспомнил, когда пригодилось. Да, само общение с людьми — это тот самый шеринг знаний.
Опускаются и теряются договоренности. Когда это стартап, то договоренности все держат в голове. И это логично, потому что зачем нам тратить время на документацию, если обсудили мы это между собой. Но что происходит при росте команды? Чем больше людей, тем больше расхождений в договоренностях, прямая зависимость. Интересно здесь вот что:
Всегда есть функционал, который находится на стыке двух команд, а ответственных определить сложно. Как решаем этот вопрос: я лучше пишу тексты, Саша — выступает, поэтому распределяем так. Делаем мы это неплохо, продукт растет, команды наши тоже, передаем договоренности своим коллегам, но спустя время замечаем, что задачи решаем неоптимально. А почему? Чаще всего эти задачи выполняют неправильные люди, потому что по факту эти обязанности были приписаны им. Да, мы договорились так, потому что нам это было удобно, но удобно ли это другим? И хорошо, если задачи в принципе выполняются, результат может и не “вау”, но есть, хуже — когда его нет.
Что скрывается за неоптимальным решением задач:
— скорость решения задач (затраченное сотрудниками время на работу —> стоимость их работы —> снижение уровня разработки + расход бюджета).
— качество (затраты на коммуникацию и объяснение, почему “так” не устраивает, последующее ревью, x2 ресурсов сотрудника (сделать в 1ый раз, переделать во 2ой) + привлечение, как минимум, еще одного). Поэтому, когда штат растет, пересматриваем процессы: точечное решение вопросов уже не подойдет, надо делать из этого систему.
На онбординг уходит много времени. Онбординг — передача договоренностей, которые не описаны или потеряли актуальность. Отсутствие процесса или как минимум плана, что делать с человеком и какую информацию ему давать, приведет либо к чрезмерному вовлечению руководителя или ментора, либо ко второму кругу доработок. “А причем здесь доработки”, — спросите вы. Увы, не все готовы спрашивать по несколько раз. А отсутствие документации и непонимание того, “а как принято здесь”, многие воспринимают как личный невысокий уровень находчивости, который, конечно, хочется улучшить. Отсюда и желание сделать самому, но далеко не гарантия того, что все будет верно. Исходы разные, результат один — простой разработки. Только если в первом случае ментор тратит меньше часов на свои ключевые задачи, то во втором — время на разработку увеличивается.
Сотрудники делают одну и ту же работу по несколько раз из-за отсутствия прозрачности и непонимания, кто за что отвечает. Вряд ли это будут точь-в-точь одинаковые задачи, скорее для достижения различных целей решение или его фрагменты могут быть использованы в нескольких случаях.
Неудобно работать с результатами задач от внутренних исполнителей. Наиболее частый кейс, когда дизайнеры и фронтенд разработчики/верстальщики не договариваются на берегу о формате документов, которые передают друг другу. Что мы имеем в результате: уходит больше времени на разработку —> снижается скорость и число гипотез на проверку —> компания теряет в прибыли. А если бизнес не устраивает темп —> найм новых людей —> увеличение ФОТ. А если сократить всю цепочку будет так: отсутствие процесса/договоренностей касательно формата передачи задач —> увеличение ФОТ. Неожиданно, правда? Кстати, наш выбор и мнение: результаты своей работы мы передаем в том виде, который удобен внутреннему заказчику.

Вопросы взаимодействия решаются двумя способами: описанием процессов или выделением координатора. Как правило, роль координатора присваивается руководителям или ключевым сотрудникам за счет их инициативности. Но есть и другой вариант — найм джуна. Что эффективнее — надо считать: частота появления задач, необходимая скорость реагирования. Если эти затраты ниже средней З.П. джуна, то вопрос решен, но будьте внимательны, спустя время чаша весов может склониться и в другую сторону.

Процессы взаимодействия между командами надо выстраивать как продуктовую разработку. Бизнес считает важным проводить интеграционное тестирование и нанимать деливери менеджеров, чтобы соединять все детали в пазл, при этом делать это быстро и качество, а на выходе иметь целостный продукт. Так как отсутствие этой целостности сильно ощутимо, да еще и в краткосрочный период. Но если результаты отсутствия процессов межкомандного взаимодействия не столь очевидны, вовсе не значит, что они не съедают бюджет компании. Съедают, еще как!

Ради интереса мы посчитали, сколько придется на 2 команды с численностью по 10 человек, средняя З.П. сотрудника — 3500 евро, наймом — 2 человека в квартал, а процессами такими же, как год назад с численностью 6 человек.

Вроде бы ничего необычного, каждая 3 компания сейчас так работает, потому что есть вещи приоритетнее. А если перевести это в цифры и посчитать потери... Приоритизация поменяется?

При плохо выстроенных процессах убытки бизнеса составят:

за квартал: 22 910 EUR
за год: 91 640 EUR

И это при найме 2 человек в квартал! Что говорит точно не о развитии компании. При развитии цифры еще страшнее. В следующей статье расскажем подробнее о расчетах.

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

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