Сроки — как прогноз погоды? ☀️

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

🗂 Согласования. Требуют гораздо больше времени, чем кажется. Когда вам называют сроки до старта работ, в них обычно не заложено время на обратную связь. Представьте дизайн типового ecom-проект с 100+ экранами: предварительное согласование, затем правки, потом утверждение всего пула, а еще адаптив под минимум 4 разрешения. И ведь нужно не просто посмотреть, но и вникнуть, дать конкретные замечания. Сколько на это заложить времени?

👥 Команда. Еще один критический фактор. Люди болеют, уходят в отпуск. Конечно, эти риски лежат на подрядчике, и если его менеджмент умеет виртуозно жонглировать ресурсами, то сроки едут не сильно или вовсе не едут. Тут многое зависит от проектного менеджера — сильный PM вывезет проект с любой командой.

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

🔗 Интеграции. Сегодня есть почти в каждом проекте — 1С, ERP, Microsoft Dynamics или какая-нибудь шина данных. И даже при максимально качественном предпроектном обследовании что-то может пойти не так. Данные в каталоге могут оказаться заполненными наполовину или быть в неожиданном формате.

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

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

🤔 Недооценка сложности задач. Это классическая проблема — разработчики склонны оптимистично оценивать задачи, не учитывая "закон Хофштадтера": все занимает больше времени, чем кажется, даже с учётом закона Хофштадтера.

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

✅ Нечёткое определение готовности. Без чётких критериев приёмки или "definition of done" команды могут бесконечно полировать функциональность или, наоборот, считать задачу завершённой раньше времени.

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

Минимизируем риски

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

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

— 🧑‍⚕️ Резервирование ресурсов. Создание резервных ресурсов и планов на случай отсутствия ключевых сотрудников (по болезни, отпуску).

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

— 🧩 Планирование рисков. Идентификация потенциальных рисков на старте проекта и подготовка стратегий для их минимизации.

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

Это база. Laravel + Orchid = ❤️

Не только Битриксом едины. Иногда мы меняем модули и компоненты на роуты и контроллеры — Laravel в нашем арсенале давно. На нём мы собираем всё: от бэкендов под мобилки до админок для магазинов. А дальше — как фантазия подскажет 😅

Если CMS, с одной стороны, накладывает на нас ограничения, но при этом предлагает мощную встроенную админку, то фреймворки такой роскоши нам не дают. Когда бекенд на Laravel, а админка нужна, у нас есть несколько путей:
🔹 Писать с нуля на HTML – можно даже купить готовый шаблон, есть весьма приличные варианты.
🔹 Сделать отдельный фронт на Vue или React – пишем API для редактирования, отдельно собираем фронтенд.
🔹 Использовать готовое решение – наиболее известные сейчас: SleepingOwl, Laravel Nova и Orchid.

Когда-то давно мы использовали SleepingOwl, но по ряду причин отказались от него. Laravel Nova хороша, но платная. В итоге мы обратили внимание на Orchid – визуально приятное, опенсорсное, кастомизируемое и регулярно обновляемое решение.

Это база
⚡️ Быстрое создание админок – Orchid позволяет быстро разрабатывать сложные админ-панели без необходимости писать много кода. Используется декларативный стиль, что делает код более читаемым.

📊 Гибкие таблицы и формы – Встроенные механизмы для работы с таблицами (TD, Layouts, Screens) позволяют легко создавать CRUD-интерфейсы, настраивать фильтрацию и сортировку данных.

🔐 Система разрешений (ACL) – Гибкая ролевая модель, которая позволяет управлять доступом на уровне пользователей, ролей и отдельных действий.

🎨 TailwindCSS + Turbo – В Orchid используется современный стек технологий, что делает интерфейс легковесным и быстрым без необходимости вручную писать HTML и CSS.

🧩 Гибкость и расширяемость – Можно подключать свои классы, middleware, события и сервисы, создавая кастомные модули и плагины.

Неочевидно
🧠 "Глобальные состояния" в Screens – Можно использовать $this->state() для хранения и передачи данных между методами внутри одного экрана (аналог Livewire). Это позволяет сделать более сложные и динамичные страницы без обновления.

🚀 Интерактивные элементы через AsyncAction – Orchid поддерживает асинхронные операции без перезагрузки страницы. Можно использовать AsyncAction для выполнения сложных запросов, отправки писем или обновления данных в фоновом режиме.

🔔 Поддержка WebSockets – Orchid позволяет легко интегрировать Laravel Echo и Pusher для создания real-time интерфейсов, но эта возможность редко используется. Можно делать обновления данных без перезагрузки.

🧵 Кастомные фильтры в таблицах – Помимо стандартных фильтров можно создавать сложные предустановленные фильтры, которые работают через QueryFilter. Это полезно для сложных отчетов и аналитики.

🛠 Использование Modifiers для форматирования данных – Можно создавать собственные классы модификаторов, которые изменяют отображение данных в таблицах без необходимости писать логику форматирования в экранах. Например, для автоматического преобразования дат, валют или статусов.

В итоге — Orchid оказался именно тем, что искали для Laravel-проектов. Прост в освоении, гибок в кастомизации и визуально приятен. Можно быстро собрать MVP, а потом не стыдно и в прод выкатить.

Боль, привычка или искусство?

Довольно много работаем с коробочными Битрикс24 — от энтерпрайзов до поменьше — и почти всегда на таких проектах всплывает тема интеграций. Битрикс24 с чем-то ещё.

Чаще всего это, конечно, 1С. Обычно в виде ЗУП — «Зарплата и управление персоналом». Вполне логично: когда у тебя 1000+ пользователей внутреннего портала, удобнее управлять ими централизованно через одну систему.

В целом для ЗУПа есть штатная интеграция. Пользователей и немного данных она передаёт, но не более.

🔐 Проблема закрытых контуров
Частая история: 1С живёт в изолированном контуре, где интернет даже не ночевал. А интеграция даже у коробочных Битриксов работает через серверы вендора. Получается, что связать «открытый» Битрикс24 и «закрытую» 1С — почти невозможно.

А бывает и хуже: обе системы закрыты, и каждая — в своём контуре. Это уже совсем весело.

🧰 Какие есть варианты интеграции
Разберу по степени сложности и зрелости проекта.

🗂 1. Обмен через файлы
Форматы могут быть любые: CSV, XML, Excel.
1С формирует файл, кладёт у себя. Прокси-сервер, у которого есть доступ и туда, и наружу, отгружает файл в Битрикс24. Дальше всё обрабатывается. Обратно — по той же схеме.

Плюсы:
– быстро
– просто
– дешево

Минусы:
– сложно контролировать
– мало гибкости
– можно сломать одной запятой

🔌 2. API с обеих сторон
На стороне 1С — веб-сервис. На стороне Битрикс24 — обработчик, который знает, что и куда тащить. Прокси по-прежнему нужен. Такой вариант требует больше усилий, особенно если потоков несколько: пользователей гоним, задачи, отпуска, статусы.

Если настроить всё грамотно — один из самых универсальных способов. Особенно если есть потребность в двустороннем обмене.

🛢 3. SQL-шина
Работает как прокси. Оба участника читают и пишут в общую базу. Обычно один поток = одна таблица. Например, пользователи из 1С → в Битрикс24 — это один поток. Можно, конечно, всё в одну таблицу, но тогда больше шансов на косяки.

Хорош тем, что всегда можно зайти, посмотреть, что передано, что зависло, что обработалось. Прозрачно и удобно. Я бы назвал это «шина на коленке», но работает стабильно.

🏗 А если нужно что-то посерьёзнее?
Когда обменов много, системы становятся сложнее, появляется больше направлений и требований по отказоустойчивости — начинают появляться полноценные брокеры сообщений: Kafka, RabbitMQ, всё чаще — Datareon.

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

🤔 Что выбрать?
Зависит от задач. Вот примерная логика:
– если обмен простой и редкий — хватит файлов
– если данные гоняются туда-сюда часто — уже API
– много направлений обмена, хочется прозрачности — SQL
– если проект масштабный и планируется подключение других систем — пора смотреть в сторону брокеров

⚠️ О чём часто забывают
– CSV может поломаться от одной запятой
– API требуют авторизации, логирования, повторных попыток
– SQL-шина без чётких расписаний может вызвать гонки данных
– Kafka и Rabbit — мощно, но требовательно, особенно к инфраструктуре и команде

🔒 Безопасность и устойчивость
Независимо от подхода — критично:
– логировать обмен
– ограничивать доступ
– обрабатывать ошибки
– предусмотреть восстановление после падения

Особенно если данные важные, а обмен идёт в реальном времени.

🧩 Что удобно в реальных проектах
– возможность вручную «толкнуть» данные в систему
– визуализация очередей (видно, что висит и почему)
– простое добавление новых параметров без переписывания всей логики
– защита от потери данных, подтверждение доставки

