Привет, на связи RANX, и эта статья - первая в рубрике “Будни проект-менеджера”.
Это небольшой цикл (а может, и большой - мы еще не решили) историй о рутине начинающего менеджера проектов. Возможно, кто-то узнает в этих историях себя на старте карьеры, а кто-то из программистов и дизайнеров проникнется работой коллег.
Мы расскажем о роли проект-менеджера в создании и развитии интернет-проектов. Рассмотрим его типовые задачи, проблемы и вместе подумаем, как можно было бы их решить.
Готовы? Поехали!
Знакомьтесь, это наш герой - Петя. Он уже несколько месяцев работает менеджером проектов в небольшой, но активно развивающейся IT-компании.
Петя счастлив: он потратил много сил и времени на привлечение клиента, и после долгих переговоров ему удалось договориться о сотрудничестве.
Проект - сложный интернет-магазин. После очередного разговора с клиентом Петя понял, что просто оценить объем работ и начать разработку не выйдет: требования клиента нечеткие, границы проекта обозначить не получается. Петя понимает: нужно проектирование.
Предложив услугу клиенту, он слышит в ответ: “Мне это не нужно, мы с вами обсудили проект - начинайте работу”. Опасаясь негатива, Петя ставит задачи программисту и дизайнеру в точности так, как сказал ему заказчик.
В итоге через несколько месяцев кропотливой работы Петя представляет заказчику результат и ... получает негативную реакцию и требование возврата денег! Как же вышло, что клиент остался недоволен работой? Что пошло не так?
Петя обращается за помощью к руководителю, а после отправляется на тяжелые переговоры.
Пока он общается с клиентом, мы с вами проведем небольшую работу над ошибками и подумаем, какие решения менеджера привели к негативу со стороны клиента и как можно было бы их избежать.
Ошибка №1
Петя не отработал типовое возражение клиента.
Решение: работать с возражениями клиента (рассказывали об этом тут и тут).
Ошибка №2
Вытекает из первой: Петя пошел на поводу у клиента и согласился на разработку сложного интернет-магазина без проектирования.
Решение: Пете нужно было донести до клиента пользу проектирования (об этом расскажем далее).
Вопрос читателям:
Какие еще шаги помогли бы Пете избежать негативной реакции клиента и качественно выполнить поставленную задачу? Напишите об этом в комментариях.
Как сделать клиента адептом проектирования?
Аргументы в пользу того, что проектирование - это пустая трата денег и времени, можно часто услышать от заказчиков. И это нормально!
Задача менеджера - помочь клиенту увидеть в проектировании пользу. Рассказываем, как это сделать.
У самурая нет цели, есть только путь
...а путь самурая – это смерть.
Идти без цели равнозначно гибели. Чтобы создать действительно качественный продукт, который будет работать на клиента, нужно обозначить цель, поставить задачи, провести подготовку и наметить путь реализации проекта. Все эти этапы являются частью проектирования.
Конечно, проектирование для клиентов - это дополнительные время и деньги, потому что для выполнения столь крупного объема работ нужно время специалиста (а порой много времени). И оно должно оплачиваться. Но эти расходы - ничто в сравнении с теми неприятностями, которые могут возникнуть при разработке сложного проекта без проектирования (как и получилось у Пети).
Проект без проектирования в продакшене ждут одни неприятности.
Затягивание проекта
Запуску проекта будут мешать бесконечные согласования, доработки и правки, которые обязательно возникнут, потому что на старте проекта не были изучены рынок, ЦА, конкуренты, не была спланирована структура.
Бесполезные траты
Грустно в процессе разработки или, еще хуже, после запуска проекта осознать, что вы сделали совсем не то: пользователям нужен функционал, о котором вы даже не думали, дизайн их не привлекает, сайт не решает своих задач. А деньги и время потрачены.
При отсутствии этапа проектирования понимание того, что и как нужно делать, зачастую появляется уже в процессе разработки. Но когда какая-то часть проекта уже реализована, заказчику может дорого обойтись даже относительно простая доработка.
Ожидание ≠ реальности
При проектировании почти непрерывно ведется коммуникация с клиентом. Это помогает обеим сторонам выстроить общее понимание того, каким будет проект. Без проектирования каждая сторона может быть "на своей волне", и в итоге заказчика и исполнителя может ждать неприятный сюрприз в виде несовпадения ожиданий и реальности.
Устаревание функционала
Из-за бесконечных правок релиз проекта может отодвинуться на неопределенный срок, что повлечет за собой устаревание уже созданного функционала, который даже не успеет отбить потраченный на реализацию бюджет.
Вывод
Если бы Петя грамотно отработал возражение и объяснил заказчику пользу проектирования, можно было сберечь бюджет, время и нервы.
Не повторяйте ошибок Пети: в переговорах будьте решительнее, уделяйте время отработке возражений и грамотно оценивайте ожидания клиента и риски, с которыми вы можете столкнуться при разработке. Предусмотрите возможные неприятности сегодня, чтобы снизить риски при разработке и избежать негатива клиента завтра.
