Привет, я Эрнест 👋

О чём этот канал
Здесь — практика. Без воды, успешного успеха и инфобиза. Пишу, как устроены IT‑процессы, команды и внедрение решений — через опыт, ошибки и подходы, которые работают.

Фирменный стиль канала — каменный век с ретро‑техникой. Тут живут персонажи и их IT-ситуации: от бардака с доступами до автоматизации на костяных серверах.

Кто я
CTO, архитектор IT‑систем, тимлид и IT-консультант. 16+ лет на стыке технологий и бизнеса.

Запускал и масштабировал десятки проектов — от eCommerce до SaaS, автоматизировал склады, выстраивал процессы, собирал сильные IT-команды.

Среди прочего — Onboarding.ru, платформа для адаптации и обучения. Развиваю её как отдельный B2B‑продукт для упрощения HR‑процессов.

Партнёр 1С‑Битрикс с 2009 года.
Беру в работу только то, что имеет смысл. Не занимаюсь видимостью и «прикручиванием решений» без цели.

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

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

Пишу нечасто, но по делу. Всё здесь — прожито, проверено, применено. Если это близко — подписывайтесь

Так не надо внедрять CRM
Когда бизнес внедряет IT-решения “потому что надо” — ничего не меняется. Только деньги уходят.

На словах цель — “упростить процессы” или “всё автоматизировать”.
На деле — появляется очередной инструмент, в который никто не заходит.

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

Хотели “навести порядок”. А получили — лишнюю сущность.
Сотрудники продолжили работать в мессенджерах и таблицах.
CRM так и осталась “где-то там”.

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

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

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

Если цель — масштабировать:
например, обработать не 10, а 1000 заказов к 8 марта — тогда CRM с этапами, статусами, уведомлениями и логистикой будет инструментом роста.
А не модным словом в отчёте. Важнее правильно сгруппировать доставки по гео, чем поставить «статус».

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

И пока эти цели не сформулированы — внедрение не имеет смысла.
Ни одно решение не работает без контекста.

© TheITDirector

#такненадо #crm #bitrix24

Denwer. Кто помнит — уже не джун
Напомнили сегодня про Denwer — тот самый джентльменский набор разработчика. Кто ставил — поймёт. Кто не ставил… ну вы просто молоды)) забавно было вспоминать про инструменты, которые выдают в тебе возвраст разработчика, и объяснять это тем, кто в IT недавно)

🔥 Кто помнит — ставим огоньки)

© TheITDirector

#webdev #php #алдытут

Ошибки в eCommerce, которые не видны, но вы за них заплатите

Сайт был удобный, продажи шли, товар учитывался через 1С.

Но была одна тонкость:
когда клиент добавлял товар в корзину и оформлял заказ, товар уходил в резерв.

Если заказ не оплачивали — он так и оставался в резерве.
А в системе — числился как “уже выкуплен”.

На практике это выглядело так:
— товар лежит на складе
— система считает, что его нет
— клиенту он не показывается
— никто не понимает, почему он не продаётся

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

Решили это просто:
— автоматическое снятие заказа из резерва, если не был оплачен в течение N часов
— уведомления в админку
— чистка “мертвых” резервов
— восстановление остатка без участия человека

Такие кейсы вытаскиваются в результате аудита: когда смотришь на связку сайт ↔ 1С ↔ склад, а не просто на “работает / не работает”.

Это то, с чего часто начинается реальная оптимизация в eCommerce. Не с редизайна и не с новой CMS. А с устранения глухих узлов, которые просто не видно в интерфейсе.
 © TheITDirector - авторский канал

#ecommerce #разбор

У нас всё работает — зачем менять?
Так думают до первого сбоя.
Когда уходит ключевой сотрудник — и никто не знает, как работает система.
Когда страшно что-то трогать — потому что всё завязано на "одного человека".
Это не стабильность. Это иллюзия контроля.

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

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

© TheITDirector

Вы говорите, что вам нужно всё. Это значит, что вы не знаете, что именно.
Когда бизнес-заказчик хочет «всё и сразу», это сигнал, что стратегию никто не выстроил. Задача ИТ — в том числе отфильтровать это “всё” до ядра.

Как сказал один руководитель отдела мне во время ИТ аудита:

Я не задаю вопросов, руководство сказало копать, и я копаю

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

