CI/CD — это про зрелость процессов.
На всех проектах я внедрял CI/CD не как «модную» штуку, а как способ избавиться от хаоса.
Если коротко: в процессе разработки есть инструмент, который позволяет отслеживать изменения, вносить правки и откатывать их, работать одновременно с проектом в разных его «ветках» и «стадиях».
Где-то это деплой через Git. Где-то — автосборка стендов под каждую ветку через API облака и Telegram-бота. Написал в чат: поднимается отдельный сервер под задачу, можно спокойно тестировать.
Для бизнеса это не просто “удобно”. Это:
— меньше багов на проде
— возможность откатиться
— прозрачность работы команды
— экономия времени и нервов
Разработчикам поначалу проще править на проде. Но это игра в “повезёт — не повезёт”.
Так можно только в одиночку и недолго.
© TheITDirector
На всех проектах я внедрял CI/CD не как «модную» штуку, а как способ избавиться от хаоса.
Если коротко: в процессе разработки есть инструмент, который позволяет отслеживать изменения, вносить правки и откатывать их, работать одновременно с проектом в разных его «ветках» и «стадиях».
Где-то это деплой через Git. Где-то — автосборка стендов под каждую ветку через API облака и Telegram-бота. Написал в чат: поднимается отдельный сервер под задачу, можно спокойно тестировать.
Для бизнеса это не просто “удобно”. Это:
— меньше багов на проде
— возможность откатиться
— прозрачность работы команды
— экономия времени и нервов
Разработчикам поначалу проще править на проде. Но это игра в “повезёт — не повезёт”.
Так можно только в одиночку и недолго.
© TheITDirector
8❤5👍4💯2
🛠️ “А где заказ?” — Это провал в системе и контроле
Когда заказов десятки — всё работает.
Когда сотни — начинаются “потеряшки”.
Когда тысячи — без системы ты не знаешь, что происходит.
В одном из проектов я выстроил полноценный “производственный” процесс —
от приёма заказа до доставки клиенту.
Не просто сайт. А ERP-логика: сборка, упаковка, сортировка, логистика — всё в цифре.
📦 Каждый этап — свой экран:
— что собрать,
— кто упаковывает,
— куда везти,
— когда заказ уехал,
— и вернулся ли.
💡 Это решает сразу несколько проблем:
— не надо писать в чат: “а где заказ?”
— видно, где узкое место в процессе
— есть метрики: сколько собирают, где затык, сколько возвратов
🧠 Автоматизация — это не про витрину.
Это про контроль. И предсказуемость.
© TheITDirector
Когда заказов десятки — всё работает.
Когда сотни — начинаются “потеряшки”.
Когда тысячи — без системы ты не знаешь, что происходит.
В одном из проектов я выстроил полноценный “производственный” процесс —
от приёма заказа до доставки клиенту.
Не просто сайт. А ERP-логика: сборка, упаковка, сортировка, логистика — всё в цифре.
📦 Каждый этап — свой экран:
— что собрать,
— кто упаковывает,
— куда везти,
— когда заказ уехал,
— и вернулся ли.
💡 Это решает сразу несколько проблем:
— не надо писать в чат: “а где заказ?”
— видно, где узкое место в процессе
— есть метрики: сколько собирают, где затык, сколько возвратов
🧠 Автоматизация — это не про витрину.
Это про контроль. И предсказуемость.
© TheITDirector
6💯20🔥16🎉16❤13👍11
• Найм разработчика — это про последствия — чек-лист для HR
• 1.5 млн на замену джуна — экономика онбординга
• Удалёнка — это навык — правила игры на ремоуте
• Чаты — не таск-трекер — прозрачность задач
• Сотня задач, ни одна не завершена — приоритеты по деньгам
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤4🔥4
📦 Как я продавал Funko Pop и что из этого понял
Funko Pop — это такие коллекционные фигурки с большой головой.
Я продавал их на маркетплейсах: Ozon, Wildberries, Яндекс.Маркет.
Тогда это был новый сегмент никто их не продавал в ассортименте.
Я закупал игрушки партиями, сам выходил на площадки,
решал всё: от ЭДО до интеграций.
Главный вывод: автоматизируй всё, что можно.
Использовал «МойСклад» — не реклама, просто удобный инструмент:
— единый остаток на всех маркетплейсах
— автоматическая блокировка товара после покупки
— учёт возвратов, списаний, акций и упаковки
— реальное понимание, что ты заработал, а не просто “оборот”
Если не вести учёт — кажется, что всё хорошо. Но когда начинаешь считать: комиссии, логистика, упаковка, скидки, —
маржа улетает, а ты даже не замечаешь.
💡 Торговля без учёта — это игра в угадайку.
Ты должен не просто продавать, а понимать экономику каждой позиции. Иначе это не бизнес, а витрина на удачу.
© TheITDirector
Funko Pop — это такие коллекционные фигурки с большой головой.
Я продавал их на маркетплейсах: Ozon, Wildberries, Яндекс.Маркет.
Тогда это был новый сегмент никто их не продавал в ассортименте.
Я закупал игрушки партиями, сам выходил на площадки,
решал всё: от ЭДО до интеграций.
Главный вывод: автоматизируй всё, что можно.
Использовал «МойСклад» — не реклама, просто удобный инструмент:
— единый остаток на всех маркетплейсах
— автоматическая блокировка товара после покупки
— учёт возвратов, списаний, акций и упаковки
— реальное понимание, что ты заработал, а не просто “оборот”
Если не вести учёт — кажется, что всё хорошо. Но когда начинаешь считать: комиссии, логистика, упаковка, скидки, —
маржа улетает, а ты даже не замечаешь.
💡 Торговля без учёта — это игра в угадайку.
Ты должен не просто продавать, а понимать экономику каждой позиции. Иначе это не бизнес, а витрина на удачу.
© TheITDirector
3👍6⚡3🔥3💯1
Что даёт бизнесу сильное IT
Если IT в компании — это просто “кодеры для сайта”, значит, вы недополучаете рост.
Хорошее IT:
— уменьшает стоимость привлечения клиента
— ускоряет цикл сделки на 50%
— делает процессы прозрачными
— снижает ручные ошибки (да, склад в Excel — реальный кейс на -1,2 млн)
— даёт маркетингу воронку, а не догадки
Я видел, как после аудита и настройки:
— лиды перестают теряться
— поддержка стоит дешевле
— команда понимает, что и зачем делает
IT — это бизнес-партнёр, который помогает расти.
© TheITDirector
Если IT в компании — это просто “кодеры для сайта”, значит, вы недополучаете рост.
Хорошее IT:
— уменьшает стоимость привлечения клиента
— ускоряет цикл сделки на 50%
— делает процессы прозрачными
— снижает ручные ошибки (да, склад в Excel — реальный кейс на -1,2 млн)
— даёт маркетингу воронку, а не догадки
Я видел, как после аудита и настройки:
— лиды перестают теряться
— поддержка стоит дешевле
— команда понимает, что и зачем делает
IT — это бизнес-партнёр, который помогает расти.
© TheITDirector
2👍7❤5⚡2
Тимлид жалуется: "Команда ничего не успевает".
Открыл их календари — всё понятно без слов.
Посчитали на реальной команде:
— 8 разработчиков
— В среднем 15 митингов в неделю на человека
— 15 часов × 8 человек = 120 часов в неделю
— Это 3 полных рабочих дня. Каждую неделю. В никуда.
При средней зарплате разработчика и стоимости часа:
→ 375 000₽ в месяц уходит в переговорки
→ 4.5 млн в год на обсуждение работы вместо работы
Самое дикое: после каждого митинга разработчику нужно 23 минуты, чтобы вернуться в контекст кода (исследование Microsoft).
15 митингов × 23 минуты = ещё 5.5 часов потерь.
Что делать:
No Meeting Friday
Пятница — священна. Никаких созвонов. Вообще.
Результат: один день глубокой работы = 40% недельного объёма задач.
Async-статусы вместо стендапов
Каждое утро в Telegram — трекер обновлен.
Стендап из 30 минут превратился в 2 минуты чтения.
Митинги по необходимости
Отменили все регулярные созвоны "на всякий случай".
Встречаемся, только когда есть конкретная проблема или решение.
Результаты через 2 месяца:
— Время на митинги: с 47% до 18%
— Скорость закрытия задач: +30%
— Овертаймы сократились на 60%
Один senior сказал: "Впервые за 3 года я пишу код, а не обсуждаю, как его писать".
❗ Главное правило: каждый митинг должен отвечать на вопрос "Что изменится после этого созвона?".
Нет ответа — нет митинга.
Сохраните себе и покажите тимлиду. Особенно если у вас "продуктивные" 4-часовые планирования спринта 📌
И помните, чаты — не трекер.
© TheITDirector
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍25🔥18❤12🎉12💯11
Строите продукт? Платформу? SaaS? Регистрируйте товарный знак сразу.
Потому что через год будет сюрприз:
• кто-то уже использует ваше название
• маркетплейс не пускает без ТЗ
• домен отобрали через арбитраж
• ребрендинг обойдётся в миллионы
Продукт есть, а защиты нет. Всё раскрутили, а название уже чужое.
Как это работает на практике?
У меня несколько товарных знаков. Один даже продал по франшизе, открыли сеть в других городах. Не я их открывал. Они заплатили за использование бренда.
Товарный знак это:
• защита от копирования
• пропуск на маркетплейсы
• решение споров без суда
• актив с конкретной стоимостью
• часть капитализации компании
Мы считаем серверы, лицензии, домены. Но забываем, что название и образ часто стоят дороже всей инфраструктуры.
Пусть кривенький логотип, пусть название простое, но оно ваше юридически.
© TheITDirector
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍24🔥7⚡3
Теперь можно не только читать про кейсы, но и обратиться ко мне, начать улучшать свой проект уже сегодня.
Есть команды, с которыми мечтаешь работать.
Когда очень сильные специалисты, серьёзный опыт, впечатляющее портфолио, десятки проектов в разработке и дизайне, внимание к деталям и глубокая экспертиза. Редко где встретишь сегодня, чтобы все совпало.
И я рад быть частью именно такой крутой команды экспертов.
Я пишу много кейсов разработки, построения процессов, eCom и HR, но можно прийти с задачей, от дизайна и разработки до интеграций складов и сложных IT-решений. Сделаем.
Покажем эффект от внедрения на бизнес-показателях, расскажем какие еще можно найти точки роста на текущем трафике, возьмем на поддержку.
Вам или коллегам точно нужна такая экспертиза - обязательно делитесь контактом и пишите мне.
Коллеги из HR - ваш директор по маркетингу / eCom скажет вам спасибо, прослежу лично.
@eb_account - Эрнест.
Please open Telegram to view this post
VIEW IN TELEGRAM
8❤10👍8🔥4
Кейс: цветочный бизнес
Удобный дизайн, много акций, хорошая съемка букетов, есть upsale (мишки, конфеты, открытки). CRM, интеграции, аналитика.
Где была точка роста:
В поле адреса. Покупатель вводил адрес вручную. Ошибался в улице и не находил дом, некоторые путали район и сайт сообщал, что доставки нет. В праздники и сезон - хаос. Курьеры теряли время, заказы срывались.
Все усложнялось еще и тем, что покупатель вводил не свой адрес, а адрес получателя букета, потому что обычно цветы заказывают с доставкой другому человеку.
Решение:
Добавили автоподсказки адресов через определение GEO, настроили в чекауте оформления заказа. Адрес подтягивается сам, ошибки исключены, курьеры получают координаты для доставки и интервалы.
Результат:
Конверсия выросла. Меньше звонков о проблемах. Меньше отмен.
+2 млн к выручке. Без редизайна и рекламы, не считая даже экономии времени сотрудников.
Фича, требующая буквально пару дней разработки, решала проблему, которая годами считалась «человеческим фактором» в компании.
Вывод:
Иногда достаточно, чтобы адрес просто находился. И инвестиция в такие задачи не просто упрощает процессы в компании, но и позволяет масштабировать бизнес в разы.
Разработка - это инвестиция, а не расходы.
© TheITDirector
Please open Telegram to view this post
VIEW IN TELEGRAM
14🔥14💯8👍5🎉1
📋 Галочка в тетрадке вместо нормальной системы
Замечали, как на завтраке в отеле вас отмечают ручкой в распечатке? Спрашивают номер, ищут в списке, ставят галочку.
Я заметил это в одной известной сети отелей зарубежом и сильно удивился «цифровизации», а теперь не могу не замечать.
Представьте: в отеле 3 ресторана. Гость заходит в первый — кофе и круассан. Идёт во второй — омлет и сок. В третьем берёт фрукты. Везде разные списки, никто не видит общей картины. А может, у него вообще не было завтрака в тарифе. Или под его номером ходит кто-то другой. Кажется, что проблема решается на завтраках, так как у некоторых работает только один ресторан, но на ужинах и системе «а-ля карт» цифры становятся еще интересней.
Результат: отель кормит всех подряд. Потери незаметные, но постоянные.
🔥 А ведь всё давно решается
PMS (1С:Отель) знает, кто живёт и какой тариф. iiko или другая ресторанная система может эти данные принять и обработать.
Гость подходит. Называет номер или показывает QR.
Система сама проверяет: был или не был.
Если был — отказ. Если нет — отметка автоматом.
Все рестораны видят одни данные, единый обмен, а бухгалтерия получает отчёт без ручной сверки.
Никаких тетрадок. Никаких дублей. Никаких "ой, забыли отметить".
Что это даёт
• Один гость = один завтрак, хоть ресторанов десять
• Аналитика по факту, а не по "примерно столько съели"
• Прогноз загрузки кухни и закупок
• Персонал не стоит с листочками у входа
Интеграция - это не про обмен данными ради галочки.
Это про то, чтобы отель работал как единая система, а не набор отделов с Excel и тетрадками.
Если у вас до сих пор списки на бумаге - это не работает и вы теряете деньги.
💡 Знаете отель или ресторан, где до сих пор так работают?
Отправьте им этот пост. Такие задачи решаются быстрее, чем кажется - от аудита до внедрения. И это только один пример проблем, с которыми сталкиваются в HoReCa, не говоря уже про доставку и интеграцию с системами заказа в номера.
Подробнее о том, как можем помочь и контакты есть в закрепленном сообщении.
Иногда достаточно одной правильной интеграции, чтобы закрыть проблему раз и навсегда для многих смежных отделов.
© TheITDirector
Замечали, как на завтраке в отеле вас отмечают ручкой в распечатке? Спрашивают номер, ищут в списке, ставят галочку.
Я заметил это в одной известной сети отелей зарубежом и сильно удивился «цифровизации», а теперь не могу не замечать.
Представьте: в отеле 3 ресторана. Гость заходит в первый — кофе и круассан. Идёт во второй — омлет и сок. В третьем берёт фрукты. Везде разные списки, никто не видит общей картины. А может, у него вообще не было завтрака в тарифе. Или под его номером ходит кто-то другой. Кажется, что проблема решается на завтраках, так как у некоторых работает только один ресторан, но на ужинах и системе «а-ля карт» цифры становятся еще интересней.
Результат: отель кормит всех подряд. Потери незаметные, но постоянные.
🔥 А ведь всё давно решается
PMS (1С:Отель) знает, кто живёт и какой тариф. iiko или другая ресторанная система может эти данные принять и обработать.
Гость подходит. Называет номер или показывает QR.
Система сама проверяет: был или не был.
Если был — отказ. Если нет — отметка автоматом.
Все рестораны видят одни данные, единый обмен, а бухгалтерия получает отчёт без ручной сверки.
Никаких тетрадок. Никаких дублей. Никаких "ой, забыли отметить".
Что это даёт
• Один гость = один завтрак, хоть ресторанов десять
• Аналитика по факту, а не по "примерно столько съели"
• Прогноз загрузки кухни и закупок
• Персонал не стоит с листочками у входа
Интеграция - это не про обмен данными ради галочки.
Это про то, чтобы отель работал как единая система, а не набор отделов с Excel и тетрадками.
Если у вас до сих пор списки на бумаге - это не работает и вы теряете деньги.
💡 Знаете отель или ресторан, где до сих пор так работают?
Отправьте им этот пост. Такие задачи решаются быстрее, чем кажется - от аудита до внедрения. И это только один пример проблем, с которыми сталкиваются в HoReCa, не говоря уже про доставку и интеграцию с системами заказа в номера.
Подробнее о том, как можем помочь и контакты есть в закрепленном сообщении.
Иногда достаточно одной правильной интеграции, чтобы закрыть проблему раз и навсегда для многих смежных отделов.
© TheITDirector
5👍10💯5❤4🔥1🎉1
Сотрудник видит: задачи дублируются, процессы тормозят, всё можно автоматизировать.
Предлагает - игнорируют. "Потом", "не до того", "и так работает".
Через полгода он уходит. Не потому что устал. А потому что видел решение, но его никто не слушал.
Когда команда предлагает навести порядок - это не нытьё. Это сигнал, что бьёт по ним в первую очередь.
Автоматизация и процессы - уважение к тем, кто работает с этим процессом каждый день.
© TheITDirector
Please open Telegram to view this post
VIEW IN TELEGRAM
10👍16🔥8💯6❤4
Немного личных историй:
Я выбирал это вместо игр на компьютере. 2004 год. Samsung D500. Я ночами собирал прошивку из кусков Sony Ericsson через HEX-редактор. Хотел одного, чтобы телефон умел ставить свои темы. Никаких гайдов. Чистый азарт.
В те же годы с верстальщиком 4elovek (да, такой ник) написали кросспостинг между ЖЖ и Li ru. Пишешь в одном — публикуется везде. Просто для комьюнити.
Тогда тех, кто занимался программированием называли "додиком за компом". IT было уделом тех, кто реально любил это дело. Спойлер - «додиками» не был никто, просто другое мышление и видение, и сейчас все уже понимают это.
Что изменилось за 20 лет
Многие специалисты застряли в той эпохе. Где знание = власть. Где "только я знаю как это работает", не трогай и не дыши, а грубость и хамство считались нормой общения сисадминов, например, и у некоторых до сих пор остаточный эффект, каждый сталкивался точно.
Но сегодня бизнес и IT — единое целое. Закрытость не защищает, а создаёт риски:
• Специалист в отпуске = процессы стоят
• Уволился ключевой человек = месяц восстанавливаем доступы
• Новичков боятся учить ("вдруг меня заменят")
Как строить сильную команду
Один может быть гениален в своей области, но без команды будет чувствовать себя самозванцем. Выбирайте тех, кто ценит бизнес-задачи, если сотрудник не играет в команде - рано или поздно он уйдет или потеряет доверие команды, каким бы он «лучшим» не был. Можно ли положиться на него? Основной вопрос, ответ на который и есть решение.
Команда:
- Каждый несёт свой опыт в общий котёл
- Можно не знать что-то и спокойно спросить
- Обучение, как часть работы, а не "разберёшься сам"
- Растём вместе, а не конкурируем за "незаменимость"
Никто не грубит и не хамит, даже если в 100 раз больше знаний, он делится ими, либо теряет доверие команды
Те, кто пришёл в IT по любви (а не за хайпом), выберут такой рост, поверьте. И те, кто очень давно, и те, кто недавно. И будут дорожить командой больше, чем временным ростом зарплаты или какими-то титулами. Все должно быть, конечно же, одно без другого не работает, просто в балансе.
Сильных удерживает возможность расти рядом с такими же увлечёнными.
© TheITDirector
Please open Telegram to view this post
VIEW IN TELEGRAM
22❤20👍15🔥6💯6🎉3
и почему это бьёт по бизнесу
Реальный кейс одной очень известной сети клиник.
Каждая — свой маленький мир, свой директор, свой Excel.
Зарплата и мотивация считаются так:
руководитель клиники открывает тетрадку посещений,
переписывает услуги «как понял»,
ставит галочки «кто что делал»,
и вручную считает проценты, надбавки и KPI.
Никакой общей системы.
Никакой автоматизации.
CRM «планируют внедрить» уже третий год.
В это время:
• персонал получает деньги «по ощущениям», а не по факту
• ошибки — норма, не исключение
• upsell и допы невозможно контролировать
• LTV пациента никто не замеряет
• маркетинг льёт трафик вслепую
• руководители тратят часы на расчёты, вместо того чтобы управлять
Самое печальное — все понимают проблему.
Но каждый месяц повторяют то же самое: вручную, по тетрадке, в Excel.
Пока нет единой системы, мотивация разваливается, персонал выгорает, а сеть теряет деньги там, где могла их зарабатывать.
© TheITDirector
Please open Telegram to view this post
VIEW IN TELEGRAM
11❤12👍6🎉2⚡1
🎁 Промокод на -100%: как случайно подарить весь магазин
У одной компании был внутренний промокод на минус 100%, «только для тестов», «только для руководства».
Без лимитов, без ролей, бесконечное количество применений.
Пока этот код не оказался в CPA*-сети
*«партнёрские площадки, где веб-мастера льют трафик за вознаграждение».
Никакого взлома. Просто кто-то поделился «по дружбе», и дальше он разошёлся как скидка века.
Через час — 112 заказов по 0 ₽ со всей страны. По закону покупатель прав и уверен: если код работает, значит можно.
Что проверить у себя прямо сейчас, если у вас интернет-магазин:
- Есть ли промокоды без ограничений по ролям и количеству
- Живут ли тестовые скидки в «боевой» (а должны жить в тесте)
- Ограничен ли канал применения: сайт, приложение, сегмент пользователей
- Логируются ли *внутренние* промокоды
И главное: есть ли у бизнеса инвентаризация всех активных промо с правилами?
© TheITDirector
У одной компании был внутренний промокод на минус 100%, «только для тестов», «только для руководства».
Без лимитов, без ролей, бесконечное количество применений.
Пока этот код не оказался в CPA*-сети
*«партнёрские площадки, где веб-мастера льют трафик за вознаграждение».
Никакого взлома. Просто кто-то поделился «по дружбе», и дальше он разошёлся как скидка века.
Через час — 112 заказов по 0 ₽ со всей страны. По закону покупатель прав и уверен: если код работает, значит можно.
Что проверить у себя прямо сейчас, если у вас интернет-магазин:
- Есть ли промокоды без ограничений по ролям и количеству
- Живут ли тестовые скидки в «боевой» (а должны жить в тесте)
- Ограничен ли канал применения: сайт, приложение, сегмент пользователей
- Логируются ли *внутренние* промокоды
И главное: есть ли у бизнеса инвентаризация всех активных промо с правилами?
© TheITDirector
3👍13🔥5❤4⚡1
🎯 Прямой эфир: почему интернет-магазин теряет деньги, даже если продажи растут
27 ноября в 17:00 разберем 5 проблем, которые съедают прибыль.
Без воды. С кейсами. С цифрами. Можно задать вопросы в прямом эфире.
Ссылка будет ближе к дате.
Кто придёт — ставьте 🔥
Всех приглашаю!
© TheITDirector
27 ноября в 17:00 разберем 5 проблем, которые съедают прибыль.
Без воды. С кейсами. С цифрами. Можно задать вопросы в прямом эфире.
Ссылка будет ближе к дате.
Кто придёт — ставьте 🔥
Всех приглашаю!
© TheITDirector
5🔥12❤6👍2🎉1
Что разобрали (и где чаще всего болит):
🔸 полунастроенная логистика;
🔸 аналитика «по ощущениям»;
🔸 забытые доступы;
🔸 CRM, которая теряет клиентов;
🔸 маркетплейсы и остатки, которые врут;
Спасибо, что пришли на вебинар!
Запись будет позже.
Спасибо, что пришли на вебинар!
Запись будет позже.
Please open Telegram to view this post
VIEW IN TELEGRAM
4❤10🔥5👍3⚡1🎉1
🕙 Почему API банка ломается именно в пятницу вечером
Есть вечный закон разработки:
чем ближе пятница к 18:00, тем выше шанс, что API банка решит «жить своей жизнью».
И нет, это не мистика.
Это комбинация процессов, которые все знают, но никто не признаёт.
Что реально происходит:
• в банке выкатывают релизы в самый «удобный» момент — под конец дня
• интеграции держатся на устаревших сервисах, к которым никто не хочет прикасаться
• SLA есть только в презентации, но не в жизни
• логирование «временно отключили, чтобы ускорить»
• тестовый контур “отличается буквально чуть-чуть”
• и где-то в недрах стоит один сервер, который все боятся перезапустить
Разработчики уже знают:
если в пятницу падает платежка — техподдержка не берет трубку, менеджер говорит «посмотрим в понедельник», а пользователи уверены, что виноваты именно вы.
Что установить у себя, чтобы прожить пятницу
• реальный мониторинг интеграций, а не заглушки
• алерты на деградацию до полного падения
• ретраи + очереди, чтобы не терять транзакции
• автоматическую подмену провайдера (если есть возможность)
• тестовый контур, который действительно совпадает с продом
• расписание релизов, где пятница — закрытый день
API банков ломается не потому, что «невезёт».
Оно ломается там, где нет инженерной дисциплины и никто не думает на шаг вперёд.
© TheITDirector
Есть вечный закон разработки:
чем ближе пятница к 18:00, тем выше шанс, что API банка решит «жить своей жизнью».
И нет, это не мистика.
Это комбинация процессов, которые все знают, но никто не признаёт.
Что реально происходит:
• в банке выкатывают релизы в самый «удобный» момент — под конец дня
• интеграции держатся на устаревших сервисах, к которым никто не хочет прикасаться
• SLA есть только в презентации, но не в жизни
• логирование «временно отключили, чтобы ускорить»
• тестовый контур “отличается буквально чуть-чуть”
• и где-то в недрах стоит один сервер, который все боятся перезапустить
Разработчики уже знают:
если в пятницу падает платежка — техподдержка не берет трубку, менеджер говорит «посмотрим в понедельник», а пользователи уверены, что виноваты именно вы.
Что установить у себя, чтобы прожить пятницу
• реальный мониторинг интеграций, а не заглушки
• алерты на деградацию до полного падения
• ретраи + очереди, чтобы не терять транзакции
• автоматическую подмену провайдера (если есть возможность)
• тестовый контур, который действительно совпадает с продом
• расписание релизов, где пятница — закрытый день
API банков ломается не потому, что «невезёт».
Оно ломается там, где нет инженерной дисциплины и никто не думает на шаг вперёд.
© TheITDirector
5👍13🔥9💯8🎉7❤6
Почему junior удалил продакшн-базу
и как этого не допустить
Классика жанра.
Junior запускает «безопасную» команду — и прод-база пропадает.
Не потому что плохой.
Потому что система дала ему такую возможность.
Типичные причины:
• одинаковые доступы ко всем средам
• похожие названия баз
• прямой доступ в прод «для удобства»
• команды без страховок
• нулевая маркировка среды
В таких условиях ошибётся любой.
Что проверить прямо сейчас
• разные роли и пароли для dev/stage/prod
• доступ к прод-БД только на чтение
• заметная маркировка среды (цвет, баннер, префикс)
• критичные команды с dry-run по умолчанию
• регулярный автотест восстановления бэкапов
• любые изменения — только через CI/CD
Если прод можно стереть случайно и не восстановить — виноват не человек, а процесс.
© TheITDirector
и как этого не допустить
Классика жанра.
Junior запускает «безопасную» команду — и прод-база пропадает.
Не потому что плохой.
Потому что система дала ему такую возможность.
Типичные причины:
• одинаковые доступы ко всем средам
• похожие названия баз
• прямой доступ в прод «для удобства»
• команды без страховок
• нулевая маркировка среды
В таких условиях ошибётся любой.
Что проверить прямо сейчас
• разные роли и пароли для dev/stage/prod
• доступ к прод-БД только на чтение
• заметная маркировка среды (цвет, баннер, префикс)
• критичные команды с dry-run по умолчанию
• регулярный автотест восстановления бэкапов
• любые изменения — только через CI/CD
Если прод можно стереть случайно и не восстановить — виноват не человек, а процесс.
© TheITDirector
3💯12👍9❤8🔥8🎉7⚡2
🔥 Пару слов про прошедшее мероприятие.
Кто хотел посетить вебинар, но не смог - можно посмотреть тут
Большое спасибо всем, нас было много 👍 мы с Никой обсудили действительно важные темы и инсайты, которые основаны на прожитом опыте, нюансы, которые не увидеть, если не анализировать, не проходить этот путь. Всех ошибок можно и нужно избегать.
Обещанный чек-лист, много полезного контента от очень крутых коллег - в канале бстд | говорит команда. Подпишитесь, команда делится опытом и кейсами, на которые можно смотреть бесконечно!
Это не реклама. У меня в канале её нет и никогда не будет, цель данного канала - делиться опытом, давать пользу. Там тоже про это. Я являюсь частью этой крутой команды экспертов, вы можете обращаться за экспертизой, контакт
@eb_account
Совсем скоро будут новые кейсы и посты, спасибо, что читаете!
Кстати, анонс мероприятия был в РБК
Кто хотел посетить вебинар, но не смог - можно посмотреть тут
Большое спасибо всем, нас было много 👍 мы с Никой обсудили действительно важные темы и инсайты, которые основаны на прожитом опыте, нюансы, которые не увидеть, если не анализировать, не проходить этот путь. Всех ошибок можно и нужно избегать.
Обещанный чек-лист, много полезного контента от очень крутых коллег - в канале бстд | говорит команда. Подпишитесь, команда делится опытом и кейсами, на которые можно смотреть бесконечно!
Это не реклама. У меня в канале её нет и никогда не будет, цель данного канала - делиться опытом, давать пользу. Там тоже про это. Я являюсь частью этой крутой команды экспертов, вы можете обращаться за экспертизой, контакт
@eb_account
Совсем скоро будут новые кейсы и посты, спасибо, что читаете!
Кстати, анонс мероприятия был в РБК
11👍5🎉5🔥4⚡2❤1💯1
Техническое собеседование: рекрутер не понимает половину слов в резюме
Рекрутер смотрит вакансию: "React, TypeScript, CI/CD, Kubernetes, опыт 3+ года". Смотрит резюме: "React, TypeScript, Docker, GitLab CI" — вроде похоже?
Зовёт на собеседование. Разработчик приходит — junior с курсов. Тимлид теряет час, HR получает фидбек "зачем позвали".
Или наоборот: сильный кандидат написал "Vue вместо React" — отсеяли сразу, хотя человек за неделю переучится.
Почему так происходит:
Рекрутер работает по ключевым словам, но не понимает:
• Docker и Kubernetes — это не одно и то же
• "3 года коммерческой разработки" ≠ "прошёл курс 3 года назад"
• мидл на одном стеке может быть сильнее сеньора на другом
• какие технологии критичны, а какие "nice to have"
Реальность:
В IT-компаниях нужны IT-рекрутеры. Не "рекрутеры, которые иногда закрывают айтишные вакансии", а специалисты, которые понимают технологии.
Это не значит, что HR должен уметь писать код. Но если вы работаете в IT и хотите расти — технологии нужно знать. Хотя бы базово.
Что с этим делать:
1 - Становитесь IT-рекрутером осознанно
Если закрываете вакансии разработчиков — это ваша специализация. Погружайтесь в технологии так же, как юрист погружается в законы, а финансист — в отчётность.
Разница между frontend и backend, junior и senior, популярные стеки, тренды рынка — это базовая грамотность, а не "бонусные знания".
2 - Учите язык разработки
10-15 минут в день:
• читайте Habr, Telegram-каналы про разработку
• смотрите, какие технологии упоминаются в вакансиях конкурентов
• спрашивайте у тимлида: "Объясни на пальцах, чем отличается React от Angular"
Через 2-3 месяца уже не будете слепо искать по ключевым словам.
3 - Тимлид участвует в скрининге
Не обязательно каждое резюме. Но на старте — да. "Вот 5 кандидатов, кого из них звать?" — 10 минут для тимлида, экономия часов для команды.
Со временем вы сами начнёте понимать, кто подходит, а кто нет.
4 - Чек-лист вместо интуиции
Тимлид даёт список: что обязательно, что желательно, что можно заменить. Пример: "Обязательно: React. Желательно: TypeScript. Необязательно: конкретная библиотека."
Но чтобы пользоваться чек-листом — нужно понимать, что в нём написано.
5 - Обратная связь = ваше обучение
После каждого собеседования спрашиваете: "Почему этот кандидат не подошёл? Что в резюме было красным флагом?"
Через 10-15 таких разборов вы уже видите паттерны. Через полгода — отсеиваете слабых кандидатов быстрее, чем тимлид успеет открыть резюме.
Итого:
Если вы рекрутер в IT — становитесь IT-рекрутером. Это не про "выучить Python". Это про понимание индустрии, в которой работаете.
Без этого:
• тратите время команды на неподходящих кандидатов
• теряете сильных специалистов (они уходят к конкурентам быстрее)
• стоите на месте, пока рынок требует всё больше экспертизы
Инвестиция: 15 минут в день на обучение. Возврат: рост как специалиста, уважение команды, закрытие вакансий быстрее.
Рекрутер и разработка — одна команда. И когда рекрутер говорит на языке технологий, все выигрывают.
Рекрутер смотрит вакансию: "React, TypeScript, CI/CD, Kubernetes, опыт 3+ года". Смотрит резюме: "React, TypeScript, Docker, GitLab CI" — вроде похоже?
Зовёт на собеседование. Разработчик приходит — junior с курсов. Тимлид теряет час, HR получает фидбек "зачем позвали".
Или наоборот: сильный кандидат написал "Vue вместо React" — отсеяли сразу, хотя человек за неделю переучится.
Почему так происходит:
Рекрутер работает по ключевым словам, но не понимает:
• Docker и Kubernetes — это не одно и то же
• "3 года коммерческой разработки" ≠ "прошёл курс 3 года назад"
• мидл на одном стеке может быть сильнее сеньора на другом
• какие технологии критичны, а какие "nice to have"
Реальность:
В IT-компаниях нужны IT-рекрутеры. Не "рекрутеры, которые иногда закрывают айтишные вакансии", а специалисты, которые понимают технологии.
Это не значит, что HR должен уметь писать код. Но если вы работаете в IT и хотите расти — технологии нужно знать. Хотя бы базово.
Что с этим делать:
1 - Становитесь IT-рекрутером осознанно
Если закрываете вакансии разработчиков — это ваша специализация. Погружайтесь в технологии так же, как юрист погружается в законы, а финансист — в отчётность.
Разница между frontend и backend, junior и senior, популярные стеки, тренды рынка — это базовая грамотность, а не "бонусные знания".
2 - Учите язык разработки
10-15 минут в день:
• читайте Habr, Telegram-каналы про разработку
• смотрите, какие технологии упоминаются в вакансиях конкурентов
• спрашивайте у тимлида: "Объясни на пальцах, чем отличается React от Angular"
Через 2-3 месяца уже не будете слепо искать по ключевым словам.
3 - Тимлид участвует в скрининге
Не обязательно каждое резюме. Но на старте — да. "Вот 5 кандидатов, кого из них звать?" — 10 минут для тимлида, экономия часов для команды.
Со временем вы сами начнёте понимать, кто подходит, а кто нет.
4 - Чек-лист вместо интуиции
Тимлид даёт список: что обязательно, что желательно, что можно заменить. Пример: "Обязательно: React. Желательно: TypeScript. Необязательно: конкретная библиотека."
Но чтобы пользоваться чек-листом — нужно понимать, что в нём написано.
5 - Обратная связь = ваше обучение
После каждого собеседования спрашиваете: "Почему этот кандидат не подошёл? Что в резюме было красным флагом?"
Через 10-15 таких разборов вы уже видите паттерны. Через полгода — отсеиваете слабых кандидатов быстрее, чем тимлид успеет открыть резюме.
Итого:
Если вы рекрутер в IT — становитесь IT-рекрутером. Это не про "выучить Python". Это про понимание индустрии, в которой работаете.
Без этого:
• тратите время команды на неподходящих кандидатов
• теряете сильных специалистов (они уходят к конкурентам быстрее)
• стоите на месте, пока рынок требует всё больше экспертизы
Инвестиция: 15 минут в день на обучение. Возврат: рост как специалиста, уважение команды, закрытие вакансий быстрее.
Рекрутер и разработка — одна команда. И когда рекрутер говорит на языке технологий, все выигрывают.
2❤7🔥7⚡2