Как заказать разработку ПО: этапы процесса от анализа до запуска

Отдел продаж собирает заказы через WhatsApp, склад вносит их в файл Excel, бухгалтерия переписывает ту же информацию в третий раз. Вы посмотрели готовые программы на рынке; ни одна не подходит точно к вашему порядку согласования, правилу скидок или тому, как работают люди на выезде. Вы думаете заказать ПО у разработчика, но ответы на вопросы «с чего начинать, что делать мне, когда система заработает» неясны. Это руководство описывает процесс с вашей стороны, то есть глазами человека, который будет принимать решения.

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

Что такое разработка ПО на заказ и когда она нужна?

ПО на заказ — верный ответ не для каждого бизнеса. Если одновременно есть несколько признаков из списка ниже, вы дошли до предела готового решения:

• Ваш процесс отличается от отраслевого стандарта; порядок согласования, правило цен или форма учета свойственны только вам.
• Чтобы подогнать готовую программу под свой процесс, вы каждый месяц делаете новое дополнение в Excel или ручные исправления.
• Нескольким системам (заказы, склад, бухгалтерия, выездная работа) нужно обмениваться данными друг с другом.
• Разные роли должны видеть и делать разное в одной записи; правило доступа вытекает из процесса.
• Сотрудникам на выезде нужен короткий пошаговый сценарий для работы с телефона.

Этапы разработки ПО: сводная таблица

Как заказать разработку ПО? Процесс шаг за шагом

1. Анализ потребностей: процесс раньше экранов. На первом шаге экраны не рисуют; выявляют цель, пользователей, данные и бизнес-правила. Ответы на вопросы «кто открывает заказ, кто утверждает, в каком случае он возвращается, что считается исключением?» фиксируются письменно. От вас требуется включить в эти встречи человека, который реально ведет процесс; процесс в пересказе руководителя и процесс на месте часто не совпадают. Решение на этом этапе — что войдет в первую версию, а что останется на потом.
2. Проектирование: сценарий использования и архитектура. Какие шаги и в каком порядке будет делать пользователь, какая роль что увидит, где будут храниться данные, с какими системами будет обмен? На этом этапе макеты экранов и техническая структура рассматриваются вместе. Ваша задача — проверить макет, мысленно выполнив в нем свою ежедневную работу: «сколько шагов на этом экране занимает моя самая частая задача?»
3. Разработка: поэтапно, по модулям. Если программа создается частями, каждую часть можно проверить рано. Большой пакет, сданный за один раз, — способ, при котором недопонимание обнаруживается позже всего. На этом этапе от вас ждут быстрой обратной связи по промежуточным версиям и сбора решений в одних руках; разные пожелания трех руководителей незаметно раздувают объем.
4. Тестирование и приемка: проверьте на своих данных. Тестирование — работа не только разработчика. Критерии приемки должны быть записаны с самого начала: «принимаем, когда такой-то сценарий дает такой-то результат». Проверяйте систему не на примерах, а на заказах, отменах и исключениях одной своей реальной недели. Точка принятия решения — выполнены ли критерии.
5. Запуск: от старой схемы работы к новой. Запуск — это не только техническое событие, но и смена привычек. Когда закрывается старый Excel, как переносятся текущие записи и как информируются пользователи, нужно спланировать заранее. Иначе все работают в двух местах сразу и начинается спор, где актуальная версия.
6. Поддержка и улучшение: запустить и измерять. Когда система запущена, работа не заканчивается; реальное использование впервые становится видно на реальных данных. Какой экран пропускают, на каком шаге застревают и какого отчета не хватает, показывает использование. Собрать обратную связь и расставить следующие улучшения по приоритету — ваше решение.

Кто должен быть на вашей стороне на протяжении всего процесса?

Чаще всего программные проекты буксуют не из-за технических вопросов, а из-за пробела в ответственности на стороне заказчика. Четыре роли должны быть названы поименно; один человек может совмещать несколько, но ни одна не должна оставаться без исполнителя:

• Лицо, принимающее решения: тот, за кем последнее слово по объему, приоритетам и приемке. Он должен быть доступен не раз в несколько недель, а при каждой промежуточной версии.
• Владелец процесса: тот, кто ведет работу изо дня в день и знает исключения. На этапе анализа это самый ценный источник информации.
• Представитель конечных пользователей: сотрудник, который будет фактически пользоваться программой на выезде, на складе или в офисе. Именно он скажет, работает ли последовательность экранов на деле.
• Ответственный за данные и системы: тот, кто знает, где лежат текущие файлы, базы данных и другие системы; он адресат вопросов об интеграции и переносе данных.

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

Процесс раньше экранов; пользователи, данные и бизнес-правила раньше списка функций.

Как далеко можно зайти с Excel, WhatsApp и готовой программой?

В небольших командах, при малом числе записей и в работе, правила которой редко меняются, Excel и WhatsApp вполне справляются; к тому же они не требуют никакой разработки. Проблемы начинаются, когда множатся версии, один файл обновляют несколько человек и возникает вопрос «кто, что и когда утвердил». Разграничить права невозможно, историю не отследить, информация остается в телефонах людей. Готовая программа обычно самый быстрый путь, когда ваш процесс стандартен; ПО на заказ имеет смысл там, где ваше главное отличие — в процессе, а подгонка под готовый инструмент каждый месяц добавляет вам работы.

Иногда решение — не новая программа, а упрощение процесса. Сначала описать текущий процесс, найти узкое место и только потом решать — так чаще всего дешевле и быстрее. Работа над дорожной картой цифровой трансформации — шаг, который можно сделать до решения о программе.

Шесть частых ошибок, которые замедляют процесс

• Пропустить анализ и сразу требовать экраны.
• Не включать во встречи человека, который знает процесс.
• Не фиксировать критерии приемки письменно.
• Пытаться уместить все в первую версию; не вести список для второй версии.
• Несколько лиц, принимающих решения, требуют изменений, не зная друг о друге.
• Оставлять запуск и информирование пользователей на последний день.

Как YazSis ведет процесс разработки ПО на заказ?

YazSis ведет работу по разработке ПО на заказ в четыре блока: сначала выявляются цель, пользователи, данные и бизнес-правила; затем проектируются сценарий использования и устойчивая техническая структура; после этого идут модульная разработка и проверка на реальных сценариях; в конце система запускается, измеряется и улучшается по обратной связи. В объем могут входить веб-приложения, панели управления с ролевым доступом, процессы «заявка — согласование — назначение», мобильные приложения, API-сервисы для обмена данными с другими системами и интерфейсы бэк-офиса для загруженных операционных команд. В этой статье мы не называем сроки и цены; и то и другое обсуждается вместе с объемом после анализа.

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