В прошлую пятницу нам позвонил клиент номер один. Буквально. Самый первый оплаченный счет, и с самый первый подписанный акт. Elgrow в те времена, состояла из меня, ноутбука и количества энтузиазма, за которое сегодня, наверное, штрафуют.
Естественно, на встречу нужно было ехать исключительно мне. И, естественно, вытирая рукавом слёзы ностальгии — всё-таки не каждый день видишь человека, который поверил в тебя, когда у тебя ещё даже сайта не было.
Клиент сразу заявил, что подрядчиков, кроме нас, рассматривать не будет. Причина достойная каменной таблички: их система работает почти 15 лет без внешнего вмешательства. Хотя, если честно, я до сих пор не уверен, что это физически возможно. Мы тогда писали код с настроением: «Лишь бы дожил до релиза». А он, похоже, взял и решил жить вечной жизнью.
Пообщались, обсудили планы, договорились делать снова — и, судя по всему, ещё на 15 лет вперёд. Приятно, конечно, но слегка тревожно: выходит, мы тогда делали лучше, чем понимали сами.

На этой неделе завершились два богических события юридической плоскости. Один из клиентов Miceconnect (да, он не сдох на MVP и продолжает захватывать гостиничный сервис), наконец, согласился начать работу, с которой тянул больше месяца. Почему? Потому что пытался понять, на каком основании авторы ПО владеют своим же ПО. В итоге, никаких значимых изменений договор так и не претерпел, но на подпись генеральному лег. Аминь!

Другой кейс — уже Elgrow. Заказчик третью неделю охотится за багами в договоре, которые благородно сам и создаёт. То цену срежет, то сроки перепутает, то разделы местами поменяет. Мы за это время сделали 90% работ и уже собрали требования ко второму этапу, а договор всё лежит на подписи, как артефакт, к которому страшно прикасаться.

Ничто так не тормозит прогресс, как бюрократия, уверенная, что без нее все превратится в хаос. Да, иногда мы начинаем работать до подписания договора. Риск? Возможно. Клиентоориентированность? Абсолютно.

Неделя выдалась весьма интересной на стартапы..

CoreOps.AI получил $3.5 млн на идею, на которой, честно говоря, должны были заработать ещё лет пять назад: заставить ИИ чинить древние корпоративные системы, которые уже и своих разрабов–то пережили. Авторы обещают научить своего питомца читать легаси-код, находить связи, предлагать миграции и вообще избавить мир от страшного слова “онбординг”. Бизнесу это нравится: дешевле, быстрее, не так больно. Разработчики, правда, пока смотрят с подозрением: если ИИ научится чинить легаси, то кто же будет рассказывать клиентам, что «тут проще переписать всё с нуля»?

Пока одни стартапы учат ИИ лечить древний код, Honeyjar AI решил заняться куда более сложной задачей — лечить корпоративные коммуникации. За $2 млн инвестиций компания собирается автоматизировать PR, упорядочить хаос в соцсетях и, возможно, впервые в истории сделать корпоративные тексты читабельными. Звучит фантастично, но рынок поверил: если разработчики могут делегировать ИИ рутину, почему бы маркетологам не делегировать штампы?

А между тем TechPred-2025 дал редкий по нынешним временам сигнал: хватит бояться, пора снова запускать продукты. Стартапам обещают упрощённые процедуры, новые меры поддержки и программы, налоговые льготы, что очень актуально, вообще-то. Для разработчиков это означает одно: нас ждёт сезон массовых MVP, срочных архитектур и клиентов, которые приходят со словами «хотим всё и сразу, но желательно вчера». Хорошая новость: спрос на настоящую разработку растёт. Плохая: ленивым снова будет тяжело.

Рынок, похоже, просыпается. ИИ лечит старое, автоматизирует новое, а стартапам снова дают разгон. Будем посмотреть!

И в продолжение истории...

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

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

Самое забавное, что договор нам подписали… 8 декабря. То есть к моменту подписи мы уже уверенно подходили к финалу.

Тот редкий случай, когда за девятью женщинами действительно можно родить за месяц. Аминь.

