Какие особенности небольшого ИТ-проекта стоит учитывать

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

Как обычно запускаются ИТ-проекты

Классический способ запуска ИТ-проекта обычно представлен в двух вариантах:

1. Запуск на базе типового решения. Компания покупает, либо находит готовый код. Под проект нанимается команда,  которая адаптирует код под задачи бизнеса.
2. Разработка с нуля. Компания нанимает команду, которая под конкретные цели делает ИТ-проект.

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

Давайте остановимся на варианте — взять типовое решение (готовый код) и доработать его. Это существенно дешевле и быстрее, чем разрабатывать все с нуля. Рассмотрим, какие риски могут быть в таком подходе.

Сложности, о которых нужно знать перед запуском проекта 

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

На что же стоит обратить внимание при реализации небольшого ИТ-проекта:

• Формирование команды

Небольшой проект обычно не позволяет нанимать разных профильных специалистов.
Компании нужно чтобы кто-то понимал, как у нее работают процессы, чтобы кто-то предлагал красивые, интересные решения (UX/UI-проектировщик, дизайнер) и кто-то все это реализовывал (разработчик), тестировал (тестировщик) и самое главное нужен тот, кто будет всех специалистов стыковать и организовывать синхронно их работу (менеджер проекта).

• История изменений

Небольшой проект не позволяет накапливать экспертизу по внесенным изменениям в голове у одного разработчика. Обычно это выглядит так:

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

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

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

• Архитектура проекта

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

Для решения задачи нужно комплексно понимать, что и как происходит в проекте. Другими словами, задача требует больше компетенций, чем просто «закодировать кнопочку на странице».

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

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

Варианты решения

Использовать SaaS

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

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

Так в Адвантшоп мы предоставляем выбор из тарифных планов для создания интернет-магазина, мобильного приложения и работы с маркетплейсами. Чтобы начать торговать в интернете достаточно простыми настройками создать свой ресурс. Техническая поддержка помогает разобраться с настройками. Не требуются значительные вложения финансов для старта проекта.

Использовать SaaS-кастомизацию

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

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

Подведем итоги

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