Диалог и вопросы - это не про нарушение субординации, а выполнение своих обязанностей.

© TheITDirector

У вас сотня задач в разработке — и ни одна не доведена до конца?
Частая история.
Потому что нет человека, который понимает, что вообще важно для бизнеса, а что можно смело выкинуть. Команды перегружены.
Бизнес не умеет приоритизировать. Вечно все «горит» и нужно «срочно»

В итоге таски ставятся по принципу "надо", "кто-то просил", "давайте сделаем".

А как надо?
Сначала — приоритет по деньгам:
Что принесёт больше выручки или сократит косты?
Потом — опыт пользователя и рост конверсии.
Дальше — скорость внедрения:
Лучше за месяц сделать 10 полезных задач, чем 10 месяцев — одну "мегаидею".

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

И наконец — кому дать задачу?
А вот тут магия:
➤ Если разработчик уже писал этот блок — пусть и дорабатывает.
Это снижает онбординг, ошибки и повышает результат.

Я такие истории разбираю на каждом аудите.
И всегда начинаю с вопроса:
“Какая из ваших задач приносит деньги?”

© TheITDirector
#итдиректор #аудитит #jira #разработка

MVP — это не продукт. Это тест одной гипотезы.
Его делают, чтобы проверить: “а будет ли работать?”.
MVP — Minimum Viable Product (минимально жизнеспособный продукт).

Но часто даже не формулируют — что именно должно “заработать”.

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

Проверяют не всегда идею или задумку.
У идеи уже есть 100 конкурентов, которые это делают.
Проверяют: смогу ли я стать 101-м — и продавать это.
Бывают уникальные проекты, в которых проверяется сама идея и насколько продукт нужен рынку, но это крайне редко и не применимо к большинству проектов.

Запускаете интернет-магазин цветов или чехлов для телефона — проверяете не идею, что цветы нужны, а получится ли у вас конкурировать на текущем рынке, с конкретным продуктом и ценообразованием, с "вот этим" набором преимуществ. Работает ли бизнес-модель в текущей форме продукта? И это важно понимать, чтобы делать правильные выводы и заранее ставить себе метрики, а как "цена" влияет на результат или "условия доставки". Кто-то называет это тестированием, но все это такие же этапы MVP, и все продукты в том или ином виде MVP, пока не стали монолитом с огромными бюджетами, аудиторией и тд.

Один из моих проектов, где мы привлекли крупные бренды.
Они пришли, посмотрели "так называемый MVP" — и не купили.

Продукт был почти готов и даже закрывал потребность. Казалось — вот она точка роста. Но нет. Если бы остановились — всё. Но пошли дальше, нашли, что мешало — и процесс сдвинулся. Опросили, разобрались в причинах, нашли что мешает. Мы умеем правильно собирать заявки, лендинг и его метрика сработала, даже выход на демо-период, а продажа нет, потому что были запросы аудитории, которые еще нужно исправить. MVP ли это в классическом представлении? Наверное... нет, продукт готов. И как можно выпустить MVP продукта хуже рынка? Предложения конкурентов - уже ваша нижняя планка для продукта.

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

Это и есть MVP по-настоящему:
одна гипотеза → одна метрика → конкретное решение.
Если MVP “не сработал” — это не провал.
Это сигнал. Но его надо услышать — и обработать.
А не просто “не пошло — всё, закрываем”.

© TheITDirector
#mvp #saas #разработка #dev

“Найдите нам одного сильного разработчика — он всё решит.”
Так думает бизнес. А потом у проекта год нет прогресса.
Во время аудитов я часто вижу одну и ту же ошибку:
нет системного аналитика, нет PM, нет архитектуры.
Зато есть один разработчик, которому “сказали сделать”.

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

Разработчик не может вытянуть проект в одиночку.
Нужна система: задачи, приоритеты, цели, процессы.

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

Если у вас этого нет — не важно, кого вы наймёте.
Он просто устанет, сгорит — и уйдёт.

© TheITDirector
#productmanager #projectmanager #pm #разработка

Что на самом деле даёт бизнесу IT-директор
Многие думают, что IT-директор — это “когда сложно” или “когда нужна разработка”.
На деле — это про рост. Системный, управляемый, без срывов.

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

Не решать задачи “в чате с разработчиком”, а строить систему, где процессы прозрачны, задачи приоритетны, а IT — это инструмент роста, а не набор реакций на проблемы.

