Как сформулировать запрос на разработку: руководство для предпринимателей

Привет, я Максим из Sailet. Мы специализируемся на заказной разработке, работаем с 2017 года, выполнили множество интересных проектов, рассказываем про автоматизацию и развиваем свой СЭД.

Постоянно коммуницируя с предпринимателями, знаем, что множество из них тратят огромное количество своего, и не только своего, времени на поиск IT-подрядчика: «чтобы разработать систему». После рассказывают, что на рынке мало спецов, компании их не понимают и вообще все эти студии — «фу фу фу». Решил сделать подробный мануал для всех будущих заказчиков, который, надеюсь, улучшит жизни многих. Поехали!

Цель — указывает направление всего проекта. Если у вас нет понимания, зачем вам нужна эта система, уже на этом этапе можно заканчивать. Проще, чтобы она была конкретной, измеримой, достижимой, релевантной и временно ограниченной (классика, SMART). Ни один подрядчик не сформирует цель за вас, потому что это будет его цель.

1. Определение проблемы или потребности — а что я хочу решить/получить от будущей системы?

2. Определение ЦА — а кто вообще будет использовать мою систему? Сотрудники это тоже внутренняя ЦА. Лидия Михайловна в бухгалтерии и Сергей Федорович на производстве, в зависимости от задачи, могут быть одним сегментом. 20-ти летние специалисты поддержки другим.

3. Анализ рынка и конкурентов — а что у них и как работает? Нужен ли вообще мой продукт? К нам приходило пару десятков запросов на разработку сервиса такси («Брат хочу как яндекс»). Вопросы «зачем?» или «какая цель?», естественно оставались без ответа.

4. Формулирование цели — надеюсь, что SMART уже стал классикой везде. Если вдруг нет, то ответственность за понимание в этот момент на говорящем. Т. е. целью не может быть «хочу, чтобы компания взлетела» или «делаю, потому что у конкурентов есть» или «надо освоить бюджет». Это реальные примеры…

5. Приоритезация потребностей — что важнее именно сейчас? «Хотим автоматизировать всю компанию, сделать единый портал», чаще всего означает, не знаем что хотим, процессы не описаны.

6. Вовлеченность заинтересованных сторон — нужна ли пользователям система? Понятно, что люди в большинстве своем боятся нового, но тут классическое управление изменениями, сначала продаем и доносим ценность, затем внедряем и обучаем.

7. Документация — понятно, что великий «Агил» говорит нам, что работающий продукт важнее исчерпывающей документации, но это не отменяет ее в целом. Ориентир должен быть всегда, а что не написано, то неправда.

Помогает визуализировать вашу идею и раскладывает её по полочкам.

Используйте их для получения обратной связи от потенциальной аудитории, чтобы понять их потребности.

Конечно же, на этапе продажи, когда к нам приходит запрос, если он «наш» мы с вами его формулируем, перекладываем в mindmap, делаем структуру проекта и т. д. Ниже парочка примеров, как это может выглядеть. Оставить заявку можно по ссылке. Делаем не всем, только после квалификации.

Работают на самом деле все форматы, главное уметь их применять.

Давайте рассмотрим три простых примера запросов и почему они могут не соответствовать требованиям качественного запроса.

Слишком общий запрос: «Нам нужен сайт для нашего бизнеса»

Проблема: Недостаток деталей. Неясно, какой тип сайта нужен, какие функции он должен выполнять, кто целевая аудитория.

Запрос без бюджета и сроков: «Мы хотим разработать мобильное приложение для онлайн-курсов»

Проблема: Отсутствие конкретных рамок. Разработчику сложно оценить проект и предложить решения, соответствующие ограничениям заказчика.

Технически перегруженный запрос от непрофессионала: «Нам нужно приложение на React с использованием GraphQL для бэкенда и Firebase для аутентификации»

Проблема: Технологические предпочтения без цели и задачи. Может это вообще пирамида или веб-сервис на «голом Си»?

• Краткое описание вашего бизнеса

Хотя бы название компании. Многие даже это боятся оставить в форме. Мы сами нагуглим)

• Цель проекта

По SMART — высший пилотаж. Но, хотя бы кратенькую

• Описание задачи, которую должен решить проект

• Целевая аудитория, в том числе внутренняя

• Список must-have функций

Прям сильно верхнеуровнево, но тем не менее

• Реалистичный бюджет и временные рамки проекта

«Ищу ERP, бюджет 2000 $» ведет только в самостоятельный open source

• Ссылки на схожие продукты или функции, которые вас вдохновляют

Если есть, конечно же

Название: Компания «Х»
Запрос: ищем команду для создания мобильного приложения, помогающего пользователям формировать и отслеживать ежедневные привычки. Цель — запуск MVP за 4 месяца с функциями создания привычек, напоминаний и аналитики прогресса. ЦА — молодые профессионалы 25−35 лет. Бюджет — до 20 000 $. В качестве примера рассматриваем 'Habitica' и 'Todoist'."

Название: «Обучаем и точка»
Запрос: необходимо создать веб-платформу для курсов повышения квалификации. Задача: обеспечить доступ к обучающим материалам, видеолекциям и тестам с возможностью отслеживания успеваемости. На курсе 1000 студентов. Целевая аудитория — взрослые обучающиеся 30−45 лет. Бюджет проекта ограничен 10 000 $, сроки — до 6 месяцев. Примеры для ориентира — 'Coursera' и 'Udemy'."

Название: ТОО «Сайлет»
Запрос: планируем разработать систему для автоматизации учета запасов для малого ритейла. Хотим упростить инвентаризацию и учет товаров, сократить время на обработку данных для владельцев малых магазинов. Бюджет проекта — до 40 000 $, желаемый срок реализации — 3 месяца. Желаемые функции: сканирование штрих-кодов, интеграция с существующими системами учета, отчетность. Ориентируемся на функционал 'Square' и 'Shopify'."

Это примеры реальных запросов, немного скорректированных и обезличенных.

Фактически, у нас есть две ЦА, с которыми работа строится немного по-разному. Понятно, что пунктов в квалификации в десятки раз больше, но глобально: первые — люди/компании с идеей, вторые — компании с процессами. Поэтому, ниже расписаны 2 этих сценария.

Подробнее про процессы можно посмотреть тут:

Я конечно немного «задушнил» и вам может показаться, что я перекладываю ответственность на вас (будущего заказчика), ведь качественная услуга = сервис. Но, ответственность за успешность проекта всегда лежит на двух сторонах. Если ваш проект не нужен вам на старте и вы не готовы инвестировать в него время, разбираться, что-то там формулировать, то и закончите вы его с вероятностью 1% (указал как стат. погрешность).