Как разработать веб-приложение: этапы, сроки и способы
Разбираем процесс со стороны заказчика — что происходит на каждом этапе, что требуется от вас и в каких четырёх местах обычно уезжают сроки.
Коротко
Коротко
- Веб-приложение отличается от сайта не технологией, а тем, что в нём работают, — отсюда роли, права и обработка отказов.
- Внутреннее приложение и публичный сервис требуют разного: у первого важнее права и интеграции, у второго — нагрузка и интерфейс.
- Способов разработать четыре, и выбор определяется не бюджетом, а тем, кто будет менять приложение через полгода.
- Сроки теряются в четырёх предсказуемых местах, и три из них лежат на стороне заказчика.
- Роли, журнал действий и обработка отказов дешевле заложить сразу — добавить их потом означает переделку.
Веб-приложение, сайт и веб-сервис: в чём разница
Все три открываются в браузере, и на этом сходство заканчивается. Разница важна не для терминологии, а потому что от неё зависит объём работ.
Сайт рассказывает. Посетитель читает, смотрит и в лучшем случае оставляет заявку. Контентом занимается редактор, данные посетителя нигде не живут дольше письма менеджеру.
Веб-приложение работает. У человека есть учётная запись, он что-то создаёт и меняет, данные хранятся и связаны между собой, а у разных людей разные права. Личный кабинет, система заявок, реестр договоров, система согласований — всё это веб-приложения, даже если внешне похожи на страницы сайта.
Веб-сервис обычно не имеет интерфейса вовсе. Это способ одной системы получить данные у другой. Когда говорят «сделайте нам сервис для обмена с 1С», речь идёт про него.
Практический признак, по которому легко отличить приложение от сайта. Спросите, что случится, если сайт полежит два часа недоступным. У сайта ответ — потеряем часть заявок. У приложения — встанет работа отдела, и кто-то будет разбираться с последствиями. Отсюда и всё остальное — приложению нужны резервное копирование, журнал действий и разграничение доступа.
Сайт рассказывает. Посетитель читает, смотрит и в лучшем случае оставляет заявку. Контентом занимается редактор, данные посетителя нигде не живут дольше письма менеджеру.
Веб-приложение работает. У человека есть учётная запись, он что-то создаёт и меняет, данные хранятся и связаны между собой, а у разных людей разные права. Личный кабинет, система заявок, реестр договоров, система согласований — всё это веб-приложения, даже если внешне похожи на страницы сайта.
Веб-сервис обычно не имеет интерфейса вовсе. Это способ одной системы получить данные у другой. Когда говорят «сделайте нам сервис для обмена с 1С», речь идёт про него.
Практический признак, по которому легко отличить приложение от сайта. Спросите, что случится, если сайт полежит два часа недоступным. У сайта ответ — потеряем часть заявок. У приложения — встанет работа отдела, и кто-то будет разбираться с последствиями. Отсюда и всё остальное — приложению нужны резервное копирование, журнал действий и разграничение доступа.
Внутреннее приложение против публичного: разные требования
Различие, которое почти не проговаривают, а оно определяет и смету, и выбор подрядчика. Требования у двух классов не просто разные — они конкурируют за бюджет.
Из таблицы следует вывод, который экономит деньги. Внутреннему приложению не нужен продающий дизайн и запас по нагрузке на миллион посетителей. Ему нужно, чтобы двадцать человек быстро выполняли операцию и видели правильные данные. Бюджет, ушедший в красоту первого экрана, у внутренней системы почти всегда потрачен зря.
Внутреннее приложение | Публичный сервис | |
Кто пользуется | Сотрудники, дилеры, поставщики — известный круг | Любой посетитель, число непредсказуемо |
Что решает успех | Точность данных и скорость операций | Конверсия и удержание |
Главное требование | Роли, права, интеграции с учётными системами | Нагрузка, отклик, внешний вид |
Дизайн | Функциональный, важнее плотность информации | Продающий, важнее первое впечатление |
Цена ошибки | Неверные данные в учёте, остановка процесса | Ушедший пользователь |
Что меняется чаще | Правила и маршруты вслед за регламентом | Интерфейс и контент вслед за маркетингом |
Из таблицы следует вывод, который экономит деньги. Внутреннему приложению не нужен продающий дизайн и запас по нагрузке на миллион посетителей. Ему нужно, чтобы двадцать человек быстро выполняли операцию и видели правильные данные. Бюджет, ушедший в красоту первого экрана, у внутренней системы почти всегда потрачен зря.
Из чего состоит веб-приложение
Чтобы разговаривать с исполнителем на одном языке, достаточно понимать четыре слоя. Смета всегда раскладывается по ним, даже если в ней этого не написано.
Интерфейс. То, что видит пользователь. Экраны, формы, списки, фильтры. Объём работы здесь считается не количеством экранов, а количеством состояний — пустой список, ошибка ввода, загрузка, отказ в доступе.
Логика. Правила, по которым приложение работает. Кто что может, какой статус за каким следует, как считается срок, что происходит при отклонении. Самая недооценённая часть и обычно самая дорогая.
Данные. Какие сущности есть, как они связаны, где хранятся, кто имеет право менять. Ошибка в этом слое исправляется хуже всего, потому что от него зависят остальные три.
Интеграции. Обмен с 1С, каталогом пользователей, платёжным сервисом, почтой, мессенджерами. Единственный слой, стоимость которого зависит не от вас, а от системы на другой стороне.
Полезное упражнение перед разговором с подрядчиком — разложить свою задачу по этим четырём слоям на одном листе. Обычно сразу видно, где основная сложность, и это редко тот слой, о котором думали изначально.
Интерфейс. То, что видит пользователь. Экраны, формы, списки, фильтры. Объём работы здесь считается не количеством экранов, а количеством состояний — пустой список, ошибка ввода, загрузка, отказ в доступе.
Логика. Правила, по которым приложение работает. Кто что может, какой статус за каким следует, как считается срок, что происходит при отклонении. Самая недооценённая часть и обычно самая дорогая.
Данные. Какие сущности есть, как они связаны, где хранятся, кто имеет право менять. Ошибка в этом слое исправляется хуже всего, потому что от него зависят остальные три.
Интеграции. Обмен с 1С, каталогом пользователей, платёжным сервисом, почтой, мессенджерами. Единственный слой, стоимость которого зависит не от вас, а от системы на другой стороне.
Полезное упражнение перед разговором с подрядчиком — разложить свою задачу по этим четырём слоям на одном листе. Обычно сразу видно, где основная сложность, и это редко тот слой, о котором думали изначально.
Четыре способа разработать веб-приложение
Способы отличаются не только сроком и ценой, но и тем, кто сможет менять приложение потом. Последняя колонка важнее первых двух.
Первые два способа дают полную свободу и подходят, когда приложение — продукт компании. Вторые два ограничены возможностями платформы и выигрывают на внутренних системах, где свобода нужна редко, а менять приложение приходится постоянно.
Отдельно про соблазн собрать веб-приложение свободной генерацией кода. Инструменты, которые поднимают приложение по описанию, действительно работают и дают результат за часы. Проблема проявляется на второй месяц — у приложения появился собственный код, который никто не проектировал и за который никто не отвечает.
Когда задача — проверить гипотезу, разумнее начинать с MVP: что собирается на low-code за неделю.
Способ | Срок до работающей версии | Что требуется от вас | Кто вносит изменения потом |
Своя команда | Месяцы; если команда занята — не начнётся | Постановка задачи и приоритет | Своя команда, если её не переключат |
Подрядчик | Недели и месяцы | ТЗ, приёмка, бюджет на итерации | Подрядчик по договору на доработки |
Платформа своими руками | Недели | Сотрудник, который освоит платформу | Этот сотрудник, пока он в компании |
Сборка ассистентом на платформе | Дни и недели | Описание процесса словами или ЧТЗ | Любой, кто может описать правку словами |
Первые два способа дают полную свободу и подходят, когда приложение — продукт компании. Вторые два ограничены возможностями платформы и выигрывают на внутренних системах, где свобода нужна редко, а менять приложение приходится постоянно.
Отдельно про соблазн собрать веб-приложение свободной генерацией кода. Инструменты, которые поднимают приложение по описанию, действительно работают и дают результат за часы. Проблема проявляется на второй месяц — у приложения появился собственный код, который никто не проектировал и за который никто не отвечает.
Когда задача — проверить гипотезу, разумнее начинать с MVP: что собирается на low-code за неделю.
ЧЕТВЁРТЫЙ СПОСОБ
Приложение собирается по описанию процесса
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Вы описываете процесс словами или загружаете ЧТЗ. Ассистент переводит описание на объектный язык платформы — сущности, поля, роли, экраны, маршруты — и собирает приложение из компонентов, которые в платформе уже есть и уже работают. Дальше правки вносятся в чате.
От работы с подрядчиком это отличается устройством цикла. Там каждое изменение проходит постановку, оценку, разработку и релиз, и между потребностью и результатом стоит очередь. Здесь очереди нет.
Приложение собирается по описанию процесса
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Вы описываете процесс словами или загружаете ЧТЗ. Ассистент переводит описание на объектный язык платформы — сущности, поля, роли, экраны, маршруты — и собирает приложение из компонентов, которые в платформе уже есть и уже работают. Дальше правки вносятся в чате.
От работы с подрядчиком это отличается устройством цикла. Там каждое изменение проходит постановку, оценку, разработку и релиз, и между потребностью и результатом стоит очередь. Здесь очереди нет.
- личные кабинеты, заявки, согласования, реестры и внутренние порталы
- правки в чате без нового релиза
- заявленный эффект — в 10–50 раз меньше трудозатрат на типовое решение
Этапы разработки и что происходит на каждом
Порядок работ примерно одинаков у всех способов, различается длительность. Знать этапы полезно, чтобы понимать, за что вы платите и в какой момент можно остановиться.
Два этапа, которые пытаются сократить чаще всего, — разбор задачи и пилот. Сокращение первого возвращается переделками на сборке. Сокращение второго переносит обнаружение проблем на всю компанию сразу.
Про остановку. После этапа сборки уже можно принять решение, нужно ли идти дальше. Если приложение открыли и стало ясно, что процесс задуман неверно, это лучшая новость проекта — она пришла до того, как потратились интеграции и тестирование.
Этап | Что происходит | Что получаете на выходе |
Разбор задачи | Исполнитель выясняет процесс, роли, данные, исключения | Описание процесса, с которым вы согласны |
Проектирование | Модель данных, схема экранов, маршруты, права | Понимание, что именно будет собрано |
Сборка | Появляется работающее приложение | Версия, которую можно открыть и потыкать |
Интеграции | Подключение к учётным и внешним системам | Данные приходят и уходят сами |
Тестирование | Проверка сценариев, ролей, отказов | Список найденного и исправленного |
Пилот | Один отдел работает по-настоящему | Обратная связь и правки |
Запуск и передача | Все пользователи, доступы, инструкции | Работающая система и понимание, кто её ведёт |
Два этапа, которые пытаются сократить чаще всего, — разбор задачи и пилот. Сокращение первого возвращается переделками на сборке. Сокращение второго переносит обнаружение проблем на всю компанию сразу.
Про остановку. После этапа сборки уже можно принять решение, нужно ли идти дальше. Если приложение открыли и стало ясно, что процесс задуман неверно, это лучшая новость проекта — она пришла до того, как потратились интеграции и тестирование.
Что нужно от заказчика
Работа заказчика в таком проекте недооценивается систематически, а сроки уезжают именно из-за неё. Ниже честная раскладка по этапам.
Самая частая причина срыва срока — не разработка, а недоступность людей. Проект, в котором владелец процесса уехал в отпуск на этапе проектирования, встаёт целиком, потому что отвечать на вопросы больше некому.
Этап | Что нужно от вас | Сколько времени это занимает |
Разбор задачи | Человек, который знает процесс, и два-три часа его времени | Основная нагрузка проекта на вашей стороне |
Проектирование | Решение по спорным местам — кто согласует, что при отказе | Несколько коротких ответов, но быстро |
Сборка | Ничего, кроме доступности для вопросов | Минимально |
Интеграции | Доступ к системам и человек, который знает их устройство | Часто узкое место проекта |
Тестирование | Проверка на своих сценариях, а не только по инструкции | Полдня-день от двух сотрудников |
Пилот | Отдел, который согласился работать по-новому | Три недели наблюдения |
Запуск | Решение, кто внутри компании ведёт систему дальше | Одно решение, но обязательное |
Самая частая причина срыва срока — не разработка, а недоступность людей. Проект, в котором владелец процесса уехал в отпуск на этапе проектирования, встаёт целиком, потому что отвечать на вопросы больше некому.
Где теряются сроки: четыре типовые точки
Все четыре предсказуемы, и три из них лежат на стороне заказчика. Знание этого не ускоряет проект автоматически, но позволяет подготовиться.
Согласование требований. Процесс описали, и выяснилось, что два отдела понимают его по-разному. Пока они не договорятся, дальше идти нельзя. Лечится тем, что спорные места выносят наверх сразу, вместо попыток договориться между отделами.
Доступ к данным и системам. Тестовая база, учётная запись для обмена, разрешение службы безопасности. Формально мелочь, на практике недели ожидания. Запрашивать это надо одновременно со стартом, до того как понадобится.
Интеграции. Единственная точка на стороне исполнителя, и она же самая непредсказуемая. Если у системы на другой стороне есть описанный API, связка идёт быстро. Если нет — начинается разбор форматов и выгрузок, и оценка может измениться в разы.
Приёмка. Приложение готово, а посмотреть его некому — все заняты. Между «сделано» и «принято» проходит месяц, и за этот месяц требования успевают измениться.
Согласование требований. Процесс описали, и выяснилось, что два отдела понимают его по-разному. Пока они не договорятся, дальше идти нельзя. Лечится тем, что спорные места выносят наверх сразу, вместо попыток договориться между отделами.
Доступ к данным и системам. Тестовая база, учётная запись для обмена, разрешение службы безопасности. Формально мелочь, на практике недели ожидания. Запрашивать это надо одновременно со стартом, до того как понадобится.
Интеграции. Единственная точка на стороне исполнителя, и она же самая непредсказуемая. Если у системы на другой стороне есть описанный API, связка идёт быстро. Если нет — начинается разбор форматов и выгрузок, и оценка может измениться в разы.
Приёмка. Приложение готово, а посмотреть его некому — все заняты. Между «сделано» и «принято» проходит месяц, и за этот месяц требования успевают измениться.
Требования, без которых приложение придётся переделывать
Четыре вещи, которые дешевле заложить сразу. Добавить их потом означает не доработку, а переделку, потому что они затрагивают структуру данных.
Роли и права. Не «администратор и пользователь», а реальная картина — кто видит только своё подразделение, кто только своих контрагентов, кто видит суммы. Права, зависящие от данных, добавляются задним числом хуже всего.
Журнал действий. Кто и когда изменил запись. Нужен для разбора спорных ситуаций, а иногда и для требований безопасности. Включить его в готовое приложение означает вернуться ко всем операциям и дописать запись в журнал.
Обработка отказов. Что видит пользователь, когда обязательное поле пустое, файл не загрузился, смежная система не ответила. Приложение, которое падает молча, люди перестают использовать за несколько дней.
Место для истории. Понимание, нужны ли вам предыдущие значения записи. Если да, это решается в модели данных на старте; если решать потом, историю придётся собирать заново и за прошлый период она не появится.
Роли и права. Не «администратор и пользователь», а реальная картина — кто видит только своё подразделение, кто только своих контрагентов, кто видит суммы. Права, зависящие от данных, добавляются задним числом хуже всего.
Журнал действий. Кто и когда изменил запись. Нужен для разбора спорных ситуаций, а иногда и для требований безопасности. Включить его в готовое приложение означает вернуться ко всем операциям и дописать запись в журнал.
Обработка отказов. Что видит пользователь, когда обязательное поле пустое, файл не загрузился, смежная система не ответила. Приложение, которое падает молча, люди перестают использовать за несколько дней.
Место для истории. Понимание, нужны ли вам предыдущие значения записи. Если да, это решается в модели данных на старте; если решать потом, историю придётся собирать заново и за прошлый период она не появится.
ГДЕ АССИСТЕНТ НЕ НУЖЕН
Честная граница применимости
Сборка на платформе закрывает внутренние приложения — кабинеты, заявки, согласования, реестры, порталы. Роли, права и журнал действий в таких приложениях появляются как часть платформы, а не как отдельная работа.
Есть класс задач, где этот способ не подходит, и лучше знать об этом до начала. Публичный высоконагруженный сервис с обязательствами по отклику. Продукт, ядро которого — собственный алгоритм. Уникальный интерфейс, за который платит пользователь. В этих случаях нужна команда разработки, а платформа разумна для внутренних контуров вокруг такого продукта.
Честная граница применимости
Сборка на платформе закрывает внутренние приложения — кабинеты, заявки, согласования, реестры, порталы. Роли, права и журнал действий в таких приложениях появляются как часть платформы, а не как отдельная работа.
Есть класс задач, где этот способ не подходит, и лучше знать об этом до начала. Публичный высоконагруженный сервис с обязательствами по отклику. Продукт, ядро которого — собственный алгоритм. Уникальный интерфейс, за который платит пользователь. В этих случаях нужна команда разработки, а платформа разумна для внутренних контуров вокруг такого продукта.
- потолок задаёт платформа, на которой приложение разворачивается
- на внутренних системах это ограничение почти не мешает
Интеграции: с чем обычно связывают веб-приложение
Отдельная глава, потому что интеграции определяют, будет приложение частью рабочего контура или ещё одним местом ручного ввода.
Учётная система. В большинстве случаев 1С. Из неё приходят справочники, номенклатура, остатки, контрагенты; в неё уходят документы. Ключевой вопрос — направление обмена и его частота, потому что от них зависит и сложность, и поведение при сбое.
Каталог пользователей. Вход по корпоративной учётной записи вместо отдельного пароля. Для внутреннего приложения это заметно упрощает жизнь администратору и снимает вопрос с увольнениями.
Почта и мессенджеры. Уведомления и, реже, приём заявок из переписки. Простая по реализации часть, которая сильно влияет на приживаемость.
Внешние сервисы. Платежи, СМС, распознавание документов, карты. Тут стоимость определяется чужой документацией и тарифами.
Что закладывать по каждой интеграции, кроме самой связки. Поведение при недоступности — встанет процесс или заявка дождётся в очереди. Сверку — кто и как убедится, что данные в двух системах совпадают. И владельца обмена на вашей стороне, то есть человека, который знает, что эта связка существует.
Учётная система. В большинстве случаев 1С. Из неё приходят справочники, номенклатура, остатки, контрагенты; в неё уходят документы. Ключевой вопрос — направление обмена и его частота, потому что от них зависит и сложность, и поведение при сбое.
Каталог пользователей. Вход по корпоративной учётной записи вместо отдельного пароля. Для внутреннего приложения это заметно упрощает жизнь администратору и снимает вопрос с увольнениями.
Почта и мессенджеры. Уведомления и, реже, приём заявок из переписки. Простая по реализации часть, которая сильно влияет на приживаемость.
Внешние сервисы. Платежи, СМС, распознавание документов, карты. Тут стоимость определяется чужой документацией и тарифами.
Что закладывать по каждой интеграции, кроме самой связки. Поведение при недоступности — встанет процесс или заявка дождётся в очереди. Сверку — кто и как убедится, что данные в двух системах совпадают. И владельца обмена на вашей стороне, то есть человека, который знает, что эта связка существует.
Архитектура на пальцах: что важно знать заказчику
В архитектуру заказчику погружаться незачем, но четыре вопроса стоит задать — ответы на них определяют стоимость владения.
Про технологии. Заказчику почти безразлично, на чём написано приложение, и попытки выбирать стек — потерянное время. Значение имеет другое — сколько на рынке людей, умеющих с этим работать. Экзотический выбор превращает вас в заложника одной команды.
- Где приложение будет работать. Облако исполнителя, ваш сервер, облако платформы. От этого зависят требования безопасности и то, что произойдёт при расторжении договора.
- Что будет при росте нагрузки. Не «выдержит ли миллион», а простое — что делать, если пользователей станет вдвое больше. Ответ должен существовать заранее.
- Как обновляется приложение. Останавливается ли работа на время обновления, можно ли откатиться, кто это делает.
- Что с резервным копированием. Как часто, где хранится, кто проверял восстановление. Последняя часть вопроса самая важная и самая нелюбимая.
Про технологии. Заказчику почти безразлично, на чём написано приложение, и попытки выбирать стек — потерянное время. Значение имеет другое — сколько на рынке людей, умеющих с этим работать. Экзотический выбор превращает вас в заложника одной команды.
Доступ с телефона: адаптивный интерфейс и PWA
Требование «чтобы работало с телефона» звучит почти в каждом проекте, и за ним скрываются три разных решения.
Адаптивный интерфейс. Приложение открывается в мобильном браузере и подстраивается под экран. Самый дешёвый вариант, закрывает большинство внутренних задач — посмотреть заявку, согласовать, отметить выполнение.
PWA. То же веб-приложение, но добавленное на домашний экран телефона. Выглядит и запускается почти как обычное приложение, умеет работать с ограниченной сетью и получать уведомления. Ограничения на iPhone стоит знать заранее. Уведомления работают начиная с iOS 16.4, и только если пользователь сам добавил приложение на домашний экран через меню «Поделиться» — открытая вкладка не считается. Автоматически предложить установку iOS не позволяет, поэтому сотрудников придётся провести по шагам.
Приложение в магазинах. Отдельный класс задач со своими требованиями к сборке и ревью. Для внутренней системы нужен редко, а возможность собрать его определяется платформой, на которой приложение сделано, и это стоит уточнять до старта.
Практический совет. Начинайте с адаптивного интерфейса и смотрите, чего людям не хватает. В большинстве внутренних проектов на этом можно остановиться, а требование «нужно приложение» при разборе оказывается требованием «нужно, чтобы открывалось с телефона».
Адаптивный интерфейс. Приложение открывается в мобильном браузере и подстраивается под экран. Самый дешёвый вариант, закрывает большинство внутренних задач — посмотреть заявку, согласовать, отметить выполнение.
PWA. То же веб-приложение, но добавленное на домашний экран телефона. Выглядит и запускается почти как обычное приложение, умеет работать с ограниченной сетью и получать уведомления. Ограничения на iPhone стоит знать заранее. Уведомления работают начиная с iOS 16.4, и только если пользователь сам добавил приложение на домашний экран через меню «Поделиться» — открытая вкладка не считается. Автоматически предложить установку iOS не позволяет, поэтому сотрудников придётся провести по шагам.
Приложение в магазинах. Отдельный класс задач со своими требованиями к сборке и ревью. Для внутренней системы нужен редко, а возможность собрать его определяется платформой, на которой приложение сделано, и это стоит уточнять до старта.
Практический совет. Начинайте с адаптивного интерфейса и смотрите, чего людям не хватает. В большинстве внутренних проектов на этом можно остановиться, а требование «нужно приложение» при разборе оказывается требованием «нужно, чтобы открывалось с телефона».
Тестирование и приёмка: как понять, что приложение готово
Приёмка «на глаз» — источник большинства конфликтов с исполнителем. Готовность проверяется по списку, составленному заранее.
Что проверять обязательно.
Полезное правило приёмки. Проверять должен тот, кто будет работать в приложении, а не тот, кто заказывал. Заказчик проверяет по своему представлению о процессе, сотрудник — по тому, как процесс идёт в действительности, и находит на порядок больше.
Что проверять обязательно.
- Главный сценарий целиком, от создания до завершения, на реальных данных.
- Каждую роль отдельно. Зайти под каждой и убедиться, что видно ровно то, что должно.
- Отказ и возврат. Не только успешный путь, но и отклонение, отмену, повторную отправку.
- Пустые состояния. Как выглядит список, в котором пока ничего нет.
- Некорректный ввод. Буквы в числовом поле, слишком большой файл, дата в прошлом.
- Поведение при недоступности смежной системы. Хотя бы на уровне разговора о том, что будет.
- Права после увольнения. Что происходит с доступом, когда сотрудника отключают.
Полезное правило приёмки. Проверять должен тот, кто будет работать в приложении, а не тот, кто заказывал. Заказчик проверяет по своему представлению о процессе, сотрудник — по тому, как процесс идёт в действительности, и находит на порядок больше.
Если приложение уже есть
Отдельный сюжет, который встречается чаще, чем разработка с нуля. В компании работает приложение, оно устарело или перестало устраивать, и вопрос звучит как выбор между доработкой и заменой.
Разбор начинается с трёх вопросов, и ответы на них обычно решают дело.
Практический порядок при замене. Сначала выгрузить и осмотреть данные, потом описать процесс так, как он идёт сейчас в старом приложении, включая обходные пути, и только потом выбирать способ. Порядок именно такой, потому что обходные пути в старом приложении — это готовый список требований, которых не было в первоначальном задании. Их сбор занимает день и экономит месяц. Старое приложение при этом работает до последнего дня — параллельная работа двух контуров неделю-две дешевле, чем попытка переключиться одним днём.
Разбор начинается с трёх вопросов, и ответы на них обычно решают дело.
- Можно ли изменить модель данных? Если нужное изменение требует переделать структуру, доработка перестаёт быть дешёвой. Добавить поле легко, разделить одну сущность на две — почти всегда переписывание.
- Есть ли кому его поддерживать? Приложение, автор которого недоступен и код которого никто не читал, формально работает, а фактически заморожено. Доработка такого приложения стоит как новое.
- Что в нём ценно? Обычно ценность в данных и в накопленной логике процесса, код же вторичен. Если данные можно выгрузить, а логика описана, замена выглядит иначе — это перенос накопленного, и с нуля начинать не придётся.
Практический порядок при замене. Сначала выгрузить и осмотреть данные, потом описать процесс так, как он идёт сейчас в старом приложении, включая обходные пути, и только потом выбирать способ. Порядок именно такой, потому что обходные пути в старом приложении — это готовый список требований, которых не было в первоначальном задании. Их сбор занимает день и экономит месяц. Старое приложение при этом работает до последнего дня — параллельная работа двух контуров неделю-две дешевле, чем попытка переключиться одним днём.
Сроки и из чего складывается стоимость
Срок зависит в первую очередь от способа. Сборка на платформе укладывается в дни и недели, работа с подрядчиком идёт неделями и месяцами, своя команда начинает тогда, когда освобождается. При этом на любом способе есть часть срока, которая от исполнителя не зависит вовсе, — согласования и доступы внутри вашей компании.
Стоимость складывается из пяти частей, и сравнивать варианты имеет смысл по всем пяти.
Ошибка сравнения, которая встречается почти всегда, — считать только вторую строку. Дешёвая сборка, после которой каждое изменение идёт через подрядчика по часовой ставке, обходится дороже, чем сборка подороже с правками внутри компании.
Построчно смета разобрана отдельно: из чего складывается стоимость веб-приложения.
Стоимость складывается из пяти частей, и сравнивать варианты имеет смысл по всем пяти.
- Разбор и проектирование. Первый этап, который пытаются сократить и который определяет всё остальное.
- Сборка. Единственная часть, которую обычно и считают.
- Интеграции. Самая непредсказуемая строка, потому что зависит от чужих систем.
- Владение. Хостинг, обновления, поддержка. На горизонте трёх лет обычно больше стоимости создания.
- Изменения. Цена типовой правки, умноженная на то, сколько раз в год меняются процессы.
Ошибка сравнения, которая встречается почти всегда, — считать только вторую строку. Дешёвая сборка, после которой каждое изменение идёт через подрядчика по часовой ставке, обходится дороже, чем сборка подороже с правками внутри компании.
Построчно смета разобрана отдельно: из чего складывается стоимость веб-приложения.
Покажем Nolan на вашем процессе
Свяжемся в течение одного рабочего дня. Без спама.
Опишите задачу — мы разберём ваш процесс и подготовим демо-приложение на его основе
1
Вы оставляете заявку и кратко описываете задачу
2
Мы разбираем процесс или ЧТЗ
3
Показываем демо работающего приложения
Наши продукты:
Программа для ЭВМ «Nolan»
Программа для ЭВМ «CDP.Light»
Программа для ЭВМ «Корпоративный портал»
Компания «Технологии возврата»
3 года занимается разработкой и развитием ИИ
Из описания — в готовое приложение