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