Хочу поговорить о теме, которая, на мой взгляд, не так широко раскрыта в учебниках по проектному управлению, – о том, как совместить несовместимое, или о совмещении ролей в проекте.
Сначала хочется сказать, почему я вообще взялась за эту тему. Уже более восьми лет я автоматизирую производственные предприятия, прошла путь от консультанта до руководителя отдела, который строит команды и отвечает за результат. За это время я точно усвоила, что даже самый эффективный инструмент может достаточно быстро разрушиться из-за неправильно собранной команды или, что еще важнее, неправильно распределенных ролей.
Говоря про команду, мы не всегда понимаем, насколько она может быть многолика. В каждой команде есть те, кто генерирует идеи, и те, кто доводит эти идеи до конца. Те, кто контролирует, координирует и создает атмосферу.
Если говорить про роли в проекте автоматизации, то, скорее всего, это будут руководитель проекта, аналитик, тестировщик и разработчик. В более крупных проектах появляются технические эксперты и архитекторы. Именно об этих ролях пойдет речь.
Роль и должность – не одно и то же
Мы постоянно что-то совмещаем, для нас это достаточно привычно. Но важно не путать роль и должность.
То, что написано у нас в трудовой книжке, – это должность: наш статус, оклад и место в организационной структуре предприятия. А роль – это маска, которую мы надеваем, чтобы выполнить конкретные задачи в рамках определенного проекта на некоторый промежуток времени.
В жизни мы тоже постоянно совмещаем роли. Например, роли руководителя, жены и мамы. Их я научилась как-то распределять, и для многих такое совмещение уже понятно.
Когда мы включаем музыку за рулем, мы совмещаем роль слушателя с ролью водителя. И не всегда совмещаем их эффективно, потому что, например, я не могу безопасно парковаться под громкую музыку. Рябина у меня во дворе, к сожалению, это подтвердит.
Точно так же и в проектах. Иногда совмещение не просто неэффективно – оно может быть опасным и неподходящим для конкретной ситуации.
Почему компании совмещают роли
Но мы объединяем и совмещаем роли по разным причинам. Нередко это делается осознанно.
Первая причина – оптимизация расходов. Мы в большинстве случаев работаем в коммерческих организациях, а найти и оплатить работу четырех-пяти человек – отдельно аналитика, разработчика, тестировщика – очень недешево.
Компании идут на компромисс и находят одного-двух универсалов, которые могут совмещать какие-то роли: аналитик-разработчик, разработчик-тестировщик и так далее. В каких-то случаях им платят немного больше, но общая экономия за год оказывается существенной.
Еще одна причина – недостаток персонала. Сейчас говорят, что рынок меняется и кадровый голод ощущается уже не так сильно. Но даже в тех проектах, которые у нас сейчас активны, или на предприятиях, находящихся на постпроектном сопровождении, иногда месяцами не могут закрыть вакансию аналитика на внутреннюю первую линию.
Это остается реальностью. Поэтому нашли кого нашли, холим, лелеем, платим сколько можем: «Спасибо, что ты есть». Куда уж тут говорить про три-четыре отдельные выделенные роли.
Следующая причина – оптимизация скорости. Не всегда это решение принимается осознанно, но на уровне интуиции мы понимаем: если в процессе задействовано меньше людей, сокращается время передачи информации и уменьшается вероятность ее искажения.
Чтобы задача от аналитика перешла к разработчику, должно появиться техническое задание. Его нужно прочитать, изучить, возможно, задать вопросы. Чтобы тестировщик мог проверить результат, у него должны быть тест-кейсы. Он точно так же должен ознакомиться с техническим заданием.
Если все это делает один и тот же человек, то он сам придумал, сам разработал, сам сделал. Он не тратит время на документацию, что в некоторых случаях кажется преимуществом. А что будет потом, об этом задумываются не всегда.
Тем не менее ускорить процесс за счет совмещения возможно, и в некоторых случаях это оправданно.
Есть еще одна причина, которая беспокоит меня как руководителя отдела, когда встает вопрос о том, открывать нам вакансию или не открывать. Это возможная недостаточная загрузка сотрудников – здесь и сейчас или в дальнейшем.
В инхаус-командах об этом тоже задумываются. Сейчас у нас есть задача для всех: для троих, для четверых. Но когда проект закончится, что мы будем с ними делать?
Иногда компании идут на такой компромисс: «Мы возьмем двоих. Сейчас им будет тяжело, но зато потом они останутся. Нам не придется переводить их в системные администраторы или сокращать. Главное, чтобы они дожили до конца проекта».
И это уже один из рисков. Когда мы идем на совмещение, то чаще думаем о пользе, а о рисках вспоминаем не так часто.
Риски совмещения
Одни из неочевидных рисков – конфликт полномочий и конфликт интересов.
Если один и тот же человек продает и реализует, то в силу хитрости нашей психологии он, скорее всего, будет предлагать то, что ему больше всего нравится, что он лучше всего знает или что ему легче всего реализовать. В этом случае могут пострадать интересы заказчика и качество результата.
Мы тоже сталкивались с такими ситуациями. Сейчас у нас продают и реализуют разные люди. Это был еще один виток нашего развития.
Я люблю продавать очень интересные решения, но понимаю, что где-то в отделе разработки, возможно, лежит моя кукла вуду. Не всегда легко реализовать то, что мы придумываем и продаем. Но квалификация наших разработчиков в том числе растет за счет этого.
Спустя какое-то время они говорят: «Слушайте, а мы даже не думали, что такое умеем». А мы вынудили, потому что уже продали.
Когда один и тот же человек продает и реализует, такие возможности часто упускаются. Клиенту в большинстве случаев продается что-то средненькое – то, что можно подпереть одним-двумя костылями. Оно работает, вроде бы всех устраивает, но развития и настоящего удовлетворения от результата почти ни у кого нет.
Перегруз команды и дублирование задач – это риски, к которым приводит ситуация, когда у нас один человек и жнец, и швец, и на дуде игрец.
Кажется, что сотрудники немного напрягутся, несколько месяцев поработают в горячке, а потом расслабятся. Но далеко не все действительно готовы к такому режиму. Потом приходит понимание, что люди выгорают. Спустя какое-то время приходится искать новых сотрудников. Мы теряем в сроках и качестве. Перегруз становится прямым следствием попытки оптимизировать штат.
Несоответствие характера работы. О соответствии характера человека и характера работы тоже задумываются не всегда.
Попытка отправить разработчика в поля может закончиться тем, что он оттуда просто не вернется и скажет: «Я на такое не подписывался. Давайте как-нибудь без меня». Ему дали задачу, которая абсолютно не соответствует характеру работы, к которому он привык.
Когда я пришла консультантом, то считала разработку вершиной своей карьеры. Мне казалось, что мне прямо туда надо, потому что там круто. Я даже начинала обучение, но в какой-то момент поняла: если я не навожу суету на протяжении трех часов, то просто взрываюсь и взрываю все вокруг. «Горящий стул» возможен, но только на короткий промежуток времени. Навыки разработки однозначно полезны, в том числе аналитику, но как основной формат работы это точно не для меня. Хорошо, что мне удалось понять это на старте.
Если мы пытаемся совмещать роли, которые не подходят людям по характеру и складу, и вынуждаем их выходить за рамки того, на что они подписывались, это приведет к открытому конфликту. Никакой долгосрочной пользы для компании и проекта такое решение не принесет.
Еще один риск – недостаток квалификации. Это бич универсалов: ты понемногу хорош во всем, но ни в чем конкретном у тебя нет глубокой экспертизы.
Это тоже компромиссный вариант. Мы проходили такой этап, и он действительно был оправдан на маленьких проектах и разовых небольших работах. Но со временем стало очевидно, что нам нужно расти в квалификации и разделять роли. Если все навыки, которые мы хотим получить от одного эксперта, составляют очень большой пул скиллов, то уложить все это в голову одного человека крайне сложно. Исключения, конечно, есть. Но в целом – нет.
Когда мы берем такого универсала, нужно всегда помнить о риске, что в каких-то моментах ему не хватит компетенций.
Еще один риск – потеря или усложнение контроля.
Если один и тот же человек сам делает и сам себя контролирует, то с собой он всегда сможет договориться. Иногда – в угоду срокам, иногда – в угоду бюджету: пусть получится не так качественно и не так интересно, зато мы уложимся в сроки и бюджет. Но результат не всегда соответствует тому, что хотел заказчик. И не всегда получается то, о чем мы договаривались на входе.
Есть еще один важный момент – отсутствие критики и стороннего взгляда.
Пару лет назад я услышала классную формулировку о том, что может получиться, если аналитик и разработчик – одно лицо. Все, что аналитик придумает, он же и реализует. Но что получится на выходе?
У нас нередки случаи, когда технические задания поступают к квалифицированным разработчикам, которые уже прошли огонь и медные трубы. Они дают аналитику конструктивную и здравую обратную связь: «Ребятки, нет, давайте мы так не будем. Давайте затормозим на этом этапе, еще раз подумаем и посовещаемся. Но сделаем по-другому».
Когда нет этого конструктивного диалога и стороннего взгляда, возникает риск, что решение будет сделано не совсем оптимально. Не так, как хотелось бы и как можно было бы сделать, если бы эта беседа все-таки состоялась.
Последствия неправильного совмещения ролей
Последствия реализации этих рисков на самом деле очевидны, но их не всегда связывают с конкретными причинами.
Это выгорание сотрудников и распад команды. Это выход за рамки сроков и бюджета, потому что приходится искать новых людей, экстренно вводить их в курс дела или тушить пожары новыми силами.
Это отклонение от целей проекта, потому что было сделано множество компромиссных вариантов, но в итоге получилось все равно не то, что нужно.
Это формальное внедрение, когда акты уже подписаны и деньги оплачены, но самим проектом и программой практически не пользуются. К сожалению, у нас тоже был такой случай. Вроде бы все хорошо, но морального удовлетворения не случилось.
Самое негативное последствие – остановка проекта в результате реализации перечисленных рисков.
Неудачное сочетание ролей
На наш взгляд, не стоит совмещать все, что смешивает квалификацию и контроль. В таких случаях мы можем потерять точки опоры.
Например, аналитик-разработчик или любые комбинации с тестировщиком.
Если единственным тестировщиком выступает аналитик, он будет проверять систему ровно так, как сам ее придумал. Он знает заложенный алгоритм, пойдет по нему и будет выявлять несоответствия этому алгоритму.
Если систему проверяет только разработчик, он будет тестировать ее ровно так, как сам реализовал.
Только отдельный тестировщик с большой долей вероятности наденет ту самую кастрюльку на голову или покажет, что решение неудобно и пользователю оно, возможно, не понравится. Тогда станет понятно, что нужно что-то изменить.
Какие роли можно совмещать
Стандартный вариант – руководитель проекта и администратор на небольших проектах. Подготовить документацию, организовать встречи – наши ребята с этим справляются. Сейчас во многом может помогать искусственный интеллект, например при формировании документации. Почему бы и нет?
Бизнес-аналитик и системный аналитик – тоже классическое совмещение. У нас эти роли в принципе не разделены, все выполняет один аналитик. Сначала он общается с бизнесом и собирает требования, потом перекладывает их в задачи.
Функциональный архитектор, консультант, аналитик и методолог – это роли, которые требуют похожего характера работы, но при этом не затрагивают контроль.
Можно совмещать разработчика и системного администратора: сам развернул программу, сам проверил, как все работает, обеспечил доступы. Такое совмещение вполне возможно.
Совмещаем компетенции, но разделяем ответственность
Мы пришли к этому выводу, наверное, в том числе через определенную боль.
Не стоит совмещать роли, которые выполняют принципиально разные задачи. Здесь можно вспомнить разработчика в полях.
Не стоит объединять роли, требующие разной квалификации, потому что мы можем потерять в качестве.
Не нужно совмещать работу, предполагающую разный характер деятельности или работу на разных уровнях, когда в одном случае нужно смотреть изнутри, а в другом – сверху.
Главный вывод: совмещаем компетенции, но разделяем ответственность. Не стоит отдавать одному человеку все роли, связанные с созданием, придумыванием и контролем. Тогда появится шанс сделать результат более качественным и получить удовольствие от работы всем участникам. Главная задача – сделать так, чтобы проект заработал, система функционировала, команда не разбежалась, а мы остались в рамках бюджета и сроков.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