Самооборона с гейзенбагом 🥋

💡 Гейзенбаг (Heisenbug) — это такой баг, который исчезает или меняет поведение, как только ты пытаешься его исследовать. Смотришь — и он уже ведёт себя по-другому. Почти как квантовая частица 🧙‍♂️

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

Ситуация вымышленная, все совпадения случайны (ну почти).

На входе: корпоративный сайт на Битриксе, который отдаёт API. Фронт — на Vue 3 / Nuxt.
Симптомы: периодически, в разное время, часть фронта просто перестаёт работать, а в браузере — ошибка: Nuxt не работает.

Примерно через 20–60 минут всё само «оживает» и продолжает работать как ни в чём не бывало.

Что говорят логи?
🔍 pm2 — пусто (есть варнинги, но не критичные)
📄 nginx — чисто
🐘 php — молчит
🧱 Битрикс — почти ничего, а что есть — не страшно
🖥 Нагрузка на сервер — не выше 20%
💽 Жёсткие диски — расслаблены, курят бамбук

Мы прыгали с бубном вокруг сервера, но:
— эмуляция нагрузки не даёт сбоя
— API отвечает
— тестовый стенд работает как часы

Железо и нагрузка тут не при чём.

Так мы жили пару месяцев, перебирав все мыслимые и немыслимые варианты 🧠

Пока однажды...

В access.log заметили, что часть трафика отбраковывается с ошибкой 403 ❌
Причина — попытка инъекции вредоносного кода. С одной стороны — хорошо: злоумышленник не пробрался 👮‍♂️
С другой — странно. Кто именно блокирует?

Выяснилось: проактивный фильтр Битрикса.
Стало интересно. Копаем глубже ⛏️

Симулируем атаку: подставляем «вредный» код в URL и… ловим бан от Битрикса.
Фронт частично перестаёт работать. Вот оно! 🧩

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

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

🚫 Вуаля: фронт частично недоступен, API под блоком.
🔥 Причём инициатором бана оказался... он сам 🤦

P.S.
Решение «сложить фронт и бэкенд на один сервер и один домен» — не наше, так что не кидайтесь тапками 👟

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

Разведчики и сапёры 💣

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

Почти любая смена подрядчика и/или команды на IT-проекте — это боль. Дорого, долго и зачастую с кучей неожиданностей и нюансов.
— 💀 легаси
— 📄 много/мало документации
— 🤷‍♂️ и всё вытекающее

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

Что случилось с предыдущим подрядчиком?
Просто так никого не меняют. Это долго и затратно.
Обычно причина — медленно делают, дорого берут, или делают "как-то не так".
Но бывает, что дело не в них: сроки были космические, ТЗ писалось на салфетке, а команду казнили "ритуально". Лучше это знать до входа в проект, а не через пару спринтов.

Доступы к проекту и админке
Git, история коммитов, ветки, .gitignore, админка — это как медицинская карта проекта.
По этим вводным уже можно понять, жив проект или скорее в коме.
Если всё в порядке — круто. Если хаос — значит, закладываем время на реанимацию.

Что на серверах?
Обновлённое ли окружение, какие версии пакетов, насколько всё запущено или хорошо.
Сервер — это не просто железо. Если на нём правят прод через nano — ну, ты понял.
Как обстоят дела с бэкапами.

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

Кто принимает решения?
ЛПР — лицо принимающее решения. Его нужно найти и познакомиться.
Потому что можно потратить кучу времени на фичу или дизайн, а потом окажется, что согласовывать всё должен человек, которого ты даже в переписке не видел. И всё по новой.

История проекта
Сколько команд уже сменилось? Были ли свои разработчики? Сколько раз всё начинали с нуля?
Контекст важен. Он может объяснить, почему одни фичи "просто есть", а другие "мы не трогаем это с 2018 года".

Какие у проекта цели?
Важно понять, что клиент считает успехом.
Быстрое развитие? Безопасность? Рефакторинг? Чтобы ничего не трогали вообще?
Если ожидания не совпадают с реальностью — беда будет не в коде, а в коммуникации.

Как всё устроено внутри?
Есть ли трекер задач, кто их ставит, есть ли процессы ревью и деплоя?
Бывает, проект выглядит как корабль, но рулит им один человек в шторм и без карты.
Хорошо бы это понять до того, как вы станете штурманом.

Клиент вовлечён или просто "отдал и забыл"?
Если он на связи, быстро принимает решения, участвует — шансы на успех выше.
Если "напишите бота и отпишитесь через месяц" — нужно закладывать время на "ожидание ответа от клиента".

Есть ли техдолг, и что о нём думают?
Технический долг есть почти везде. Но важно: осознают ли это? Хотят ли с ним что-то делать?
Если не хотят — это их право. Главное, чтобы вы знали, с чем работаете, и могли это оценить.

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

Уверенный пользователь ПК

Когда-то фраза "уверенный пользователь ПК" была неотъемлемой частью каждой второй вакансии и каждого третьего резюме. А иногда — в довесок: "уверенный пользователь пакета Microsoft Office", "глубокое знание Excel" и прочие артефакты корпоративной эпохи.

Справедливости ради, далеко ходить не надо — такие формулировки можно найти и сейчас, если чуть-чуть покопаться. Даже среди IT-вакансий.

На мой взгляд, это уже чистой воды атавизм. Почти всё, до чего дотянулись IT и что хоть немного экономической целесообразности, уже давно оцифровано. И, как следствие, умение пользоваться интерфейсами/ПК — становится таким же обязательным, как умение говорить или дышать.
То есть "уверенное пользование ПК" давно уже не скилл, а фон — как стрессоустойчивость, коммуникабельность и любовь к работе в команде.

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

Но не об этом сегодня.

Если уж выбирать новый аналог для "уверенного пользователя ПК", то, скорее всего, это будет "уверенный пользователь чат-ботов", "навыки prompt engineering’а", или "умение взаимодействовать с нейросетями". Новый хардскилл, который прямым текстом влияет на эффективность конкретного человека.

ИИ, вероятно, не заменит программистов, дизайнеров, аналитиков — ну, разве что слегка потреплет копирайтеров. И то — не всех. Но он точно трансформирует ландшафт. То, что раньше делалось день, теперь делается за пару часов.

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

Выводы. Если слишком часто использовать ИИ — начинаешь немного тупеть. Это правда.
Но если не использовать — ещё хуже. Новые технологии надо не бояться, а осваивать и применять. И желательно — до того, как "уверенный пользователь нейросетей" станет новым "уверенным пользователем ПК".

Мистер Монолит vs банда микросервисов 🥊

Объявим участников. В правом углу — бывший чемпион в супертяжелом весе, грозный и опытный Мистер Монолит. В левом — молодая и дерзкая банда микросервисов, лёгкая на подъем, но со своим характером.

Я видел в жизни несколько настоящих монстров. Один монолит, например, собирался больше пяти часов, и компания построила свой собственный CI, чтобы просто не стоять на месте. С другой стороны, видел и микросервисную архитектуру, в которой для запуска требовалось 11 балансировщиков. Просто представьте себе делать это руками.

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

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

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

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

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

Дежурства становятся весёлыми. В два часа ночи кто-то из микросервисов «чуть-чуть подустал» — и просыпается именно тот, кто знает, где у этого сервиса находится печень. А если он в отпуске и без связи? Ну, держитесь. Монолит, при всех его грехах, даёт хотя бы общее понимание происходящего.

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

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

🎭 А ведь и с монолитом не всё так просто. Он растёт, толстеет, становится всё более громоздким, и в какой-то момент вы понимаете, что разделить его теперь — это как распилить самолёт на ходу.

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

Что же выбрать? Позвольте открыть портал в ад и сказать: я за здравый смысл. Большинству проектов отлично подойдёт разумно устроенный монолит, один или два сервиса, ничего сверхъестественного. А дальше — наблюдать. Как только вы начинаете тратить 5% времени на борьбу с архитектурой — самое время подумать о разделении.

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

В реальности почти не бывает чистых монолитов или идеальных микросервисов. Всё вокруг — гибрид, компромисс, эволюция. Главное — понимать, во сколько обойдётся трансформация и насколько больно её будет делать. Всё остальное — детали.

📊 У нас было 60 минут, 50 участников, одна презентация и один микрофон.

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

Поговорили о самом важном:
— Какие тендеры действительно стоит брать, а какие лучше сразу пропускать
— Как понять, что тендер “под кого-то”
— На какие грабли мы наступали сами (и как их теперь обходим)
— Почему тендеры могут быть не только головной болью, но и возможностью для роста

