При первой встрече и знакомстве с новым клиентом мы часто обсуждаем проблемы которые возникли на проекте. Особенно внимательно мы стараемся выяснить что случилось с предыдущими подрядчиками или внутренними специалистами.

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

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

В результате заказчик ищет виновника торжества чтобы в будущем не повторять ошибок. Сам на себя он не подумает, может быть причина в подрядчике, но довольно часто заказчик приходит к выводу, что вероятно проблема кроется в технологии. На перезапуск проекта ее непременно нужно поменять на другую: с WordPress на Битрикс, с Битрикса на Laravel, с PHP на Python и так далее. Можете написать любую комбинацию, не промахнетесь.

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

Выбор

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

Рассмотрим показательный пример: компания по производству мебели планирует создать платформу для онлайн-продаж. На первый взгляд, задача кажется простой — нужен интернет-магазин. Но копнем глубже: компании требуется интеграция с 1С для учета складских остатков, конфигуратор мебели для клиентов, система управления заказами для менеджеров и API. И здесь мы сталкиваемся с классическим выбором между популярными решениями: Tilda, WordPress, OpenCart, 1С-Битрикс.

Каждая из этих систем прекрасна в своей нише. WordPress изначально создавался как блоговая платформа, OpenCart и 1С-Битрикс специализируется на e-commerce. И хотя современные CMS благодаря плагинам и расширениям способны выполнять практически любые задачи, это не всегда оптимальный путь.

Да, многие скажут, что WordPress с набором плагинов может превратиться в прекрасный интернет-магазин, и люди успешно используют такое решение. Это действительно правда, но лишь отчасти. Здесь уместна аналогия с транспортом: можно прикрепить к велосипеду мотор, но это не сделает его мотоциклом. На таком решении вы сколько то проедет, но вопрос насколько далеко?

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

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

Ключевой критерий

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

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

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

Как обычно важен контекст

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

В IT-мире нет однозначно плохих или хороших решений — они просто разные, как цвета и вкусы. Главное — правильно оценить контекст и сделать осознанный выбор технологии под конкретные задачи.