Представьте: вы вложили деньги и силы в свой IT-продукт, запустили его, а через полгода любое обновление превращается в ад. Знакомо? Я часто вижу это на практике. Хорошая новость: этого можно избежать. Из статьи вы узнаете, как не угробить проект «костылями» и сохранить бюджет на развитие.
Любой работающий сервис должен меняться под запросы пользователей и новые бизнес-задачи. Это аксиома.
Не бывает успешных программ, которые один раз сделали, и они живут годами без изменений.
Но как вносить изменения, не угодив в капкан нарастающей сложности? Когда каждое новое улучшение внедрять всё тяжелее? Давайте разберемся.
Представьте сайт со сложной логикой. Владелец продукта не заботится о технической стороне и просто добавляет функции одну за другой.
Со временем они наслаиваются, конфликтуют, вызывают сбои.
Это как дом, к которому пристроили 2 этажа, потом углубили цоколь, потом сделали площадку на крыше. И так — без оглядки на коммуникации и материалы. В итоге — страшный монстр, где проблема может вылезти из любого угла.
Важно последовательно развивать сайт, сохраняя общую стройность системы.
В разработке есть понятие «костыль». Это плохое решение, которое удовлетворяет сиюминутному желанию заказчика.
Чем больше костылей, тем выше риски сбоев. Систему становится сложнее поддерживать.
А значит, дороже: больше ошибок, больше времени на разбор, нужны более опытные программисты.
Если заказчик не думает об оборотной стороне разработки, он ведет проект к тяжелому и дорогому сопровождению в будущем.
Во-первых, для каждой новой фичи оценивайте сложность внедрения и ценность для пользователя. Ценность мала, а перепахать нужно полпроекта? Такая фича не нужна.
В нашей платформе Falcon Space мы не внедряем фичу, если нет целостного решения. Особенно это касается ключевых компонентов — Таблицы, Формы. Любое костыльное решение в ядре порождает проблемы в будущем.
В конкретном проекте на базе платформы иногда приходится обходить ограничения. Но лучше сделать это точечно, чем ради одного случая городить костыль для всей платформы.
Во-вторых, сдерживайте аппетиты. Не нужно гнаться за трендами без обоснования. Если нет явной ценности от новой возможности, она будет вредна. Даже если ее внедрили бесплатно.
Сложность системы растет. Чем больше возможностей, тем больше кода — это ведет к удорожанию поддержки.
Третье: новые фичи потенциально ослабляют безопасность и быстродействие. Подключаете плагин для генерации PDF? Вы не знаете, есть ли в нем уязвимость. И как он поведет себя на больших файлах. Пример из практики: мы использовали внешнюю библиотеку для Excel. Всё было отлично, пока не попробовали выгрузить очень большие файлы — процессор забился моментально.
Чем меньше технологий задействовано, тем проще и надежнее решение.
Если вы делаете «фарш-проект», где переплетено всё, что можно, риски тормозов и взлома растут. Проверить все внешние компоненты почти невозможно. Пример — WordPress. Поставьте 50–100 плагинов, и 1–3 из них (а то и больше) могут иметь лазейки для хакеров или проблемы с быстродействием. Именно поэтому сайты на WP взламывают чаще.
Четвертое: у продукта должен быть фокус. Все внедрения должны соответствовать направленности проекта. Пришла идея? Как она соотносится с основной идеей? Противоречит? Отложите на 1–2 года.
Возьмите 1С. Многие считают систему тормозной. А ведь когда-то 1С была про скорость — любой запрос за секунду. Но компания, видимо, забила на позиционирование и сделала упор на широту возможностей.
Пятое: не торопитесь с внедрением. Фича простая и нужная? Внедряйте сразу. Сомневаетесь? Пусть полежит.
Фича должна как пазл встать в нужное место. Если не получается — не ломайте весь пазл.
Возможно, её нужно представить иначе, реорганизовать — и тогда она органично впишется в ваш «оркестр».
Важно: Любое тяжелое костыльное решение в ядре системы порождает новые проблемы при внедрении других возможностей. Лучше вообще отказаться от костылей на уровне ядра, насколько это возможно.
«Хочу и точка» — это безответственно. Такой проект в зоне риска. Наша позиция: высказать мнение, привести аргументы, но конечное решение за владельцем. Если он решил угробить проект — его дело. Не нужно переживать за чужой продукт больше, чем сам владелец.
Многие думают: «Сделаем аналог гиганта, только лучше». Не работает. Позаимствовать идеи — нормально. Чужой проект уже доказал состоятельность. Но полностью копировать — нет смысла. У них другая ситуация, ресурсы, стадия развития, аудитория. Что хорошо для крупного — не нужно начинающему. К тому же вы не знаете, что у них в бэк-офисе.
Лучше думать своей головой и критично подходить к своим процессам, а не слепо копировать чужую обложку.
Чем сложнее система, тем дороже обслуживание и дольше запуск. Учитывайте ресурсы: если идете с широким забралом, есть риск не хватить сил на внедрение. Большие сроки, увеличение бюджета, дополнительные затраты на непредвиденные интеграции.
Обложка важна. Но важнее, чтобы пользователь получил то, что ему нужно. Пример: ERP SAP R\3 — мировой лидер. Знаете, как она выглядит?
Упор должен быть на бизнес-цели пользователя и системы. Дизайн — лишь инструмент для их достижения.
Это подход лендингов 2010-х: наобещать кучу всего, таймеры обратного отсчета. Конечно, такие пользователи есть. Но у других это вызовет отторжение. Лучше сделать упор на реальные преимущества и доверие. Не пытайтесь дешевыми уловками манипулировать — это сразу настраивает на негатив.
Встречаются клиенты с таким подходом. Чувствуется манипуляция в каждом сообщении. Это читается на раз и вызывает желание дистанцироваться.
Уважительно относитесь к покупателю — это выгоднее в долгосрочной перспективе.
Рынок решает, жить вам или искать работу к конкуренту. Держите нос по ветру. Есть спрос — копайте туда. Если делаете продукт на чутье — риски растут. В идеале — опираться на существующий реальный спрос.
Если вы делаете продукт чисто на своем чутье — вы увеличиваете риски продукта.
Мне чужда идея создания продукта с кучей инвестиций без подпитки от рынка. Именно отдача от рынка дает понимание — в правильном ли направлении вы движетесь. Иначе можно познать судьбу Ван Гога: сделать что-то большое, но не добиться признания при жизни.
Чем дольше проект без запуска, тем дольше нет обратной связи от пользователя. А без жесткой обратной связи можно тешить себя иллюзиями об успехе.
Необходимо как можно раньше столкнуть продукт с рынком, собрать реальную обратную связь и шлифовать, шлифовать и еще раз шлифовать.
Долгий запуск увеличивает риски закрытия из-за нехватки финансирования. Деньги не поступают от рынка — проект дотируется инвестором или фаундером. Это временно. Нужно быстрее переходить к самодостаточности.
Мы рассмотрели проблематику развития IT-проекта и типичные болезни владельцев:
Используйте описанные подходы — это уменьшит проблемы развития вашего IT-продукта. Если вы на старте, советую почитать про с чего начать создание веб-сервиса. А если уже есть проект, взгляните на анализ рисков веб-проектов и как запустить проект с минимумом затрат.
.jpg)
.jpg)