🕓 Немного не рассчитал количество слайдов и темп, поэтому в финале пришлось ускоряться, но мы всё успели. А в конце пообщались — 15 минут живых, конкретных вопросов и ответов.

🎥 Запись встречи уже доступна в личном кабинете ARDA:
https://lk.arda.digital/video/165/

Если тема тендеров вам близка или только начинаете в неё погружаться — очень рекомендую посмотреть.

Спасибо всем, кто был в онлайне! До встречи на следующих эфирах 🙌

Когда-то и мы были дикими 🦖

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

Сейчас, попадая на проект без Git, мы испытываем недоумение: как компания жила и развивала свой проект без системы контроля версий? Например, совсем недавно к нам обратился клиент с запросом на доработку e-commerce проекта. Начав разбираться, мы увидели, что изначально это был шаблонное решение, но со временем в него добавили массу кастомных решений – местами удачных, местами не очень.

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

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

Базовый набор инструментов для работы над проектами
1. Git – это база 🖥
Без Git сегодня никуда. Это не только система контроля версий, но и страховка от случайных ошибок и удобный инструмент командной работы. Мы используем локальный GitLab, но если у клиента уже есть свой репозиторий, работаем с ним.

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

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

3. CI/CD – автоматизация развертывания ⚙️
На некоторых проектах без CI/CD просто невозможно работать. Хотя не всегда он нужен в минимальном наборе, на серьезных проектах это must-have. Мы используем GitLab CI/CD для автоматизации развертывания и тестирования.

4. Документация – экономия времени в будущем📚
Честно говоря, мы сами не всегда вели документацию, но это неизменно приводило к проблемам. Поэтому сейчас придерживаемся правила:
– Завершил задачу – добавь описание в таск-трекер.
– Внес значительное изменение – задокументируй в базе знаний.

Для этого используем комбинацию Яндекс.Трекера и его встроенной вики. Главное – неважно, какой инструмент вы используете (хоть Google Docs), важно, чтобы документация была.

5. Резервное копирование 🗃
Перед любыми изменениями на боевом сервере надо убедиться, что бэкапы: существуют, целостны, разворачиваются без проблем.

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

6. Мониторинг – чтобы не ловить проблемы постфактум 🔍
Даже качественный код не спасает от внешних факторов: сервер может упасть, провайдер может отключить услугу, модули могут сломаться. Чтобы не узнать о проблеме от разъяренного клиента, мы используем три инструмента:

Uptime – отслеживание доступности проекта и сбор статистики.
Zabbix – мониторинг состояния сервера (нагрузка, память, дисковое пространство).
Sentry – слежение за ошибками на фронтенде и бэкенде. Да, он потребляет 15 ГБ ОЗУ, но зато все ошибки наглядно и с алертами.

В поиске новых инструментов
Сейчас мы рассматриваем варианты ПО для анализа статической безопасности кода, но пока находимся в процессе изучения.

А какие инструменты используете вы?

Киллер-фича 🚀

Хотите приложение для своего проекта? Допустим, у вас есть портал, сервис или интернет-магазин, и вы хотите сделать для него мобильное приложение. Какие у вас есть варианты?

Нативные приложения 📱
Первое, что приходит на ум, — это нативные приложения для iOS и Android. Для их разработки используются Swift и Kotlin. По сути, это два отдельных проекта, объединенных только общим API и дизайном (и то далеко не всегда). У каждой платформы свои особенности, поэтому неудивительно, что иногда Android уходит вперед в развитии, а иногда наоборот. Разработка нативного приложения требует ресурсов, ведь поддерживать две платформы сразу — это двойная работа, больше затрат на тестирование, исправление багов и обновления.

Кроссплатформенные решения 🔄
Следующий вариант — кроссплатформенные технологии. Например, Xamarin (жив ли он еще?), React Native или Flutter, который сейчас на коне. В этом случае процесс разработки схож: сначала создаем API, затем собираем дизайн, интегрируем аналитику, настраиваем пуш-уведомления и наконец запускаем приложение. Поддерживать такой проект проще, так как код один, но все же в некоторых случаях приходится делать доработки под каждую платформу. Это дешевле, чем нативная разработка, но все равно может быть затратным.
Но что, если и этот вариант не подходит по бюджету? 🤔

PWA — альтернатива ⚡️
Здесь на сцену выходит PWA — технология, которая позволяет создать приложение на базе обычного веба. Прогрессивные веб-приложения (Progressive Web Applications) представляют собой улучшенные версии привычных сайтов, которые ведут себя как мобильные приложения.

Существует также TWA (Trusted Web Activities), которая позволяет запускать веб-сайты как приложения на Android, используя Chrome Custom Tabs, и IWA (Isolated Web Apps) — изолированные веб-приложения, работающие в ограниченной среде. Однако в большинстве случаев никто не вникает в эти нюансы и называет все просто PWA.
Мы используем эту технологиями уже 6-7 лет и можем сказать: работает, можно брать.

Как создать? 🛠
Если ваш проект уже работает на Vue или React, то считайте, что он готово, почти. В противном случае сначала нужно собрать API, затем создать отдельный фронтенд, ориентируясь на мобильное разрешение, и наконец интегрировать все вместе. Бэкенд может быть любым — хоть Laravel, хоть Битрикс, хоть даже WordPress (да-да, мы такое встречали). Главное, чтобы сайт работал по HTTPS.

Когда все готово, начинается магия. Загружаем проект на сервер и переходим на сайт PWA Builder или аналоги Аналогов довольно много. Указываем ссылку на наш PWA, ждем. Если есть ошибки в манифесте или других настройках, исправляем их и повторяем процесс. В результате получаем два исходника: один для Android, другой для iOS. Дальше загружаем их в магазины приложений, следуя стандартным инструкциям.

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

Минусы? 🤷‍♂️
Есть нюансы, с которыми придется мириться. Например, пуш-уведомления работают через браузер, а не как нативные. Но все же их можно настроить. Аналитика также имеет ограничения, поскольку PWA не обладает полным доступом к системным возможностям устройства. И наконец, PWA не может работать в офлайне. Хотя если речь идет об интернет-магазине, то какая разница, ведь без интернета покупки все равно никто не делает?

Заключение 📊
По последним исследованиям, спрос на PWA растет, и это неудивительно. Решение обладает своими плюсами и минусами, но при этом работает стабильно, обходится дешевле, чем нативная разработка, и позволяет быстро выпускать обновления. Возможно, в будущем PWA станет стандартом, а пока это отличная альтернатива.

Розыгрыш MacBook Air

30+ экспертов из IT и digital собрались в одной папке, чтобы научить тебя оформлять кейсы, находить общий язык с заказчиками, управлять проектами и развивать личный бренд.

Подпишись на них и получи один из 3 призов:

🏆Главный приз — MacBook Air (M2).
🏆2 место: разбор карьерного трека от креативного директора Пиробайт.
🏆3 место: консультация по карьерному росту от секретного эксперта.

Как участвовать:

1. Подпишись на папку: https://t.me/addlist/fEvzl5khQT8yZTcy
2. Подтверди участие в боте
3. Отправь ссылку на бота своим друзьям — за каждого приглашённого человека ты получишь +1 призовой билет

🗓 26 апреля в прямом эфире узнаешь, какой приз достался тебе

Выполнил все условия? Тогда включай уведомления — и до связи 🚀

Участников: 745
Призовых мест: 3
Дата розыгрыша: 10:00, 26.04.2025 MSK (1 день)

Четырнадцать миллионов шестьсот двадцать пять вариантов 🎲

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

Эта история возникла после недавнего общения с товарищем. Когда-то мы помогали ему с eCommerce, но сегодня уже нет, и поэтому обсуждение попало сюда.

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

На первый взгляд задача кажется тривиальной, но под капотом у нас "всемогущий и всеобъемлющий Битрикс", а значит, придется приложить усилия.

Вариант 1: "Барский" 👑

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

Плюсы: решение гибкое, настроить его сможет практически любой пользователь.

Вариант 2: "Жестко в коде" 🖥

Прописываем логику прямо в коде — можно на PHP, можно на JavaScript. Определяем, когда показывать доставку, а когда нет. Главное — правильное серверное время. Можно скрывать доставку (не лучший вариант) или исключать ее из массива данных — здесь уже масса решений.

Этот вариант проще первого, но если что-то потребуется поменять, придется снова звать разработчика. В проекте, о котором идет речь, используется Vue, так что можно реализовать логику и там. Однако вариант так себе. 🤷

Вариант 3: "Калашников" 🔫

Создаем два PHP-файла: один включает доставку, другой выключает. Запускаем их по cron в нужное время — и готово.

Гибкость: можно легко менять расписание в cron. Однако для этого потребуются хотя бы базовые знания. Сами скрипты для включения/выключения доставки напишет ChatGPT за пару минут. В итоге задача вместе с настройкой cron займет пару часов. ⚡️

