Как спланировать ПО для бизнеса до найма разработчика

Краткое содержание

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

В этом руководстве метод разбирается шаг за шагом на одном примере — системе онлайн-бронирования билетов в кино. Те же шаги подойдут для клиники, магазина, учебного центра или службы доставки.

Почему проекты по разработке ПО для малого бизнеса терпят неудачу?

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

Некоторые из этих негласных решений — это решения для бизнеса. Может ли один клиент забронировать сразу несколько мест? Действительно ли бронирование до его оплаты? Зависит ли цена от места или от времени сеанса? Если разработчик угадывает не так, как задумал владелец, ошибка обычно обнаруживается уже после создания программы, а изменение готовой структуры стоит гораздо больше, чем изменение плана на бумаге.

Решение проблемы — не более длинный документ. Решение — более четкий документ, и системный анализ дает воспроизводимый способ его создания.

Что такое системный анализ и проектирование простыми словами?

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

Центральная идея — это класс. Класс — это тип объекта, который программа должна помнить, вместе с его деталями и тем, что он может делать. В системе кинотеатра Movie (фильм) — это класс: у каждого фильма есть название, жанр и продолжительность, и существует множество фильмов. Booking (бронирование) — это класс: у каждого бронирования есть номер, общая стоимость и статус.

Список классов, их деталей и связей называется моделью классов. Обычно ее рисуют в виде диаграммы классов на UML (Unified Modeling Language — унифицированный язык моделирования), стандартной нотации, которую используют разработчики. Вам не нужно рисовать UML самостоятельно, чтобы извлечь пользу из этого метода; вам нужно лишь следовать его логике.

Шаг 1: Опишите свой бизнес простыми предложениями

Начните с честного описания того, как работает бизнес, написанного так, как вы бы объясняли это новому сотруднику. Лучше всего работают короткие, конкретные предложения.

Вот пример, используемый в этом руководстве. Сеть кинотеатров хочет систему онлайн-бронирования. Клиенты регистрируются, указывая имя, email, номер телефона и пароль. Они просматривают фильмы, у каждого из которых есть название, жанр, продолжительность, язык, возрастной рейтинг и описание. У каждого фильма есть один или несколько сеансов, и каждый сеанс проходит в одном зале кинотеатра в определенные дату и время. Клиенты выбирают сеанс, одно или несколько мест и платят онлайн. После успешной оплаты они получают электронный билет по email или SMS.

Администраторы добавляют, редактируют и удаляют фильмы, составляют расписание сеансов, устанавливают цены для категорий мест, таких как стандарт, премиум и VIP, а также просматривают отчеты по бронированиям. В каждом зале есть схема рассадки, и место, забронированное на сеанс, становится недоступным для этого сеанса. Фильмы группируются как «Сейчас в прокате», «Скоро на экранах» или «В архиве».

Это описание состоит примерно из двухсот слов. Все остальное в этом руководстве строится на его основе.

Шаг 2: Выпишите каждое существительное и каждый глагол

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

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

В описании кинотеатра получается около 45 существительных. Только примерно четверть из них станут классами. Такое соотношение нормально, и оно показывает, почему сырое описание — это еще не план.

Шаг 3: Какие существительные действительно важны?

Задайте три вопроса о каждом существительном в таком порядке.

1. Есть ли у него собственные детали и поведение? Если это одиночное значение, например, email-адрес или жанр, то это деталь чего-то другого, а не класс.

2. Нужно ли программе помнить много таких объектов? Если он только один, или существительное обозначает саму программу, вычеркните его.

3. Это самостоятельный объект, или роль, или тип другого объекта? Роли и типы часто становятся ярлыком в другом классе, а не отдельным классом.

В примере с кинотеатром восемь существительных проходят все три вопроса: Customer, Admin, Movie, Showtime, CinemaHall, Seat, Booking и Payment. Слова вроде названия, продолжительности, даты, номера места и общей стоимости становятся деталями этих классов.