Моя формула:
IT-директор нужен не тогда, когда всё горит, нужно, чтобы не горело вообще — и чтобы бизнес мог расти, не проседая в технологиях.

© TheITDirector

🧓 Из прошлого — привет от дедов
Раньше мы деплоили по FTP, писали SQL в шаблоне и гордились этим.

Сейчас джуны знают Docker, OpenAI, умеют собрать проект с нуля за вечер.
Но всё ещё не могут объяснить, почему цикл не выходит из бесконечности.

🧠 Инструменты — отличные.
Но если не думать, ты просто оператор чужих решений.
GPT не заменяет голову. Он усиливает того, кто ей пользуется.
© TheITDirector

Удалёнка — это не только свобода, но и навык.
Мир давно стал распределённым: команды из разных стран, часовых поясов, культур. Кто не умеет этим управлять — остаётся в прошлом.
Важно не просто «созвониться раз в день».

Нужны:
— ясные цели
— roadmap
— задачник
— процессы
— метрики
— и главное — доверие.

💡 Инсайт: если правильно выстроить команду в разных часовых поясах — вы получаете эффект 24/7.

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

Это ускоряет time to market и делает вашу систему живой — без ночных дежурств и костылей.
Управлять удалёнкой — это отдельная профессия. И навык, который нужно развивать.

Если было полезно — перешлите этот пост коллегам 👌
© TheITDirector

🧠 Чаты — не таск‑трекер
Если вы ставите задачи в личку —
не удивляйтесь, что всё горит и ничего не двигается.

У меня был кейс: сотруднику слали задачи в Telegram, кучей.
Он не понимал, что главное. Команда — не в курсе, кто что делает.
Это не работа. Это пожар.

Задачи должны идти через нормальный трекер:
с приоритетами, сроками, статусами и контекстом.
🔹 Trello — отлично для продуктовой доски и визуального контроля
🔹 Jira — когда нужно трекать время, вести эпики, связать задачи с ветками и деплоем

Хороший задачник:
— снижает ошибки
— экономит нервы
— показывает, куда движется продукт
— делает работу прозрачной для всей команды

📌 Задачи — не “напомни в чате”.
Продукт строится не из сообщений, а из управляемых процессов.
© TheITDirector

🧱 Найм разработчика — это не про код. Это про последствия
Когда ищу разработчика, я не думаю: “умеет ли он писать на нужном стеке”.

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

Плохой найм — это не баг. Это накопленный ущерб, который будет копиться тихо:
в коде, в коммуникации, в доверии внутри команды.

Что важно:
Как он работает с чужим кодом
Не "как он пишет", а как он встраивается в уже написанное. Без обнулений и войн.

Есть ли потенциал к росту
Если это middle — может ли дорасти до роли, где он ведёт, а не ждёт задачку.

Есть ли порядок в голове
Структура в ответах, подход к задачам, умение докрутить самому. Без суеты.

Относится ли с уважением к чужой работе
Если приходит в команду и сразу кричит “тут всё плохо” — значит, так и будет работать.

Я всегда задаю один вопрос, который показывает системное мышление:

“Как бы ты реализовал доставку заказов из нескольких складов для e-commerce: с учётом остатков, логистики и интеграций с внешними системами?”

Ответ показывает всё:
— как человек думает,
— как строит цепочку,
— и видит ли вообще бизнес-задачу, а не просто «я бы сделал API».

Хороший разработчик не просто кодит. Он понимает, как не сломать систему.

📎 Мини-чек‑лист для HR: как понять, что перед вами сильный разработчик
— Не спешит переписать — сначала вникает
— Не говорит “всё плохо” — ищет, что сохранить
— Видит бизнес-задачу, а не только фичу
— Умеет объяснить логику простыми словами
— В ответах есть структура, а не поток сознания

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

Сохраните, отправьте коллегам, пригодится 👌

© TheITDirector

💸 IT бизнес на доменах
Один из самых тихих, но прибыльных бизнесов, которым я занимаюсь — это домены.

Купил twelve.ru до того, как появился жилой комплекс.
Продал застройщику в Москве. Ни строчки кода. Только тайминг, чутье и инвестиция. Хороший домен, и будет только дорожать со временем, уверен.

🧠 IT — это не только программирование. Это и стратегия, и активы, и сделки.