Выводы 🧐

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

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

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

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

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

Брокеры 📩
Допустим, вам срочно нужно организовать обмен данными между системами. Какой механизм передачи выберете, если вас разбудят среди ночи? Чтобы ответить на этот вопрос, разберёмся с основами.

Виды общения 💬
Общение — это фундамент любого взаимодействия, будь то между людьми или между системами. Самый привычный формат — диалог, когда один человек (N) передаёт информацию другому (Y) и ожидает ответ. Это классическая модель запроса и ответа.

Но бывают ситуации, когда N транслирует сообщение Y, не ожидая ответа. Например, рекламные рассылки или push-уведомления.

Существует также обмен через посредника. Представим, что N передаёт сообщение X, а тот, в свою очередь, распространяет его среди друзей C, D и E. Этот принцип реализован в мессенджерах и новостных рассылках.

Другой вариант — N записывает сообщение и оставляет его в специальном ящике. X может забрать его в удобное время. Здесь каждый получатель получает только одно сообщение.

Паттерны обмена 🔄
Сервисы и приложения взаимодействуют между собой, обмениваясь данными. Основные модели взаимодействия:
– Request-Response (Запрос-Ответ) – примером является работа HTTP, когда клиент делает запрос на сервер и ждёт ответа.
– One-Way (Односторонний обмен) или Fire and Forget (Отправил и забыл) – отправитель передаёт сообщение без ожидания ответа, как в случае с UDP-пакетами.
– Publish-Subscribe (Публикация-Подписка, Pub-Sub) – отправитель публикует сообщение в канал, а подписчики его получают.
– Point-to-Point (Точка-Точка) – каждое сообщение доставляется только одному получателю.

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

Роль брокеров 🏗
Брокер сообщений – это программный посредник, который реализует паттерны Pub-Sub и Point-to-Point. Его задача – упрощение маршрутизации, хранения и доставки сообщений. Использование брокера оправдано, если задачи требуют ресурсов, необходимо координировать много сервисов, требуется масштабируемость и отказоустойчивость.

Гарантия, очереди и топики 📜
При передаче данных возможны сбои, поэтому брокеры предлагают различные уровни гарантии доставки:
– At most once (Не более одного раза) – сообщения могут теряться.
– At least once (Хотя бы один раз) – возможна повторная отправка, чтобы гарантировать доставку.
– Exactly once (Строго один раз) – сообщения не теряются и не дублируются.

Брокеры реализуют два механизма работы:
– Очереди (Queue, Point-to-Point) – сообщение читается одним получателем и затем удаляется.
– Топики (Topic, Pub-Sub) – сообщение доставляется сразу нескольким подписчикам.

Среди множества решений можно выделить наиболее популярные: RabbitMQ, Kafka, Datareon. А иногда вместо брокера можно использовать SQL-базу данных как очередь, но это менее гибко.

RabbitMQ: "умный брокер, тупой потребитель" 🐰
RabbitMQ – традиционный брокер с поддержкой Pub-Sub и Point-to-Point. Он активно управляет сообщениями: распределяет их по подписчикам, отслеживает их статус и удаляет после обработки. Он поддерживает At most once и At least once, а его настройка проще, чем у Kafka.

Принцип работы:
1. Отправитель (Publisher) передаёт сообщение в обменник (Exchange).
2. Сообщение попадает в одну или несколько очередей (Queue).
3. Подписчики (Consumers) забирают сообщения из очереди.

Kafka: "тупой брокер, умный потребитель" 🦄
Брокер для работы с большими объёмами данных. В отличие от RabbitMQ, он не удаляет сообщения после обработки. Они остаются в хранилище и могут быть прочитаны несколько раз. Kafka поддерживает Exactly once и обладает высокой отказоустойчивостью.

Принцип работы:
1. Продюсер (Producer) отправляет сообщение в топик.
2. Брокер записывает сообщение в журнал (лог) без удаления.
3. Подписчики (Consumers) сами запрашивают (pull) сообщения.

Kafka vs RabbitMQ ⚖️
Выбор зависит от контекста. Если требуется обработка событий с высокой пропускной способностью и хранение данных, лучше подойдёт Kafka. Если важно оперативное взаимодействие микросервисов с возможностью гибкой маршрутизации, RabbitMQ будет предпочтительнее.

🔥 Друзья, 27 марта в 14:00 собираемся на онлайн-встречу, где будем говорить про тендеры честно, без воды и иллюзий. Вместе с командой Arda делаем вебинар, где я поделюсь своим опытом участия в тендерах — а это уже больше 2000 попыток.

Будем обсуждать, какие тендеры реально стоит брать, а какие лучше обходить стороной. Поговорим о том, как понять, что тендер “под кого-то”, чтобы не тратить время впустую. Разберу наши главные ошибки и расскажу, какие грабли можно обойти, чтобы не терять деньги и нервы.

Тендеры — это возможность для роста или бессмысленная гонка за призрачными контрактами? Давайте разбираться вместе. Формат встречи неформальный: сначала я поделюсь опытом, а потом будем общаться, обсуждать и дискутировать.

📌 Участие бесплатное, но по регистрации: ссылка

Приходите, будет интересно! 🚀

Кто убил конверсию? 😂🔥

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

Было 10%, стало 5%, хотя еще месяц назад она держалась на уровне тех же 10%. Бац — и просадка. Это десятки миллионов рублей. Точная цифра неизвестна, но масштаб проблемы ощутимый.

Первая мысль: где-то накосячили? 😱
Естественно, первой версией было то, что мы налажали. Может, корзина или оформление заказа перестало работать? Или сервер лежал и сайт был недоступен?

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

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

Следующий шаг — сам сайт. Оформление заказа функционирует без нареканий: цели на месте, скорость загрузки хорошая, доставка и платежные сервисы работают как часы. Ошибок нет. Была мысль, что проблема кроется в логистике — вдруг транспортные компании подвели или условия доставки ухудшились. Или, может, платежные шлюзы барахлили?
Но и тут мимо — всё в порядке.

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

Тогда возникла гипотеза: а что, если дело в трафике?🤔
Мы не занимались продвижением, но раз уж ситуация такая, полезли в Метрику. Может, раньше там крутилась рекламная кампания, которая давала волшебный трафик и удваивала конверсию? Смотрим — ничего подобного. Всё стабильно: органический трафик даже немного вырос и год к году, и месяц к месяцу. Логично было бы ожидать роста конверсии, но её, наоборот, обрубило.

Мы перебрали еще несколько гипотез, но ни одна не подтвердилась. Оставалось копать дальше.

Ассортимент под подозрением🕵️‍♂️
В какой-то момент решили проверить ассортимент — вдруг 1С что-то напортачила? Интеграция там стандартная, всё должно работать как автомат. Логи интеграции показывают стабильность, никаких сбоев. История цен тоже в порядке: изменения разумные, без резких скачков вроде удвоения стоимости. В самой 1С, судя по данным, обновлений не выкатывали.

И тут осенило: а что с остатками? В штатном БУС логов остатков нет, но на этом проекте раньше уже были проблемы с интеграцией — она работала нестабильно. Поэтому мы сделали сохранение файлов обмена в отдельную директорию, так сказать, на память. За пару месяцев там накопилось достаточно данных.

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

Кто виноват и куда махать шашкой💡
Ответственное лицо, которое пришло к нам с шашкой, мы вежливо перенаправили к тем, кто управляет производством и остатками в 1С. Выяснилось, что производство сократило объемы: остатки ушли дилерам, а для интернет-магазина ничего не осталось. Вот и весь секрет падения конверсии. Клиенты заходили, видели "под заказ" и уходили ни с чем.

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

Где что? Пособие для потерявшихся 🔍

Так уж случилось, что накопилось столько текстов на канале, что я сам начал путаться, где что лежит. Память, как известно, не резиновая, а поиск по ключевым словам иногда напоминает квест🕵️‍♂️

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

Последнее обновление: 20 марта 2025.

• Участвовать можно. Выигрывать? Сложнее
• РРЦ есть, а если найду?
• Длинные деньги в разработке
• Микроразметка, которая работает. Наверное
• Персонализация в e-commerce

• Time & Materials по дружбе
• Миграция менеджеров как инструмент B2B-продаж
• Как сделать онбординг: просто, на коленке
• Где заканчиваются знания и начинается иллюзия
• Про пилотаж на собеседовании

• Как боты устроили распродажу производительности
• Почему ваш список дел — не ваш?
• Лучший фильм об управлении проектами
• Сервисы для планирования встреч
• Держите меня семеро, я прикручиваю ИИ

