Технологический краш-тест: как убить свой проект и потерять время, деньги и нервы

Поговорим про то, с чем мы живем ежедневно?

Программы, разработки, ИИ, как оценить задачу и не переплатить, как найти порядочного разработчика, как не попасть на крючок к непорядочному… В современном техномире легко потеряться (можно сразу дезертировать в деревню без интернета, хотя такую поди найди еще).

Лет 15 назад я был настоящим технологическим гением — коллеги и родственники обращались ко мне с просьбами подключить вайфайный принтер или настроить роутер. Я свободно ориентировался в мире технологий: знал разницу между СЕО и SEO, понимал, какие технологические стеки актуальны, а какие устарели.

Тогда был простой, понятный мир: две основные социальные сети — MySpace и только родившийся Facebook. Из приложений — Evernote для заметок, Google Docs для документов, Basecamp для управления проектами, Dropbox для облачного хранения. Весь технологический мир умещался в паре десятков программ.

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

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

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

Если у вас есть такой же CTO — вам повезло. А что делать тем, кому приходится разбираться самостоятельно? Я попросил Влада рассказать.

***

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

Сегодня вокруг много шума про NoCode, LowCode, AI-инструменты и другие «волшебные» решения, которые, кажется, могут все. Но технологии — это инструмент, и важно выбрать такой, который действительно подходит вашему проекту. Иначе вы рискуете потратить месяцы, только чтобы понять, что нужно начинать с нуля.

Давайте разберем три частые ошибки, которые могут стоить вам времени, денег и нервов.

1. Не доверяйте схожести названий

Когда подрядчик говорит, что сделает проект на одной технологии, а выдает на другой, это может стать неприятным сюрпризом. Один из таких случаев мы увидели на аудите: клиент заказал разработку на Flutter, а получил проект на FlutterFlow.

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

2. Не гонитесь за «единым стеком»

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

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

3. Не поддавайтесь хайпу

Популярные технологии часто выглядят как идеальное решение: быстро, модно, удобно. Исполнитель может убедительно объяснить, почему именно этот инструмент подходит вашему проекту, и это может быть правдой. Но важно подумать, что будет дальше.

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

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

Что делать?

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

Его задача — подобрать оптимальное решение, которое будет работать и для бизнеса, и для команды разработки.

При этом самое главное, чтобы эксперт заходил в проект не чтобы поиграть своим эго и показать, что он прав, а действительно помочь.

Итог

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