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

Но бывает и по-другому, когда менеджмент и разработчики не находят общего языка. Эту проблему можно назвать типовой для IT. Но кроме нее есть и другие, связанные уже с процессами в технологической компании. Обо всех этих проблемах и способах их решения подробнее рассказывает Павел Мальцев, руководитель департамента разработки Skipp.

Менеджер + разработчик != полное взаимопонимание

Личный опыт, как и общение с коллегами, показывает, что разработчики недовольны менеджером проекта примерно в 8 из 10 случаев (конечно, это субъективная оценка, но, тем не менее, считаю ее близкой к реальному положению вещей). Проблема, чаще всего, носит системный характер. Например, мотивация менеджера и команды отличается, причем  так, что общая ситуация при работе над проектом напоминает сюжет басни Крылова "Лебедь, рак и щука", с аналогичным финалом.

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

• Связанные с нерелевантной текущему проекту и/или команде квалификацией менеджера.

• Связанные с неправильно выстроенными процессами внутри компании.

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

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

Как все это сказывается на рабочих процессах

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

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

Есть несколько типов менеджеров, которые не помогают, а мешают работе компании:

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

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

• Фрилансер. Очень популярный тип менеджеров после перехода на удаленку. Фрилансер больше бизнесмен, чем наемный менеджер. Может быть настоящим профессионалом. Но он уже работает в пяти разных компаниях, причем фуллтайм в каждой. Сами понимаете, к чему все это может привести.

• Курьер. Не погружается в проект, занимается исключительно форвард-менеджментом. Передает задачи от бизнеса в команду без экспертизы и проработки.

Как не допустить появления проблемных менеджеров в команде?

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

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

Кейс компании Skipp - как избежать появления плохих менеджеров

Отмечу, что Skipp изначально проектируется как горизонтально масштабируемое решение. Это платформа для автоматизированного найма разработчиков middle- и senior-уровня со всего мира. Классическую древовидную иерархическую структуру управления в таких масштабах сложно реализовать. Как же тогда организовать процесс разработки на сотнях проектах и при этом понимать, что на них происходит в разрезе одного дня?

Для решения этой задачи команда разработала композитную метрику — «индекс здоровья проекта». Метрика формируется на основе десятков независимых показателей проектной деятельности: количества выработанных часов, движения тасков, изменения задач в каждом статусе, диаграммы "сгорания" задач, выполнения специфических скрам-активностей и т.д. Так, можно видеть общее состояние проекта. Если что-то идет не так, менеджеры и разработчики оперативно решают проблему.

Данные для индекса собираются из Jira и ряда других проектных инструментов, затем обрабатываются на стороне Skipp и визуализируются в дашборде. 

Квалифицированные менеджеры и оптимизированные процессы - советы по решению проблем

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

Второй - по процессам. Так вот, на уровне бизнеса, необходимо проработать следующие направления:

• Мотивация. Мотивация менеджмента, команды и заказчика - должна быть сонаправлена и прозрачна. 

• Лучшие практики. Необходимо определить пул практик наиболее подходящих для вашего проекта: модель управления, состав активностей, способы взаимодействия и инструментарий. Например: работаем по скраму, спринты 2 недели, обязательные активности: планирование, дейли, ретроспектива, демо.

• Система метрик. Нужно выделить 4-5 ключевые проектные метрики (доход с проекта, загрузка специалиста, погрешность оценки и т.д.) и завязать на них групповую мотивацию.