Очередные итоги суматошного ноября. Заходим на усиление команды разработки первого серьезного сервиса доставки в Крыму. Названий не будет — NDA. Скажем лишь, что речь не про «привезти Филадельфию соседу». Проект обещает быть большим, сложным — все как мы любим. И, казалось бы, причем здесь геополитика?

Российский ИТ-рынок в 2025 году внезапно вспомнил, что бизнес — это не презентации и «growth mindset», а деньги. По данным CNews, за январь–ноябрь число ИТ-компаний, ушедших в банкротство, выросло на 28%: 630 случаев против 491 годом ранее. Это не «стартапы на энтузиазме», а рабочие компании с контрактами. Рынок сжался, бюджеты стали осторожными, а право на ошибку — исчезло. ИТ больше не баловство, а статья расходов, которую проверяют трижды.

Казалось бы, если ИТ-компании банкротятся — значит, бизнес перестал тратить. Но нет. Опрос CIO российских компаний показывает куда более странную картину: проблема не в технологиях, а в самих компаниях. Около 50% ИТ-директоров признают, что внедрения буксуют из-за инертных процессов, страха изменений и желания «ничего не сломать». В итоге бизнес выбирает короткие PoC и локальные решения вместо больших трансформаций. ИТ готовы покупать — но только без риска, боли и сюрпризов.

Когда внедрять страшно, а ошибаться дорого, начинаются разочарования. Эксперты ГК ЛАНИТ фиксируют то, о чём в отрасли шепчутся давно: в 2025 году рост ИТ-рынка замедлился, облачный сегмент просел, а спрос сместился в сторону сложных кастомных решений. Универсальные платформы оказались слишком общими, а подписки — слишком дорогими. Бизнес всё чаще выбирает больную, долгую, но понятную кастомизацию вместо красивых обещаний «из коробки».

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

Пока рынок внутри страны сжимается, часть российских ИТ-компаний делает самый рациональный шаг — выходит за пределы России. По данным ComNews, более 40 отечественных ИТ-компаний уже продают свои решения во Вьетнаме, а около 14 открыли там полноценные представительства. АТР перестаёт быть «экзотикой» и становится реальным источником выручки. Экспорт больше не выглядит как стратегия роста — это способ остаться на плаву, когда дома слишком тесно.

Российский ИТ-рынок в 2025-м выглядит как парковка после распродажи: тихо, пусто и слегка тревожно. Компании банкротятся, бюджеты режут, решения принимают медленно и с дрожью в коленях. Но у этой истории есть обратная сторона. Пока внутри страны экономят, за рубежом продолжают покупать — прагматично, без пафоса и за живые деньги. ИТ-бизнес снова учится делать то, что давно должен был: конкурировать, считать, адаптироваться и продавать не «планы», а результат. Да, здесь пусто. Зато там — густо. И, что особенно приятно, платят вовремя.

И если что, нам сегодня 14 лет 🥂

Внимание: открыта вакансия менеджера проектов!

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

Чем ты будешь заниматься (спойлер: не херней)
- Вести клиентов Elgrow — от первого «а давайте созвонимся» до спокойного «спасибо, было приятно работать».
- Понимать, что клиент на самом деле хочет, даже если он сам пока не уверен.
- Быть связующим звеном между клиентом и командой разработки (и не теряться между ними, как багаж в Шереметьево).
- Контролировать ожидания, сроки, договорённости и здравый смысл.
- Иногда — аккуратно говорить «нет», потому что «да» здесь приведёт к пожару.

Ты нам подойдёшь, если:
- Умеешь общаться с людьми без скриптов и пластиковых улыбок.
- Не боишься сложных клиентов и не теряешься при словах «ERP», «интеграция» и «а это точно в ТЗ было?».
- Понимаешь, что IT-проекты — это не магия, а процесс (иногда шумный, но управляемый).
- Любишь порядок в договорённостях и ненавидишь фразы «мы же вроде договаривались».
- Умеешь держать лицо, когда клиент в десятый раз меняет мнение.

Опыт в IT, digital, агентстве или студии — большой плюс. Опыт «я всё понял, сейчас спрошу у разработчиков» — вообще золото.

