Итак, как я уже писала в прошлой статье Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей, я собрала серию советов от опытных РП начинающим.
И в среду на вебинаре вместе с несколькими экспертами мы обсуждали наиболее спорные советы. И итоги обсуждения получились, на мой взгляд, в некотором плане, полезнее самих советов. Так что давайте здесь попробуем обсудить три совета, вызвавших наиболее бурное обсуждение.
Традиционное лирическое отступление. Тем, кому интересно погрузиться в тему управления проектами серьезнее - приглашаем на Курс по управлению ИТ-проектами (Базовый курс и Комплексный курс). К последнему в этом году набору можно подключиться до 23 сентября. А уже в четверг 17.09.20 будет открытый вебинар, где мы будем продолжать традицию дискуссий - на этот раз разберем несколько реальных проблемных ситуаций из управления проектами, и подумаем, как их можно было бы разрулить. Присоединяйтесь к вебинару!
Теперь, давайте объясню, а почему, собственно, шляпная вечеринка? Дело в том, что прокомментировать советы начинающим РП я попросила из трех ролей, условно говоря, примерив три разные шляпы:
- Зеленая шляпа: Шляпа реалиста. “Окей, вот вы дали совет - всё прекрасно. А какие практические выводы из этого следуют?”
- Черная шляпа: Шляпа критика. “Почему этот совет никуда не годится? Почему ни в коем случае не следует так делать?”
- Лиловая шляпа: Шляпа мечтателя. “Что будет, если пофантазировать? Продолжить этот совет, и довести ситуацию до возможного максимума?”
Это упражнение “Примерить разные шляпы” очень хорошо позволяет посмотреть на ситуацию с разных сторон (рекомендую практиковать это умение). И в ходе вебинара у нас, на мой взгляд, это неплохо получилось.
Спасибо всем участникам дискуссии, из которых я составила собирательные образы “Критика”, “Мечтателя” и “Реалиста” - в первую очередь Клавдии Макаровой, Василию Оводкову, Андрею Аввакумову и Евгению Карпову.
А ниже давайте посмотрим, что у нас получилось (далее следует пересказ вебинара в в форме диалога из нескольких персонажей - РП-автора совета, Реалиста, Критика и Мечателя).
Совет №1.
Александр Блинов, РП: РП в некотором смысле - противоположность аналитику и разработчику. РП ориентирован на результат, аналитик и разработчик - на процесс. Так что с пониманием относись к стремлению других членов команды к перфекционизму )!
Критик: Это вы сейчас что-то странное сказали! Если руководитель проекта противопоставляет себя команде - он проф.непригоден! РП часть команды, он не может противостоять им.
Реалист: Речь не совсем об этом. Скорее о том, что система мотивации в большинстве компаний чаще всего заточена под руководителя проекта - чем больше проектов и чем на большую сумму выполнено - тем лучше. Так что если хотите заботиться о команде - уточняйте схему мотивации, чтобы аналитики и разработчики были заинтересованы делать свою работу хорошо. Иначе - будьте готовы потерять людей, работу которых не ценят.
Критик: “Потерять людей?” У нас с вами получается, что РП - это такой людоед. Местечковый...
Мечтатель: Возможно, нужны несколько разных систем мотиваций для разных членов команды?
Критик: Еще чего! Новая система мотивации не добавляет позитива ни в какую команду. Команда должна быть замотивирована на общий результат!!!
Реалист: Не вижу здесь большой проблемы. Если ценностям РП и руководства компании не претит такое, повышаются KPI и прибыль, то и хорошо, каждый обращает внимание к своим ценностям
Мечтатель: И все-таки - что нам делать с ситуацией, что РП и команда хотят разного?
Реалист. Давайте разложим суп отдельно, мух - отдельно. Мы сейчас говорим о выполнении проекта. Команда должна заботиться о том, чтобы проект эффективно выполнить. Согласно ТЗ и к удовлетворению бизнес-заказчика (неважно, внешний проект или внутренний). РП должен доносить до всех рамки проекта и цели, они и должны стать ключевым вектором.
Мечтатель: А как же творчество? Как же стремление сделать “лучше, чем просили”?
Реалист: Креативность и перфекционизм поощряются, но выносятся за рамки проекта, например в качестве публикаций на Инфостарте, как отличное место для демонстрации собственных идей (“вот, мы придумали вот такую доработку, верим, что она может оказаться много кому полезной”).
Ну и вообще, не надо пытаться объять необъятное и сделать все “идеально”. Надо выполнить 80% работы за 20% времени, а потом решать проблемные вопросы
Александр, автор тезиса, надевая Шляпу Мечтателя: Коллеги, давайте расскажу, как должно быть устроено в идеальном мире. Сразу оговоримся: я использую модель франчайзи, но с небольшими правками модель работает много где.
Первое. Мы можем обсуждать лозунги типа “за все хорошее, против всего плохого” и “мы одна команда, и цели у нас одни”, но… на самом деле цели у всех действующих лиц проекта (заказчик, РП, аналитик, разработчик, руководитель проектного офиса, генеральный директор, учредитель…) разные, и игнорирование этой аксиомы приводит к неожиданностям разной степени неприятности.
Второе. Давайте рассмотрим только один аспект - заработную плату. Как правило, зарплата во франчайзи делится на две части - оклад и премия. Премия легко может превышать оклад, поэтому мотивация к ее получению бывает очень значимой. KPI, применяемый для расчета премии для разных должностей тоже разный:
- у Руководителя проекта (РП) цель - завершить проект с максимальной маржинальностью
- для Аналитика (А) и Разработчика (Р) - выполнить свою часть работы с максимальным качеством.
Если кто-то хочет поспорить “а у нас по-другому” - не надо )) вот всего пару примеров от авторитетов:
- мотивация персонала в 1С:Франчайзи (статья Андрея Мироненко, экс-Раздолье, в настоящее время - 1С)
- роли в проектной команды (заметка в ЖЖ Дмитрия Завалишина, E-legion, экс-Яндекс)
Да, для фирм-франчайзи еще хорошо бы получить клиента на постпроектную поддержку, а для этого нужно уложиться в сроки, сделать работу качественно, и сохранить хорошие отношения с клиентом. Но - поддержку будет делать другое подразделение, и на премию РП не повлияет. Значит - можно заботиться только о своем бонусе.
Третье. Для тех, кто уже все понял - пропускайте этот пункт )
А и Р стремятся сделать свою работу максимально качественно. А хочет описать все кейсы; сделать методическую проработку; отрисовать схемы в Visio, а не в PowerPoint; нотация чтобы по стандартам BPMN, а не смесь eEPC и 1Сных бизнес-процессов. Р хочет весь код написать по стандартам разработки 1С; написать тест-кейсы в СППР (и вообще - запустить в компании СППР и наконец-то писать тест-кейсы); сделать оптимальной архитектуру… да много чего.
А РП по договору нужно через 3 дня сдавать очередной этап. И перфекционизм А, аккуратно вырезающего скриншоты, сейчас ну вообще не вовремя. И без СППР сейчас вполне можно обойтись, тем более что - заказчик нам за изучение СППР не платит, да? Поэтому - тестируйте вручную, по старинке. Зато проект будет сдан вовремя, а что там “под капотом” с техническим долгом - покажет только code review. Через некоторое время после сдачи проекта.
Да, всегда можно спросить: кто виноват в том, что дедлайн на носу, и надо торопиться? Причины могут быть разными, и не всегда виноват участник рабочей группы
- у РП с самого начала выдернули из проекта ключевого аналитика, на которого он рассчитывал, а нового не дали
- Заказчик накидал новых требований, которые к сожалению укладываются в договор
- Разработчик заболел
- Второй разработчик ушел в Газпром (питерцы заплакали).
Ну и т.д.
Четвертое, последнее. РПшнику нужно учитывать, что А и Р любят свою работу, и хотят сделать ее качественно. Аналитику и Разработчику - учитывать сроки сдачи, и не быть оптимистами )
Совет №2
Александр: Знай свои слабые стороны. Компенсируй их либо привычками, либо другими членами команды
Реалист: Разумный совет! Слабые и сильные стороны есть у каждого, это нормально. Нужно развивать свои сильные стороны (это проще и быстрее), а слабые компенсировать командой. И так все будут в плюсе. Для этого и собирается команда, чтобы усиливать сильные стороны и митигировать слабые стороны друг друга.
Мечтатель: Ну нет, это как-то несерьезно. Если известна слабая сторона, то надо начать борьбу с ней, а не принимать как данность.
Критик: Соглашусь с Мечтателем! То, что я что-то не умею - это не повод приходить к клиенту и команде и заявлять: “я вот такой, любите меня таким”. Учись и работай над собой каждый день!
Реалист: Мне кажется, что этот совет - не в том смысле, что “любите меня таким”. А про то, чтобы говорить с командой и работать вместе над ошибками и косяками.
Критик: Вот да. Наконец-то мы заговорили о команде. Знать свои слабые стороны полезно - но не обязательно. На самом деле РПшнику ВАЖНО и ОБЯЗАТЕЛЬНО управлять компетенциями команды. Так что я переформулировал бы этот совет: Знай слабые стороны всей команды и пытайся их преодолеть за счет обучения. Как вариант это может стать дополнительной мотивацией участия в проекте специалистов.
Реалист: Мне кажется, что важный шаг - это признать, что слабые стороны есть и у тебя тоже. Спрашивай у команды, где твое слабые стороны. И слушай, что тебе говорят!!! (это куда сложнее, чем кажется на первый взгляд).
Мечтатель: А что все-таки дает признание наличия слабых сторон??
Александр, автор тезиса (поправляя шляпу Реалиста): Вы спрашиваете, какие практические выводы из обсуждаемого принципа? Давайте посмотрим.
Первое. Компенсация ритуалами.
Кейс: кое-кто постоянно забывает заполнять табель. Почему? не очень важно, вот пример причин, которые могут относиться к разным людям:
- сбит work-life balance
- работа не с 9:00 до 18:00, а с 7:00 до 23:00
- специфика работы с распределенными командами, располагающимися в часовых поясах до +8 от времени Москвы
и т.д. Между тем заполнять табель - надо.
Решение простое: в Google Calendar на 9:00 настроено совещание длительностью 0 минут; за 0 минут до этого совещания приходит письмо-напоминалка. Название совещания - “Табель”. Теперь открывая почту, кое-кто сразу видит письмо, и вспоминает - надо заполнить табель! Табель заполнен, письмо удалено, все довольны.
Так с помощью ритуала, созданного календарем и почтой, компенсируется слабая сторона кое-кого, не будем показывать пальцами.
Второе. Компенсация командой.
Есть ролевая модель Белбина, PAEI-модель Адизеса, еще масса других. Они о том, что важен контекст - разные психотипы востребованы для разных ситуаций. И никто не совершенен.
Кейс: РП имеет слабую сторону - не знает предметную область проекта (вообще, по компетенциям РП постоянно в разных группах Фейсбука, форумах и т.д. возникают холивары - должен ли РП не только руководить, но и быть аналитиком / разработчиком / уметь продавать и т.д. Выводы - очень разные).
Что делать? Можно экстренно прокачаться - купить курсы, поискать в интернете, поговорить с профи и т.д. А можно - довериться профессионализму своей команды, и через косвенные признаки (например, через частые релизы документации и ПО отслеживанием на демо-показах удовлетворенности клиента) отслеживать, все ли в порядке с проектом.
Ну и напоследок, цитата из Адизеса: идеальный руководитель (управленец, который одинаково хорошо справляется со всеми видами управленческой деятельности) – это миф, причем миф вредный, поскольку он является помехой для проявления реальных управленческих талантов, которыми владеют менеджеры… нужно создать взаимодополняющую команду – организовать руководящий состав компании так, чтобы все важнейшие стили управления не только присутствовали в ней, но и дополняли друг друга.
Мечтатель: Коллеги, посмотрите - к нашей беседе подключился еще один участник. С советом, который на первый взгляд может напугать...
Совет №3
Евгений Карпов: Все врут ((С) Доктор Хаус).
Критик: И это тоже ложь…И вообще - чем нам поможет этот совет в работе над проектами???
Мечтатель:Если мы заранее знаем это, то мы сможем не разочаровываться в людях
Реалист: Ну и дополню, что надо всё записывать. Надо себя обезопасить - в том числе правильным договором.
Мечтатель: Полная формализация выйдет слишком дорого!
Реалист: Тогда давайте работать короткими спринтами. Чтобы рисковать только работой за короткий промежуток времени.
Критик. Не знаю. Мне не нравится такая установка! Не понятно как с такой философией вообще работать. Надо стараться всегда говорить правду, иначе теряется доверие в команде
Реалист: Давайте я попробую смягчить эту мысль. Под ложью мы понимаем довольно широкий спектр понятий.
Ложь быватет нескольких типов:
1. Заблуждение
2. Некомпетентность
3. Догадки
4. Мечты и надежды
Мечтатель: Вот да, так уже понятнее! От такой “лжи” может помогать качественная обратная связь заказчику/коллегам. Плюс то о чем мы говорили раньше - фиксировать договоренности.
Реалист: И еще - люди меньше врут, когда настроены на долговременное сотрудничество. См. статью про Дилемму заключенного в управлении проектами...
Какие же выводы из этой дискуссии?.. А выводов не будет. Как я уже рассказывала в своих предыдущих статьях, в постиндустриальную эпоху вопросы - они важнее ответов. Потому что, как известно, любая задача имеет простое, изящное и красивое неверное решение. И простых ответов в управлении сколько-нибудь сложными вещами не бывает (Только дубли у нас простые - (С) Аркадий и Борис Стругацкие) Так что выводы из этой статьи предлагаю каждому сделать самому. Можете написать в комментариях, какая из прозвучавших мыслей натолкнула вас на какие-то полезные размышления. И - удачи на ваших проектах!
Спасибо большое всем участникам вебинара, в первую очередь - Клавдии Макаровой, Василию Оводкову, Андрею Аввакумову и Евгению Карпову.
Ну и еще разок напомню тем, кто дочитал до конца - присоединяйтесь к Базовому курсу по управлению ИТ-проектами, кто еще не (или сразу к Комплексному курсу). В четверг 17 сентября пройдет открытый вебинар, можно принять в нем участие.
