Если ты держишь всё в голове, ты не управляешь.

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

Ты вроде держишь всё под контролем, а на самом деле команда ждёт. Один день, другой, неделя.

Скорость падает, но никто тебе не скажет потому что “ну ты же босс”.

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

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

Если хочешь понять, какие HR-процессы можно автоматизировать — пиши: @wbt_sales
Сделаем бесплатный аудит.

Как Цинь Шихуанди навёл порядок в HR и зачем вам это знать

Китай, 3 век до н.э.

До Цинь Шихуанди (тот самый, что терракотовое войско) в стране был кадровый хаос.
Чиновников нанимали “по знакомству”, увольняли “по настроению”, учёта не вели.

Кто за что отвечает непонятно. Кто где работает никто не знает.

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

То есть по сути он:
📌 наладил учёт людей,
📌 автоматизировал вход и выход,
📌 настроил разгрузку руководителей от рутинных решений.

И знаете что? Империя после этого продержалась дольше, чем любая стартап-команда без HR-процессов)

Цинь справился 2000 лет назад.
Скорее всего, ты тоже сможешь.

Если хочешь собрать свою систему - пиши: @wbt_sales
Сделаем бесплатный аудит.

«У нас HR - это один человек и Excel. С чего вообще начать автоматизацию?»

Начни с одной конкретной боли.
Условно: люди постоянно забывают, кто в отпуске → автоматизируй отпуска.
Просто форма + уведомление в чат.

Или справки: сделай шаблон, поставь бота, пусть сам шлёт PDF.
Занимает 2 вечера - экономит каждый день.

Ты не обязан строить HR-систему как в Яндексе.
Но если не начнёшь с малого - будешь сидеть в Excel ещё три года.
И винить всех, кроме процесса.

Хочешь, поможем разобраться, что именно автоматизировать первым.
Пиши: @wbt_sales
Аудит бесплатный.

Один на миллион и ноль — это колоссальная разница, когда речь идет о попытках чего-то достичь.

В минувший шаббат смотрели семьёй October Sky. Фильм про школьника из крошечного шахтёрского городка в Западной Вирджинии, где жизнь каждого определена заранее и крутится вокруг шахты.

За окном — 1957 год, начало холодной войны, СССР запускает первый искусственный спутник.

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

И вот в этой атмосферке нам показывают парня, который видит как в небе пролетает советский спутник, огибая Землю за каких-то 90 минут.

Это настолько поражает его воображение, что он вдруг решает строить ракеты.

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

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

Гениальная сцена, поразившая меня:

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

— Один на миллион.

— Почему ты сразу не сказал, что такой большой?

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

И этого действительно достаточно когда ты чего-то хочешь.

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

Горящие на этом внутреннем топливе энтузиазма, и с опытом за плечами — для меня очевидно, что с ними продукт получится.

А вы помните момент, когда не было шансов, но вы продолжили?

Как Amazon внедрил AI на складах и почему это стоит разобрать.

Amazon начал автоматизировать логистику потому что не справлялся с объёмами.

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

Люди ошибаются, устают, тормозят. Это стало узким горлышком.

Сейчас на складах у них работают более 750 000 роботов, и каждый не сам по себе — им управляют AI-системы.

Sparrow сортирует товары, Proteus двигает тележки, Sequoia ускоряет комплектацию.

Система сама решает, кто что делает человек или машина.

В результате:
– заказы обрабатываются быстрее,
– меньше ошибок,
– сокращены издержки на 25% (данные: FT).

И да, параллельно они сэкономят десятки миллиардов за десятилетие.
Но не в этом суть.

Они решали проблему и ставили туда систему, которая лучше справляется, чем человек.

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

Хочешь найти такие места у себя — пиши @wbt_sales

Сделаем аудит. Просто покажем, где можно убрать лишнее или заменить с ИИ

Кандидаты уходили, потому что им не отвечали. Решили эту задачу через AI.

Резюме влетает → никто не ответил → человек уходит → потом говорим “эх, нормальный был”.

HR просто не успевали. Много ручной работы, нескончаемые чаты, таблички, кто на каком этапе, никто не понимает.

Что сделали:

Подключили AI‑модуль к системе подбора.

И вот где он реально помог:

✔️ Сам читает резюме и письма.
Выделяет ключевые навыки, сравнивает с описанием вакансии, проставляет “приоритет отклика”.

✔️ Формулирует первый отклик.
По шаблону, но с учётом контекста + есть конкретика: почему интересно, что откликнулись.

✔️ Следит за “висяками”.
Сам предлагает: “этого, кажется, пора позвать”, “этого можно закрыть”.

✔️ Учится на действиях HR.
Если отклоняем одинаковых кандидатов, со временем предлагает метки: “низкий опыт”, “нет нужных технологий”.