Что мы предлагаем
- Работу в Elgrow — студии с 14+ годами реальных проектов, а не презентаций ради презентаций.
- Клиентов из бизнеса, а не «стартап за идею».
- Вменяемую команду, с которой можно говорить нормальными словами.
- Гибкий формат работы (офис / гибрид / удалёнка — обсудим).
- Жалование в 120 - 250 т.р в месяц (зависит от твоего скилла и опыта)
- Возможность расти: в аккаунт-директора, проджект-менеджера или куда захочешь, если есть голова.

Чего точно не будет
- Холодных звонков «по базе».
- Продаж «впарь любой ценой».
- Токсичного микроменеджмента.
- Крика «почему клиент ещё не доволен?!» без контекста.

В 2026 году можно чувствовать себя очень умным человеком. Одна нейросеть напишет вам техническое задание. Другая — сравнит стеки. Третья аккуратно разложит аргументы в таблицу с колонками “производительность”, “масштабируемость” и “современность”. Всё выглядит настолько логично, что остаётся только расслабиться и получать удовольствие.

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

Сейчас я нахожусь в пресейле одного проекта, где стек обсуждается с почти научной серьёзностью. Сравниваются цифры. Приводятся тесты. Делается вывод: один фреймворк быстрее другого.
И в этот момент всегда хочется задать простой вопрос: а это “быстрее” оно сейчас с нами в этой комнате?

Очень часто собственники задают неправильные вопросы, хотя звучат они донельзя логично: “Что быстрее?”, “Что современнее?”, “Что выдержит 15 тысяч пользователей, одновременно нажавших одну кнопку?” Проблема в том, что эти вопросы возникают слишком рано. Когда у продукта еще нет подтвержденного спроса и понятной нагрузки, обсуждать предельную производительность — это как проектировать скоростную автомагистраль, не зная, поедет ли по ней хотя бы один автомобиль.

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

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

Избыточная сложность почти никогда не выглядит как ошибка. Она выглядит как предусмотрительность. Добавим ещё один слой “на будущее”. Заложим масштабирование “с запасом”. Подготовимся к росту, который пока существует только в презентации. И в этот момент проект начинает медленно дорожать. Больше инфраструктуры — больше времени на настройку. Больше компонентов — больше точек отказа. Больше “правильных решений” — меньше скорости. Команда тратит недели на согласование технических деталей, которые не приближают продукт к рынку. Релиз откладывается. Гипотезы не проверяются. Обратная связь не собирается. Зато архитектура выглядит впечатляюще. Самое ироничное в том, что сложность почти всегда оплачивается дважды. Сначала — в бюджете. Потом — в невозможности быстро изменить направление, когда рынок говорит: “ребята, нам нужно немного другое”.

И в этот момент становится понятно: дело было не в выборе технологии. Дело было в выборе масштаба задачи. И вот этот вопрос нельзя просто взять и делегировать алгоритму.
Нейросеть отлично отвечает на вопрос “что возможно”, но она не отвечает на вопрос “что уместно”. Она не знает вашей финансовой модели. Не чувствует, насколько команда способна переварить сложность. Не понимает, где вы строите систему, а где — иллюзию контроля. Её задача — расширять поле вариантов, а не сужать его до “единственно правильного”. Поэтому нейросеть не нужно заменять. Её нужно правильно использовать. Она может ускорить анализ, подсветить альтернативы, проверить логику. Но решение о масштабе — это всегда выбор осознанный. Алгоритм считает. Человек несет ответственность. И пока эти роли не перепутаны, технологии работают на бизнес. Как только перепутаны — бизнес работает на технологии...

У меня все

