Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

5 правил менеджмента, о которых не пишут в книгах

Как PM за 5 лет я смогла поработать с разными проектами, командами, стейкхолдерами и начальниками. Пройдя путь от чтения абсолютно всего, где написано «менеджмент», и просмотра всех роликов на Udemy до изучения узкопрофильных блогов, я осознала, что о ключевых правилах работы PM’а не пишут нигде. Так, чтобы и кратко, и понятно, и по делу. Решила поделиться своими правилами, или истинами, как я их называю, и облегчить жизнь многим начинающим и не только PM.

Эта статья довольно провокационна, и местами будет обидно и неприятно узнавать себя, но она поможет вам и команде стать лучше, если возьмете на вооружение хотя бы некоторые истины.

Истина № 1. Вы не главный

Вопреки распространенному мнению, менеджер — не главный человек на проекте. Ваше слово — не закон, и ваше мнение не важнее всех остальных мнений.

Менеджер — это человек, чья зона ответственности и полномочий немного шире, чем остальных участников команды, но это не делает его главным.

Как менеджер проекта вы можете стать лидером группы, если будете принимать правильные решения, или «неприятным дополнением», если ваши решения будут неправильными. Разница между первым и вторым в том, что второго терпят, а первого боятся потерять.

Однажды друг пожаловался мне на своего PМ’а с формулировкой «когда она заходит в комнату, становится душно». После череды вопросов, чем обусловлено такое отношение к менеджеру, я выяснила, что его PМ обладает интересной особенностью встревать в абсолютно любой разговор и выражать свое мнение, активно перебивая других участников диалога. Стоит ли говорить, что такое поведение напрочь отбивает желание обсуждать любые вопросы в присутствии менеджера? К слову, PМ был абсолютно не техническим человеком, поэтому его комментарии несли околобессмысленный характер.

Чтобы понять, какую же роль вы играете на проекте, задумайтесь, какие проблемы помогаете команде решать? Как часто вам приходится настаивать на своем решении, используя формулировку: «Я менеджер, и мне виднее, что нужно клиенту»? И как часто к вам обращаются за советом во время работы?

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

Истина № 2. Не мешайте

Лучшее, что вы можете сделать для своей команды, — это не мешать ей работать.

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

Вам кажется, что без вас команда точно не успеет сдать работу вовремя, а отданный билд будет разломан. Что на продакшене точно что-то сломается и клиент откажется за это платить. Поэтому вы старательно собираете статусы, интересуетесь каждой проблемой в деталях, контролируете каждый потраченный час, но правда в том, что если ваша работа забирает больше 15 минут времени команды — вы ей мешаете. 15 минут — это длительность дейли-митинга, который, я уверена, у вас есть.

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

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

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

Как только вы становитесь ключевым участником решения проблемы, то обрекаете команду на неудачу. Вы не даете людям ответственность принимать решения и работать с последствиями, убиваете инициативу и не даете расти профессионально.

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

Истина № 3. Учите людей работать с проблемами, а не с кодом

Неожиданно, правда? Ведь программисты пишут код, а менеджер решает проблемы. Если вы так думаете, то, скорее всего, часто сталкиваетесь с проблемой приоритетов на проекте.

Например, у клиента не работает кнопка регистрации в живом сайте, а ваш разработчик решает совершенно другую архитектурно важную проблему. При этом он совершенно не понимает, почему вы так недовольны тем, что задача, которую вы дали ему утром, еще не выполнена. Ведь там «работы на 5 минут» и он успел бы сделать ее перед уходом домой.

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

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

Никто в здравом уме не будет специально оттягивать решение проблемы, чтобы заставить кого-то страдать. Сделайте так, чтобы ваша команда это понимала.

Истина № 4. Поощряйте людей делать ошибки

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

Да, вы правы, но не все ошибки нужно предотвращать, многие из них дают команде бесценный опыт, который сделает их работу качественнее и тем самым повысит профессионализм. А команда профессионалов — это ведь именно то, чего вы хотите?

Так дайте людям делать ошибки, которые помогут им расти. Не бегите решать каждую их проблему, если, конечно, она не сорвет сроки, которые вы уже пообещали клиенту. Это репутационные потери, которые вам не нужны.

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

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

Ваша задача как менеджера предоставить людям ответственность и возможности принимать решения, совершать ошибки и исправлять их.

