Как быть хорошим менеджером и не разочаровать команду
Японцы любят говорить: «Кому не удалось подняться на гору Фудзи — тот дурак. Тот, кто поднялся на гору Фудзи дважды, — ещё больший дурак».
Успев побывать менеджером нескольких крупных проектов, я часто думаю о себе в том же ключе. Столкнувшись с проблемой впервые, поднимаешь голову и говоришь: «Зато я получил ценный опыт». Столкнувшись с ней же второй раз, думаешь: «Ну ё-моё, вот я дурак». Поэтому сейчас я живу с мыслью, что есть hard skills, есть soft skills, а есть опыт. Эта мысль заставила меня собрать вместе важные привычки, которые появились благодаря опыту. Я решила поделиться им с вами: где-то с конкретными примерами, а иногда и без них, если они не нужны.
Не думайте, что первая версия вашего продукта будет и последней
Когда мы считаем, что запускаем идеальный продукт, мы либо ошибаемся, либо уже опоздали и пользователи хотят что-то лучше. О том, какой вариант решения будет наиболее подходящим, могут сказать только клиенты. Заранее запустив MVP на рынок, мы сможем получить верную обратную связь и работать, опираясь на данные, а не на гипотезы. Ведь они ничего не стоят без своевременной проверки.
В качестве примера приведу свою работу над MVP в сервисе Wistory.io, который позволяет брендам показывать истории в приложении или на сайте, как сейчас это делают Сбер, МегаФон и другие компании. Глядя на конкурентов, мы самозабвенно строили интеграцию с Instagram, будучи уверенными, что клиентам важно их синхронизировать. Но практика показала, что у клиентов уже есть Instagram. Брендам нужны не просмотры историй, а работающий инструмент для продаж. А сколько историй при этом увидят пользователи — не так важно. И чтобы это понять, даже не надо было делать MVP — достаточно выйти на рынок с продажей этой фичи и оценить спрос.
Компромиссы — не всегда лучший выход
Здесь пойдёт речь не о банальном «слушайте команду». Очень легко идти на компромисс, когда всё хорошо. Даже нерадостные новости в духе «прототип не прошёл исследования, market fit не подтверждён» — это часть рабочего процесса. Если вы ещё ни разу не ошиблись — значит, вы тестируете слишком очевидные гипотезы.
Представьте другую ситуацию. Вы давно ведёте проект, запустили прототип, MVP, потом пару новых релизов. Проект постепенно выходит из этапа, когда всё руководство смотрело на него с восхищением. Ему уделяется всё меньше времени и ресурсов. Появились новые проекты-звёзды, на которых вам ещё не довелось поработать. Другими словами, проект рискует превратиться в долгострой. Что делать? Договариваться.
Правда в том, что если вы выйдете из этих переговоров победителем (например, убедите руководство финансировать проект в полном объёме), то подниметесь на новую ступень менеджмента. Договариваться о проекте, в котором все заинтересованы, проще простого. А гнуть свою линию, несмотря ни на что, гораздо сложнее.
Вспоминаю о нашем проекте в EdTech — makelove school. Больше года мы не могли найти точки для масштабируемого роста, поэтому школа дважды выносилась на суд компании, её надо было замораживать. Но у проекта было двое ярых сторонников: проджект-менеджер и креативный директор. Они убедили поставить школу на «испытательный срок», за который проверили свою догадку — перевели проект на онлайн-платформу и модульную схему обучения. Школа до сих пор работает в новом режиме. Рисковали ли они? Безусловно.
Доверяйте команде и сделайте так, чтобы она доверяла вам
В начале года я решила поработать с коучем. Это помогло мне расставить приоритеты, чтобы преследовать не только интересы команды, но и собственные. Я стала развивать персональный бренд, публиковать статьи о кейсах с моим участием, зарегистрировалась в LinkedIn.
Это был тяжёлый месяц, когда наши отношения с руководством стали натянутыми. Мне потребовалось время, чтобы понять, что мои руководители ждут новости, что я ухожу от них. Всё исправил честный рассказ о том, что же происходит на самом деле. После этого я поняла, что и сама часто сомневаюсь в сотрудниках по надуманным причинам. А можно было просто поговорить.
Сделайте так, чтобы каждый хорошо понимал, чем он занимается
Ситуация, которая ярко показывает, что люди не понимают, кто чем занимается, — это когда менеджер увольняется. Сейчас становится нормой ещё 2–3 недели после ухода поддерживать команду, терпеливо объясняя, как что делать и где что найти. Внимание — это здорово, а вот то, что вы не построили этот процесс раньше, — плохо.
У многих менеджеров есть подсознательное желание вовлекаться во все процессы команды, чтобы ощущать свою значимость. Результаты плачевны: менеджер становится бутылочным горлышком, команда не умеет решать проблемы сама, а отсутствие менеджера останавливает вообще всё. Ну и главное: пока вы не подниметесь над процессом, вас никто не повысит. Потому что попытка забрать вас из проекта ставит его под угрозу — куда они без вас?
Не вносите изменения в проект слишком легкомысленно
Я — тот человек, который на своей шкуре ощутил, каково столкнуться с отсутствием документации и какими могут быть последствия. Я пришла на новый проект вместо уволившегося менеджера и не нашла практически никакой документации об изменениях, которая помогла бы мне разобраться в происходящем. Только к концу первого месяца работы я узнала и смогла описать всю ключевую информацию.
Я как следователь воссоздавала историю изменений по кусочкам. И вот что из этого вынесла:
- Не стоит удалять или изменять функциональность, не разобравшись в контексте использования (вероятно, вам вскоре придётся возвращать её).
- Не стоит изменять функциональность, которая описана в задаче, не пообщавшись с командой. Даже если вы знаете решение лучше. Функциональность, которая отличается от описанной в документации, — бомба замедленного действия.
- Популярные фреймворки работают уже потому, что любой менеджер с грейдом middle и выше сразу сможет их прочитать. Храните верхнеуровневую документацию в них (речь про Lean Canvas, CJM, AARRR и подобные).
Не начинайте проект, если ещё на старте очевидно, что для его завершения не хватает ресурсов
Заведомо провальные проекты станут тяжёлым испытанием. Они либо будут заморожены, когда в них перестанут верить, либо команда будет работать через силу, а после вы её потеряете. Безнадёжные проекты редко кладут в портфолио — вы не будете ими гордиться. Зачем вам это?
Не бойтесь уйти из проекта, если видите, что руководство ведёт себя неразумно
Для большинства руководителей разработка ПО — вопрос сомнений и веры.
Первая компания, где я заняла должность продакт-менеджера, занималась розничной торговлей. Я пришла с конкретной задачей: запустить онлайн-продажи и превратить разрозненные сайты в единый маркетплейс. И самой непростой работой было получить согласие владельцев сети на что бы то ни было. Исследования, тестирования — всё без сомнения резалось ради сокращения бюджета. Сеть экономила на команде.
Я уверена, что у каждого менеджера есть похожая история личной борьбы за истину.
Более чем за два года я успела дважды поработать с некомпетентными людьми. Мы завершили сайт (упрощённую версию) лишь с третьей командой, потеряв год и огромные деньги. После релиза я ушла из компании, потому что чувствовала своё бессилие. Теперь на собеседованиях я обязательно спрашиваю работодателя о приоритетах и подходах компании к разработке. Разумная экономия важна, экономия вопреки всему — нет.
Проводите регулярные совещания для обсуждения хода разработки, но не затягивайте их больше чем на час
Статистика показывает, что на собрания длиной 30 минут люди соглашаются в два раза чаще, чем на часовые и полуторачасовые. Нет риска не успеть сделать свои дела: порешали вопросы и разошлись. Кроме того, при частых собраниях люди привыкают приносить на них регулярные новости и собирают мысли в кучу, чтобы успеть обсудить их всей командой. Еженедельные планинги — это дедлайн, к которому все чистят пёрышки.
Не требуйте от джунов невозможного: они пришли научиться этому у вас
Сейчас в IT-индустрии стало принято даже джуниоров брать с образованием и опытом от 6 месяцев. Причина в большой востребованности индустрии: компании задают правила, и это позволяет многим менеджерам ждать от джунов самостоятельной работы. Я сама радуюсь, когда нахожу сообразительного студента. Но нужно уметь брать на себя ответственность и за своё доверие в том числе.
Да, они будут делать работу хуже и дольше, чем это делаете вы. Вы никогда не сможете передать им 100% своих знаний. Да, они не несут ответственности за ключевые решения и будут теряться при заказчике, консультанте, даже HR-директоре. Это нормально, и им нужна ваша забота. Зато именно из таких вырастают самые лояльные сотрудники — ведь за вложения в них они будут вам «должны». Но нужно помнить, что и такие сотрудники рано или поздно уходят, и не стоит их в этом винить. Скорее всего, так же когда-то уходили и вы.
Отдыхайте после больших релизов или перед началом крупного проекта
Знаю, что в такие моменты может казаться, что вы бодры, возбуждены и готовы перформить. Но это чаще всего не так. От работы в режиме нон-стоп мотивация и работоспособность снижаются. Из-за этого мы не успеваем придумывать нестандартные решения.
Как-то раз мы разрабатывали стратегию для Х5 Retail несколько месяцев, и каждая новая итерация нам не давалась — команде и мне самой не нравилось то, что получалось. В итоге мы взяли паузу почти на месяц, после неё вернулись и за один подход доделали. Это как в игре, где никак не можешь пройти уровень, а спустя время быстро проскакиваешь его.
Не забывайте о себе и личной жизни
Только когда есть на что отвлечься, мозг отдыхает. Работа не должна оставаться единственным, что у вас есть на свете. Ведь тогда все проблемы проекта будут фатальными жизненными сложностями для вас. Здесь я не буду приводить примеров, к этому каждый должен прийти сам.
Спокойствие — залог стабильности. А только стабильность позволяет сделать разработку непрерывной и улучшать продукт с каждым новым шагом. А проблемы… случаются. Встаём, разбираемся, идём фиксить. Иногда посреди ночи :)