Студенты, обучающиеся в Университете «Синергия» по программе «Кадровый резерв» и работающие в Корпорации, отличаются полезным качеством для профессионального роста в любом направлении — приверженностью к самообразованию. Многие сотрудники «Синергии», проходящие обучение по программе сейчас или же успешно завершившие её, регулярно находят время для совершенствования навыков и компетенций в выбранной области, освоения смежных сфер и огранки своего профессионального мастерства. Источником постижения нового может быть профессиональная литература и образовательный контент по выбранной теме, участие в практико-ориентированных учебных программах, курсах и так далее.
Но среди студентов «Кадрового резерва» и сотрудников Корпорации есть человек, который пошёл дальше — не только обратил себе на пользу плоды своего самообразования, но занялся популяризацией своей профессиональной сферы среди широкой аудитории «Синергии». Иван Идрисов, проектный менеджер в департаменте веб-разработки и студент «Кадрового резерва», обучающийся на факультете менеджмента, подготовил развёрнутую статью об особенностях работы проектных команд. Полная версия будет приведена далее в этом материале, но сперва стоит познакомиться с работой Ивана и его профессиональными взглядами и убеждениями.
Итак, Иван Идрисов работает на позиции проектного менеджера в департаменте веб-разработки, который ориентирован на разработку программы лояльности Synergy Friends. Его образовательная траектория полностью соответствует специфике задач, которые требуется решать в повседневной работе: в рамках обучения на «Кадровом резерве» он недавно закончил бакалавриат по специальности «Проектный менеджер» на факультете менеджмента, а сейчас продолжает изучать то же направление на уровне магистратуры того же факультета. Также он дополняет своё образование прохождением узкоспециализированных образовательных программ по продуктовому и проектному менеджменту — успешно прошёл курсы «Школы бизнеса» и других образовательных платформ.
В небольшом интервью Иван расскажет о своём пути в освоении проектного и продуктового менеджмента, об особенностях рабочего процесса и источниках вдохновения для создания статьи.
- Иван, с чего начался твой интерес к сфере проектного менеджмента?
- Моя первая проектная команда сформировалась ещё на этапе учёбы на бакалавриате. Так сложилось, что много моих друзей из моего родного города — Донецка начали развиваться в ИТ-сфере. В нашем общении нас часто объединяли интересы по реализации различных ИТ-проектов, главным образом волонтёрской направленности. В итоге мы организовали свою проектную команду и начали совместно пробовать воплотить в виде ИТ-решения различные некоммерческие волонтёрские идеи. Самым заметным результатом стало создание в марте 2022 года платформы в Telegram, нацеленной на оказание помощи мирному населению в моём родном регионе — ДНР. Этот сервис помогал организовать эвакуацию людей и защитить их от боевых действий.
- Хорошо, а какие источники стали наиболее полезными для твоего самообразования и профессионального становления?
- Хочу выделить книгу PMBOK от PMI (Рroject management institute) — всемирно известного учебного заведения, которое специализируется на проектном менеджменте. Считаю, что это — обязательная книга для развития начинающего проектного менеджера. Всем рекомендую!
- Перейдём к нюансам твоей работы. Как ты полагаешь, в чём заключается главная миссия проектного менеджера?
- Его задача — систематизировать видения и мнения о продукте всех участников проектной команды и выстроить комфортный микроклимат в коллективе, чтобы каждый знал, что может повлиять на общий результат.
- Как тебе удаётся реализовывать эти принципы в твоей работе?
- Начну с того, что я перешёл в департамент веб-разработки сравнительно недавно. Мои коллеги в целом значительно опытнее, отмечу особенно их экспертизу в коммерческой работе. Стараюсь учиться у них и в то же время налаживать рабочие процессы. В моей работе важно держать баланс между настройкой этих внутрикомандных процессов и координацией работы команды в целом.
Интересным, хотя и не самым простым направлением моей деятельности является поиск и внедрение новых мотивационных стимулов для участников моей проектной команды. Конечно, в больших разветвлённых корпоративных структурах не всегда бывает просто внедрить эффективные мотивационные стимулы, ведь все инициативы проходят через много уровней согласования, а ещё важно верно определить источники мотивации сотрудников. Именно этим я сейчас и занимаюсь в отношении моих коллег — стараюсь понять, что движет их мотивацией, и насытить их деятельность нестандартными и интересными задачами.
- Можешь привести пример такой задачи?
- Конечно, могу рассказать об автоматизации контроля пользователя с помощью платформы Jira SD. Для решения такой задачи программисту потребуется поработать с API (интерфейс программного приложения) самой платформы Jira, чтобы выводить из неё данные и также интегрировать её с интерфейсом, который создаётся в программе лояльности. Подобные задачи могут мотивировать сотрудников тем, что они дают новые навыки, которые повышают их уровень как разработчиков. Соответственно, в будущем они могут претендовать уже на более высокий оклад, премию и должность.
- Поговорим, наконец, о твоей статье. Твой уровень профессионализма очевиден. Скажи, что натолкнуло тебя на такую тему — особенности коммуникации внутри проектной команды и необходимость вхождения в её состав участников с разной ментальностью? Тебя вдохновила твоя работа или что-то, о чем ты узнал в процессе самообразования?
- Скорее второе. В процессе углублённого изучения проектного менеджмента я не раз замечал изъяны в работе проектных команд разных направлений и уровней. Ключевым недостатком часто являлось стремление излишне контролировать работу проектной команды и разработчиков. Речь идёт о проявлении ярко выраженного авторитарного подхода руководителя, при котором тот уверен и старается внушить коллегам, что правильно только его мнение.
- Заключительный вопрос перед переходом к статье. В качестве аргументации своей позиции ты приводишь 4 кейса из практики работы реальных проектных команд. Расскажи, какими источниками ты пользовался — это инсайдерская информация, личный профессиональный опыт или что-то другое?
- Кейсы 3 и 4 мне удалось узнать от первоисточников — моих друзей, которые были вовлечены в работу этих проектных команд. А для кейсов 1 и 2 я проанализировал и обобщил информацию из открытых источников в интернете.
Спасибо Ивану Идрисову за такой подробный и интересный рассказ, и пришло время представить вашему вниманию полный текст статьи.
Почему проектной команде стоит состоять из разных участников и необходимо ли уметь слушать и слышать, что говорят в команде?
Многие слышали истории успеха великих проектов: Facebook, Apple, YouTube, Google, Tesla. Как два парня в гараже собрали компьютер и появился огромный кампус Apple в Пало-Альто, как студенты, сидя в общежитии, сделали социальную сеть и появилась компания Facebook или трое парней создавали сервис для хранения видео, а сделали You Tube и продали его Google за 1.6 млрд. долларов. Однако, мало кто задумывается о тех периодах этих самых компаний и проектов, когда в них только-только поверили инвесторы, дали денег и сказали: «Вперед».
Что и как они делали, чтобы дойти до того момента, где они стоят в здании Нью-Йоркской биржи, открывают шампанское и празднуют выход компании на IPO?
Конечно, существует огромное количество причин, почему так случилось. Но сегодня поговорим об одной из них — о том, какие команды собирали фаундеры таких проектов, кого они привлекали работать и как выстраивали систему управления в них.
Прежде всего стоит обратить внимание на то, какими были подобные проекты. Возможно, изначально сами основатели строили подобные компании как локальные, предназначенные для узкого круга лиц, однако их продукты стали решать проблемы большого количества людей на планете и по итогу они стали глобальными. При масштабировании компании на мировой рынок появляется логичный вопрос: «А как нам сделать продукт таким, чтоб он подходил для людей разного возраста, пола, мировоззрения, религии, национальности, менталитета и т.д.?».
Убедительным ответом на этот вопрос стало понимание того, что в состав таких проектных команд должны входить абсолютно разные люди, имеющие полноценные права высказываться на счет видения продукта и вносить в него свои дополнения, если большинство согласны с их мнением. Согласитесь, если вы создаете приложение, в котором продаете кулинарные рецепты, то будет странно, если у вас в команде будут работать люди, которые не умеют готовить.
Предлагаю на примерах рассмотреть ситуации, когда в командах не хватало разных точек зрения и к чему это приводило:
Венчурный инвестор и сооснователь стартапа Cherry Labs Николай Давыдов рассказал о том, почему важно, чтобы в продуктовой команде обязательно были и мужчины, и женщины.
Он со своим партнером Максимом Гончаровым создал технологию, которая с помощью видеокамер позволяла следить за происшествиями в доме. Цель их проекта заключалась в том, чтобы предотвратить ситуации, когда у людей случались непредвиденные ситуации со здоровьем дома, в которых они не были в силах обратиться за помощью, например, когда человек теряет сознание и падает на пол. Система видеонаблюдения в таком случае сразу могла зафиксировать непроизвольное движение человека, передать сигнал в ближайшую больницу и вызвать скорую помощь. Казалось, действительно хорошая и полезная вещь.
Камера висит дома и всегда начеку. Однако, как только к их команде присоединилась девушка, она сразу указала на то, что женская половина целевой аудитории не захочет, чтобы за ней следила какая-то камера в ее доме. Так как целевой аудиторией проекта были семейные пары, это действительно могло стать проблемой при продаже, так как жена была бы против такой покупки. Но было немного поздно, когда они обратили внимание на эту проблему. Компания совершила несколько продаж, и это действительно вызвало волну возмущения с женской стороны. После этого команда переключилась на работу с более пожилой целевой аудиторией и начали продавать продукт бабушкам и дедушкам, за здоровьем которых никто из семьи не мог регулярно следить.
Вторую историю про то, почему в команде должны быть правши и левши, рассказал экс-директор по продуктам компании Google Андрей Дороничев.
Когда он пришел в Гугл на позицию продуктового менеджера, ему в команду дали двух инженеров. Они разрабатывали мобильное приложение YouTube (на тот момент Google только выкупил YouTube и им можно было пользоваться только на ПК). Когда они выпустили приложение, в их команде появился человек-левша и сразу указал на проблему, что у левшей картинка на телефоне не переворачивается и телефон приходится крутить на 180 градусов, чтобы посмотреть видео (правша, когда включал видео, чтобы его посмотреть на полном экране, поворачивал телефон в левую сторону и картинка на видео переворачивалась, а левша переворачивал телефон в правую сторону, но картинка по-прежнему переворачивалась в левую).
Это оказалось действительно большой продуктовой ошибкой, которую команда не заметила бы вовремя, если у них не было бы сотрудника-левши.
Историю про то, почему в команде должны быть люди разных национальностей и умеющие говорить на разных языках, однажды мне поведал CEO компании Ostrovok.ru Феликс Шпильман.
Когда они выводили свой сервис по бронированию отелей на мировой рынок, то решили сделать дубль компании, зарегистрировать его в Европе и дать ему другое название. После долгих часов обсуждения названия новой компании они решили дать ей имя «Happy Rooms». Но иностранная аудитория не оценила такого названия компании, приняв его за название сайта девушек легкого поведения.
«Если бы у нас в команде на тот момент был иностранец, носитель английского языка, он бы сразу смог указать на то, с чем будет ассоциироваться подобное название, и мы не допустили бы такой оплошности», — рассказал Феликс.
Еще одну историю про то, почему важно, чтобы в команде были люди разного возраста мне рассказали ребята, которые делают туристический стартап, цель которого дать возможность человеку самостоятельно пакетировать себе тур на сайте исходя из его пожеланий.
Команда проекта была возрастом от 19 до 21 года, и, разрабатывая продукт, они опирались на поведение потребителя своего возраста. Они создали технологию, которая давала возможность в моменте сформировать себе тур и оплатить его на сайте. Однако была проблема: она заключалась в том, что более взрослая часть пользователей заходила на сайт, формировала тур и не бронировала его. И это могло повторяться большое количество раз у одного и того же пользователя сервиса. К счастью, в их команде появился человек, которому на тот момент было 45 лет, и он смог указать на то, что более взрослая часть пользователей сервиса не привыкла бронировать тур в моменте. Им необходимо время обдумать, все ли они учли в своих пожеланиях, что хотели, и после этого они будут готовы его забронировать. Этот человек предложил сделать функцию, которая позволяла сохранять созданный пользователем тур в его личном кабинете и вернуться к его бронированию позже, что повлияло на увеличение конверсии бронирования пользователей старше 40 лет, как мне сказали позже.
Таким образом, необходимо заметить, что команды, в которых разный контингент людей, где участники имеют одинаковые возможности аргументированно высказываться на счет видения продукта, который они создают и с правильно выстроенными доверительными отношениями внутри, действительно являются более конкурентоспособными по сравнению с командами, участники которых похожи друг на друга.
Такие команды могут быть даже менее опытными на старте, однако за счет своей разносторонности они имеют возможность быстро и в большом объеме этот опыт получать.
В заключение я бы хотел привести два примера из своей практики, в которых я столкнулся с различным поведением команды и сам по-разному подошел к вопросу управления.
Первый раз с управлением командой я столкнулся, когда создал и возглавил команду по продаже международных образовательных программ иностранным абитуриентам. Команда состояла из ребят разных национальностей: марокканцев, алжирцев, нигерийцев, иранцев, казахов и россиян. На правах более опытного участника нашей команды я ставил задачи менеджерам, вводил новые практики работы с клиентами и стандарты работы в команде. В ту же очередь, я не хотел слышать остальных участников нашей команды, которые часто описывали текущие проблемы в продажах и предлагали их решения. Делал я это не из-за своего тщеславия или эгоизма, а по причине того, что искренне верил, что я опытнее и лучше знаю, как нужно делать. Все это привело хоть и к медленному, но все же полноценному распаду команды.
Второй случай, когда мне пришлось управлять командой, произошёл, когда я и еще пятеро ребят решили создать сервис, помогающий людям с поиском автомобиля для переезда. К менеджменту в этот раз я подошел, используя методологию Agile (гибкий подход к разработке программного обеспечения), одними из главных принципов которого являются следующие правила:
- непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды;
- команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы;
- в команде мы выслушивали позицию каждого ее участника, спорные моменты решали способом голосования и вместе искали пути дальнейшего развития.
Каждый осознавал, что может быть умнее и опытнее других в какой-то определенной области знаний и это давало понимание, независимо от должности в команде, что важно слышать каждого: что он говорит, как он видит наш продукт, какие, по его мнению, есть или могут быть проблемы и так далее. Это привело к тому, что команда работала быстро, слажено, каждый ее участник ощущал свой весомый вклад в создании продукта и получал огромное удовольствие по завершению проекта.
В вашей работе необязательно использовать какие-то определенные методологии, но важно помнить, что каждый созданный продукт или услуга, которую вы предоставляете, несет определенную пользу той целевой аудитории, на которую он рассчитан. Но в целевую аудиторию могут входить люди разного пола, национальности, религии, правши и левши, говорящие на разных языках, тяжело и легко раздражающиеся, те, кто может легко понять функциональность вашего приложения или которым это дается тяжело и так далее.
Поэтому очень важно уметь слушать, слышать и быть готовым к тому, что вы не можете быть самым умным и опытным во всем. Будучи лидером команды необходимо двигаться с ней на равных правах, равноправие позволяет каждому быть услышанным, возможность быть услышанным открывает двери свободному высказыванию работы команды, свобода слова порождает интерес, интерес заставляет человека думать, двигаться, развиваться, помогать друг другу, приходить раньше и задерживаться допоздна, исследовать, предлагать нововведения, генерировать идеи и стремиться к общей цели.
И благодаря команде, состоящей из разных людей, которой двигает интерес к тому, что вы делаете или создаете, возможно достигнуть поставленных целей!