Сейчас в продаже
HRBP.ru - домен + сайт.
В ближайшее время стартует аукцион, предложения по цене можно отправлять в личку, контакт в профиле. Отличный домен для HR бизнеса или личного бренда HR Business Partner.

Ставьте 🔥, буду писать чаще про домены и поделюсь опытом в этом направлении
© TheITDirector

🎟 Как я сделал первую онлайн-систему бронирования для кинотеатра

Когда ко мне обратились из Синема Стар, не было ни готовых решений, ни интеграций, ни SaaS-сервисов, которые справились бы с этим, ~ 2008 г.

Нужно было: не продать одно и то же место дважды, и дать возможность бронировать онлайн.

Я делал сайт и систему бронирования с нуля.
Связывал схему зала с базой, вводил блокировку мест до оплаты, считал таймеры резерва, — всё необходимо было учесть. И это работало.

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

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

После этого я всегда думаю как должен работать «бизнес» в реальности с «разработкой».
© TheITDirector

IT-структура и хаос за 30 миллионов

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

Я заходил в проекты, где всё выглядело «как надо» — до первого аудита.

И находил вот это:
– домен зарегистрирован на бывшего маркетолога;
– хостинг — на физлицо, “обещали, что всё норм”;
– бэкапов нет. Вообще. Или лежат рядом с продом;
– автоматизации — ноль. Хотя команда и так перегружена.

🧯 Как это чинить — пошагово:
Проведите IT-аудит.
Не только теха, но и всей инфраструктуры: от прав до рисков.

Проверьте критические точки:
– На кого оформлены домены, серверы, облака?
– Где и как хранятся бэкапы? Есть ли offsite-копии?
– Кто реально имеет доступ к ключевым системам?

Приведите всё в порядок:
– Переведите активы на компанию.
– Внедрите схему 3–2–1 для резервного копирования.
– Разграничьте права, отключите лишних людей.
– Упакуйте документацию и регламенты.

Автоматизируйте рутину.
Если у вас 8 человек делают то, что можно автоматизировать за неделю — нужно решать это.

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

👀 Проверь, всё ли у тебя в порядке.

Начни с простого:
На кого оформлено то, чем ты реально владеешь?

© The IT Director

🔐 Бэкапы спасают бизнес — когда всё остальное подвело
После поста про IT-хаос много кто написал, оказалось — схема 3–2–1 почти никому не знакома.

Что означает
3 копии — хотя бы три версии ваших данных.
2 носителя — на разных устройствах: например, на компьютере и на флешке.
1 копия вне офиса — дома, в облаке или хотя бы не рядом с основной.

Для чего это нужно
• Один диск может сгореть.
• Второй — случайно удалить.
• А третий — спасёт.

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

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

Если есть вопросы — пишите, контакты в профиле.
© TheITDirector

🚀 Почему сайт может тормозить — и как это чинится
Когда человек заходит на сайт, сервер начинает «собирать» страницу: тянет товары, картинки, меню, фильтры. Это занимает время.

А теперь представьте, что всё уже собрано заранее и лежит «в коробке» — просто отдай и всё. Это и есть кэш.

📦 Кэш — это как готовый набор, а не конструктор.
Не нужно собирать каждый раз заново — просто показать.

💡 Что даёт:
— сайт открывается мгновенно
— меньше нагрузки на сервер
— не тратим деньги на «лишние» запросы
— люди не уходят с сайта из-за ожидания

⚙️ В одном проекте я просто включил кэш — и скорость загрузки выросла в 10 раз. Без редизайна, без переписывания кода.

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

Конечно, кеш не решает проблемы плохой архитектуры и лишних запросов, или серверные проблемы, но в большинстве «простых» проектов — помогает.
© TheITDirector

🛑 Почему нельзя пилить всё сразу?
Потому что через 3 месяца будет сюрприз:
— ничего не работает до конца
— всё делали параллельно
— показать нечего
— надо ещё месяц… и ещё месяц

📉 Продукт есть — а толку нет.
Все устали. Всё не то. Всё не в срок.

✅ Как делать правильно?
Каждая User Story — максимум 2 недели.
Список товаров без фильтров — ок.
Корзина без оплаты — тоже ок.
Главное — видеть результат, давать обратную связь, корректировать.

Пусть кривенько, пусть не идеально — но видно, куда идём.
Если тянете до конца — получите конец.
© TheITDirector