Что делать, если разработчики и бизнес-подразделения компании не могут договориться

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

Меня зовут Артур Нек, я Kanban-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В этой статье расскажу, как выйти из ситуации, когда бизнес и производство не могут работать сообща. Буду рассматривать проблему на примере IT-компании, но эти советы подойдут для любого бизнеса, где несколько подразделений не могут договориться между собой.

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

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

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

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

• Сотрудники физически не могут выполнять эффективно все задачи, если их постоянно перегружают. Завод, который рассчитан на производство ста деталей в месяц, не может сделать двести, потому что так захотелось управляющему. Так же и в IT — пропускная способность команды ограничена.

Поэтому важно, чтобы все члены команды понимали, что менеджмент и производство — это часть одного целого. И, если они не будут работать сообща, бизнес потерпит убытки.

Сотрудники начнут работать на общую цель, если правильно ее обозначить. Нельзя просто сказать: «Клиенту надо, поэтому сделайте до завтра» — так ничего не получится. Чтобы донести реальную ценность работы, нужно собрать сотрудников и проанализировать, какие проекты приносят деньги, а какие нет. Тогда и менеджмент, и разработчики поймут, какую роль они играют в компании и что от них зависит.

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

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

Чтобы понять, сколько времени требует выполнение разных задач, подойдет спектральная диаграмма. На оси X расположены дни, а на оси Y — количество карточек, задачи по которым команда выполнила за определенный период.

На графике есть две вертикальные линии: синяя показывает среднее время выполнения всех задач, а красная — это перцентиль. Он отмечает, в каком промежутке находятся 85% карточек.

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

График поможет спрогнозировать, сколько времени уйдет на решение новой задачи. На нашей диаграмме красная линия перцентиля говорит о том, что с вероятностью 85% на выполнение уйдет 7,5 дней. Чтобы прогноз был более точным, можно посмотреть на новую задачу и понять, на какие карточки она больша похожа: на те, что закрыли за день, или на ту, что заняла три недели.

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

Это делается в два этапа.

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

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

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

Не переименовывайте задачу в таск-менеджере, а используйте формулировку клиента. Если нужно что-то изменить или уточнить, добавляйте в карточку чек-листы или создавайте подзадачи.

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

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

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

Внутри таск-менеджера можно настроить систему, которая прозрачно покажет приоритетность задачи:

• Самое простое — договориться, чтобы менеджеры ставили срочные задачи выше в колонках. Но у этого метода есть недостаток: разработчик не поймет, насколько задача «горит» и почему нужно заниматься именно ей.
• Оптимальный вариант — метки. Например, красная может означать критический приоритет, а зеленая — нормальный. Также можно определить цвета для таких задач, как ошибки и обновление ПО.

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

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

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

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