Вы наверняка подумаете, что у вас есть отличный инструмент для работы с ошибками — ретроспектива. Но она не сработает. Если вы основной источник решения проблем для команды, то ретроспектива — бесполезная трата времени. Для ретроспективы важен обмен опытом, позитивным или негативным. А поскольку вы решаете все проблемы, то забираете у людей этот опыт.

Истина № 5. Ваши люди — ваша ответственность

Успех команды и людей во многом зависит от того, как вы выстроите работу внутри коллектива и с каждым его участником. Для себя я вывела несколько правил, которыми поделюсь с вами.

Не избегайте трудных диалогов

Они преследуют нас ежедневно. Когда нужно аргументировать отказ в рейзе, когда приходится не закрывать испытательный срок по результатам работы, когда вы просили предоставить статус-апдейт вечером, а получили его на следующий день, когда ваш технический лид прекрасно пишет код, но совершенно не умеет расставлять приоритеты.

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

И это нормально, но это не идет на пользу ни вам, ни коллегам. В свое время мне очень помогла книга «Трудные диалоги», и я до сих пор держу ее на столе и читаю, когда предстоит трудный разговор.

Говорите людям правду, подтвержденную фактами

Это правило вытекает из первого. Зачастую трудный диалог предстоит вести после событий, которые, по вашему мнению, имели негативное влияние на проект и качество работы.

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

«Олег, мне кажется, в этом спринте ты работал слабовато, поэтому мы не успели сдать проект вовремя».

«Олег, в этом скоупе ты сделал 5 задач из запланированных 8, и в 3 задачах были найдены критические баги, поэтому тебе пришлось потратить время на их исправление, что сильно повлияло на скорость работы и не позволило выполнить обещанный объем в срок».

Находите время на каждого человека

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

Научитесь признавать свои ошибки так же открыто, как вы признаете ошибки коллег

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

На последнем проекте я попала в сильную команду с сильным менеджером, который пользовался колоссальным авторитетом у людей. Мне очень хотелось не ударить в грязь лицом перед ним и командой. Это привело к тому, что, работая со статус-апдейтами для клиента, я с умным видом записывала апдейт и потом передавала его клиенту, но при этом не понимала, где проблема и как мы ее решаем. Соответственно и клиент по итогу не понимал. Это приводило к дополнительным раундам выяснений, потери времени и моего, еще даже не заработанного, авторитета. Я была вынуждена признать, что не понимаю многих базовых вещей. Удивительно, но конца света не произошло.

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


Иллюстрации Дарии Филипповой

👍НравитсяПонравилось22
В избранноеВ избранном3
Подписаться на автора
LinkedIn

Похожие статьи



26 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Не розкрите головне питання: як донести до свого ПМа ці істини. ) Особливо перші дві.
Виглядає так, що ті менеджери хто читає такі статті скоріш за все і так це розуміюють. А ті хто не читає... навіть не знаю, бігти чим далі з таких проектів?

Отправьте ему случайно ссылку на статью;) Если не поможет, меняйте менеджера)

Адекватний підхід, коротко і ясно. Дякую за цікаву статтю! :)

К слову, PМ был абсолютно не техническим человеком, поэтому его комментарии несли околобессмысленный характер.

Вьетнамские флешбеки с некоторых прошлых мест работы (-___-)

Неплохая статья, местами есть здравые мысли, но никак не могу согласиться с Истиной номер 1. Все дело в том, что именно Проектный Менеджер несет всю ответственность за ход и успешность проекта, именно поэтому он назначается главным на проект и последнее слово всегда за ним. Задача ПМ именно управлять, а тут без формальной авторизации ну совсем никак. Судя по всему вы хоть и прочитали много книг со словом «менеджмент» в названии, но пропустили самую главную — Project Management Body of Knowledge. Но в любом случае спасибо вам и удачи.

Мне ближе когда ПМ является не просто формальным «главным», а все же становится лидером. Но я признаю тот факт что потребности разных проектов и компаний могут требовать «формального» главенства.
Спасибо за конструктивный фидбек)

