5 правил менеджмента, о которых не пишут в книгах
Как PM за 5 лет я смогла поработать с разными проектами, командами, стейкхолдерами и начальниками. Пройдя путь от чтения абсолютно всего, где написано «менеджмент», и просмотра всех роликов на Udemy до изучения узкопрофильных блогов, я осознала, что о ключевых правилах работы PM’а не пишут нигде. Так, чтобы и кратко, и понятно, и по делу. Решила поделиться своими правилами, или истинами, как я их называю, и облегчить жизнь многим начинающим и не только PM.
Эта статья довольно провокационна, и местами будет обидно и неприятно узнавать себя, но она поможет вам и команде стать лучше, если возьмете на вооружение хотя бы некоторые истины.
Истина № 1. Вы не главный
Вопреки распространенному мнению, менеджер — не главный человек на проекте. Ваше слово — не закон, и ваше мнение не важнее всех остальных мнений.
Менеджер — это человек, чья зона ответственности и полномочий немного шире, чем остальных участников команды, но это не делает его главным.
Как менеджер проекта вы можете стать лидером группы, если будете принимать правильные решения, или «неприятным дополнением», если ваши решения будут неправильными. Разница между первым и вторым в том, что второго терпят, а первого боятся потерять.
Однажды друг пожаловался мне на своего PМ’а с формулировкой «когда она заходит в комнату, становится душно». После череды вопросов, чем обусловлено такое отношение к менеджеру, я выяснила, что его PМ обладает интересной особенностью встревать в абсолютно любой разговор и выражать свое мнение, активно перебивая других участников диалога. Стоит ли говорить, что такое поведение напрочь отбивает желание обсуждать любые вопросы в присутствии менеджера? К слову, PМ был абсолютно не техническим человеком, поэтому его комментарии несли околобессмысленный характер.
Чтобы понять, какую же роль вы играете на проекте, задумайтесь, какие проблемы помогаете команде решать? Как часто вам приходится настаивать на своем решении, используя формулировку: «Я менеджер, и мне виднее, что нужно клиенту»? И как часто к вам обращаются за советом во время работы?
Если хотя бы на некоторые из этих вопросов вы получили неудовлетворительный ответ, то читайте статью. Дальше я поделюсь секретом, который помог мне в свое время завоевать доверие команды и заделиверить огромный скоуп работы в два раза быстрее, чем ожидалось.
Истина № 2. Не мешайте
Лучшее, что вы можете сделать для своей команды, — это не мешать ей работать.
Звучит неприятно, потому что каждый из нас, а особенно менеджер, хочет чувствовать себя незаменимым на проекте. И это, к сожалению, самая главная ошибка.
Вам кажется, что без вас команда точно не успеет сдать работу вовремя, а отданный билд будет разломан. Что на продакшене точно что-то сломается и клиент откажется за это платить. Поэтому вы старательно собираете статусы, интересуетесь каждой проблемой в деталях, контролируете каждый потраченный час, но правда в том, что если ваша работа забирает больше 15 минут времени команды — вы ей мешаете. 15 минут — это длительность дейли-митинга, который, я уверена, у вас есть.
В вашей команде работают умные люди, они знают, что нужно сделать, куда обратиться и как написать код, чтобы решить проблему.
К примеру, я никогда не вовлекаюсь в процесс непосредственной разработки требований, вся коммуникация с бизнес-аналитиками, тестировщиками и другими участниками разработки является ответственностью команды разработки, а значит и решение конфликтов и всех вопросов, связанных с определенным требованием, — это ее ответственность. Мы взращиваем в людях культуру Delivery Ownership. То есть мы не пишем просто код, мы предоставляем сервис. Когда люди чувствуют ответственность за свою работу, это повышает осознание их собственной ценности. Ваша задача сделать так, чтобы каждый ощущал: я играю важную роль в проекте.
Хорошей практикой будет создать матрицу компетенций проекта, где перечислены все участники и напротив каждого человека написана его основная экспертиза или домен, с которым он работает. Это поможет командам быстрее находить нужных людей и адресно решать любые проектные вопросы, что сэкономит уйму времени.
Как только вы становитесь ключевым участником решения проблемы, то обрекаете команду на неудачу. Вы не даете людям ответственность принимать решения и работать с последствиями, убиваете инициативу и не даете расти профессионально.
Поэтому основная задача — сделать так, чтобы процессы в команде от вас не зависели. Такой подход потребует времени и работы с людьми, но именно в этом и заключается ценность менеджера. Ну а начать стоит с отношения к проблемам.
Истина № 3. Учите людей работать с проблемами, а не с кодом
Неожиданно, правда? Ведь программисты пишут код, а менеджер решает проблемы. Если вы так думаете, то, скорее всего, часто сталкиваетесь с проблемой приоритетов на проекте.
Например, у клиента не работает кнопка регистрации в живом сайте, а ваш разработчик решает совершенно другую архитектурно важную проблему. При этом он совершенно не понимает, почему вы так недовольны тем, что задача, которую вы дали ему утром, еще не выполнена. Ведь там «работы на 5 минут» и он успел бы сделать ее перед уходом домой.
И дело не в том, что программист безответственный или специально бойкотирует работу. Суть в том, что проблема важна только в вашей картине мира, вы понимаете, что сейчас происходит у клиента, сколько пользователей он теряет. И с этими данными уже подсчитали потерянную прибыль и, конечно, определили репутационные риски.
Вы понимаете приоритет задачи, потому что смотрите на проблему глазами конечного пользователя. Когда люди смотрят на задачу через призму того, что каждая задача — это решение чьей-то проблемы, они совершенно по-другому расставляют приоритеты.
Никто в здравом уме не будет специально оттягивать решение проблемы, чтобы заставить кого-то страдать. Сделайте так, чтобы ваша команда это понимала.
Истина № 4. Поощряйте людей делать ошибки
На этом моменте вы подумали, что у автора не все в порядке с головой. Ведь зачем на проекте нужен менеджер, если не для того, чтобы предотвращать проблемы?!
Да, вы правы, но не все ошибки нужно предотвращать, многие из них дают команде бесценный опыт, который сделает их работу качественнее и тем самым повысит профессионализм. А команда профессионалов — это ведь именно то, чего вы хотите?
Так дайте людям делать ошибки, которые помогут им расти. Не бегите решать каждую их проблему, если, конечно, она не сорвет сроки, которые вы уже пообещали клиенту. Это репутационные потери, которые вам не нужны.
В начале своего пути я работала в компании, где вся коммуникация с клиентом проходила только через менеджера и он по сути был посредником между командой разработки и клиентом. Компания занималась разработкой медиаконтента, и для таких проектов важно, чтобы все участники были на одной волне. К сожалению, это происходило далеко не всегда, так как люди, которые непосредственно воплощали идеи заказчика в реальность, не имели никакой связи с ним. Это нередко приводило к недопониманию, бесконечным правкам, овертаймам, потере бюджета и так далее.
Такая политика была обусловлена тем, что многие члены команды имели базовый уровень английского языка, и руководство боялось потерять клиента из-за этого, но по итогу теряло еще больше уже в процессе сотрудничества.
Ваша задача как менеджера предоставить людям ответственность и возможности принимать решения, совершать ошибки и исправлять их.
Вы наверняка подумаете, что у вас есть отличный инструмент для работы с ошибками — ретроспектива. Но она не сработает. Если вы основной источник решения проблем для команды, то ретроспектива — бесполезная трата времени. Для ретроспективы важен обмен опытом, позитивным или негативным. А поскольку вы решаете все проблемы, то забираете у людей этот опыт.
Истина № 5. Ваши люди — ваша ответственность
Успех команды и людей во многом зависит от того, как вы выстроите работу внутри коллектива и с каждым его участником. Для себя я вывела несколько правил, которыми поделюсь с вами.
Не избегайте трудных диалогов
Они преследуют нас ежедневно. Когда нужно аргументировать отказ в рейзе, когда приходится не закрывать испытательный срок по результатам работы, когда вы просили предоставить статус-апдейт вечером, а получили его на следующий день, когда ваш технический лид прекрасно пишет код, но совершенно не умеет расставлять приоритеты.
Нам приходится говорить людям неприятные вещи, чтобы помочь им и проекту стать лучше, но, к сожалению, иногда мы закрываем глаза на мелкие недоработки, чтобы лишний раз не портить взаимоотношения с командой.
И это нормально, но это не идет на пользу ни вам, ни коллегам. В свое время мне очень помогла книга «Трудные диалоги», и я до сих пор держу ее на столе и читаю, когда предстоит трудный разговор.
Говорите людям правду, подтвержденную фактами
Это правило вытекает из первого. Зачастую трудный диалог предстоит вести после событий, которые, по вашему мнению, имели негативное влияние на проект и качество работы.
Любой фидбэк можно оспорить, если он базируется на оценочном мнение, а не на фактах. Разницу наглядно видно в следующих двух предложениях.
«Олег, мне кажется, в этом спринте ты работал слабовато, поэтому мы не успели сдать проект вовремя».
«Олег, в этом скоупе ты сделал 5 задач из запланированных 8, и в 3 задачах были найдены критические баги, поэтому тебе пришлось потратить время на их исправление, что сильно повлияло на скорость работы и не позволило выполнить обещанный объем в срок».
Находите время на каждого человека
Ситуации, описанной выше, могло бы не произойти, если бы у вас нашлось время поговорить с Олегом и узнать, что недавно у него родился сын и, помимо работы, он помогает жене по хозяйству. Зная эту информацию, вы могли оперировать рисками и учесть, что продуктивность сотрудника в этом скоупе будет ниже.
Научитесь признавать свои ошибки так же открыто, как вы признаете ошибки коллег
Менеджер не всегда прав. Мы привыкли проводить ретроспективы и обсуждать ошибки и недочеты разработчиков, но мы никогда не говорим о собственных и тем самым теряем мощный инструмент для построения доверительных отношений. Никто не идеален, и вы тоже, научитесь это признавать.
На последнем проекте я попала в сильную команду с сильным менеджером, который пользовался колоссальным авторитетом у людей. Мне очень хотелось не ударить в грязь лицом перед ним и командой. Это привело к тому, что, работая со статус-апдейтами для клиента, я с умным видом записывала апдейт и потом передавала его клиенту, но при этом не понимала, где проблема и как мы ее решаем. Соответственно и клиент по итогу не понимал. Это приводило к дополнительным раундам выяснений, потери времени и моего, еще даже не заработанного, авторитета. Я была вынуждена признать, что не понимаю многих базовых вещей. Удивительно, но конца света не произошло.
Если вы прочитали эту статью до конца и ваш стул еще не сожжен — поздравляю, вы отличный менеджер и ваша команда уверенно движется к успеху. Во всех других ситуациях я рекомендую сделать выдох и критически посмотреть на работу команды. Действительно ли вы делаете все для успеха команды, а не для своего личного?
Иллюстрации Дарии Филипповой
