Когда речь заходит о корпоративном портале, внутренней CRM, системе заказов или специализированном сервисе, часто возникает один и тот же вопрос: может ли один разработчик вообще справиться с таким проектом?
Привычная картина серьёзной разработки выглядит иначе: менеджер проекта, аналитик, дизайнер, несколько программистов, тестировщик, DevOps. Поэтому предложение работать напрямую с одним Laravel-разработчиком иногда вызывает вполне понятное недоверие.
Мы разобрали этот вопрос без лозунгов про «индивидуальный подход» и «гибкость небольшой команды». В интервью:
Содержание
Да.
Но с очень важной оговоркой: далеко не любая система.
Один разработчик вполне может создать серьёзный рабочий продукт, если проект находится в разумных границах по объёму и сложности.
Например:
Но если речь идёт о системе масштаба крупного банка, маркетплейса или инфраструктуры большой корпорации, один человек — очевидно неправильная модель.
Проблема начинается тогда, когда пытаются представить одиночную разработку как универсальное решение.
Она не универсальна.
Обычно причина довольно прозаичная.
Компания не хочет оплачивать большую организационную надстройку вокруг относительно компактной задачи.
В классической студийной модели клиент может взаимодействовать с менеджером, который передаёт информацию аналитику, тот — разработчику, затем подключается тестировщик и так далее.
Для больших проектов это оправданно.
Для небольшой специализированной системы иногда получается наоборот: коммуникация становится сложнее самой разработки.
При прямой работе цепочка короче:
бизнес → разработчик → работающая система
Человек, который обсуждает процесс с клиентом, одновременно понимает архитектуру системы и пишет код.
Информация меньше искажается по дороге.
Он не обязан заменять профессионального бизнес-аналитика на крупном проекте.
Но разработчик бизнес-систем обязан уметь задавать вопросы.
Причём иногда довольно неудобные.
Например:
Если разработчик просто записывает требования в стиле «здесь нужна кнопка», а потом реализует кнопки, хороший продукт из этого получается редко.
Нужно понимать не экран.
Нужно понимать процесс за экраном.
Такой риск существует.
Поэтому принципиально важно не пытаться быть одновременно десятью специалистами на уровне крупной продуктовой команды.
В небольших проектах работает другой подход.
Используются проверенные технологии и стандартные решения там, где нет необходимости изобретать собственные.
Например, для бизнес-системы обычно нет смысла писать с нуля:
Фреймворк уже решает значительную часть инфраструктурных задач.
Работа разработчика должна концентрироваться на том, что действительно уникально для бизнеса.
Вот это уже более серьёзный вопрос.
В команде существует естественный внутренний контроль: pull request, code review, тестировщики, технический руководитель.
При работе одного специалиста такой контроль действительно слабее.
Поэтому его приходится компенсировать процессом.
Например:
Особенно важно не разрабатывать систему полгода «в тишине», чтобы потом впервые показать её заказчику.
Чем меньше команда, тем чаще должен появляться проверяемый результат.
Это один из главных рисков модели с одним исполнителем.
И его нельзя отрицать.
Правильный вопрос здесь не «может ли разработчик исчезнуть».
Конечно, может.
Правильный вопрос:
что останется у бизнеса после этого?
У заказчика должны быть:
Система не должна существовать только в ноутбуке разработчика.
Если новый специалист получает проект и не может даже понять, как его запустить, — это уже проблема организации разработки.
Документация должна соответствовать масштабу системы.
Для небольшого проекта нет смысла писать несколько сотен страниц технической документации, которую никто не будет читать.
Но должны быть описаны хотя бы ключевые вещи:
Часть документации должна находиться непосредственно рядом с кодом.
Тогда вероятность её актуальности выше.
Это нормальная ситуация.
Более того, успешный внутренний сервис часто именно так и развивается.
Сначала компания автоматизирует один процесс.
Например:
заявка → проверка → согласование → выполнение
Потом появляются:
В какой-то момент один разработчик действительно становится ограничением.
И это не означает, что изначальная модель была ошибочной.
Просто проект перешёл в другую стадию.
Нет.
Если система изначально построена нормально, к проекту можно подключать дополнительных разработчиков.
Для этого особенно полезно разделять систему на понятные модули.
Например:
Необязательно сразу строить микросервисную архитектуру.
Для многих подобных проектов хороший модульный монолит гораздо практичнее.
Но внутри проекта должны существовать границы.
Тогда команда может расти вместе с системой.
Нет.
Микросервисы решают конкретные организационные и технические проблемы.
Но они одновременно создают новые:
Если системой занимается один или несколько разработчиков, а нагрузка не требует распределённой архитектуры, микросервисы легко превращаются в дорогую архитектурную декорацию.
Для многих B2B-систем разумнее начинать с хорошо структурированного монолита.
А разделять его тогда, когда для этого появилась реальная причина.
Главное преимущество — не обязательно цена.
Оно в скорости передачи информации.
При прямой работе разработчик может услышать:
«Менеджеры постоянно путают версии заказа».
И сразу начать выяснять:
В длинной коммуникационной цепочке исходная проблема иногда превращается в техническое задание:
«Добавить поле “Версия заказа”».
Формально задача выполнена.
Но проблема бизнеса может остаться.
Нет.
Есть проекты, где агентство или команда объективно лучше.
Например, если одновременно требуется:
Один человек просто становится узким местом.
И попытка сэкономить здесь может увеличить сроки и риски.
Не существует числа вроде «до 100 пользователей можно одному, после 100 нельзя».
Количество пользователей вообще далеко не всегда главный показатель.
Гораздо важнее:
Система для 20 сотрудников производственной компании иногда может оказаться сложнее сервиса с несколькими тысячами пользователей.
Я бы не начинал с вопроса:
«Сколько лет вы программируете на Laravel?»
Это полезная информация, но она мало говорит о том, как будет устроена работа.
Гораздо интереснее спросить:
Последний вопрос особенно интересный.
Если разработчик отвечает, что никаких рисков нет, — это само по себе информация.
Несколько признаков довольно очевидны.
Например, одновременно необходимо разрабатывать web-систему, мобильное приложение, несколько интеграций и заниматься миграцией данных.
Один разработчик физически не может масштабировать количество часов.
Один человек не может гарантировать полноценное 24/7 присутствие.
Некоторые классы программного обеспечения требуют другого уровня процессов, контроля и сертификации.
Тогда разработка становится не только технической, но и организационной задачей.
Обычно тогда, когда существует конкретный бизнес-процесс, который нужно привести в порядок.
Например, сейчас он выглядит так:
Excel → Telegram → письмо → ещё одна таблица → уточнение по телефону → повторный ввод данных
И задача заключается не в создании «новой корпоративной платформы», а в том, чтобы сделать нормальный единый рабочий процесс.
В таких случаях небольшая команда или один разработчик действительно могут быть эффективнее большой структуры.
Для клиента сама технология редко является основной ценностью.
Бизнесу обычно важно другое:
Laravel удобен для такого класса задач потому, что вокруг него уже существует зрелая инфраструктура для типичных серверных задач:
Это позволяет меньше времени тратить на инфраструктуру и больше — на сам бизнес-процесс.
Иногда можно.
Но для нестандартной бизнес-системы точная цифра до детального изучения процесса часто является скорее предположением.
Особенно если на первом разговоре звучит:
«Нам нужна CRM примерно как наша таблица, только нормальная».
После разбора может оказаться, что внутри этой таблицы скрываются:
Поэтому разумнее сначала определить минимальный рабочий контур системы.
Да, но термин MVP часто понимают неправильно.
MVP — это не обязательно плохая или урезанная система.
Это минимальный законченный процесс, который уже приносит пользу.
Например, вместо попытки сразу автоматизировать весь отдел продаж можно начать с одного участка:
заявка → назначение ответственного → обработка → согласование → завершение
Он должен работать нормально от начала до конца.
После этого можно добавлять следующий процесс.
Можно.
Но доверять нужно не количеству людей.
И не слову Laravel.
И даже не красивому портфолио.
Нужно смотреть на то, как организована разработка.
Есть ли:
Если всего этого нет, команда из пяти человек тоже не гарантирует хороший результат.
А если процесс разработки выстроен нормально, один сильный разработчик способен создать и долго развивать вполне серьёзную бизнес-систему.
Главное — понимать масштаб задачи и вовремя заметить момент, когда проект действительно перерос одного человека.
Вопрос «может ли один разработчик сделать серьёзную систему?» поставлен немного неправильно.
Гораздо полезнее спросить:
«Достаточен ли один разработчик именно для нашей задачи — и что произойдёт с проектом, если он станет в несколько раз больше?»
Если на оба вопроса есть понятный ответ, количество людей в команде перестаёт быть главным критерием выбора.
Нужен похожий контур — обсудим.
B2B-портал с интеграцией 1С · Закупочный портал сантехники · Laravel vs Битрикс и OpenCart