Результат:

Минус 40% потерянных откликов.
Среднее время до первого ответа в 2 раза быстрее.
И всё это без найма нового человека.

Важно: AI здесь помощник, но не замена человеку. Он снимает рутину, чтобы HR фокусировался на собеседовании.

Хочешь понять, можно ли у тебя внедрить что-то подобное, пиши: @wbt_sales
Сделаем аудит.

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

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

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

Как это сделать:

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

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

А у вас есть свои настройки или лайфхаки для удобной работы за маком?
Делитесь в комментах - заберу👇

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

Почему?

Потому что проект - это штука с границами. Есть начало, конец, задачи.

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

В Вбтеке мы часто обсуждаем именно работу, а не «таски». Потому что цель - не завершить спринт, а принести клиенту ценность:

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

Список задач - это только маршрут. Ценность всегда на финише⚡️

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

А потом ждёшь, чтобы тебе её привезли - быстро, тёплой и не вверх дном.

С разработкой так же.

Любой проект - это две отдельные задачи:

- выбрать что делать: купить готовое решение, доработать своё или собрать с нуля;

- доставить результат: так, чтобы оно реально работало и приносило пользу, а не просто лежало «в проде».

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

А потом удивляться, почему «вроде сделали, а ценности нет».

Мы у себя разделили это жёстко.

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

И да, иногда проще купить пиццу 🍕, чем готовить самому. Но это уже другая история.

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

Ну, думаю, знаю город, по памяти доеду. Через 15 минут оказался в тупике. Потом выехал куда-то на окружную, потратил 40 минут, чтобы вернуться обратно… в итоге доехал, но зачем было так?

С проектами та же история.

Когда есть энергия, команда и желание, то легко рвануть с места. Но если нет маршрута, то велика вероятность, что уедешь не туда, застрянешь или потратишь в 3 раза больше, чем нужно.

Унас всё едет по вот такому циклу:

- Идея. Зафиксировать и проговорить, чтобы все понимали, откуда она взялась.

- Изучить. Проверить, нужно ли это вообще. Часто уже тут говорят «нет».

- Подписать. Чёткие договорённости: кто, что, зачем.

- Сделать. Работаем поэтапно, с регулярными демо. Видим, где затык - тормозим.

- Эксплуатировать. Не бросаем на релизе. Поддержка, метрики, обратная связь.

И на каждом шаге «стоп-сигналы». Маркеры, что пора переспросить, подумать, переформулировать.

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

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

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

Мы собрали 2 простых инструмента, которые экономят время и деньги при заказе разработки. (Всё на основе опыта десятков проектов)

Они помогают:
📍быстро описать задачу,
📍получить честную смету,
📍понять, кому можно доверять до подписания договора.

1. Шаблон Брифа
13 коротких вопросов, которые помогают описать задачу.

2. Чек-лист подрядчика
24 вопроса, которые помогают проверить подрядчика ещё до договора.

Получить можно по кнопке ниже.

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

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

Что это за проект?

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

Мы писали бэкенд, который превращал видеопоток с камер в аналитику:

— текущая активность лошади,
— пуши с рекомендациями,
— удобные дашборды для владельцев.


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

А у вас был такой проект? Расскажите - люблю такие истории.

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

Эти и десятки других вопросов регулярно всплывают в разговорах с клиентами, знакомыми предпринимателями и даже внутри команды.

Поэтому мы в WB—Tech на нашем сайте сделали раздел «50 быстрых ответов» - короткие, понятные заметки по самым частым вопросам бизнеса про автоматизацию, управление и разработку.

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

Писали просто, без маркетинга, только по делу.

Если интересует, как мы на них отвечаем — читайте тут:

👉 https://wbtech.ru/faq/

А если есть свой вопрос: напишите в комменты или в личку. Может, он станет 51-м 🙂

Если бы в 2013 году ты сказал, что Slack станет стандартом коммуникации для бизнеса - в тебя бы, скорее всего, бросили мем с Teams.

А начиналось всё как чатик… для геймеров.

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

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

Что они сделали дальше?
— Убрали всё лишнее. Оставили каналы, упоминания, поиск.
— Сделали ставку на UX: Slack был «тёплым», визуально уютным и быстрым.
— И главное, создали интеграции. Slack не просил «перейти на новый мессенджер», он просто вписался в твои процессы.

В итоге он стал рабочим «вторым мозгом» компании. В нём живут задачи, документы, логика процессов.

Каждый раз, когда мне кто-то говорит: «Ну у нас проект заглох, но есть пара тулов, может, из них что-то получится…» - я вспоминаю Slack.

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

Кстати, мы используем именно Слак у себя в компании.

Удалите ваши дешборды по критичным метрикам.

