Junior Project Manager — одна из самых спорных позиций в сфере IT. Считается, если уж ставить человека руководить проектом — это обязательно должен быть опытный управленец, выросший из Middle to Senior разработчика и идеально разбирающийся в технических нюансах. Вот только программисты чаще интроверты, чем экстраверты, а когда в команде 10 синьоров, кто-то должен услышать каждого и принять взвешенное решение. К тому же, разработчики предпочитают расти не в PM, а в тимлиды и СТО.
Что касается технических знаний, согласны, у нас даже есть отдельный курс, который задумывался для того, чтобы PM мог коммуницировать с разработчиком без дополнительных уточняющих вопросов, но в остальном считать, что менеджером не может стать человек без опыта в IT — неправильно. Просто новичков ждут ошибки, всегда, и это так в каждой профессии.
К нам на курс DAO PM приходят ребята с разным бэкграундом, после чего устраиваются на свою первую работу… Факапить и расти. Для этой статьи мы попросили друзей IAMPM, сейчас уже проектных менеджеров с опытом, рассказать о своих ошибках на позиции Junior PM.
Самые смелые PM-ы не постеснялись приоткрыть нам дверцы своих шкафов со скелетами. А мы их отсортировали по косточкам и разбили по категориям, чтобы было интересно и поучительно читать. Сразу предупреждаем: факапы — не всегда что-то смешное, но мы же сюда пришли не только за весельем.
Часть 1. Факапы при работе с клиентами
Клиенты — тоже люди, кто бы что о них не говорил. А люди бывают разными: доверчивыми и подозрительными, справедливыми и предвзятыми, щедрыми и не очень. А еще клиенты бывают со специфическими требованиями, которые находятся за гранью добра и зла. Именно такой персонаж и открывает наш список испытаний для Junior PM-ов.
История 1. Когда от PM-а ничего не зависит
Сейчас эта девушка давно уже успешно работает в IT, но в самом начале своей карьеры она столкнулась с необыкновенным заказчиком, который отказался сотрудничать не потому, что у нее было недостаточно опыта в проектном менеджменте, а просто потому, что она — девушка. И здесь можно было бы сказать, что во всем виноваты мужчины, если бы не один маааленький нюанс: заказчик и сама была дамой из Сингапура.
Вывод: когда дело доходит до рынка IT, эйджизм и гендерная дискриминация имеют место быть (как бы все не говорили о толерантности). Просто смиритесь.
С другой стороны, лучше сразу поставить крест на сотрудничестве, чем работать с клиентом из следующей истории.
История 2. Поучительная
Во времена своей Junior PM юности, один из наших друзей потерял письмо, в котором было утверждение клиента, что надо делать месячную доработку. Клиент оказался из категории суровых бизнесменов, так что после месяца работы над проектом, начал все отрицать.
Вывод: фиксируйте любой вздох заказчика, который касается финансовой стороны, а также изменения и уточнения требований. Иногда полезно вести бортовой журнал проекта, в котором можно быстро найти информацию о важных изменениях, а также прикрепить скриншоты переписки или ссылки. Кстати, диктофон и запись видеозвонков тоже отличные инструменты в борьбе за справедливость. Только предупредите заказчика о том, что вы это делаете заранее, а не постфактум.
Не все заказчики плохие. Иногда они просто не могут внятно донести свои мысли об итоговом видении продукта. Об этом повествует третий кейс.
История 3. Когда PM-у приходится выполнять роль бизнес-аналитика
Эта история об отважном PM-е, который возглавлял команду разработки в их славной битве по проектированию финансового сервиса. Заказчик хотел, чтобы продукт умел всё (или почти всё). Для этого, по мере реализации функционала, он придумывал улучшения и просил их внедрять.
— А давайте добавим модуль бухучета? — генерировал заказчик новую идею.
— Конечно! — PM уже начал декомпозировать задачу на майлстоуны.
Как только модуль бухучета был добавлен, заказчик спешил с новой просьбой:
— Хочу модуль по подсчету KPI сотрудников компании!
— Я знаю, кому это поручить! — отважному PM-у нравился такой подход, понятные задачи, все четко и по полочкам.
От модуля к модулю эти двое все больше понимали друг друга, пока в один прекрасный день заказчик не решил, что мир готов лицезреть его маленький шедевр из мира финансовых продуктов. В этот самый момент проект столкнулся с реалиями рынка: такое решение никто не хотел покупать. Продукт делал очень многое, но не решал проблем потенциальных пользователей. В результате, решение умерло, не получив и сотни клиентов.
Вывод: Конечно, PM не всегда должен исполнять обязанности продакта. Порой аутсорсингу даже на пользу, что клиент делает что-то важное и систематически платит. Денюжки-то капают. Но вот как это потом скажется на репутации менеджера, да и самой компании? Ответ очевиден.
Поэтому лучше не допускать разработки ради разработки. Узнавайте основную цель, по достижению которой проект будет считаться успешным. Своего рода acceptance criteria, но только не для фичи, а целиком для проекта. Тогда, выполняя майлстоуны, можно будет корректировать действия согласно конечной цели. Лучше провалить план и сделать новый, чем провалить проект и полностью его похоронить.
История 4. Трудности коммуникации
Просто перечитывайте то, что вы пишете. Хоть иногда.
PM поговорил сам с собой и еще больше запутал заказчика
Вывод: Лучше задать 1 вопрос и получить ответ, чем смешивать описание ситуации со списком уточнений, тем самым сбивая человека с толку. Отвечая на такое письмо, заказчик может упустить часть вопросов, их придется задавать снова, лишний раз раздражая клиента.
Если в ходе переписки клиент согласится на другое решение, нужно сохранять все его аппрувы, так как случаются ситуации, когда даже факт наличия утвержденного ТЗ может не быть воспринят как аргумент в пользу команды разработки.
Об этом следующий случай.
История 5. Истеричный заказчик
На этот раз нашему другу повезло: душка-клиент с небольшим проектом, который быстро утвердил ТЗ и дизайн, не задерживал платежи и вовремя присылал контент для работы. Через 3 месяца команда сдала проект в срок и приложение оказалось в Google Play. Казалось бы, хэппи-энд, но нет. Ровно через 2 часа после релиза клиент уже обрывал телефон и сокрушался, что на Xiaomi его бабушки 2005 года приложение не запускается.
Заказчик был уверен, что софт будет работать на любом девайсе, а аргумент о том, что в ТЗ была прописана минимальная поддерживаемая версия ОС, он просто игнорировал. Истерика продолжалось 3-4 месяца и здорово портила настроение как руководству, так и проектному менеджеру. Вроде и сделали все правильно, но неверно.
Вывод: Всегда детально обсуждать с клиентом, на каком оборудовании и софте будет работать продукт. Особенно важно проговаривать ожидаемую поддержку версий ПО. Заказчик — не профессионал в разработке и может не знать нюансов. Ценность команды состоит в том, чтобы подсказать ему, какие могут появиться трудности и ограничения.
История 6. А вдруг клиент сочтет меня назойливым?
Всем менеджерам аутсорса знакома ситуация, когда не хочется писать заказчику по мелким вопросам. В то же время, если от его ответов зависит реализация продукта — нужно брать себя в руки и писать / звонить / доставать бедолагу из-под волны важных задач и другого пинга.
Вот же странно? Не отвечает. Может, потому что PM писал клиенту неделю назад?
Вывод: если клиент не отвечает — постарайтесь найти его любыми способами, но не через неделю. А еще поставьте на почту плагин, например, mailtrack — он поможет понять, когда письмо открыли. При случае можно доказать клиенту, что письмо он не просто видел, а еще и открывал несколько раз.
Это в случае, если по каким-то причинам, оперативным каналом общения осталась почта. Лучше, конечно, утвердить с клиентом сценарий, в котором указан порядок действий команды, если она не может продолжать работу без ответов на ряд вопросов.
Например:
- Команда останавливает проект и уходит на другой до выяснения обстоятельств.
- Решение остается за помощником клиента (контактные данные) или за PM-ом, и оно не должно оспариваться впоследствии.
Такой сценарий позволяет компании подстраховаться от непредвиденных простоев.
Часть 2. Факапы при работе с командой
Чтобы статья не получилась однобокой, мы узнали мнение ребят из команды разработки о задачах PM-a, реализация которых вызывает у них максимальное количество грусти и печали.
Боль 1. Овертаймы
На часах 15:45, до митинга с руководством компании осталось ровно 15 минут. PM-у в Telegram прилетает сообщение от клиента: «Ребята, нужно за сегодня пофиксить вот эти баги, т.к. завтра утром показываю продукт инвесторам». PM навскидку решает, что правки займут от силы 2 часа, поэтому пишет заказчику «ок» и отправляется на митинг. На встрече PM узнает о новых задачах и KPI, так что через час полностью забывает об обещанных правках, аккурат до следующего сообщения заказчика.
В 20:00 клиент напоминает о себе: «Как ваши дела, уже можно тестировать?» PM хватается за голову (никто ничего делать и не начинал), извиняется перед заказчиком, и говорит, что все уже делается, но задача оказалась сложнее, чем казалось вначале.
После этого весь вечер вся команда посвящает багфиксу. При этом команде менеджер говорит, что заказчик со своими правками появился только сейчас и не заплатит, если теперь они быстро не пофиксят баги.
Вывод: ставьте будильник, наклеивайте стикер на ноут, создавайте задачу из 2 слов с дедлайном через час, но не вынуждайте команду работать сверхурочно, если есть хоть малейшая возможность так не поступать. А еще — не врите. Это историю нам рассказал не PM, а разработчик, который в общении с клиентом случайно выяснил правду о том, когда на самом деле поступила задача по багфиксу.
Боль 2. Как насчет взять на себя немного ответственности?
Следующая печальная история случилась с PM-ом, который, очевидно, только начал вникать в детали проекта и не до конца разобрался с тем, что происходит вокруг.
Вывод: Если PM работает на проекте — пусть об этом помнит… и не забывает поднять проект.
В команде у каждого есть свои роли и все друг от друга ожидают соответствующего поведения. Но если руководство решило не посвящать PM-а в процессы компании, а он еще слишком юн и стесняется задавать лишние вопросы, то вышеописанная ситуация может случаться. Парочка подобных переписок поможет PM-у освоиться на новом проекте, но лучше бы о своих обязанностях знать заранее.
Боль 3. Когда PM живет в своем вымышленном мире
Команда будет лояльнее относиться к PM-у, который называет вещи своими именами: стадион так стадион, мокап так мокап. В противном случае нормой могут стать сообщения следующего вида:
Вывод: с командой лучше быть на одной волне, так и задачи становятся понятнее, и обратная связь содержательнее. Продавать мокап за дизайн — это специализация совсем другого направления (например sales отдела), но сегодня не об этом.
Часть 3. Как никогда не ошибаться
Никак. Даже если впитать опыт всех проектных менеджеров на свете, окажется, что именно сегодня появился заказчик с уникальными, невиданными доселе заскоками. Зато, опираясь на чужой опыт, можно получить общее представление о том, что же такое проектный менеджмент и так ли он подходит желающим «войти в IT». С этой целью мы создали спецпроект «Выживание PM-a», где рассказали об основных категориях заказчиков, разнице между фреймворками на примере палаток в лесу и собрали базовые советы новичкам. Проект развивается силами Выживших PM-ов, которые делятся своими историями и вносят лепту в общее дело.
Менеджеры, помните, вы не одни!