Отброшенные существительные не менее поучительны. Система и программа описывают то, что мы создаем. Сеть кинотеатров — это владелец, и о нем ничего не хранится. Аккаунт здесь означает то же самое, что и клиент, а транзакция — то же самое, что и оплата. Email и SMS — это каналы доставки, не имеющие собственных данных. Доступность мест вообще не хранится, потому что она вычисляется из бронирований.

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

Шаг 4: Превратите глаголы в действия и связи

Глагол становится действием, когда его выполняет один класс, и связью, когда он описывает, как соотносятся два класса. Правило размещения действия простое: поместите его в тот класс, который хранит данные, необходимые для этого действия.

Например, расчет общей стоимости бронирования относится к Booking, потому что бронирование знает, какие места оно включает, а каждое место знает свою ценовую категорию. Проверка того, какие места еще свободны, относится к Showtime, потому что место свободно или занято только для конкретного сеанса.

Связи возникают из таких фраз, как «у каждого фильма может быть один или несколько сеансов», «каждое бронирование связано ровно с одним сеансом» и «бронирование может включать одно или несколько мест». Слова, обозначающие количество в этих фразах (один, ровно один, один или несколько), называются множественностями (multiplicities). Это бизнес-правила, написанные простым языком, и они определяют, как будут работать база данных и экраны. Явное их описание — одна из самых ценных вещей, которые может сделать владелец бизнеса.

Шаг 5: Проверьте план с помощью CRC-карточек

CRC-карточка — это небольшая карточка или строка в таблице, состоящая из трех частей: имя класса (Class), его обязанности (Responsibilities) и его коллабораторы (Collaborators), то есть другие классы, которые нужны ему для выполнения своей работы. Эта техника старая и очень практичная, потому что она превращает статический список в разговор о том, кто что делает.

Описывайте обязанности как задачи, а не как списки полей. «Знает свои контактные данные» и «рассчитывает общую стоимость» — это обязанности; «имя, email» — нет.

Карточки проверяют список из Шага 3. Класс без обязанностей следует удалить. Обязанность, которой негде разместиться, указывает на недостающий класс. В примере с кинотеатром карточки выявили три пробела:

- Booking нужна цена, а администраторы устанавливают цены по категориям, поэтому цене нужен дом. Это добавляет класс SeatCategory с названием и ценой.

- Booking выдает электронный билет, который создается только после оплаты и отправляется клиенту. Это добавляет класс Ticket.

- У Customer и Admin есть имя, email и пароль, и оба авторизуются в системе. Это добавляет общий класс User, на основе которого строятся оба.

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

Какие бизнес-правила легко упустить?

Некоторые правила нельзя нарисовать в виде прямоугольников и линий, и именно они часто наносят реальный ущерб, когда отсутствуют.

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

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

Частые ошибки при описании требований к ПО

- Отношение к каждому существительному как к функции. Email, пароль или жанр — это детали, а не модули для разработки.

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

- Добавление того, что бизнес на самом деле не делает. Возвраты, скидки, отзывы и снеки реальны во многих кинотеатрах, но если их нет в описании, их не должно быть в первой версии. Масштаб проекта незаметно растет, когда никто этого не контролирует.

- Хранение того, что должно вычисляться. Доступность мест, итоговые суммы и отчеты обычно получаются из других данных. Их отдельное хранение создает цифры, которые не сходятся.

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

Как это помогает при найме разработчика или использовании ИИ-инструментов?

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

Тот же план отлично работает с ИИ-помощниками по написанию кода. Эти инструменты пишут гораздо лучшие программы по четкому, структурированному описанию, чем по вольному абзацу текста. Предоставление ИИ-помощнику списка классов, множественностей и явных правил оставляет ему гораздо меньше пространства для догадок.

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

Главные выводы

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

- Сначала выпишите каждое существительное и глагол, а уже потом оценивайте их.

- Оставьте только те существительные, которые имеют собственные детали, существуют во множестве экземпляров и являются реальными объектами, а не ролями.

- Поместите каждое действие в класс, который хранит необходимые для него данные, и запишите слова, обозначающие количество, как бизнес-правила.

- Используйте CRC-карточки, чтобы найти недостающие классы и удалить те, которые ничего не делают.

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

Нужна помощь в планировании или создании вашей системы?

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