В ноябре 2016 года на ITVDN появятся первые видео курсы по управлению проектами. Дмитрий Охрименко, CEO ITVDN, встретился с Еленой Петровой, новым бизнес-партнером ITVDN и автором курсов по Project Management, чтобы обсудить вопросы, которые интересуют пользователей нашего образовательного ресурса.
Дмитрий: Елена, пользователи ITVDN - в основном программисты. Расскажи, пожалуйста, в чем суть Проектного Управления и чем новый курс будет полезен для разработчика?
Елена: Как ты знаешь, разработчики работают в команде, которой управляет Project Manager. Если нет PM` a, то есть Team Lead, и в этом случае он - менеджер, который организовывает процесс работы. Разработчику нужно понимать, почему от него что-то требуют, ведь бытует мнение, что работа разработчика — это творчество, а на самом деле это не совсем так, есть ограничения. Есть ограничения по требованиям, по каким-то условиям в компании, в зависимости от модели бизнеса. Например, в той компании, в которой работает разработчик, она диктует определенные правила работы. Опять же, в зависимости от того, какая организационная структура - матричная, проектная или функциональная - это все очень влияет на его полномочия.
Дмитрий: Надеюсь, это есть в курсе?
Елена: Конечно, в курсе есть и это, также в курсе мы подробно рассматриваем состав команды. Кстати, это тоже очень полезно для разработчиков - знать, с кем он работает и какие обязанности у других людей. Мы рассматриваем бизнес аналитика, какие у него задачи и возможности, какие задачи и обязанности у sales manager. Достаточно часто бывает такое, что у разработчиков, у всей команды вцелом, включая PM`a, есть определенное недовольство sales`ами.
Дмитрий: Обязательно кто-то должен быть виноват во всем.
Елена: Да, продали то, что нереализуемо или еще что-то. В таком случае мы пытаемся в этом курсе показать, что у всех есть определенные интересы, но успех бизнеса будет только в том случае, если они согласуют между собой все эти интересы и построят такой процесс, когда кому-то придётся чем-то пожертвовать для общего блага компании.
Дмитрий: На основе какой методологии управления проектом будет построен курс? Какая это методология?
Елена: Я бы могла сказать, что курс построен на PMBoK, но на самом деле нет. PMBoK- это обо всем, это идеальный вариант, сбор лучших практик со всего мира с разных проектов, но далеко не все это применимо в жизни. Каждый PM должен знать, что требует PMBoK, это никогда не помешает и только разнообразит его методы управления. Но применять в жизни он должен очень выборочно и очень осторожно. Далеко не всегда то, что применимо в NASA, применимо для компании, которая занимается e-commerce.
Дмитрий: По Вашему мнению, что самое сложное в работе PM`a? Самое интересное и самое сложное?
Елена: Как ни странно, PM - это посредник, даже больший посредник чем sales. И ему нужно быть очень гибким, ему нужно понимать комбинации различных интересов. Самое важное и сложное то, с чем многие PM`ы "факапят", когда они становятся на сторону команды, но на самом деле PM выражает интересы бизнеса, не заказчика, не команды. Он - наемный работник, он работает на бизнес, его задача, чтобы клиент был доволен, но и при этом бизнес не пострадал. Есть разные способы не навредить и получить выгоду, об этом я тоже буду говорить в курсе, но самое важное здесь - правильно выбрать позицию. Ни в коем случае ни перед кем не очернять заказчика или компанию. PM очень часто overtime-ит, потому что он пытается объять необъятное. Нужно сконцентрироваться на общих интересах для проекта, удовлетворить каждого разработчика все равно не получится. Он должен занять очень умеренную позицию – это сложно, но интересно. Я бы сказала, что для PM`a очень важен склад характера, когда он готов рассматривать различные решения той или иной проблемы и принимать комплексное решение. Как говорят, успех проекта - это в срок, в рамках бюджета и объема работ, также это успех и для PM`a. Но, на самом деле ,это не совсем так. Самое важное - это получить выгоду и не растерять команду. То, о чем мы говорили: на чью сторону должен стать PM, если есть конфликт между заказчиком и командой. Становиться на чью-то сторону нельзя. Нужно правильно уметь объяснить команде, почему то или иное решение было принято.
Дмитрий: PM должен преподнести так проблему, чтобы и команда осталась в плюсе, и проект принес то, что бизнес изначально планировал получить. Из Вашего опыта, например, разработчики общаются с тестировщиками. Тестировщик - это отдельный типаж работников в ИТ компании, а разработчик — это другой типаж. У каждого есть свои особенности и фишки. Что самое сложное в общении между PM и разработчиком? И есть ли вообще такие сложности?
Елена: Сложности в общении зависят только от человека. Если он готов идти на компромиссы и заинтересован в результате, то всё решаемо. На мой взгляд, есть более серьезные проблемы. Когда разработчик не понимает, что нужно сделать. Он хочет что-то сделать и делает это хорошо, но со своей точки зрения. Из-за этого бывают конфликты, причем зачастую между разработчиком и бизнес-аналитиком, если такой, конечно, есть. В маленьких компаниях обычно все функции бизнес-аналитика выполняет PM или Team Lead разработчик. Если не было уделено достаточно внимания проработке бизнес-потребности заказчика, то разработки могут быть потом и не применимы в жизни.
Дмитрий: То есть, проблема обычно в непонимании предметной области?
Елена: Я бы не сказала, что это так. Скорее, это непонимание потребности заказчика. Ведь у него есть свои ограничения, свои требования по внешним условиям. У нас был как-то случай. Проект нужно сделать к определенному сроку. Начинается футбольный сезон и все – должен быть запущен продукт. Тут были ограничения по скоулпу и по функционалу, который действительно нужен. Ведь заказчик не всегда понимает, что ему нужно. Он дает материал, но после анализа команда понимает, что нужно ограничиться и делать только необходимое. Тут как раз и начинается работа и PM, и бизнес-аналитика, и команды разработчиков, поскольку чрезмерное увлечение архитектурой, например, или «как было бы хорошо сделать» не всегда работает. При этом, упрощая, нужно правильно масштабировать проект, чтобы впоследствии можно было бы как-то дорабатывать продукт.
Дмитрий: Еще вопрос. У меня есть много знакомых, которые работают PM, и они регулярно пытаются изучать программирование на C#, JS, Java. Вот насколько это вообще нужно PM? Правильно ли это – пытаться понять работу разработчика, влезать в нее, помогать?
Елена: Думаю, они должны знать, что такое объектно-ориентированное программирование, должны знать основные технологии. На мой взгляд, достаточно понимать, в какой предметной области ты работаешь, какого типа продукт ты создаешь и какие технологии сейчас применимы к разработке подобных продуктов. Если PM будет нырять глубже, это будет только мешать. Точно так же и разработчики – я рекомендую только первый курс «Введение в PM», это даст им понимание, в какой среде они работают, почему именно так устроена компания, почему именно такие решения принимает менеджер или руководитель компании. Разработчикам желательно знать и понимать такие вещи, от этого будет зависеть успешность их работы.
Дмитрий: Насколько реалистична ситуация, когда разработчик становиться PM? Например, некоторые наши студенты на вопросы «Кем хотите быть?», «Как Вы видите свое дальнейшее развитие?» кто-то отвечает, что через какое-то время хочет стать Team Lead/Senior Developer, кто-то хочет стать PM. Насколько такой процесс развития разработчиков реалистичен?
Елена: Все вполне реально. Есть замечательные PM – выходцы из разработчиков. Но тенденция такова, что лучше разработчику стать Product менеджером, тем более, что сейчас активно стараются создать тенденцию развития продуктового бизнеса. И разработчику с опытом и навыками, которыми он владеет, с его отношением к работе, более интересно будет управлять продуктом. Разработчику ,скорее, нужно больше знаний в бизнес-анализе и в управлении людьми. Например, управление расписанием, рисками и т.д.
Відео курси за схожою тематикою:
Дмитрий: А кто будет идеальным PM? Какой портрет человека? Чем он должен заниматься?
Елена: Лично мое мнение из того, с чем я сталкивалась, такое, что идеальные PM выходят из QA специалистов. Вот, действительно, очень хороши. Говорят, что девушки - лучшие PM, нежели мужчины. Тут можно поспорить. Лишь до определенной степени это правда. У девушек слишком живой ум, они впечатлительнее мужчин, а PM должен четко понимать границы проекта, границы компании. И какие бы эмоции или мысли не возникали, хороший PM всегда должен придерживаться этих рамок. Я знаю отличных PM и девушек, и парней, и разработчиков, и даже тех, кто не связан с IT. Сейчас многие идут в IT на PM, ведь программирование для этого учить не нужно. Не всегда в таком сценарии все получается, но бывают и удачные случаи.
Дмитрий: Ты сказала, что программисту лучше расти в сторону Product менеджмента. В чем кардинальные отличия между продуктовыми компаниями и аутсорсинговыми, с точки зрения PM?
Елена: В продуктовой компании главный Product менеджер.
Дмитрий: PМ там не нужен?
Елена: Нет, PМ там нужен, обязательно. Product менеджер разрабатывает стратегию развития продукта, а какие-то элементы или дополнения к продукту идут как проекты. Вот ими, обычно, и занимается PМ, подчиняясь Product менеджеру. В продуктовых компаниях заказчиком является Product менеджер, в то время как в аутсорсинговых компаниях заказчик вне бизнеса. Поэтому в аутсорсе приходиться комбинировать интересы внешнего заказчика и внутреннего бизнеса. В продуктовых компаниях, на мой взгляд, у PМ меньше ответственности: он принимает меньше решений, у него меньше посредничества.
Дмитрий: Он просто управляет отдельными маленькими проектами, которые нужны для общего развития продукта?
Елена: Да, верно. У PМ в продуктовых компаниях вполне определенные организационные функции – это скучнее, но безопаснее, чем в аутсорсе. Зато есть четкие задачи, четкое понимание продукта, ситуации, связей. А ответственность за идею и главную цель несет Рroduct менеджер. В аутсорсинговых компаниях нет как такового Product менеджера, а РМ приходиться постоянно лавировать. Работа более изматывающая, но некоторые находят это более живым и интересным.
Дмитрий: Чтобы стать Product менеджером, какие знания и навыки нужно культивировать? Что читать и где учиться?
Елена: Сейчас есть очень много информации для Product менеджеров. И вебинаров хватает на тему «Кто такой Product менеджер?», и курсы появляются. На мой взгляд, вне зависимости от того, разработчик ты, тестировщик или еще кто-то, чтобы стать Product менеджером, необходимо пройти через бизнес-аналитика. Нужно получить навыки бизнес-аналитика, поскольку даже в аутсорсинговой компании главный человек, который работает с продуктом – это аналитик. Хороший специалист изучает бизнес заказчика, рынок, конкурентов, продукт, он должен понимать, какие "фичи" этого продукта будут эффективными с точки зрения экономической эффективности. И это первый шаг для того, чтобы стать Product менеджером.
Дмитрий: Какой второй?
Елена: У Product менеджера еще больше функций, помимо аналитики. Он является, в первую очередь, носителем идеи самого продукта, «гореть» самой идеей данного продукта. Также Product менеджер должен понимать, какие бизнес-потребности не только своих пользователей он решает, но и свои - почему он выгоден. Почему вообще владелец бизнеса спонсирует производство этого продукта? Product менеджер – это смесь технической роли, аналитики и серьезного понимания бизнеса. Так что, если разработчик не планирует идти вглубь технологий, а заняться карьерным ростом, то сначала это бизнес-аналитика, потом Product менеджер, ну а там уже много вариантов. Многие создают свои компании, именно пройдя такой путь.
Дмитрий: Они получают понимание бизнеса, видят, как работает сама «кухня».
Елена: Да. Сейчас очень много компаний, где руководители – это бывшие разработчики. Но им не хватает именно понимания того, как организовать работу, процесс.
Дмитрий: Думаю, нашим студентам будет полезна эта информация про РМ и Product менеджера.
Елена: Надеюсь. Я записывала курс «Введение в РМ» не столько, как курс по Product менеджменту, это курс по менеджменту в IT компании. Как я говорила, он будет полезен любому человеку, который работает с командами. Это может быть Team Lead или HR. HR-ам и рекрутерам это будет мега-полезно, потому что они занимаются поиском и подбором персонала и им нужно задавать правильные вопросы, уметь правильно оценить резюме. А также будет полезно sales’ам, они не всегда понимают, как работает операционная сторона. Если они прослушают курс, то поймут, чем занимается РМ, по каким вопросам с ним можно консультироваться.
Дмитрий: Кто больше всего критикует работу PМ?
Елена: Разработчики. Они говорят, что РМ не нужны, они мешают работать. Я частично с этим мнением согласна, но ведь одна из задач РМ – это устранять проблемы для разработчиков. А задача разработчиков – взаимодействовать, участвовать в организации процесса работы. От них требуется помощь РМ, потому что он не всегда может обосновать, почему то или иное решение приняла команда. И опять же, если в проекте идет что-то не так, в этом виноват не один только РМ, в этом виновата вся команда.
Безкоштовні вебінари за схожою тематикою:
Дмитрий: Но РМ в первую очередь, потому что…
Елена: Да, потому что не смог организовать команду, чтобы она вместе предотвратила эту проблему. Я очень рада, что записываю данный курс, потому что в нем смогу отразить свой опыт работы в процессном менеджменте. Я отлично видела роли и их взаимодействие на уровне продукта, организации, компании и т.д.
Дмитрий: Какого опыта у тебя больше? С чем больше работала?
Елена: Я, на самом деле, процессный аналитик. Мое основное достижение – это руководство процессом оценивания компаний по модели CMMI. Это модель управления процессами в компании, она охватывает как инженерные процессы, самые простые, так и процессы управления проектами, управления организации и поддержки (системные администраторы и т.д.).
Любой человек, который занимается организацией рабочих процессов, знает, что есть такой инструмент, как теория ограничений, она показывает, где в цепочке производства компании самые узкие места, и проблема обычно на стыке разных специальностей, на стыке разных профессий, разных отделов.
Статті за схожою тематикою