• В поисках программистов-экзорцистов
• Открыл для себя Америку в Google Таблицах
• Синонимы, транслит и магия
• Айсберг надежд: как фреймворк обещает всё
• Год работы с Яндекс.Трекером: личный опыт команды

• Собеседование не горит — дожми пользу по максимуму!
• Иллюзия коллективного выбора
• eCommerce эволюционирующий
• Публичная реферальная программа
• Чем кормить менеджеров?

• Баги, Ошибки, Проблемы, Недостатки, Неисправност....
• Как сделать авторизацию на сайте
• Легаси: казнить нельзя помиловать?
• Резервное копирование: двести тысяч единиц уже готовы
• Красное, тёплое и ваше новое КП

• Концерт по заявкам: автоматизация в Яндекс Трекере
• Почему всегда хотят Fixed Price
• Книга, которая меняет мышление
• Управление временем для менеджеров
• Таинственное искусство оценки

• Пакет с пакетами
• Маркетплейсы: рай для продавцов?
• Почему простота — один из лучших инструментов
• Завеса перфекционизма
• Парадоксы управления

• Agile-проекты превратились Waterfall со спринтами
• Транскрибация встреч: Когда лень
• Saas vs Self-Hosted: Что выбрать?
• Удаленка умирает? Не спешите с выводами!
• Пиши, сокращай: как писать коротко, ясно и по делу
• Микроменеджмент: недооцененное искусство
• Бюрократ, самодур, циник и наседка

Концерт по заявкам: автоматизация в Яндекс Трекере 🎸

Недавно в одном из профессиональных чатов всплыли вопрос о Яндекс.Трекере. Оказалось, что мы не одиноки, кто активно использует его в работе. Хотя, по моим наблюдениям, большинство коллег сидят на Битриксе24 или Jira.

За несколько лет использования Трекера мы успели немного разобраться в системе. Она своеобразная, но в целом довольно гибкая. Сегодня хочу поделиться частью автоматизаций, которые мы используем. Что-то мы придумали, что-то подсмотрели, а что-то посоветовали.

Важно понимать: многие триггеры у нас связаны между собой. Например, один добавляет комментарий к задаче, другой тут же шлёт его в Telegram.

Уведомление исполнителя об активации задачи ⏰
У нас довольно много задач в статусе "Отложено" — это своеобразный бэклог. Чтобы не теряться в этом, мы сделали так: как только автор активирует задачу, триггер автоматически упоминает исполнителя в комментарии, чтобы тот точно не пропустил задачу.

Уведомление автора о готовности задачи 👌
Когда исполнитель завершает работу и задача переходит в статус "Ожидаем проверки", система автоматически призывает в комментарии автора aka менеджера, чтобы они проверили результат.

Уведомление QA ✍️
Если задача готова, но ещё не протестирована, триггер уведомляет нашего QA-специалистов. Он получает уведомление, забирает задачу в свою очередь и приступает к тестированию.

Просроченные задачи ⏰
Мы больше работаем со списками, чем с канбаном. Но в Яндекс.Трекере, в отличие от Битрикса или Wrike, просроченные задачи в списке ничем не выделяются. Чтобы решить этот момент, у нас настроен триггер, который проверяет дедлайны. Если задача просрочена, в ней автоматически появляется комментарий.

Автоматическая очистка поля "Ждёт ответа" ✅
В Трекере есть специальное поле — своего рода флажок "ждём ответа от пользователя". Но если задача закрыта и полностью готова, понятно, что никаких ответов уже не требуется. Поэтому при закрытии задача автоматически очищается от этого флажка.

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

Сбор обратной связи: оценки автора и исполнителя ⭐️
Мы стараемся следим за качеством процессов. Исполнитель может оценить постановку задачи по 5 параметрам по 5-балльной шкале. В свою очередь, автор задачи оценивает исполнителя по аналогичным критериям.

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

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

Задачу не взяли в работу 📢
У нас есть промежуточный статус "Активно" — задача должна быть в работе. Но иногда исполнитель по каким-то причинам не приступает к ней. Если наступает дата начала задачи, а статус остаётся "Активно", система пишет комментарий.

Шаблон описания для задач 📋
Чтобы описание задач были структурированными, мы используем шаблон описания. Автоматизация добавляет этот шаблон в тело задачи при создании.

Уведомление о перерасходе времени ⚠️
В каждой задаче есть поле "Оценка" — например, 8 часов. Если исполнитель начинает выходить за рамки, приходит комментарий. Чтобы автор был в курсе перерасхода, триггер шлёт уведомление.

P.S. Термины "Автор" и "Исполнитель" могут звучать сухо/грубо, но это стандартные обозначения из самого Яндекс.Трекера — так просто удобнее и привычнее.

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

Легаси: казнить нельзя помиловать? ⚖️

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

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

Но вот в чем загвоздка — это почти никогда не работает так, как задумано.

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

Спойлер: в большинстве случаев — нет, не настолько плохо. ⚠️

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

Когда код становится легаси?⏳
Вот вопрос: в какой момент проект или код становится "легаси"?
Через год? Месяц? День? Может, час после релиза? Вопрос, на самом деле, открытый.

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

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

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

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

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

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

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

Так зачем тогда? 🤔
Получается странная картина. С одной стороны, есть старый проект с накопленными проблемами. С другой — новый, который тоже начнет обрастать своими. И если учесть, что многие старые "ужасы" можно спокойно решить и в текущем проекте, возникает вопрос: а зачем все это начинать с нуля?

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

Легаси — этап развития 🌱
Любой живой проект со временем становится легаси — и это нормально. Рефакторинг не исправит плохую архитектуру, и иногда действительно проще начать с нуля.

Но важно помнить: легаси бывает разным. Есть разница между десятилетним проектом на PHP 5.6 и двухлетним на Laravel. Подход "всех под одну гребенку" здесь не работает.

В каждом случае важно разбираться в контексте и причинах проблем, а не просто сжигать все дотла. 🔥

eCommerce эволюционирующий 🎆

В 2025 году маркетплейсы всё активнее поглощают классический eCommerce. Хотя вроде уже и нет 🤷‍♂️. Крупные игроки вроде DNS чувствуют себя довольно уверенно. Что же делать компаниям поменьше или тем, кто только хочет выйти на рынок электронной коммерции?

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

🎬 Стартовый этап: готовое решение
Представим компанию, которая уже пыталась развивать eCommerce. Новый менеджер решает снова попробовать, но без долгосрочной разработки. Он ищет варианты.

Сразу пропустим Tilda и прочие SaaS-решения — у них нет точек масштабирования. Мы с клиентом смотрим дальше, насколько это возможно в современных реалиях.

Начинаем с комбинации Битрикс + готовое решение. Можете критиковать, но качественно собранное готовое решение, поддающееся кастомизации, для старта вполне приемлемо. Особенно если учесть, что в него вложено около 1000 часов разработки, и маловероятно, что на стадии MVP вы создадите нечто подобное.

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

🚀 Развитие и первые ограничения
Проект запущен и работает. Интеграции сделаны и проверены, данные перемещаются без сбоев. Что дальше?

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

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

🔥 Модернизация фронтенда
Что делать? Бэкенд менять не хотим, админка и её возможности нас устраивают, тем более что с этой стороны проблем обычно немного. А вот фронтенд хочется сделать современнее, с анимацией, да ещё и мобильное приложение добавить.

Решение: разрабатываем API. На базе текущего бэкенда создаём API для Битрикса, мы обычно используем микрофреймворк Slim. Параллельно разрабатываем отдельный фронтенд — веб, мобильное приложение или что угодно другое. Связываем всё, и вуаля — у нас свой фронтенд, который можно развивать отдельной командой и который лучше справляется с нагрузкой.

⚙️ Модернизация бэкенда
Теперь с фронтендом всё решено, у нас устойчивое решение, которое можно развивать долгое время большой командой. Но возникает следующая проблема: бэкенд уже обрабатывает тысячи заказов, и инфраструктура Битрикс не справляется.

Следующий шаг — разделение на отдельные сервисы. Обычно начинают с каталога, который включает в себя поиск, фильтрацию, выдачу и т.д. Появится PIM-система и/ или Elasticsearch. Шина данных, которая разгрузит обмены с внешними системами.

В результате получается своего рода "Франкенштейн": фронтенд — отдельное приложение, API работает через Битрикс, а к нему подключена куча сервисов.

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

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

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

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

Иллюзия коллективного выбора 🎲

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

Большинство, не задумываясь, ответит: "В демократическом". Это кажется естественным. Кто в здравом уме предпочтет авторитаризм? 💬

Демократия, как известно, — это система, при которой решения принимаются коллективно, а каждый участник имеет равное влияние на процесс.

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

