Какими качествами должен обладать «хороший» PM и должен ли он быть для своей команды «мамой» или «папой»? На этот вопрос во время дискуссии «Современный Project Management» проекта «Техпора» от компании *instinctools попробовали ответить приглашенные ведущие эксперты. Каждый из них прошел свой уникальный путь в IT-бизнесе и руководил большими проектами и большими командами. Мы предлагаем вам выдержки из дискуссии, которая длилась больше часа и, по признанию слушателей, оказалась очень полезной как для начинающих PM, так и для опытных менеджеров.    

В дискуссии участвовали Владимир Горшунов – основатель AgileLAB, General Manager Ask Applications/Apalon, Владимир Маковский – Delivery Director Profiterо, Роман Ковалевский – Delivery Manager, Banuba, создатель телеграм-канала @pm_god, Юрий Ерошенков – модератор дискуссии, Head of PMO компании *instinctools.

Что было раньше: Scrum или Agile?

Владимир Горшунов: Не надо разделять Agile и классическое проектное управление. Мы говорим про развитие теории управления. Так что Аgility –  это развитие этой теории. То есть у нас есть менеджмент 1.0 – это Питер Друкер: заводы, пароходы, рабочие, жесткий учет и контроль. Далее, менеджмент 2.0 – это идеи Дайменга, когда мы принимаем теорию, что есть «человек разумный» и он что-то делает. При этом мы будем исходить из того, что он знает, что делает. Есть менеджмент 3.0 – это то, что мы сегодня называем Agile. Тут нужно понимать, что Agile не является чем-то совершенно другим и противопоставляющим себя классическому проектному менеджменту. Аgile – это развитие теории управления, но при этом масса подходов, которые включают в себя Agile, были созданы еще задолго до его появления. Мой любимый вопрос – что было раньше: Scrum или Agile? Фишка в том, что Scrum возник до Agile и не назвался Agile. Потом мы поняли, что Scrum можно «втянуть» в Agile. 

Владимир Маковский: Для меня Agile – это работа с людьми, и она не заключается в том, чтобы объяснить, что нужно делать. Задача – объяснить, почему это нужно. Нет явного разделения на то, что нужно и не нужно делать.

Владимир Горшунов: Есть две модели, которые объясняют применимость Agile, одна из них – это модель Кеневина. Она говорит, что у нас есть четыре зоны. Зона clear-деятельность, когда мы четко понимаем, что должно быть сделано. Это зона инструкций – делай по методичке, если отступишь от нее, то будет хуже. То есть это зона накопленных знаний и понимания того, как нужно делать. Если мы делаем пятисотый сайт-визитку, это clear-деятельность, тут нам Agile не очень нужен. Но в описанном случае могут применять канбановские потоковые методы, то есть, что называется, классическое проектное управление. После clear у нас есть complex complicated, и там уже интересно, есть два подхода: где-то мы говорим, что только в одной зоне применяем Agile, а в другой – выезжаем на экспертах. Проще говоря, мы делаем типовой проект заказчику, но понимаем, что что-то пойдет не так. Но так как мы уже что-то делали в этом домене и в этой технологии, мы примерно понимаем, что может пойти не так. И здесь у нас возникают наши итеративность и прозрачность, применимость Agile.

«Команда может сидеть в Индонезии или США, а фасилитатор – в Германии» 

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

Владимир Горшунов: Есть хорошая фраза «HR – это друг для PM». По факту, когда тебе не хватает рук, ты работаешь в паре с HR. С другой стороны, американская практика свидетельствует, что онлайн и zoom-бары – это максимально грустная история. Люди пытались уже даже играть во всякие кооперативные видеоигры, но и они не решили проблему общения. Вопрос в том, как, сидя в разных городах, командообразовываться, коммуницировать. Есть команды, которые не пересекаются по часовым поясам. И если раньше мы говорили, что это плохая практика и люди должны видеть друг друга на стендапе, то сейчас мнение кардинально другое – не должны.

Для некоторых типов активностей онлайн стал более эффективен, чем оффлайн. Если вы участвуете в PI-планировании на десяток команд, то в оффлайне для этого требуется большой зал, в нем будет немного душно, немного не слышно. Зато все вовлечены. Сейчас, когда мы проводим такие мероприятия в онлайне, то собрать 100 человек – это просто, причем всем будет все слышно и видно. Если даже кто-то «отвалился», то  все равно члены его команды присутствуют. Нет такой проблемы, как посадить всех в самолеты и привезти из разных точек в одну, если команды распределенные. Команда может сидеть в Индонезии или США, а фасилитатор – в Германии, и это работает. Это немного другой взгляд на реальность, но он более интересный. Индустрия IT стала по-настоящему глобальной. Я поддерживаю мнение, что в будущем останется гибридный формат работы. Люди хотят приходить в офис, как в хаб. Сейчас есть отличные инструменты для командного онлайн-общения. В основном разработчики используют Slack, кому не повезло – Skype, а стартапы сидят в Discord.  Причем Discord – это больше продукт для игроков, но оказалось, что он вполне подходит для общения команд разработчиков.

«Хочешь быть PM – научись общаться с людьми» 

Владимир Маковский: Когда мы говорим про роль PM в работе команды, мы должны понимать, что прежде всего говорим об ответственности. За результат, за команду. И чтобы получить возможность нести эту ответственность, нужно заручиться доверием. Хочешь быть PM – научись общаться с людьми. Нужно не втереться в доверие к людям, а заслужить это доверие. То есть история PM – это скорее про доверие и коммуникации. И я не считаю, что инженер, который стал менеджером, – это позитивная история. Я читал статью, в которой была мысль, что компаниям выгоднее платить больше инженеру, чтобы он оставался инженером, чувствовал себя комфортно. Но при этом ради повышения зарплаты этого инженера не нужно продвигать на должность PM. Настоящий менеджер понимает, зачем он выполняет свои функции, а не просто ходит за всеми с палкой и двигает карточки на доске. Ну и, конечно же, сейчас очень важно для PM иметь высокий уровень английского. И этот уровень должен быть не «хорошим», а «отличным». Ведь мы работаем в эпоху, когда в IT расширяется применение распределенных команд и у PM в подчинении могут быть люди не только из русскоязычных стран.