На прошлой неделе, в роли независимого приглашённого эксперта, проводил тендер на разработку сайта и мобильного приложения для стартапа. Было полноценное ТЗ. Структура продукта, роли, сценарии, интеграции, требования. Всё аккуратно разложено. Не салфетка с номером телефона из ресторана. Документ, по которому сам бы работал. И вот что оказалось интересным: большинство потенциальных подрядчиков ТЗ даже не открыли. Зато все, как один, настаивали на встрече, без которой «посчитать сроки и стоимость проекта невозможно». Разумеется, встречи состоялись и представляли они собой трату времени на хвастовство портфолио и какими-то непонятными достижениями. Иногда даже были вопросы, ответы на которые есть в техзадании.
Технарей же на встречах либо не было, либо они подключались где-то удаленно (иногда из машины, иногда без камеры) и, чаще всего, на базовые вопросы касательно своей квалификации ответить не могли.
Финал был ещё красивее. Мы получали «Коммерческое предложение»: 20 страниц достижений, наград и логотипов. И одна строка по делу: «Стоимость — 300 000, или 800 000, или 1 500 000, или 3 000 000. Без калькуляции. Без декомпозиции. Без логики. Просто цифра.. Как прогноз погоды. У меня закономерно возник вопрос: что стало с рынком малой разработки? Пресейл превратился в формальность? Продажи окончательно отделились от производства? Техническая экспертиза больше не участвует в оценке? Или никто не готов тратить ресурс до подписания контракта?
Если говорить прямо — так считать проекты нельзя. Разработка, пусть даже и малая, — это инженерная дисциплина. Инженерия начинается с декомпозиции. Если нет разбивки на функциональные блоки, если не оценена трудоёмкость, если не обозначены риски, если не определён состав команды — это не оценка. Это рождественские гадания. А их в IT всегда оплачивает заказчик.
Плохой пресейл почти гарантирует: смещение сроков, рост бюджета, бесконечные «допработы», и конфликт в середине проекта. Почему? Потому что неопределённость никуда не исчезает. Она просто переносится на этап исполнения.
Зрелый подрядчик ведёт себя иначе. Он либо приходит с видением сразу — даже без идеального ТЗ, опираясь на опыт десятков проектов. Потому что понимает типовые архитектурные сценарии, узкие места и экономику разработки. Либо, если проект действительно сложный, он тратит встречу на проект. Не 40 минут про награды и логотипы клиентов, А 90% времени — про архитектуру, модель данных, интеграции, риски, сценарии роста. И только 10% — про себя.
Он может сказать: «Вот три возможных варианта реализации с плюсами и минусами». «Вот где будет дороже». «Вот где зона неопределённости». И даже если цифра пока диапазонная — она объяснена. Потому что пресейл — это не просто этап продажи. Это первая точка проектирования.
А если проектирование начинается после аванса — значит, оно просто оплачивается позже. Если подрядчик не инвестирует в понимание продукта до подписания — он не будет инвестировать в архитектуру во время разработки. А разработка без архитектуры всегда заканчивается одинаково: сдвинутыми сроками, пересборкой решений и разговором о «неучтённом объёме». Хороший пресейл — это не услуга для клиента. Это маркер профессиональной культуры компании. И если его нет — стоит ли удивляться всему остальному?

На праздниках до меня наконец докатилась эта модная Open Claw. Решил поставить её на отдельный VPS — эксперименты с ИИ разумнее держать подальше от рабочего компуктера. Дёргать DevOps в законный выходной — сомнительная управленческая практика. Поэтому я, эксперимента ради, решил сходить в интерфейс хостинг–провайдера чуть дальше чем до кнопки «оплатить счёт». Поднял сервер, настроил окружение, прокинул домен, завёл SSL. Без многочасового серфинга по мануалам — просто перекидываясь скриншотами с ChatGPT.

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

Операционная DevOps-рутина

Настройка VPS, конфиги Nginx, Docker-compose, базовые CI/CD, деплой типового сервиса. Это больше не барьер входа. Раньше это требовало: опыта, мануалов и форумов, набитых шишек и такой-то матери. Сегодня — это пошаговый диалог с ИИ. DevOps как инженерная дисциплина не исчезает, но порог входа в инфраструктуру резко снизился.

Типовой backend

CRUD, REST API, схемы БД, валидации, миграции. Это предсказуемые конструкции. AI их пишет быстро и часто достаточно аккуратно. Раньше на это уходили часы. Теперь — секунды. Это не революция. Это автоматизация шаблонного труда.

Документация и технические описания

OpenAPI, README, черновики ТЗ, регламенты. То, что раньше делалось «когда будет время», теперь делается сразу. AI не думает за архитектора, он снимает нагрузку по формализации.

Первичный code review

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

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

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