Разве сотрудники в таких гигантах, как Apple, Google или Microsoft, выбирают себе начальников? Существует ли в Coca-Cola день всеобщего голосования? Слышали ли вы о внутрикорпоративных выборах в McDonald’s или IBM? А ведь именно эти компании считаются эталонами успеха и эффективности.

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

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

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

Молодое поколение (назовем их условно "поколение Z") часто этого не понимает. Они уверены, что их мнение должно быть учтено в любом вопросе, а их влияние — безгранично. Результат такого подхода — разочарование, конфликты в команде, стрессы и провалы проектов. Люди чувствуют себя недооцененными и обманутыми.

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

📝 Помните об этом, когда вас в очередной раз пригласят на обсуждение стратегии компании или ключевого продукта. Даже если атмосфера кажется дружелюбной, а условия — комфортными.

Красное, тёплое и ваше новое КП 💵

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

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

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

📄 Смета обычно складывается из трёх ключевых параметров: стоимости часа, количества часов и расходов на покупку ПО. Стоимость ПО можно считать примерно одинаковой для всех, а стоимость часа — условно сопоставимой. Да, с ней можно немного играть, но больших отличий здесь ожидать не стоит.

Две или более компании готовят коммерческие предложения со сметами. У одних стоимость проекта составляет 100 рублей, у других — 200. Выбор кажется очевидным: вероятно, предпочтение отдадут более дешевому агентству.

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

🤦‍♂️ Надуманный пример по дизайну. В первоначальной смете указан пункт «дизайн главной страницы». Начинается работа: дизайн готов, верстка выполнена, интеграция проведена, адаптивная версия сделана. Заказчик начинает проверку и говорит, что адаптивная версия совершенно неприемлема и требует переделки.

На это подрядчик отвечает: «В нашей смете адаптивная версия не была предусмотрена — необходимо дополнительное финансирование».

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

По сути, когда начинается сравнение потенциальных подрядчиков, нередко сравнивают то, что в принципе несравнимо — как красное с тёплым. В одном тендере могут участвовать решения на Python, Laravel, Битриксе и Тильде. Выбрать, наверное, кого-то и получится, но к качеству это точно не приведёт.

Ищем риски🔍
Если среди предложений вы видите работы, которые отсутствуют в других сметах, стоит обсудить это с обеими сторонами. Спросите тех, кто включил эти пункты: «Зачем и почему это необходимо?». У тех, кто их не указал, уточните: «Почему эти пункты отсутствуют?».
Плохая декомпозиция — когда весь дизайн b2b-портала описан в 2-3 строках. В такой смете неизбежно что-то упустят, случайно или намеренно.

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

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

🤷‍♂️ Если вы прошли все первичные этапы и вот вы — в тройке финалистов, и вас уже рассматривают под лупой, то не забудьте проверить, чтобы сметы ваших коллег/конкурентов были идентичны по составу работ.
Ставки вы примерно знаете, и тогда останется только один фактор — количество часов, заложенных на конкретную работу.
Вот тут и выяснится, кто — «дурак, который мало заложил», или «дурак, который много заложил».

Баги, Ошибки, Проблемы, Недостатки, Неисправности, Сбои, и Дефекты 🐞
Если что-нибудь может пойти не так, оно пойдёт не так...

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

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

Дефект — это ошибка, обнаруженная на этапе разработки.

Баг — это дефект, обнаруженный на этапе тестирования. Не все ошибки обнаруживаются. Следовательно, не все ошибки вызывают дефекты и баги.

По одной из версий, термин «баг» появился в 1947 году. Проблема возникла в работе радарной электроники, и при её поиске инженеры обнаружили сгоревшего мотылька, застрявшего между контактами и вызвавшего замыкание.

Сбой или отказ — это когда система не соответствует своим требованиям. Это ошибка, которая дошла до пользователя.

Неисправность является причиной сбоя. Это может быть ошибка программирования или неправильное использование системы пользователем.

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

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

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

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

🚀 Ошибки единиц измерения
Когда вы имеете дело с физическими системами, единицы измерения имеют значение. Есть разница, едете ли вы со скоростью 100 миль или 100 км в час. Это опыт, который команде Mars Climate Orbiter пришлось пройти нелегким путем: одна команда использовала ньютоны, а другая — фунт-силы. Это несоответствие в коммуникации между двумя программными компонентами привело к взрыву космического корабля. Это потеря в размере 327,6 млн долларов США.

Мелочь? Да, но цена ошибки — космическая.

Другие примеры интересных ошибок читай на VC.ru

Публичная реферальная программа 🎯

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

На такой странице, как правило, содержится предложение следующего рода: "Приведи к нам клиента — получишь 10% от стоимости разработки и 5% с продвижения".

Процент может быть любым, иногда речь идет о фиксированной сумме — 10 000, 50 000 или 100 000 рублей. 🤑

Но суть не в цифрах 📊

Теперь задумайтесь о следующем: представьте, что вы — клиент, который ищет услугу. Вам кто-то порекомендовал компанию, вы обратились, договорились о сотрудничестве. Но есть немалая вероятность, что ваш проект обойдется вам на 10% дороже, чем он стоит на самом деле. Почему? Потому что в цену уже заложено вознаграждение для посредника.

Медвежья услуга 🧸

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

Риски ⚡️
❌ Искажение рыночной цены — компании, внедряющие публичные реферальные программы, часто компенсируют выплаты за счет увеличения стоимости своих услуг. Это делает услуги менее конкурентоспособными.

❌ Потеря доверия клиентов — когда клиент осознает, что в стоимость услуг заложено вознаграждение рефералу, у него возникает недоверие к компании. Это может привести к отказу от сотрудничества и негативным отзывам.

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

❌ Размывание ценности реальной рекомендации — в нормальных условиях люди рекомендуют услуги, исходя из собственного опыта и качества работы компании. Однако при наличии реферальной программы рекомендации могут носить исключительно финансовый характер.

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

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

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

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

Держите меня семеро, я прикручиваю ИИ 🤖

Мы начали работу над первым проектом, в техническом задании которого фигурирует использование искусственного интеллекта. Для особо душных: мы будем использовать не «искусственный интеллект», а языковую модель на основе нейронных сетей, построенную по архитектуре трансформера (далее — ИИ).

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

🔍 Выбор между локальным и облачным решениями
Перед нами стоял выбор: развернуть модель на своем сервере или использовать облачное решение.

Поскольку ИИ встраивается в уже существующий продукт, а объем его использования сложно прогнозировать — популярность сервиса еще предстоит проверить — мы остановились на облачном варианте.

Это позволило сократить время запуска, избежать сложностей с инфраструктурой и снизить стартовые затраты. В будущем, если сервис будет востребован, можно будет перенести ИИ на свой сервер.

☁️ Выбор облачной платформы
Так как сервис ориентирован на российский рынок, требовалось решение с серверами в РФ. Коробочную версию мы исключили по причинам, указанным выше. В итоге выбор сузился до Яндекса и Сбера.
Для тестирования мы использовали GPT и Claude, сформировав 10 типовых задач для генерации текста.

📊 Результаты тестирования
Вот субъективные оценки различных моделей по нашему сценарию:
— Яндекс 4 Lite / 9 ⭐️ — победитель теста
— Яндекс 4 Pro / 7
— Claude 3.5 Sonnet / 7
— Claude 3.5 Haiku - 6
— GPT-4o Mini / 8
— GigaChat / 5

В итоге остановились на младшей модели Яндекса. Она показала хорошие результаты и выдачу в нужном формате.

⏳ Песочница Яндекса
Для тестирования в Яндексе существует песочница — AI Playground. В интерфейсе имеется технический промт, который добавляется к пользовательскому запросу. Этот промт помогает получить более стабильные и предсказуемые результаты, а также обеспечивает вывод ответа в нужном формате, в нашем случае — JSON.

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

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

Ранее мы уже интегрировали GPT в чат-помощника — пользователи даже не всегда замечали, что общаются с ИИ. Теперь рассматриваем вариант внедрения ИИ в поиск, вероятно, через Elasticsearch или напрямую.

Микроразметка, которая работает. Наверное ❓

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

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

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

💡 Источник вдохновения — vc.ru. Там изображения для предпросмотра генерируются из фоновой иллюстрации статьи, заголовка и легкого затемнения. В ленте такие ссылки выделяются, а в чате их проще найти.

Мы решили повторить этот подход. Настроили микроразметку для блога и кейсов — именно туда идет основной трафик. Теперь ссылки выглядят аккуратно, заметно и просто красиво.

Этот метод можно применять и в e-commerce, и в каталогах. Удивительно, что ни один крупный маркетплейс — ни «синий», ни «фиолетовый» — пока не реализовал это на уровне микроразметки.

О результатах пока говорить рано, да и отследить эффективность сложно. Но если у вас есть сайт с портфолио — настоятельно рекомендую попробовать. Скорее всего, станет лучше. 🚀

