Советы начинающим РП: Подводим итоги шляпной вечеринки 

15.09.20

Управление проектом - Компетенции и навыки РП

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

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

Традиционное лирическое отступление. Тем, кому интересно погрузиться в тему управления проектами серьезнее - приглашаем на Курс по управлению ИТ-проектами (Базовый курс и Комплексный курс). К последнему в этом году набору можно подключиться до 23 сентября. А уже в четверг 17.09.20 будет открытый вебинар, где мы будем продолжать традицию дискуссий - на этот раз разберем несколько реальных проблемных ситуаций из управления проектами, и подумаем, как их можно было бы разрулить. Присоединяйтесь к вебинару!


Теперь, давайте объясню, а почему, собственно, шляпная вечеринка?  Дело в том, что прокомментировать советы начинающим РП я попросила из трех ролей, условно говоря, примерив три разные шляпы:

  • Зеленая шляпа: Шляпа реалиста. “Окей, вот вы дали совет - всё прекрасно. А какие практические выводы из этого следуют?”
  • Черная шляпа: Шляпа критика. “Почему этот совет никуда не годится? Почему ни в коем случае не следует так делать?”
  • Лиловая шляпа: Шляпа мечтателя. “Что будет, если пофантазировать? Продолжить этот совет, и довести ситуацию до возможного максимума?”

Это упражнение “Примерить разные шляпы” очень хорошо позволяет посмотреть на ситуацию с разных сторон (рекомендую практиковать это умение). И в ходе вебинара у нас, на мой взгляд, это неплохо получилось.
Спасибо всем участникам дискуссии, из которых я составила собирательные образы “Критика”, “Мечтателя” и “Реалиста”  - в первую очередь Клавдии Макаровой, Василию Оводкову, Андрею Аввакумову и Евгению Карпову.

А ниже давайте посмотрим, что у нас получилось (далее следует пересказ вебинара в в форме диалога из нескольких персонажей - РП-автора совета, Реалиста, Критика и Мечателя).

 

Совет №1.

Александр Блинов, РП: РП в некотором смысле - противоположность аналитику и разработчику. РП ориентирован на результат, аналитик и разработчик - на процесс. Так что с пониманием относись к стремлению других членов команды к перфекционизму )!

Критик: Это вы сейчас что-то странное сказали! Если руководитель проекта противопоставляет себя команде - он проф.непригоден! РП часть команды, он не может противостоять им. 

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

Критик: “Потерять людей?” У нас с вами получается, что РП - это такой людоед. Местечковый...   

Мечтатель: Возможно, нужны несколько разных систем мотиваций для разных членов команды?

Критик: Еще чего! Новая система мотивации не добавляет позитива ни в какую команду. Команда должна быть замотивирована на общий результат!!!

Реалист: Не вижу здесь большой проблемы. Если ценностям РП и руководства компании не претит такое, повышаются KPI и прибыль, то и хорошо, каждый обращает внимание к своим ценностям

Мечтатель: И все-таки - что нам делать с ситуацией, что РП и команда хотят разного? 

Реалист. Давайте разложим суп отдельно, мух - отдельно. Мы сейчас говорим о выполнении проекта.  Команда должна заботиться о том, чтобы проект эффективно выполнить. Согласно ТЗ и к удовлетворению бизнес-заказчика (неважно, внешний проект или внутренний). РП должен доносить до всех рамки проекта и цели, они и должны стать ключевым вектором. 

Мечтатель: А как же творчество? Как же стремление сделать “лучше, чем просили”?

Реалист: Креативность и перфекционизм поощряются, но выносятся за рамки проекта, например в качестве публикаций на Инфостарте, как отличное место для демонстрации собственных идей (“вот, мы придумали вот такую доработку, верим, что она может оказаться много кому полезной”).

Ну и вообще, не надо пытаться объять необъятное и сделать все “идеально”. Надо выполнить 80% работы за 20% времени, а потом решать проблемные вопросы

 

Александр, автор тезиса, надевая Шляпу Мечтателя: Коллеги, давайте расскажу, как должно быть устроено в идеальном мире. Сразу оговоримся: я использую модель франчайзи, но с небольшими правками модель работает много где. 

Первое. Мы можем обсуждать лозунги типа “за все хорошее, против всего плохого” и “мы одна команда, и цели у нас одни”, но… на самом деле цели у всех действующих лиц проекта (заказчик, РП, аналитик, разработчик, руководитель проектного офиса, генеральный директор, учредитель…) разные, и игнорирование этой аксиомы приводит к неожиданностям разной степени неприятности. 

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

  • у Руководителя проекта (РП) цель - завершить проект с максимальной маржинальностью
  • для Аналитика (А) и Разработчика (Р) - выполнить свою часть работы с максимальным качеством. 

Если кто-то хочет поспорить “а у нас по-другому” - не надо )) вот всего пару примеров от авторитетов:

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

Третье. Для тех, кто уже все понял - пропускайте этот пункт ) 

А и Р стремятся сделать свою работу максимально качественно. А хочет описать все кейсы; сделать методическую проработку; отрисовать схемы в 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 сентября пройдет открытый вебинар, можно принять в нем участие.  

См. также

Управление проектами Руководитель проекта Платные (руб)

Мария Темчина - директор по проектам Инфостарт, приглашает всех, кто хочет стать профессионалами в управлении проектами на Комплексный курс по управлению ИТ-проектами "3 в 1".

25.12.2023    56238    1    Infostart    21    

178

Компетенции и навыки РП Бесплатно (free)

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

22.05.2024    1979    0    user1669221    0    

8

Компетенции и навыки РП Бесплатно (free)

Часто аналитики входят в профессию и ограничиваются знаниями конкретных конфигураций. Но аналитик 1С – это, в том числе, технический специалист, и он должен обладать соответствующими навыками. О том, как аналитику не превратиться в консультанта, пойдет речь в статье.

20.05.2024    1774    0    TanyaRi    1    

6

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3081    0    biimmap    39    

38

Компетенции и навыки РП Руководитель проекта Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    867    0    PChizhov    0    

6

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    2290    0    user1270271    0    

13

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    2156    0    otkalo    1    

12

Компетенции и навыки РП Руководитель проекта Бесплатно (free)

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

22.01.2024    1506    0    andmakarov    2    

13
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Ish_2 1107 16.09.20 05:12 Сейчас в теме
Мыслям тесно, словам просторно.
strelec13; oleynikovpm; jenky_pro; dk; +4 Ответить
2. пользователь 16.09.20 06:16
Сообщение было скрыто модератором.
...
3. user1463341 16.09.20 09:46 Сейчас в теме
Все правильно написано
4. пользователь 23.09.20 11:19
Сообщение было скрыто модератором.
...
5. AntoShiK86 32 01.10.20 12:30 Сейчас в теме
Работодателюя надо ли контролировать сотрудников на предмет, сбит work-life balance? Или рекомендовать менять работу.
6. Valentunka 02.08.21 20:26 Сейчас в теме
Как расшифруется аббревиатура РП?
7. MariaTemchina 1614 02.08.21 22:51 Сейчас в теме
(6) руководитель проекта
Valentunka; +1 Ответить
Оставьте свое сообщение