Рынок начинает иначе оценивать специалистов. Ценность смещается: от объёма кода — к качеству решений, от «умею реализовать» — к «понимаю, что нужно реализовать», от исполнения — к системному мышлению. И здесь начинается самое важное. AI может предложить архитектурный паттерн. Но он не отвечает за рост х10. Может собрать стек. Но не несёт ответственность за TCO через три года. Может написать сервис. Но не принимает решение, когда нужно упростить, а когда — усложнить. И главное — он не управляет рисками. В инженерии есть точка, где заканчивается генерация кода и начинается ответственность. И именно там по-прежнему возникает настоящая ценность человека.

Мой эксперимент с VPS не сделал меня DevOps. Он просто напомнил очевидное: исполнение больше не является узким местом. Разработка больше не про то, кто быстрее пишет. Она про то, кто лучше понимает, что именно нужно строить — и зачем.

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

«Дмитрий, привет! Ты о такой штуке слышал? Телега.ме Что думаешь в плане безопасности?»

На самом деле, вопрос ведь в другом: что вообще делать с коммуникацией, если привычная инфраструктура вдруг перестаёт работать?

За последние годы Telegram незаметно стал для многих компаний гораздо большим, чем просто мессенджером. Через него общаются команды, координируются подрядчики, ведутся проектные чаты, пересылаются документы и файлы, работают боты и сервисы. Для многих это уже не просто удобный инструмент общения, а фактически слой рабочей инфраструктуры — быстрый, привычный и встроенный в повседневные процессы. И если смотреть на ситуацию спокойно, у компаний остаётся несколько базовых сценариев.
Самый очевидный — заменить Telegram другим мессенджером с похожей архитектурой. В российском контексте чаще всего обсуждают MAX, который позиционируется как коммуникационная платформа с каналами, ботами и мини-приложениями. Чтобы понять, насколько это реальная замена, имеет смысл посмотреть на ключевые элементы экосистемы. Формально набор функций у них действительно похожий: каналы для распространения контента, боты и API для автоматизации, мини-приложения внутри мессенджера. Да-да, MAX — это не ICQ на государственном уровне, разработческая платформа там действительно есть.

При этом у MAX есть и собственная логика развития. Платформа изначально строится как суперапп, с интеграциями с российскими сервисами — например, интеграция с государственными сервисами вроде «Госуслуг» , платежными системами, доставкой лекарств и алкоголя (главное — не вместе). В общем, некая попытка построить WeChat со славянским лицом. Но дальше начинаются детали, которые для компаний обычно оказываются куда важнее галочек в сравнительной таблице. Например, в Telegram существует режим сквозного шифрования сообщений — end-to-end encryption в секретных чатах. В MAX такую штуку официально не завезли. Кроме того, инфраструктура сервисов различается: Telegram использует собственную распределённую облачную архитектуру, тогда как MAX работает на инфраструктуре VK. Формально это всё ещё «мессенджер с каналами и ботами». Но архитектурно это уже другая экосистема — с другой моделью хранения данных, контроля инфраструктуры и доверия к платформе. И именно на этом месте разговор о «просто перейти на другой мессенджер» обычно перестаёт выглядеть таким простым.

Впрочем, MAX — это лишь один из возможных сценариев. И, судя по обсуждениям, далеко не для всех он выглядит правильным выбором. Поэтому следующий вариант, который довольно быстро всплывает в разговорах, — приватные мессенджеры. Самый известный из них — Signal. Он изначально строился вокруг одной идеи — максимальной приватности. Все сообщения в нём шифруются end-to-end по умолчанию, а сам протокол Signal считается одним из наиболее проверенных криптографических решений для мессенджеров. Более того, этот же протокол используется, например, в WhatsApp для защищённых сообщений. Звучит, казалось бы, идеально. Но здесь важно понимать одну вещь: Signal — это классический мессенджер, а не коммуникационная платформа.
Там нет каналов как медиаплатформы, нет экосистемы ботов, нет мини-приложений и интеграций, к которым многие привыкли в Telegram. По сути, Signal отлично решает одну задачу — безопасное общение между людьми.