Ладно, на самом деле звучит как хайп, сейчас объясню, что имею ввиду.

Раньше считалось, что хорошая аналитика - это когда у тебя есть BI-инструмент, куча графиков, и любой сотрудник может «посмотреть данные». Ага. Только вот посмотреть могут в рабочие часты 5/2.

Проблема в том, чтобы человек сам пришёл, выбрал отчёт, правильно его прочитал и ещё успел что-то изменить, пока не поздно.

Что мы делаем иначе?

В проектах WB Tech мы уходим от идеи «всё должно быть видно», и приходим к «всё важное должно само орать, если что-то пошло не так».

Поэтому:
- Метрики, они интегрированы в слак (нам автоматически приходят стата за неделю как отработала команда, сколько часов)
- Аномалии не ждут внимания, они пингуют ответственного;

А как у вас? Кто первый узнаёт, что что-то пошло не так?

Ты приносишь в команду автоматизацию, а вместо «вау!» получаешь:

— А что, если всё сломается?
— А раньше было понятно, теперь — непонятно
— А зачем вообще это менять, и так работало же

Мы с таким сталкивались. Причём не потому, что решение плохое - просто люди ему не доверяют.

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

Мы собрали в одном месте и написали статью, как вообще с этим быть:

👉 Статья про доверие к автоматизации

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

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

Иногда мне кажется, что самые опасные баги в головах. Особенно в одной конкретной: в голове собственника.

Есть такой паттерн: «Я сам лучше знаю».

Я сам его периодически ловлю у себя.

Типичное поведение:
- Дизайн обсуждаем? Да что там обсуждать, я вчера в Figma нарисовал.
- А вот эта кнопка зачем? Ну это чтоб было. Мне так нравится.
- Что, сроки срываются? Странно. Я же всё объяснил. Один раз. Год назад.

Когда собственник погружается в детали - это хорошо. Он «в теме», он болеет за результат.
Но когда он подменяет собой аналитику, дизайнера, тимлида и ещё QA впридачу - проект начинает разваливаться.

Потому что:
- Задачи неясны, потому что были в голове.
- Решения спорны, потому что взялись из вкуса, а не из данных.
- Ответственность размыта, потому что «я всё контролирую».

Мы с таким сталкивались не раз - и со стороны заказчика, и у себя.

Поэтому выработали правило: владелец продукта должен быть владельцем цели, а не реализации.

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

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

Если ты тот самый собственник, которому сложно отпустить контроль: задумайся, чего ты больше боишься: ошибки в кнопке или смерти проекта?)

Когда Юлий Цезарь захватывал территории, он строил дороги.

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

Почему я вспомнил об этом?

Потому что в приложениях всё так же.

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

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

Что мы делаем, чтобы этого не случилось:

- Сначала думаем, как будет развиваться продукт. Прямо на старте, даже если кажется, что проект «на пару месяцев».
- Строим маршруты данных и логики, которые можно использовать повторно.
- Обозначаем узкие места: где скорее всего возникнет техдолг.
- Закладываем масштабируемость — чтобы через полгода не переписывать всё с нуля.

Хочешь надолго - строй как Цезарь! И обращайтесь к нам за разработкой - написать можно сюда @wbt_sales

Что нужно делать, чтобы победить время?

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

Сюжета почти нет: вдова Эдит Притти зовёт землекопа Безила Брауна исследовать курганы на своём участке. Из песка проступает силуэт ладьи Саттон-Ху, древнее погребение.
К делу подключаются музейщики и отодвигают Брауна в тень. Но главноене в событиях.

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

Эдит смертельно больна, но продолжает руководить раскопками. В сцене, где она берёт за руку Пегги, весь смысл фильма: жизнь складывается из коротких «да», которые мы успели сказать.

Браун говорит сыну: «we all fail». Мы все оступаемся, но продолжаем чтобы кто-то подхватил дальше. Он выбирает дело, а не славу. И это спасает не меньше, чем сама находка.

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

Именно это и удерживает нить непрерывности.

Как вам такая идея?

Иногда кажется, что приложение можно запустить «через пару недель, если сильно постараться».

На деле даже простое решение от идеи до стора - это 3–6 месяцев, если по-честному.

Недавно мы в WB—Tech написали статью, в которой собрали всё, что влияет на сроки:
— от чего зависит длительность проекта,
— какие ошибки обычно растягивают время,
— и что можно сделать, чтобы всё шло быстрее (и без слёз).

Там с нюансами:
— MVP vs Full release
— iOS или Android или Flutter
— CI/CD и как помогает no-code
— почему не стоит верить таймингам без проектной аналитики.

Если у вас на горизонте релиз или нужно прикинуть сроки —
👉 вот ссылка на статью

Надеюсь, будет полезно