Поговорили с Алексеем Бояршиновым, директором компании-франчайзи о том, кто такой РП и как им стать
Какое главное качество РП?
РП в проекте 1С без знания программного продукта. Рабочий вариант или нет?
Хочу стать РП. С чего начать? Какой карьерный путь выбрать?
А зачем вообще идти в РП? И надо ли?
Какие книжки почитать?
Алексей, привет! Мы с тобой общались уже несколько месяцев назад. Поговорили про твой путь 1Сника и бизнес. Сейчас решили обсудить более узкую тематику: про РП - кто это, зачем, как им стать и надо ли им становиться?
Иногда просто не надо это делать (улыбается).
Да, мы поговорим о таких случаях, когда не надо. Давай начнем с вопроса, который всплывал в моем канале: мы затронули тему, какое главное качество РП. Может быть, навык.
Я про этот вопрос думал тоже. Читал, что у тебя в канале люди отвечали на этот вопрос. И много писали разумных вещей. Я бы сказал, что все навыки руководителя проекта можно поделить на 3 кучки.
это знание предметной области. Предметную область понимаем широко, это, в том числе и знание программного продукта, который мы собираемся внедрять. Если мы говорим про 1С, значит РП должен понимать 1С на достаточном уровне, чтобы не ходить с каждым вопросом к своим специалистам (аналитикам, программистам). То есть он должен понимать, как работает платформа, как добавить пользователю прав и что это значит, где находятся какие-то кнопочки. Он должен понимать: как что-то запустить, открыть, сохранить. Желательно, чтобы он понимал программный продукт внедряемый пусть не на уровне какого-то там методолога, но на достаточном уровне, чтобы понимать, о чем вообще идет речь. Так же и предметная область: если мы говорим про розницу, например, то надо понимать: что такое розница, какая в рознице есть специфика, какие есть виды маркировки, для каких видов товаров, какие есть информационные системы, всю эту отраслевую специфику. То есть РП должен понимать предметную область.
РП должен обладать знаниями проектной технологии. Это свод знаний: понимание того как проектом управлять, как его вести к успеху, как его планировать, как управлять заинтересованными сторонами -то есть это просто технология, которой можно научиться.
РП однозначно должен уметь хорошо коммуницировать и контактировать с людьми. Причем с людьми разными: как с людьми внутри своей команды и в компании, так и с людьми заказчика. Он должен быть в какой-то степени политиком. Он должен быть эмпатичным. Он должен чувствовать: у кого плохое настроение, кого сегодня лучше зря не теребить, на кого когда надо поднажать, а когда не надо. И руководителем проекта точно не может быть человек, который людей не любит, боится: боится поднять телефон, позвонить и спросить “Где мои деньги?” или “Почему Вы не пришли на встречу?” или “Извините, мы не успеваем сделать вовремя. Давайте перенесем демо.” Для него это должно быть нормально, он не должен бояться людей. И это ключевые большие блоки.
Если выбрать какое-то одно качество?.. Они все нужны. Нельзя сказать, что хороший программист знает только алгоритмы сортировки и это главное, все остальное может не знать...
В целом, у руководителя проекта должна быть в голове модель будущей информационной системы. То есть он должен понимать, как в целом будет выглядеть работающий запущенный проект. И я подозреваю, что это не только для 1С сферы. Руководитель проекта строительства (например, частного дома или коммерческой недвижимости) должен понимать: как в целом вот это все будет выглядеть - как это будет выглядеть внешне, какие там внутри будут коммуникации и как они друг с другом будут взаимосвязаны. Он не должен быть глубоким специалистом. Все время у меня аналогии с домом: я дом строю, это мучительный такой процесс, проект😁
Конечно, РП не должен быть специалистом в каждой области. Очень много областей, в которых есть такие глубинные знания, в которые ты просто не можешь во всех погрузиться. Но в целом картину он должен себе представлять.
И почему важно, на мой взгляд, 1Сному руководителю проекта понимать, как будет выглядеть эта система целиком (когда в ней будут люди работать, когда в нее данные будут загружены и когда все доработки будут сделаны, когда все это будет запущено): потому что без этого он не сможет принимать правильные решения. Если сегодня на планерке ему заказчик говорит: -“Слушайте, а мы вот подумали: если мы сделаем это не так, а вот так - это ведь ничего?” - он сразу должен у себя в голове причинно-следственную цепочку сложить: -“Да, это ничего, это ни на что не повлияет в принципе. Мы галочку там выключим/включим, глобально не влияет. Или потом эти данные просто перезагрузим еще раз, ничего страшного” или -“Нет, подождите, так нельзя. Это прямо глобально. Это существенно повлияет на проект: это дополнительные трудозатраты, это дополнительные сроки. Почему вы так решили вообще сделать?”
И у него это сразу должно сработать. Очень плохо, если он это все послушает, скажет “Я подумаю”, потом пойдет к команде, команде это расскажет. Команда ему скажет: “Ты чего вообще? Так нельзя”, он пойдет обратно к клиенту... и спустя неделю или две недели он клиенту будет объяснять: “Нет, так нельзя”. То есть он должен думать об этом сразу и сразу принимать решения правильные. А для этого нужно представлять себе этот "дом" целиком: вместе с отоплением, электричеством, вентиляцией, фундаментом, внутренней отделкой, крышей и окнами. Если он не представляет целиком картину - он не сможет эти решения принимать быстро.
Мне кажется, это какая-то такая “емкость” головного мозга. У кого-то в голове умещается УНФ на пять пользователей целиком, а УТ, в которой будут работать 150 человек и в которой будет миллион доработок, уже не помещается. И все, он не сможет этим проектом управлять. Он может быть отличным коммуникатором, он может дружить с людьми, он может знать технологии. Но он не сможет успешно управлять проектом, он где-нибудь запнется (на этапе реализации или на этапе обучения), у него начнутся несовместимые с жизнью проекта проблемы, они просто накопятся.
Эту емкость - ее нужно увеличивать: обучением, практикой, работой со своим мозгом. У кого-то УТ влезет на 150 пользователей, а проект ЕРП уже не влезет. ЕРП - со всем ее подсистемами и взаимодействием, со всеми ее производствами, себестоимостью - она просто не помещается в его голову целиком. Только какими-то кусочками помещается, а целиком он ее себе не представляет.
Это все равно что руководитель строительства, который может представить себе как отдельный дом стоит, но не представляет, где будет электрика, в какой последовательности нужно делать тепло, канализацию, что за чем - отдельно может, а все целиком не может. Ну не получится у него хорошо довести весь такой проект до конца.
И вот как раз ты частично уже ответил на вопрос от читателей канала. Вопрос такой “Как ты относишься к РПшникам, которые пришли на проект без знания программного продукта? То есть человек ведет проект в 1С, при этом он сам не был никогда внедренцем, не проходил с начала этот путь. И у него при этом управленческие навыки на должном уровне, но он не 1С-ник"?
Если он внедрял в принципе информационные системы: информационные системы, предназначенные для управления бизнесом (внедрял SAP, внедрял какой-нибудь Navision ) и он хороший руководитель проекта по внедрению SAP, а теперь он пришел и внедряет 1С ( но 1С не знает), но при этом у него есть команда и в команде есть методологи, эксперты, архитекторы, консультанты - возможно, все будет хорошо. Может быть, в таком варианте не нужно знание 1С, достаточно умения управлять проектами, причем, именно умения управлять проектами внедрения информационных систем.
Потому что есть определенная специфика, например: управление проектом по созданию мобильного приложения или управление по созданию сайта и управление по внедрению системы, любой - это две большие разницы, на мой взгляд. Вот если ты управлял внедрением информационных систем в компаниях, то в целом, имея хорошую команду сильных специалистов, ты можешь сделать проект нормально.
Если ты просто руководитель (например, коммерческий директор или финансовый директор или еще кто-то) и у тебя нет опыта именно управления проектами и при этом ты 1С еще не знаешь…ну такое себе… Мне кажется, какой-то дохлый номер…
То есть если я, например: руководила проектами (даже пусть и в IT, но я там, например, сайты разрабатывала или Android приложение), то скорее - нет?
Ну, скорее нет. Придется учиться. Это вопрос того пути, который придется пройти до того момента, когда человек сможет взять и сам проект довести успешно с начала и до ввода в эксплуатацию. Просто пройти этот путь будет сложнее, он дольше.
Тогда сразу следующий вопрос. Давай тогда возьмем такой кейс, когда я еще не в сфере 1С и моя цель именно стать РП. С чего мне начать? Пойти программистом поработать или консультантом? Или еще что-то?
То есть, если человек не в 1С сфере и проектами не руководил никогда еще. То есть ни в какой сфере не руководил проектами: ни в строительной, никакими?
Ну да.
Я бы сказал, что наверное, начинать путь нужно с аналитической части: аналитиком, консультантом…Потому что (опять таки, это я рассказываю про свой опыт - он, может быть, не всеобъемлющий и даже не правильный…),на мой взгляд: в рамках проекта аналитик - архитектор, если ты такой большой супер-аналитик - то как раз отвечаешь за то, чтобы эта система целиком была сделана. Чтобы она отвечала тем бизнес-задачам, которые есть у заказчика. А значит - он очень близко, на самом деле, к проекту и к результату проекта.
То есть отличие какого-нибудь многофункционального архитектора, который отвечает за то, чтобы была сделана система: правильно сняты требования, система была выбрана, правильно настроена, правильные доработки, загружены правильные данные, корректно сформирована структура справочников - вот функциональный архитектор, вот это типа там его задача. А есть РП.
РП очень близко, но только у функционального архитектора нет административно-управленческого блока: он делает систему, а руководитель проекта делает так, чтобы эта система внедрилась. И он предпринимает всякие действия, чтобы вот эта вот сделанная замечательная система, идеально подходящая клиенту (нам хотелось бы верить, что идеально подходящая клиенту) - чтобы она в итоге была внедрена, а для этого нужно сделать разные управленческие воздействия. Надо воздействовать на заказчика, надо воздействовать на свою команду, надо планировать работы, надо контролировать - как они выполняются, надо отчитываться (чтобы какая-то документация была).
Я бы сказал, что надо идти через путь аналитика: то есть в аналитика заходить, больше-больше-больше захватывать областей, типовых конфигураций и/или разделов одной конфигурации. Какую-нибудь ERP берем: потрогать продажи, потрогать закупки, склад/доставку, потом разобраться с оперативным казначейством; разобраться с производством, производственной себестоимостью и планированием производства - соответственно, и пойти по пути аналитика. Потом смотреть, как работает твой РП и подумать: “А тебе реально это надо? Ты хочешь? Может быть, лучше остаться аналитиком и делать интересные задачи, чем огребать от всех: и от наших, и от ваших?” 😁
И да, кстати: какая вообще мотивация у человека идти в РП? Кроме того, чтобы заработать много денег.
- Мне кажется, что это… Нагрузка, которая на РП есть - она же, наверное, и мотивация для кого-то. В чем такое глобальное отличие руководителя проекта? Он принимает решения и несет за эти решения ответственность. И в общем-то, когда проект успешно внедрен - и вся эта толпа народа, все люди теперь работают в этой новой системе и воспринимают ее как часть своей повседневной жизни обычной, и компания работает (пользователи что-то делают, руководство отчеты получает), собственник доволен ( он хотел потратить сколько-то денег и теперь бизнес пользу получает от новой системы) - кто может себе галочку основную поставить, что “Я это сделал”?: руководитель проекта. Понятно, что вся команда - молодцы. Тут никого нельзя обделить: и программисты поработали, и аналитики поработали, и внедренцы поработали. Но кто это все тащил, вел и кто понимает, насколько это все на самом деле было сложно? Как там пользователи сопротивлялись; как была назначена какая-то встреча, а на эту встречу взяли и не пришли; как РП со стороны заказчика посреди проекта запил и не приехал в аэропорт во время командировки 😂 или приехал, но бухой и его сняли с самолета, а нам надо ехать и обучать пользователей. Кто все это дело вообще прошел? Прошел это все руководитель проекта. И поэтому в большей степени, в первую очередь - это его галочка “Я это сделал”. А во вторую очередь уже команды, которая делала хорошо задачи внутри этого проекта. И, конечно, это очень приятно, такое достижение: “Я это запустил. Мы внедрили, например, ERP в Норильске, несмотря ни на что: ни на задержки самолетов; ни на то, что аэропорт засыпало снегом; мы не могли выехать из гостиницы - несмотря на все это, мы внедрили. Это заслуга руководителя проекта, в первую очередь: это его боль, его нагрузка, его ответственность и причина выгорать, но это же и приятно.
Мне кажется, что стоит идти в руководители проектов ради этого. Если ты реально этого хочешь и тебя это прям “зажигает”: сегодня маленький розничный магазин автоматизировать, завтра автоматизировать сетку, послезавтра - торговую компанию, после послезавтра - сеть каких-нибудь сервисов, а потом какое-нибудь производство. И вот эти разные проекты, разные бизнесы, разные собственники, разные люди, с которыми ты работаешь (менеджмент, рядовые сотрудники) - все “капец” какие сложные, у всех свои цели - но ты со всем этим справляешься и все эти проекты запускаешь. Каждый запущенные проект приносит тебе моральное удовлетворение, кроме денег. Мне кажется, деньги можно проще заработать (смеется). А моральное удовлетворение - это, конечно, такое большое…
Ок, мы выяснили, что начать надо с аналитика. Допустим, я аналитик. Я посмотрела на своего РП и поняла, что мне всё это надо, я хочу. И у меня вопрос: чему поучиться, что почитать? Может быть, какие-то курсы пройти? Вот что тут посоветуешь?
Наверное, самое простое, первое - с чего стоит начать у себя в компании ( если я работаю аналитиком в проекте, у меня есть руководитель проекта (который все эти проекты делает) - наверное, стоит спросить или у него или у моего руководителя или у руководителя проектного офиса: “Я вот поработал в проекте аналитиком, мне все нравится, я понял как работает РП и я хочу туда двигаться”. Первый логичный шаг - спросить, есть ли у нас какая-то программа по развитию руководителей проекта. Например, у нас в компании есть такая программа: у нас есть своя внутренняя книга, есть свой трек обучения, есть теоретические и практические задания. То есть мы понимаем, как человека провести по этому пути либо понять, что он не подходит. Не то, что не подходит: не получится.
И на самом деле у нас бывают такие случаи, когда приходит аналитик и говорит “Я хочу быть РП”. Он пробует, а потом говорит: “А можно назад? Я не хочу”. Мы никогда не говорим: “ Как это так? Ты же взял на себя эту ответственность, теперь давай тащи”. Я отлично понимаю, что не каждый аналитик хочет быть РП и тем более не каждый программист. Программисты вообще, мне кажется, это другая ветка развития. Программист, архитектор, директор, технический директор и руководитель проекта - это прям вообще в разные стороны, по моему ощущению.
Соответственно, первое - это пойти у спросить у себя в компании “Какой у нас есть трек? Как я могу стать РП? Хочу, понимаю ответственность, понимаю в чем сложность, понимаю риски. Понимаю, что мне надо учиться. Я готов учиться, готов туда идти”. Вот, наверное, первое.
Второе… Я, наверное, отвечу банально: почитать всякие ТКВ и ТБР. Это 1С-ные своды знаний. ТБР - это технология быстрого результата, типа как маленькие проектики делать на коленке быстро (раз-раз и сделал). А ТКВ - технология корпоративных внедрений. Она, в общем-то, собрана из каких-то частей PMBoK ‘ - очень похожа, но она упрощена, адаптирована конкретно для 1С. Там 1С-ные этапы и можно просто взять эти материалы и для начала почитать, посмотреть, порефлексировать: вот есть проект, в котором я участвовал, как аналитик; теперь я знаю как, в теории, он должен управляться и посмотреть, реально ли он так управлялся, действительно ли там все эти этапы были, почему они были, какие они были.
Можно пойти на курсы: курсов по управлению проектами, мне кажется, довольно много. Я, наверное, не готов прямо порекомендовать. Я боюсь, что сейчас какие-нибудь назову, а потом люди скажут: “Отстой. Я пошел, послушал - фигня какая-то”. Ну, поискать самому, почитать отзывы, почитать содержание курсов по управлению проектами 1С. Выбрать себе какой-то курс, пройти его - неплохое начало. Это точно не означает, что после этого курса вы пойдете и будете руководителем проекта с фиксом 150 и еще премия 150 или 250. Но это так же, как вы прошли курс программирования в 1С на каком-нибудь Скилл Боксе - это не значит, что вы теперь программист и вас взяли программистом и дали сразу кучу бабла (смеется). Но какой-то базис теперь у вас в голове есть, с этим базисом вы можете пойти устраиваться куда-то на новичка, начинающего руководителя проекта. Ну, если в текущей компании, где вы аналитик, не было вообще такой возможности и вам говорят: ” Нет, нам РП не нужен. Ты нам нужен только как аналитик. Как РП мы тебя не хотим видеть”, тогда пойти на курсы посмотреть, книжки почитать.
Книжек по управлению проектами, в отличие от курсов, много хороших. Я их могу порекомендовать целую кучу.
Давай какие-нибудь, парочку навскидку. Таких, которые must have.
Для начала PMBoK,несомненно, стоит почитать. Есть шестой, в русской редакции, я видел. Сейчас самый свежий PMBoK - седьмой, но я седьмого русского еще не видел. Я видел седьмой только на английском языке, а переводной - PMBoK 6. Он очень выглядит страшно (там порядка восьми доменов, сколько-то там принципов) - но когда ты начинаешь читать, то это оказывается не так и страшно, вполне логично и все вполне понятно.
Второе я бы почитал точно “Scrum” - это тоже про проекты, другой подход. Но сейчас очень много совмещений: классического такого водопада с гибкими технологиями, получаются разные гибриды. И я не знаю, кто не пользуется? Мне кажется, сейчас все проектные компании пользуются совмещением и делают гибриды, где есть этапы водопадные, есть внутри какой-нибудь скрам-джем или этапы смешанные. Поэтому Scrum точно надо почитать.
Замечательная есть книга, называется “Peopleware”, на русском “Человеческий фактор”. Это про проектные разработки программного обеспечения. Она считается классическая.
“Deadline. Роман об управлении проектами”. Кто читал, например “Цель” -это бизнес-роман, книжка с какими-то главными героями, с ними что-то происходит и они по ходу дела разбирают какую-то бизнесовую сферу. Вот “Deadline” - это такой же формат, но про управление проектами, очень прикольно.
Владимир Завертайлов “Настольная книга project-менеджера”. Тоже понятным хорошим языком написанная книжка.
Книжки тоже можно взять почитать для общего понимания. Конечно, лучше всего учиться подконтрольно, где у тебя есть теория и практика, а потом можешь попробовать все это на практике. Лучше поискать кого-нибудь, какую-нибудь компанию - где вас готовы будут учить и адаптировать.
Ок, за материалы спасибо. А вот смотри: если в текущей компании я не могу стать РП. Соответственно: я все это изучила, прошла какие-то курсы, ищу работу в новой компании. Все таки какой путь выбрать: идти именно как РП в маленькие проектики (условно, ларьки внедрять: там скорее всего совмещение будет - РП и аналитик в одном флаконе )? Либо, может быть: идти искать какой-то более крупный проект и начинать хотя бы с администратора проекта и учиться уже у какого-то опытного РП?
Слушай, мне кажется: оба варианта адекватны. Оба варианта можно попробовать.
И вариант, когда ты идешь таким маленьким руководителем проекта и, соответственно, заходишь как аналитик - РП в одном лице (есть такое, это как внедренец в одном лице: который и настраивает и запускает и обучает, как бы все делает).
И вариант пойти администратором проекта тоже прикольный, но правда тут надо уже понимать, что такое проект: если после курсов, после книжек это понимание появилось, то тоже хорошо.
Я бы сказал, что разные варианты подходят. Единственное, что нужно точно учеть - компания, в которую ты устраиваешься, должна уметь обучать. То есть у них такая цель должна быть: тебя обучить. Ты идешь в компанию "внедрять ларьки", на 1С автоматизировать и ты говоришь: “Я хочу стать большим РП”. И тебе: “Отлично. У нас есть план. У нас есть материалы, у нас есть технология, у нас есть методика управления проектами. Мы понимаем, как проектами управлять и мы понимаем, как тебя привести: если ты толковый, если ты можешь, если ты хочешь - мы тебя за полгода приведем от ларьков к нормальным проектам”. Вот.
Или ты приходишь администратором и говоришь: “Я прихожу к вам администратором. Я готов выполнять черновую работу, бумажки/протоколы/письма писать. Но я хочу стать руководителем проекта”. Тебе говорят: “Да, хорошо, круто. Мы растим из администраторов руководителей проектов. У нас есть стажировки, обучение, курсы. Если ты способен, то ты им через какое-то время станешь.” Это, наверное, главное. Потому что просто прийти, молча предполагая, что ты вырастешь - плохая идея. А может быть, тебя не планируют “расти”, им достаточно чтобы ты пришел администратором и администратором 5 лет работал и никакого роста им не нужно.
Да, это такой универсальный, наверное, совет: так как многие жалуются, что (условно) в БиТ пришли программировать, а по факту там диски разносили (когда еще были диски).
Да, тут вопрос - а что из тебя собирается компания выращивать? И собирается ли? И когда? И мне кажется, это нормальный вопрос, который можно задать на собеседовании, обозначить свое желание двигаться куда-то в какой-то там обозримой перспективе и спросить, есть ли у людей такая программа и готовы они тебя туда двигать или нет? Может, они тебе скажут сразу: “ Мы планируем, что администратор работает администратором минимум 2 года”, например. А ты не хочешь 2 года быть администратором. Ты хочешь уже через год делать свои проекты: пусть маленькие, но свои. Все выяснили, разошлись, и никаких неоправданных ожиданий.