РРЦ есть, а если найду? 🛍

Так уж сложилось, что мы работаем в e-commerce. А сегодня e-commerce — это, прежде всего, маркетплейсы. Следовательно, что? Верно, нужно быть там.

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

🔍 Какие варианты доступны?
1. Самописное решение — долго, дорого и мучительно поддерживать обновления API.
2. Готовый модуль — вполне рабочая история.
3. Агрегатор — промежуточное звено, которое не всегда удобно.
4. Прямая загрузка из 1С или аналогичной системы — можно, но дорого.
5. Ручной ввод — не наш метод.
Но сегодня речь не об этом.

🔥 Когда все на одном маркетплейсе
Допустим, вы — производитель. Заходите в D2C, а у вас уже есть сеть дилеров, которым настоятельно рекомендуете придерживаться РРЦ (рекомендованной розничной цены).

И вот вы все дружно оказываетесь на одном маркетплейсе. Пусть будет Фиолетовый или Синий — не суть важно. И тут начинается танец с бубном вокруг цены.

😤 Вы наверняка слышали истории о том, как маркетплейсы могут в моменте менять цены: отправлять товар в скидки, выдавать пользователям баллы и применять другие механики. В результате цена может улететь далеко за пределы РРЦ.

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

🛠 Как решить проблему?
Мы протестировали несколько подходов и остановились на таком:
1. Формируем список товаров, которые загружаются на маркетплейсы.
2. Получаем актуальный список товаров, представленных на площадках.
3. Используем парсер — свой или готовый (главное, чтобы можно было выгружать данные в CSV или API).
4. Парсим цены несколько раз в день.
5. Сверяем полученные данные с нашими РРЦ

✅Если цена в норме — ничего не меняем.
🚨Если цена ниже РРЦ — пересчитываем нашу цену и обновляем на маркетплейсе.
⚠️ Если цена выше РРЦ — откатываемся назад, значит, скидка уже ушла.

⚙️ Как это работает технически?
Все это можно реализовать внутри Bitrix или вынести в отдельный сервис на Laravel. Да, есть небольшие задержки в обновлении, но на практике лаг не критичный.

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

Так что, если вы производитель и хотите контролировать РРЦ на маркетплейсах, автоматизация — ваш лучший друг.

Участвовать можно. Выигрывать? Сложнее 🎲

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

За прошедший год мы приняли участие примерно в 169 тендерах — в нескольких даже удалось победить 🙂. С тендерами начали плотно работать 3–4 года назад. Раньше тоже пробовали, но результаты были, мягко говоря, неутешительные. В общей сложности через CRM прошло уже более 1000+ сделок.

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

Базовые принципы ⚠️
1. 80% тендеров — это формальная фиксация уже достигнутых договоренностей
2. Начинайте с коммерческих тендеров, пропускайте 44-ФЗ и 223-ФЗ на первых порах
3. Цикл принятия решений очень длинный — ведите сделки в CRM
4. Почти любой лид — это явный или неявный коммерческий тендер
5. Идти в тендер без предварительных договоренностей — рисково
6. Нанять тендерного специалиста и надеяться, что он сделает всё за вас — не сработает.
7. Аутсорсинг подбора или участия в тендерах редко бывает эффективным

Признаки тендера где победитель есть 🏆
6. В любой закупке есть критерий по опыту — чем конкретнее спрашивают, тем вероятнее что победитель уже есть
7. Указан опыт работы с конкретной компанией, которая организует тендер — сразу мимо
8. Критерии вроде экологических норм на разработку — победитель уже есть
9. Критерий наличия сертификата, который выдается платно или он особенный — это либо заработок на сертификатах, либо победитель уже есть
10. Если заказчик не идет на ВКС — победитель уже есть
11. Если на ВКС есть расплывчатые формулировки, мало конкретики — победитель уже есть
12. Если в НМЦ 3 цены с одинаковым отступом (100/150/200) — исполнитель есть

Что важно учитывать 🕹
13. Смотрите все критерии, даже если кажется, что у вас выгодная цена
14. Отраслевые рейтинги — нормальный критерий, если не указано конкретное место
15. Используйте ПО для агрегации тендеров
16. Изучите выступления экспертов: Моризо, Экстила, Артвела, Раменского
17. Лучше пропускать тендеры, где ценовой критерий более 50% — ИП вам не победить
18. Подготовьте стандартный пакет документов для подачи (включая презентацию)
19. Будьте готовы к низкой конверсии в сделку
20. Определите минимальный размер тендера, в который пойдете
21. Считайте затраты на тендер (аналитика, дизайн и прочее)
22. Тендерное задание можно использовать в портфолио
23. Аукционы лучше пропускать — ИП вам не победить
24. Есть много закрытых площадок с тендерами, куда надо попасть
25. НДС в цене важен — по году это могут быть сотни тысяч или миллионы рублей
26. На большую часть коммерческих тендеров не выкладываются результаты
27. Коммерческие и полукоммерческие тендеры — полукоммерческий например воркспейс

Если организуете тендер под себя 🕹
28. Вводите неценовые критерии и лучше больше
29. Лучше включать оценку дизайн-концепции, которая оценивается субъективно

Стоит ли игра свеч? У нас было несколько кейсов, когда мы побеждали даже в ситуациях с предопределенным победителем. Шансы есть всегда, но важно грамотно оценивать риски и свои возможности. 😉

🎯 Персонализация в e-commerce: забота о клиентах или эксплуатация данных?

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

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

🤖 Алгоритмы работают, но работают ли они в нашу пользу?

🎭 Потребители хотят персонализации... или их к этому приучили?
Маркетинговые исследования говорят, что люди любят персонализированные рекомендации:
📌 91% покупателей чаще покупают у брендов, которые предлагают релевантные товары.
📌 74% разочаровываются, если видят нерелевантный контент.
📌 66% говорят, что отсутствие персонализации может оттолкнуть их от покупки.

Но что стоит за этими цифрами? Дело не только в удобстве, но и в привычке. Чем больше компаний используют персонализацию, тем больше пользователи ожидают ее везде.

🔍 Как бренды собирают наши данные?
В идеальном мире компании бы спрашивали: "Можно мы будем показывать вам подборки товаров, которые вам действительно нужны?" Но на деле все иначе:

💾 Сайты запоминают историю просмотров и покупок.
🎯 Рекламные сети анализируют клики и поведение.
📩 Электронные письма становятся все более персонализированными, учитывая предыдущие заказы и активность.

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

⚖️ Баланс между удобством и вторжением в личную жизнь
С одной стороны, персонализация экономит время: мы быстрее находим нужные вещи, получаем релевантные скидки и предложения.

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

📢 Важно, чтобы персонализация не превращалась в манипуляцию.

🔐 Как сделать персонализацию прозрачной и честной?
⚡️ Использовать данные, которыми клиент готов делиться.
⚡️ Разрешать отключение персонализации.
⚡️ Объяснять, какие данные собираются и зачем.
⚡️ Не перегружать пользователя ненужными рекомендациями.

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

📖 Подробнее о том, как работает персонализация, какие данные собирают маркетплейсы и как брендам выстраивать доверие — в полной статье 👉 https://alexeyit.ru/all/personalizaciya-v-e-commerce/

💰Длинные деньги в разработке

На конференциях и вебинарах для агентств, можно услышать совет: "Работайте с длинными деньгами, отказывайтесь от фикс-прайса, переходите на T&M или ритейнер".

Наверное, в этом есть правда. Мы и сами еще не полностью освоили этот подход, но активно к нему движемся.

Споры о фикс-прайсе и T&M не утихают. С одной стороны, зайти к клиенту всегда проще с фиксированной ценой — это понятный и предсказуемый формат для заказчика. Но что будет дальше? Контракт может трансформироваться в T&M, ритейнер или даже аутстафф.

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

🎯При чем тут длина?
Выражение "длинные деньги" часто звучит на профильных конференциях, в видео и статьях. По сути, это долгосрочные контракты в формате T&M или его аналогов.

💭Как это работает?
1. Заказчик регулярно ставит задачи.
2. Исполнитель выполняет их на ежемесячной, недельной или поквартальной основе.
3. Деньги приходят стабильно, объем работ предсказуем.

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

📌Верный ответ — предлагать свои задачи.

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

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

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

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

К посту прикреплен документ из нашего wiki — что предложить по e-commerce b2b/b2c проектах: https://alexeyit.ru/file/roadmap.pdf

🤩🤩🤩 Разыгрываем звезды

Собрались людьми из диджитала и решили организовать для дорогих подписчиков розыгрыш 10 000 звезд! Звезды – это новая валюта Telegram 🤩

Условия простые: подписываешься на каналы, а через несколько дней можешь выиграть 1000 звезд!

