При определении объема проекта, как я могу зафиксировать требования к маркетинговым функциям, чтобы обеспечить успех проекта? - PullRequest
0 голосов
/ 07 ноября 2008

В ситуации, когда проект инициирован маркетинговой или сбытовой командой, как мы можем принять не столь очевидные требования, чтобы проект был рыночным или даже лучше саморекламным?

Во многих случаях отдел маркетинга / продаж едва ли может перечислить функциональные характеристики того, что должен делать проект, не говоря уже об описании функций для отслеживания и улучшения показателей эффективности. Увидев успешные проекты, я тем не менее осознаю необходимость не только отслеживать эффективность проекта, но и активно настраивать и продвигать продукт. Что хорошего в новом наборе сделок, чтобы сэкономить деньги клиента, если ни один клиент никогда не узнает о сделках или не найдет их?

Одна вещь, о которой я подумал, чтобы устранить этот недостаток в процессе разработки требований (который превращается в недостаток в процессе развертывания), - выделить часть объема проекта для анализа и продвижения инженерами. в отличие от отдела маркетинга / продаж. Например, для того, чтобы продукт считался запущенным, он должен быть рассмотрен 5% нашей клиентской базы в «бета-режиме» и пройти один раунд оптимизации / настройки. Затем я бы включил в сферу проекта период бета-тестирования и проверки (в дополнение к уже включенному нами периоду обеспечения качества), создание соответствующего опроса и инженерный обзор этого опроса, а затем окончательный запуск с любыми изменениями. , Я понимаю, что это выходит за рамки возможностей типичного технического менеджера по продукту для определения объема проекта, но иногда я чувствую, что должен подойти к делу.

Какие вещи я должен делать? Это может относиться к проектам во многих областях, но область, в которой я работаю, это веб-приложения, поэтому ответы, направленные на эту область, приветствуются. Конечно, не стесняйтесь давать ответы на все поля.

Обновление - пример: недавно мы запустили проект сделок, чтобы пользователи могли получать предложения, которые предоставляют наши отели. При разработке проекта сделок мы не включали RSS-поток предложений для наших клиентов, не обеспечивали регистрацию предупреждений для людей, которые ищут конкретные предложения, и, вероятно, упустили несколько других возможностей, чтобы дать людям информацию о желании / необходимости. в удобном для использования формате. Тем не менее, особенность сделок - это именно то, чего хотят многие люди, и они пропадают, когда приходят на наш сайт. Наши показатели конверсии для сделок в Диснейленд хороши для всех, кто видит предложения, поскольку у нас такие хорошие цены и комбо, но количество людей, которые видят предложения, меньше, так как им нужно знать, что сделки существуют, чтобы их найти.

Ответы [ 2 ]

3 голосов
/ 07 ноября 2008

Прототип рано, прототип часто, и убедитесь, что клиенты смотрят ваши ранние версии.

Если вы работаете в существующей системе, одной из частей решения является регистрация и отслеживание жалоб клиентов и запросов на поддержку. Много раз, это действительно запросы на улучшение, или они могут точно определить болезненные области вашего приложения. Если ваши разработчики не слушают этого, они упускают важный вклад клиентов.

1 голос
/ 07 ноября 2008

Одна вещь, которая приходит на ум, это отправить технического, не социально-неумелого человека с командой продаж как минимум часть времени, чтобы делать заметки.

Он может даже работать над исправлением ошибок, пока он на месте, так что это не потерянное время.

Кроме того, убедитесь, что вы поддерживаете связь с клиентом после , когда отдел продаж уходит, чтобы убедиться, что вы выполняете то, что они просят.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...