В вышеупомянутой книге, еще говорится, что она про проектный менеджмент. И проджект-менеджер таки не главный. Он с натяжкой главный конкретно в управлении проектом, но тоже скорее характеристика: accountable лучше отражает. А главный — неглавный это вообще не совсем про проджект-менеджмент. Если что, если вы действительно руководствуетесь ПМБОКом в ведении проектов, у вас там должен быть документ, в котором написано кто кому лайн-менеджер, спонсор, (этот товарищ, кстати, скорее подходит под определение «главный» в рамках проекта) или еще какой стейкхолдер.
В статье надо просто заменить слово «ПМ» на «ПМ из украинского аутсорса» и будет ок. Это не негативный отзыв, если что :)

так я и не говорю что ПМ это «Главный главный» ) Я конкретно аппелировал к этой фразе из статьи — «менеджер — не главный человек на проекте», он таки главный человек. И спонсор/овнер/чемпион и т.д. тут не причем, мы же конкретно обсуждаем в статье сторону истолнителя, т.е. команда, которая проект выполняет. И да, Project Charter это документ формально авторизирующий ПМа на проект, но это как раз уже детали. Я думаю автор в статье лишь подчеркнул, что одним формальным лидерством (документальным) вы не можете гарантировать успешность проекта, нужно работать над неформальным лидерством, чтобы легче было мотивировать команду.

Как разработчик повидавший очень много менеджеров, могу сказать что чем чаще менеджер ощущается как главный — тем хреновоее этот менеджер. В общем-то, «главный» это такой инструмент решения конкретной проблемы, класс которых вы должны были решить грамотно встроенными процессами, но не справились. Что, в общем-то нормально — все делают ошибки. Но менеджер который каждый день на проекте главный — 100% хреновый менеджер

это нормально, просто вам больше по душе менедмент в стиле servant leadership. Это отлично работает, но, толькое сли команда сформировалась давно и уже на 4й стадии (Performing). Когда проекти команда новая такой подход может привести к краху проекта.

Не имею компетенции с вами спорить о периоде когда вся, или почти вся, команда на более ранних стадиях, но точно соглашусь что правила там другие. Позволю только уточнение что servant leadership возможен на расширении команды, то есть когда меньшая часть команды проходит через более ранние стадии — лично видел успешные примеры. Хотя, конечно, это требует от менеджера и других членов команды дополнительных усилий и особых действий, уникальных для этого периода. Особенно от менеджера

Олексій, думаю автор мав на увазі що при керуванні проектом краще мати ситуацію коли менеджер приймає менше рішень а більше розставляє пріорітети і прояснює обмеження. Кількість різних рішень на проекті дуже велика і кількість факторів які впливають на рішення також велика, багато з них вимагають специфічної експертизи. Тому прийняття рішень менеджером звучить нереалістично через обмеженість його ресурсу. Звісно менеджер може прийняти рішення і без повноти картини, але цінність таких рішень менша.

«Как PM за 5 лет я смогла поработать с разными проектами» — нужно профиль в Li поправить, там <4 лет :)

Официально (с трудовой книжкой и прочим) я работаю 4, не официально 5)

исправьте пожалуйста ошибки, они оскорбляют чувства грамотных©. приводило к потери бюджета

Обязательно обращусь к вам за помощью когда буду писать следующую статью)

виправили, дякую за уважність :)

Занимательные тезисы :) интересно было бы узнать, как Вы строите свой день помимо 15-минутных дейли, чтобы придерживаться этих пунктов

С помощью кофе)
Утром стендапы, дальше работа с информацией + беклог. Это при условии что за ночь не упал Прод)

Статья очень крутая:)) можно это в массы ?? «Никто в здравом уме не будет специально оттягивать решение проблемы, чтобы заставить кого-то страдать. Сделайте так, чтобы ваша команда это понимала.»

классная статья, мне понравилась. а то у многих видиние, что ПМ — господь боженька всевышний.

видиние

Ваш комментарий оскорбляет чувства грамотных)

а то у многих видиние, что ПМ — господь боженька всевышний

То ваши поклонники, желающие, чтобы вы доминировали над ними почаще. Я не любитель БДСМ, но в чем-то понять их могу)

Секретные правила, о которых не пишут в книгах звучат как часть выдержки из примерно любого leadership тренинга. «Интернет взорвался, когда у Лолиты под юбкой нашли ЭТО!!!»

Я буду признательна если вы порекомендуете подобные курсы)

www.vitalsmarts.com/influencer-training например (этот и соседние). Есть и на юдеми, но по частям, у провайдера просто программа цельная

Спасибо, интересно, посмотрю))

Подписаться на комментарии