На кого подписываться?

1. Регламентошная — регламенты, чек-листы и полезные документы для диджитал от Саши Комбарова.

2. Сергей Минин — наставник по развитию продаж в IT. Помогаю в построении отдела продаж - ставим цели, пишем планы продаж, настраиваем CRM.

3. Иван Гринкевич — CEO PHPDev, аутсорс и аутстаф. PHP, Java, Devops, 1C, Системные и Бизнес аналитики. Диджитал без прикрас, прекрасная реальность жизни.

4. Суминов Антон — из экономиста в программиста, из программиста в предприниматели. Мой путь: про управление проектами, про разработку, про IT. CEO студии Adinadin.

5. Максим Фомин — CEO Vverh.digital. Рассказываю о развитии агентства, нейронных технологиях, IT и жизни без прикрас. Заимствую идеи в разработке и маркетинге геймдева для развития своей it-студии.

6. Петров Алексей — про разработку, управление командами и проектами без воды. Как двигаем задачи, строим процессы и развиваем B2B/B2C e-commerce в Webest.

7. Аналитик на Балтике — погружаемся в мир IT-анализа среди балтийских волн! Здесь вы найдете всё для старта, роста и смены карьеры: от основ системного анализа до продвинутых техник для повышения грейда и профессионального развития.

8. Инна научит — превращаю речь в ваш главный инструмент успеха! Научу говорить четко, уверенно и убедительно — будь то презентация, переговоры или онлайн-встречи. Ваш голос и речь станут вашим конкурентным преимуществом!

9. OK Digital — Канал агентства SEO-продвижения сайтов и контекстной рекламы. Публикуем свои кейсы, примеры работ, лучшие практики и статьи о подходах в работе. Основные ниши - производители, дистрибьютеры и e-com.

10. Алексей Сорокин — что вижу – о том пою. Рефлексирую на тему ИТ, управления компанией, запуска, развития нескольких бизнесов, формирования команды и прочих житейских мероприятиях.

Подведем итоги 13 февраля в 10:00 🕙

Поехали 🚀

🔍 Time & Materials по дружбе

Недавно позвали на совзон по аудиту проекта (запрос был на CTO). Стек технологий был не совсем наш, но по первичным вопросам стало ясно, что вопросы общие и к разработке имеют лишь косвенное отношение. Решил, что стоит сходить хотя бы для знакомства.
История вымышленные, все совпадения случайны. 🚨
Контекст и первые впечатления 💼
Человек, с которым общались, перешел с агентской стороны на клиентскую, в продуктовую компанию и должен навести порядок. Проект в финтех-сфере, и ситуация там одновременно пугает и заставляет задуматься.

Проект и подрядчик🔄
Подрядчик, год разработки проекта на аутсорсе по Time & Materials. Казалось бы, обычное дело, но детали настораживают: вся отчётность, в том числе демо проекта, только в PDF. Сроки сорваны, а подрядчик просит ещё 4 месяца. Подрядчик декларирует, в середине проекта, что команда меняет подход и совершает резкий переход на Agile — со всеми ретро и прочими церемониями.

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

Проблемы, которые бросаются в глаза 👀
Доступа к Git нет, документации вроде тоже, демонстрации не проводятся, контроль со стороны заказчика минимальный. Подозрительно? Ещё как! Есть предположение, что подрядчика выбирали по принципу "свой человек" — возможно, в портфолио был похожий проект.

Коллеге посоветовали первым делом получить доступ к коду/гиту, провести ревизию и составить чёткий роадмап и соотнести его с тем что реализовано, если что то реализовано.

Главный вывод 💡
История поднимает важный вопрос: как компании инвестируют в IT-проекты. Если бюджеты будут распределяться более грамотно, количество недобросовестных подрядчиков сократится. Те, кто ведет себя непрофессионально, потеряют доверие и, вероятно, уйдут с рынка.

⚖️ Эта ситуация одновременно пугает и вдохновляет. Пугает — потому что такие истории случаются слишком часто. Вдохновляет — рынок самоочищается он недобросовестных ребят.

Что дальше? 🚀
Если вы столкнулись с похожей ситуацией или просто хотите обсудить подходы к управлению IT-проектами, зовите на созвоны. Буду рад пообщаться, поделиться опытом и помочь найти решения для ваших задач. 📞✨

Так что зовите на созвоны, буду рад познакомиться и пообщаться! 😊

🚀Миграция менеджеров как инструмент B2B-продаж

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

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

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

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

💡Масштаб явления

Чтобы оценить потенциал данного подхода, обратимся к статистике IT-рынка России. По данным Минцифры, в отрасли занято около 857 тысяч специалистов. Для сравнения: это сопоставимо с финансовым сектором (850 тысяч – 1 миллион человек) и значительно меньше сферы образования (5,5 миллионов).

📊Если предположить, что на одного менеджера приходится команда из 10 человек, то в IT-секторе работает около 85 тысяч управленцев. После вычета продуктовых менеджеров, менеджеров по продажам и других (около 40%), остается примерно 50 тысяч профильных руководителей. Из них реальные решения о закупках и выборе подрядчиков принимают около 25 тысяч человек.

🛠 Как использовать

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

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

✔️ Выполняйте работу качественно
✔️ Поддерживайте менеджера в рабочих вопросах
✔️ Выстраивайте долгосрочные отношения

🔥 Факт: клиенты, пришедшие через «миграцию менеджеров», самые лояльные. В среднем за год у нас до 10 таких кейсов с конверсией почти 100%.

Это делает данный механизм одним из самых эффективных инструментов B2B-продаж в сфере IT-услуг.

🔒 Как я смотрю YouTube без задержек и рекламы

Сегодня хочу поделиться своим способом просмотра YouTube без задержек и рекламы на любом устройстве. Речь пойдет не о VPN, а о дополнительном ПО, которое стабилизирует видео и делает просмотр максимально комфортным.

Этот способ прост, доступен и не требует глубоких технических знаний. Стоимость решения — всего 22 рубля в день или около 600 рублей в месяц. Да, можно настроить свой сервер, и в конце текста я оставлю ссылки на нужные инструкции. Собственный сервер может быть безопаснее, но мой способ подходит даже для новичков. Мы будем использовать связку Beget и WireGuard, что позволяет быстро создать стабильное решение.

🚀 Регистрация и создание VPS
Первым делом нужно зарегистрироваться на Beget. Вы можете создать аккаунт как физическое лицо, а если нужна оплата по счету — как юридическое. После регистрации переходите к созданию VPS и выбирайте самый младший тариф за 22 рубля в день. Этого достаточно для 20+ человек, у которых может быть несколько устройств.

Важно: выбирайте локацию «Латвия», так как другие локации могут быть недоступны. Эти серверы разбирают быстро, так что не откладывайте.

Когда VPS создан, на вашу почту придет письмо с root-паролем. Этот пароль понадобится для дальнейшей настройки.

⚙️ Настройка WireGuard
Если вам нужен только один аккаунт, он уже создан автоматически, и QR-код для подключения можно найти в личном кабинете Beget. Настройка на этом этапе завершена.

Если нужно несколько аккаунтов, подключение к серверу выполняется через PuTTY или терминал Beget. Вам нужно будет вставить IP-адрес из письма, ввести логин root и пароль. Пароль вставляется правой кнопкой мыши, так как Ctrl+V не работает. После ввода пароля просто нажмите Enter — символы пароля не будут отображаться.

Далее переходите в директорию с файлами WireGuard:
cd /opt/beget/wireguard
Здесь запускается скрипт:
./wireguard.sh

Чтобы добавить пользователя, выберите пункт 1, укажите имя и выберите DNS-сервер. Лучше всего использовать Google DNS (цифра 2). Другие DNS пока не тестировались, но вы можете поэкспериментировать.

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

📁 Где хранятся логи и конфигурации?
Все логи подключений хранятся на вашем сервере, поэтому вы полностью контролируете политику их хранения. Конфигурационные файлы WireGuard находятся по пути /opt/beget/wireguard/. Скрипт wireguard.sh позволяет управлять клиентскими конфигурациями, что дает вам гибкость и контроль.

📱 Как настроить устройства?
Приложение WireGuard доступно для большинства устройств: телефонов, планшетов, телевизоров и т. д. Для устройств с камерой просто используйте QR-код, а для ТВ или других устройств скачайте файл конфигурации из директории /opt/beget/wireguard/clients/. Его можно передать, например, через Яндекс.Диск или другой удобный сервис.

✅ Итог
Этот способ актуален на 27.01.25, и я надеюсь, что он останется рабочим.
Кстати, с этим решением отлично работают и другие сервисы, такие как Instagram и нестабильные сайты. Приятный бонус — большинство приложений не конфликтуют с WireGuard, так что можно почти не отключать его.