Как клиенты убивают проекты: наблюдения менеджера проектов
Всем привет! Меня зовут Абиталиев Марат, я проектный менеджер в компании Webrise и сегодня я хочу рассказать немного об опыте общения с заказчиками и ошибках, которые они совершают при реализации проектов. Идея статьи не нова, но почему-то всегда на практике совершаются одни и те же ошибки и многие проект буксуют на одних и тех же «граблях». Давайте вместе разберем самые частые из них. Вполне возможно данный материал сможет помочь вам сэкономить время, деньги, нервы и даст некоторое виденье того, чего делать не стоит.
Ошибка 1. Хочу все и сразу
Суть ошибки: Заказчик приходит с идеей, которая в голове имеет уже сформированный, сложный и многогранный продукт, хочет сразу и все с формулировкой «сделайте вот как этот «сайт_нейм», только вот со своей фичей» и обязательно «максимально просто и быстро», желательно по цене лэндинга конечно, но об этом чуть позже.
Почему же это ошибка? Попытки реализовать сразу большой, сложный продукт очень рискован, так как почти никогда невозможно исследовать полностью пользовательские пути, масштабирование, архитектуру проекта. Сделать все и сразу обычно приводит к:
- Распылению ресурсов: Команда пытается ухватится за все и по итогу не может сделать качественно все или успеть в срок
- Раздутый бюджет: Стоимость таких продуктов почти всегда недооценивается
- Бесконечные правки и дебаги: В то время пока разрабатывается одна фича, заказчику приходит в голову ~10000000 правок к ней, из-за это функционал часто выходит кривым и приходится делать дебаг.
Решение проблемы: для начала необходимо выделить главную ценность продукта и запускать ее в разработку, так называемый MVP (Минимально жизнеспособный продукт). Далее стоит понять, что такое итеративность разработки, когда продукт развивается постепенно шаг за шагом, этап за этапом. На примере системы управление обучения: сначала делаем функционал обучения в полном объеме (MVP), а только затем инфографики, календарь, личные кабинеты и прочее.
Ошибка 2. Нам нужно вчера! (Классика)
Суть ошибки: Фраза «ну это просто кнопка же» стала уже притчей среди разработчиков. Заказчик не до конца не понимает, что под функционалом кнопки может скрывается множество связей и процессов, изменение которых может повлечь каскад изменений в других местах.
Почему же это ошибка?Самая типичная проблема, которая мне встречалась. Помимо каскада проблем в связи изменениями, можно еще добавить, что ограниченность по времени не добавляет качества, что в дальнейшем послужит причиной массы проблем и багов.
Решение проблемы: Только открытая коммуникация поможет в решении ситуации, любой проектный менеджер должен высказать, объяснить заказчику риски, которые преследует его решение, а также дать оценку команды.
Ошибка 3. Разработчики все сами придумают (Классика)
Суть ошибки: Некоторые клиенты думают, что сайт можно заказать. Но все-таки сайт – это не пицца, его нельзя просто взять и выбрать из меню. Распространён случай, когда заказчик передает задачу и пропадает, не отвечает на уточняющие вопросы или не учувствует в демонстрациях промежуточных результатов, не предоставляет контентные данные вовремя.
Почему же это ошибка? К большому сожалению, команда разработчиков не телепаты. В техническом задании бывают неточности или двусмысленные фразы, без контакта и обратной связи такой проект будет двигаться будто в темноте.
Решение проблемы: Можно выделить ответственного человека, который будет вовремя давать обратную связь, принимать решения и в целом учувствовать в жизни проекта, один из примеров, кстати, я давал в прошлой своей статье *тут можно вставить ссылку*. В продолжении темы, хотелось бы сказать, что просто регулярные созвоны могут творить чудеса.
Хорошие проекты рождаются там, где клиент становится партнером, а не наблюдателем.
Ошибка 4. Экономия
Суть ошибки: Заказчик недооценивает процесс тестирования, предварительного анализа, экономит на исследованиях и думает, что его проект в целом простой и не стоит заморачиваться об этом или в целом не имеет стратегии как будет жить проект в будущем.
Почему же это ошибка?В принципе это относительно прав, но я не просто так отношу это к ошибкам, так как я наблюдал следующие случаи:
1. Заказчик задумывает обычный лендинг, говорит, что в целом ничего сложного и выделяет бюджет, но в процессе до него доходит мысль, что необходимо сделать еще 10 разделов, баннер с анимацией, приветственное видео, личный кабинет пользователя, административную часть кастомную, в конце концов он приходит к тому, что ему нужен трехуровневый портал с CRM и онлайн- платежами.
Отсутствие предварительного анализа привело, к тому, что сроки проекта и бюджет были увеличены в десятки раз. Наша команда не планировала выделять столько времени на этот проект, из-за этого опять же страдает качество, появляется хаос и неопределенность.
2. В случае, когда все-таки заказчик остановится на просто лендинге бывает и такое, что сайт не приносит заявок. Заказчик закономерно удивляется, но это вполне типичная история, на самом деле, ведь сайт — это не украшение, а инструмент. Без исследования целевой аудитории, без понимания, что можно считать результатом, без четкого понимания зачем нужен сайт- любой проект превратится в набор рандомных решений.
3. Но все же самый банальный случай - это когда пренебрегают услугами тестировщика, особенно касается проектов в виде больших систем. Заказчик думает, что сможет справится своими силами или наблюдательностью разработчиков, но только QA-инженер может комплексно проверить сотни сценариев, найти неочевидные ошибки в логике, обнаружить интеграционные проблемы, проверить надежность системы.
Решение проблемы: Первым шагом будет являться внедрение обязательного предварительного анализа и проектирования, смещение фокуса на создание в первую очередь инструмента для бизнеса, а не красивого сайта, обязательное включение QA-тестирования в бюджет и сроки.
Вместо заключения
Уважаемые заказчики, ваша роль в проекте не менее важна, чем роль разработчиков. Вы — владелец видения продукта. Не забывайте и не игнорируйте системный подход к подготовке и разработке продукта. Успех на 50% зависит от того, насколько эффективно мы сможем совместно работать. Будьте открыты к диалогу, доверяйте экспертизе команды и помните, что мы работаем для достижения одной цели — создать для вас качественный и работающий продукт.