Ну если вам мало приватности, то есть и более радикальный подход — децентрализованные мессенджеры. Самый известный пример — Element, который работает на базе протокола Matrix. Идея Matrix довольно простая. Вместо одного сервиса с одной инфраструктурой существует сеть серверов, которые могут общаться между собой — примерно так же, как работает электронная почта. Любая компания может поднять собственный сервер и подключиться к общей сети. Звучит довольно привлекательно: полный контроль над инфраструктурой, независимость от блокировок и возможность интегрировать коммуникацию прямо в корпоративный контур...

... Но, как обычно, есть нюанс. Matrix — это скорее инженерное решение, чем массовый продукт. Такие системы чаще используют компании, open-source-сообщества или организации с высокими требованиями к контролю инфраструктуры. Для обычных пользователей это всё ещё немного сложнее, чем просто установить мессенджер из App Store и написать «привет».

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

И, наконец, есть ещё один сценарий. Самый простой. И, если честно, скорее всего, он и останется самым массовым.

Ничего не менять.

Просто продолжать пользоваться Telegram — но уже через VPN. Технически это самый короткий путь: установить VPN и работать дальше примерно так же, как раньше. Для личных чатов это вообще почти незаметное изменение. Но для компаний всё немного сложнее. Во-первых, не все готовы постоянно использовать VPN. Во-вторых, в корпоративных сетях такие решения нередко запрещены политиками безопасности. А в-третьих, инфраструктура, которая работает «через обход», всё-таки остаётся инфраструктурой с дополнительным слоем сложности. Поэтому для частного использования этот сценарий вполне реалистичен. А вот для рабочих процессов он обычно рассматривается скорее как временная мера.

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

На прошлой неделе знакомый прислал запрос на аутстаффинг React-разработчиков для одного своего клиента. Оказалось, что это стартап. Причём на казенных деньгах — с дедлайнами, отчётностью и всеми вытекающими. Дальше больше: на вопрос, какую именно команду нужно усиливать, выяснилось, что усиливать, в общем-то, некого. Нет ни тимлида, ни разработчика, ни девопса — вообще никого, кто хотя бы делает вид, что понимает, как всё это должно работать. Бэклога, декомпозиции задач, ТЗ — тоже нет. Есть Figma и дизайнер, который, как выяснилось позже, ещё и кофаундер. В этот момент, у нормального человека включается базовый инстинкт самосохранения и он вежливо ссылается на 100% загруз и невозможность взять проект в работу. Но мне стало очень интересно, что же такое скрывается за всей этой ситуацией…

(спойлер: всё было ровно так, как я и предполагал).

После разговора с товарищем (сам фаундер, разумеется, был очень занят и встретиться не смог) картина начала проясняться. Идея была высоко оценена государством, под неё выдали грант. Полгода назад.
Дальше — всё по учебнику. Фаундер, не сильно разбираясь в разработке, находит программиста. Одного (классика). Программист что-то делает и в какой-то момент просто исчезает (опять классика). На текущий момент: до дедлайна и отчётности — полтора месяца. Из результатов — Figma (процентов тридцать от того, что вообще должно быть) и заготовки речи перед контролирующими органами, почему “не шмогла”.

Эх… ладно… Описали проект, определили то, как за оставшееся время выполнить полугодовой объем работ (благо опыт есть). Трижды отдельно проговорили одну простую мысль: «если стартуем не сейчас — не успеем» и отправили коммерческое.

Дальше начинается мое любимое — тишина. Понимая, что, скорее всего, напугали ценой и с проектом нам не по пути, спрашиваю у знакомого, как там дела? Ответ прекрасный: «ждёт коммерческие от других». Конкуренция — это хорошо. Рынок, все дела. Ждём ещё несколько дней — ничего. Убедившись, что дальше не поедем, все же решаю выяснить, как ответит фаундер. А фаундер… перестал выходить на связь.

Мораль? В таких историях проблема не в разработчиках, которые «пропали». Не в продукте и не в сроках, которые внезапно стали критичными. Проблема в отношении. Когда проект изначально запускается без команды, без структуры и без понимания, кто за что отвечает — это не временные сложности. Это способ работы. Когда полгода проходят без результата, без фиксации решений и без какого-либо контроля — это не «не повезло с подрядчиком». Это предсказуемый итог отсутствия управления. А когда в критической точке вместо решений начинается ожидание, сравнение и исчезновения — это уже не сбой. Это закономерное продолжение той же самой модели.

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