И второй

Формула Стеклянного потолка

Математическое обоснование почему агентства не могут прыгнуть выше планки дохода:
1) Отток (churn) клиентов существует и при росте количества клиентов нужно будет всё больше клиентов, чтобы перекрывать отток.
2) Отток растёт с ростом агентства и выходом основателей из процесса оказания услуги
3) Есть плато, при выходе на которые очень тяжело расти - отток равен притоку

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

Источник и графики: https://jakobgreenfeld.com/agency-model

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

15 лет назад я написал первую строчку кода интранета для внутренних нужд компании, в которой работал. Сам придумал, что нам нужен интранет. Сам начал его писать и внедрять. На рынке был Sharepoint Portal, до выхода Битрикс24 было ещё полтора года.

Прошло 15 лет - интранет очень мощно развивается силами внутренней команды.
Почти 4000 активных пользователей - сотрудники, партнёры и клиенты. Все процессы и задачи компании происходят там.

Я передал проект команде больше 10 лет назад и уволился делать стартапы.
Смотрел пару недель назад на звонке актуальную версию интранета и удивлялся обновлениям.

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

Спасибо коллегам, что поддержали начинания 15 лет назад!

Повесить переключение языка на Caps Lock.

Самый неожиданный лайфхак за много лет за компьютером
- Caps Lock практически не используется при наборе. Большинство людей забывает о его существовании
- Гораздо удобнее нажимать одну кнопку, чем две
- Часто для него есть отдельный индикатор - как в системном трее, так и на самой клавиатуре.
- Скорость переучивания - 2 дня

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

Добро пожаловать в увлекательный аттракцион!

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

Вводные следующие:
- 30,000+ посетителей в месяц на сайте
- 0 расходов на трафик
- 0 денег фондов
- Работает 13 человек (посчитал, удивился), все part time (!)
- Месячный доход 100 тысяч рублей 😅, весь уходит на содержание штата.
- Часть участников работает за 0 или за символические деньги на интересе уже больше года ❤️
- Есть достижимый понятный план трансформации этой истории в SaaS на >1 млн дохода, в который я верю.
- Я считаю, что мы можем обогнать всех конкурентов на этом рынке.
- Конкурента в прошлом году купили за 1,000,000,000 (один миллиард) рублей 😳
- Почти все моё время съедает диджитал-агентство заказной разработки и менторство других агентств и команд.

PS: Пусть проект будет (пока) анонимным, это позволит мне не проводить посты через лишнего внутреннего цензора и палить внутрянку.

Откуда трафик?

Для большинства стартапов трафик — самая большая проблема. Без трафика нет клиентов. Реклама стоит денег, пиар стоит денег и усилий. Многие проекты не смогли отстроить математику привлечения клиентов: "воронки не сошлись", а проекты закрылись.

В агентстве я заметил, как в узких коммерческих нишах отлично работала стратегия SEO-продвижения через информационные запросы. То есть, не "купить синхрофазотрон", а "какие бывают синхрофазотроны". Хорошо продуманные публикации в течение года перекрывали по объёму трафика результаты команды по контекстной рекламе. Да, это были менее "горячие" клиенты. Но это были наши клиенты.

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

В своём проекте я никуда не спешил. Собрал черновое ядро, изучил конкурентов, нашёл "дырки" - запросы есть, а известные сайты в выдаче отвечают на эти запросы плохо. Легкая html-разметка, уважение к семантике, микроразметка, sitemap, open graph. Высокие показатели Google Page Speed, mobile-first. Первый сотрудник в редакции.

Первые полгода было грустно...

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

Всё совсем наоборот!
- В первой версии продукта не было монетизации
- До сих пор нельзя зарегистрироваться (а нам 2 года)
- Техническая SEO-оптимизация до сих пор не дожата другими SEO-работами
- Не хватает десятка "очевидных" разделов и фич

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

Если вам не стыдно за первую версию вашего продукта, вы запустились слишком поздно.
- Рид Хоффман

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

Команда разработки для стартапа

В 2003 году для старта проекта нужен был программист, продажник и дизайнер (hacker, hustler & designer). Пусть четвертый парень на картинке будет инвестором. Так и запускали первые проекты.

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

Команда супергероев теперь выглядит так:
- Продажник теперь BizDev и его меньше всего затронуло разделение труда. Он всё так же ищет жертву потребителя на рынке.
- Product Owner - единственный понимает, что все делают и что должно получиться на выходе. Но сам может генерировать только беспокойство и приоритеты.
- Product Manager - генерирует рандомные гипотезы, пытается понять что нужно считать в продукте и что из этого следует.
- Project Manager - спрашивает у всех "как дела?" и рассказывает почему проект отстает от графика.
- Business Analyst - должен всем всё разъяснить и описать, но душнилу плохо понимают.
- Brand designer - нарисует логотип, подберёт шрифт для визиток и сделает презентацию на 80 страниц с обоснованием.
- UX/UI - старательно перерисует чужой кейс с биханса в вашу фигму по мотивам фир стиля. Тоже приложит презентацию.
- Frontend-разработчик - превращает всё до чего дотронется в Java Script.
- Backend-разработчик - усложняет и так сложные штуки под капотом, которые никто кроме него не понимает.
- QA manual - проверяет, что продукт ломается там, где не ожидали.
- QA automation - заставляет робота проверять, что продукт ломается там, где ожидали.
- DevOps - сисадмин, который заливает всё на сервер, но почему-то тоже через код и 8 слоёв абстракции.

Конечно, на такую ораву теперь нужен TeamLead, HRd и ещё какой-нибудь скрам-мастер.

Нормально же сидели, откуда столько народу понабежало? 🙈

Как код попадает на сервер 2025 edition
Как раньше: открыл удалённую папку на сервере по FTP, скопировал туда свои файлы — сайт работает.

К каким проблемам это приводило:
- Два разработчика скачали один и тот же файл, внесли правки и по очереди загрузили их на сервер. Изменения первого разработчика стёрты вторым.
- Разработчики работают прямо на сервере. Человеческий фактор неизбежно приводит к ошибкам.

Как это выглядит у нас сейчас:
- Разработчик копирует код из Git-репозитория (git clone/git pull)
- Создаёт свою ветку, в ней изменения хранятся отдельно (git checkout -b)
- Вносит изменения в свой экземпляр (git commit)
- Отправляет изменения обратно в репозиторий (git push)
- Создаёт запрос на добавление своих изменений в общий код (Merge Request)
- Робот 🤖 на новом поддомене разворачивает тестовую копию сайта с изменениями (Review Apps) и запускает тестирование
- Менеджер, Тестировщик и другие разработчики смотрят и щупают изменения
- Разработчик дорабатывает код, тестовый сайт автомагически обновляется
- После принятия запроса на слияние (Merge Request) все новые изменения автоматически выкатываются на промежуточный сервер
- С промежуточного сервера время от времени все обновления попадают на основной сервер (тоже через Merge Request)

В итоге менеджеры могут одновременно отслеживать прогресс разных задач на тестовых доменах и давать обратную связь.
Дополнительные бонусы: исключаем риск утечки данных (152-ФЗ) и рукожопства на сервере (🤖).

Self-hosted

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

Мы пошли другим путем: находим продукты с открытым кодом и ставим на свой сервер вместо платного SaaS.

Что мы используем в работе:
Gitlab CE - репозитории на нашем сервере. Переезжали с Bitbucket. Используем активно CI/CD.

Sentry - сборщик логов с запущенных приложений. Очень полезный сервис - мы видим ошибки у реальных пользователей, сгрупированные по типу и с полным стеком вызова (браузер, устройство, окружение). Система прожорливая - ест CPU и RAM.

Grafana - Конструктор дашбордов с графиками. Мы используем для мониторинга серверов (БД Prometheus в качестве источника). Видел у коллег дашборды с продуктовыми метриками, но у нас до этого руки пока не дошли.

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

PostHog - мощная аналитика. Расстановка своих событий (как в метрике и ga), воронки, срезы, полная информация о визитах, возвратах и т.д. Под капотом Clickhouse, Kafka и все 33 удовольствия для работы. Как и Sentry, очень прожорливая система.

Ollgram - tg-боты для поддержки. Очень удобно - делаем бота, указываем его контакты в канал. Бот пересылает сообщения пользователей в секретную группу, а мы общаемся от имени бота. Не связано с CRM, но для получения обратной связи или старта - то что нужно. Код open source - поставили к себе.

Сейчас присматриваюсь к новым кандидатам
- Affine для документации вместо Miro и Notion
- Zammad - автоматизация службы поддержки. Helpdesk вместо ZenDesk/CarrotQuest
- Twenty в качестве CRM


Мы пока не смогли заменить трекер задач с учетом времени. Попробовал Taiga (вроде все ок, но не гибко, не хватает фич). Многообещающий Plane перекосило в урезание функционала бесплатной версии. Концептуально понравился LeanTime.

А пользуетесь ли вы self-hosted и чем?

Как сове совместить расписание менеджера и создателя?

У Пола Грэма (Y Combinator) есть замечательное эссе (англ.), в котором он рассказывает про два режима деятельности.
Расписание менеджера (manager's schedule) - звонки, переписки, постоянные переключения контекста, диспетчерская.
Расписание создателя (maker's schedule) - фокусировка, погружение в процесс, одна задача может занимать несколько дней.

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

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

13:00 — Подъём после полудня. Я сова, сколько себя помню. Ночью голова работает — ранним утром я овощ. В любой стране и при любом режиме освещения буду спать первую половину дня.

14:00 — Днём тревожность и коммуникации требуют внимание менеджера. Говорю на совещаниях, переписываюсь в множестве чатов, хожу в таск-трекеры, создаю, делегирую и делаю десятки задач, устраняю препятствия для команды.

17:00-19:00 — Количество сообщений резко уменьшается. Идеальное время менторской консультации или любого другого 1:1 с повесткой. Есть бодрость, я включен, мой мозг готов быстро обрабатывать поступающие данные и генерировать решения.

19:00 — Обед и тишина. Рутина по дому, игра с собакой.

20:00 — Начинаются стратегические звонки и вовлеченные переписки.
Очень много людей готовы говорить вечером и это качественно другие звонки, чем днём.
- Участники проектов с частичной занятостью. Учеба, дети, основная работа — всё было днём.
- Партнёры. Строить планы, консультироваться, делиться новостями своих проектов.
- Друзья и семья. Общение после работы.
- Люди в других часовых поясах. И те, кто западнее меня (у них раньше), и лютые ночные жители или очень ранние пташки восточнее.

00:00 — Тишина в эфире, пожалуйста. Самое время включить в себе Maker.
Обычно это 1 или 2 проекта на сессию. Открываю заготовленный список задач. Это всегда будет список, потому что крупная задача попадает в него только через дробление. Поехали!

04:00 — Начинают открываться ворота сна. В ближайший час я уйду от клавиатуры.

06:00 — Blackout.

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

Почему я дома в авиарежиме

Последние несколько лет мой телефон всегда находится в авиарежиме, но с включенным вайфай и Bluetooth.

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

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

Это вышло из под контроля. Я выключил.

– Меня не прерывают звонки, которые я не заказывал.
– Меня не прерывают смс, которые я не заказывал.
– Не выбивает из видео-звонков, конференций и звонков в мессенджерах.
– Чтобы принять sms от банка, я выключаю авиарежим на минуту.
– Часть 2FA завязано не на SMS, а на Google Аuthenticator — сотовая связь не нужна.
– Самые продвинутые сервисы позволяют звонить в поддержку через интернет.
– Под доставку продуктов и еды приходится входить в сеть.
– Доставки товаров едут в ПВЗ и копятся, пока я не заберу.
– Адекватные дееспособные люди умеют пользоваться телеграмом или вотсаппом. Все, кто набирал и не дозвонился — написали в мессенджер.
– При выезде из дома сотовая сеть включается из-за навигатора.
– В автомобиле входящие на беззвучном режиме — не прерывают музыку.

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

Моя первая видеоигра была аркадным автоматом. Мне было 4 или 5 лет. Мама работала в международном аэропорту, в одной из зон которого был установлен настоящий аркадный автомат. Я очень смутно помнил, как я садился на седло мотоцикла, отклонялся корпусом и ехал по трассе к далёкому ночному городу...

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

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

Итоги расследования:
- Игра Hang-On (википедия англ.) была выпущена Sega в 1985 году и стала большим хитом в США, Японии и Великобритании.
- Было продано 20 тысяч автоматов, не считая пиратских копий, что сделало Sega лидером рынка на тот момент.
- Множество версий автомата и только часть с седлом (мне повезло).
- Успешные порты на другие платформы и сиквел.
- Фамилия разработчика — Сузуки (совпадение?).

Youtube с игровым процессом.
Играть онлайн - при наведении мышкой на экран всплывает меню, в котором можно настроить клавиши.
Та самая фотография

Как не надо нанимать программистов

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

Вследствие этого столкновения рождаются очень занятные идеи:
- Пригласить человека, привыкшего медленно думать в одиночестве, на супер важное "сделай-или-провалишься" интервью. Интроверты привыкли к давлению.
- Тараторить ему про корпоративную культуру на высокой скорости и звонким голосом. Его ждут очень весёлые корпоративы, тим билдинг и море общения в весёлом офисе. Ведь он именно общения ищет в углу за монитором.
- Спрашивать его на старте академическое определение полиморфизма, чтобы он вспомнил все ощущения с экзаменов в универе. Заодно покажем, кто тут главный.
- Заставлять включать камеру — он точно захочет показать и проявить себя с незнакомыми людьми на первом звонке.
- Замучали до заикания на вопросах? — теперь время писать код по только что увиденному ТЗ под надзором незнакомого тех директора. Именно в живую, как никогда не будет происходить после.
- Соискатель прошёл 3 стадии экстравертного ада — самое время узнать об условиях работы в Джоб оффере, который сгорит за N дней. Срочно соглашайся, у HR есть KPI!
- Не очень понятно, зачем программисту работать именно у нас. Давайте завалим его деньгами и едой? Алчные айтишники только этого и ждут!

В конечном итоге выигрывает HR — программист нанят. Удовольствие найти проигравших оставлю читателю данного эссе.

А как можно нанимать программистов без стресса я расскажу завтра.

Как нанять разработчика: Вакансия

Данная инструкция отражает мой практический личный опыт.
За последние 10 лет я нанял более 50 разработчиков на полный рабочий день. Описанное касается разработчиков категории Middle и выше. Вы можете делать всё совсем иначе и у вас тоже будет результат — это нормально.

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

Хорошая вакансия будет замечена в ходе регулярного обхода площадок с работой.

Разработчик хочет прочитать вакансию и сразу для себя прояснить:
- А можно ли на удалёнке? Можно ведь, да?
- Описание архитектуры проекта одним предложением: "хайлоад екоммерс монолит на джанго с веб-мордой на реакте".
- В каком стеке и окружении работать, какой софт использовать.
- Какого рода задачи он будет делать. Только честно, без украшательств.
- На каком уровне требуется знать конкретные технологии.
- Его место в команде — за что он отвечает, за что не отвечает.
- Методологию работы: скрам, канбан, водопад, "молодой, динамично развивающийся стартап".
- Ритуалы: стендап, дейлики, покер-планирование, код-ревью, ретроспективы, багфикс-хакатоны и т.д.
- С кем работать и контактировать, а с кем не контактировать (что не менее важно).
- Количество и частота коммуникации.
- Какую продуктивность ожидают. Как и в чём она измеряется?
- Какая отчетность и зачем, кто её будет получать и проверять.
- Какая реальная вилка оплаты на позиции и какие плюшки?

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

В целом, больше ничего программиста не интересует 🙀

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


Все отклики на такую вакансию будут двух типов:
1. Осознанные отклики от целевых кандидатов
2. Вдруг я проскочу и меня доучат как-нибудь

Завтра покажу, как я отсеиваю первых от вторых.

Как нанять разработчика: Отбор кандидатов

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

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

В анкете 50+ вопросов. Спросим про часовую ставку, условия работы, работает ли с таймером, пишет ли тесты и любые другие интересные нам детали.
Самый большой блок — отдельные вопросы про каждую технологию и навык, который может потребоваться у целевого кандидата.
Какой опыт с _____?
Варианты ответа: Не было опыта, Изучал/Пробовал, Практик, Эксперт.

Кажется, что тут легко обмануть и приукрасить. Да, но навряд ли на 2 ступени. 🤡
Любой крупный обман в анкете вскроется на интервью и реальных задачах. А если что-то приукрасил — сам будет навёрстывать.

Разработчик с удовольствем заполнит анкету вместо 30-минутного интервью с рекрутёром. Анкету можно заполнить на текущем рабочем месте или после работы. Без стресса и спешки.

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

Неочевидная проблема с почтой для домена

Почта для домена — один из самых первых сервисов, которые появились в сети. Email существовал ещё в 1970-х в сети ARPANET, задолго до появления первого сайта в 1991 году.

Как обстоит ситуация сейчас, если мы хотим развернуть свою почту для домена:
- Получить статический IP.
- Настроить обратную PTR-запись в DNS, чтобы IP-адрес ассоциировался с доменом.
- Создать ящик postmaster@ — требуется для почтовых систем по стандартам RFC.
- Прописать SPF-запись — указывает, какие серверы имеют право отправлять почту.
- Настроить DKIM — криптоподпись к каждому письму.
- Включить DMARC ­— политику обработки писем, отправляемых от нашего домена. И читать отчёты, чтобы разбираться с теми письмами, которые не прошли SPF и DKIM.
- Настроить обработку bounce-писем — чтобы понимать, кому письма не доставлены и исключать их из будущих рассылок.
- Зарегистрироваться на всех крупных email-провайдерах https://postmaster.google.com/ https://postmaster.mail.ru/
- Отслеживать попадание домена и IP-адреса в публичные списки спамеров и писать письма на исключение оттуда.

Приключение на 20 минут, вошли и вышли.

Итак, вы зарегистрировали новый домен для проекта и начали получать и отправлять письма. Но почта всё ещё работает не так, как нам нужно.
- Все показатели нашего почтового домена зависят от репутации, которая от нас скрыта. Мы не знаем, как нас оценивают почтовики. У нового домена нет репутации.
- Новый домен нужно греть. Количество писем, отправленных каждый день, должно плавно расти. Маркетинг и PR должны это учитывать.
- За большой объем рассылок без прогрева нас накажут как за спам.
- Письма с домена могут попадать в спам из-за их содержания. Маркетолог выбрал ту же фразу или структуру письма, которую используют в спам-рассылках — мы в спаме.
- Мы не знаем, были ли письма доставлены и прочитаны.
- Люди нажимают СПАМ на транзакционных письмах — вся почта с домена начинает попадать в спам.
- Если мы попали в блэклист, почтовик (Gmail, Mail, Yandex, Yahoo) может заблокировать получение почты с нашего домена. После выхода из блеклиста почтовик может пару недель не принимать нашу почту.
- Почтовик может принимать ограниченное количество писем в час с вашего домена и потом замедлять их доставку до ящиков получателей.
- Если мы всё настроили правильно по стандартам и документации, письма могут не доходить. Потому что так решил фильтр, мы испортили репутацию или отправили неправильное письмо.

Реальное решение — отправлять почту с домена через крупные сервисы. Amazon SES, Mailgun, Sendgrid, Unisender и т.д. Их серверы находятся в белых списках и мы покупаем у них доставляемость.
Почта с нашего домена, отправленная через крупного провайдера, с большей вероятностью дойдёт до адресата.

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

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

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

Я выписал всё, чем нам нужно заниматься. Разработкой всё не ограничивается. Огромное количество действий поглощает рабочие дни команды: продажи, редакция, партнёрская программа, маркетинг, PR, финансы, бухгалтерия, HR, секретарь, служба поддержки, продукт, разработка, дизайн, интеграции, тестирование, юридические аспекты, инвестиции.

И попробовал рассортировать по кучкам. Потом на эти кучки можно будет приклеить ярлычки CEO, CFO, CMO, C3PO, R2D2...

Через 40 минут сортировки на доске я понял, что у меня не стыкуется. Текущая команда и виртуальная структура с дырками... В общем, заставил GPT воображать себя венчурным инвестором и успешным предпринимателем, после чего скормил ему эту задачу. Описал всех участников, рассказал, кто чем занимается и дал список направлений деятельности.

Такое распределение менеджмента получилось в итоге:
1. CEO (Chief Executive Officer) + CTO (Chief Technology Officer). Генеральный + технический директор. Стратегия и руководство, технические вопросы, финансы, инвестиции.
2. COO (Chief Operating Officer) + CRO (Chief Revenue Officer). Операционный директор + РОП. Продажи, управление редакцией, онбординг новых клиентов и сотрудников.
3. Head of Design & UX/UI — Дизайнер.
4. Head of Customer Support — Поддержка клиентов.
5. Head of Marketing (потенциально CMO) — Маркетолог.

Забавно, что AI назначает Head of, даже если в отделе один специалист. Но мы помним, что в стартапе карьерные ступеньки подставляют вниз. Ещё интересно, что не все участники команды получили позицию менеджера. Даже если этот участник в отделе один.

Теперь дополнительная польза. Кого можно сейчас не нанимать?
Chief Product Officer (CPO) — Директор по продукту. В нашем случае закрывается созданием продуктовой команды из CEO/CTO + COO + Design. Лучшее решение, спасибо искусственным мозгам! Что интересно — ровно так разработка у нас и происходит. Находка, что можно не выделять главного в этом процессе и продолжать работать коллективом.

Chief Financial Officer (CFO) — Финансовый директор. Когда деньги появятся, тогда и возьмёте. Для меня отличным решением оказалось раннее выделение роли Chief Revenue Officer без довеса на эту роль функционала CFO. И правда, чем управлять? Продавайте пока и всё.

HR-менеджер — Управление персоналом пока больше сводится к найму. Это закрывают сами CEO и COO, а что не смогут — отдать рекрутерам. Мы можем долго не нанимать выделенного HR, потому что оба фаундера много нанимали сами в других проектах.

Юрист — аутсорсить на точечных консультациях (это мы уже начали) или взять агентство (а вот это пока навряд ли).

Как возглавить восстание машин

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

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

• В самом начале нужно забыть, что мы хотим внедрить AI. Думаем от задачи, а не от технологии.
• Какой ценный конечный результат ожидается от этой роли?
• Какие должностные инструкции мы для него создадим?
• До компьютеров это решалось иначе. Продумать в точности по шагам, как бы это решал живой человек.
• Ассистента нужно проектировать точно также, как проектируются компьютерные игры, финансовые автоматизации и учётные системы — на бумаге. В нашем случае — нарисовать блок-схему по шагам.
• До того как втыкать везде AI, нужно разобраться где действительно нужен AI. Главный вывод всех AI-стартапов, пытающихся выполнять повторямые задачи реального мира — чем меньше участков с AI, тем меньше фронт ошибок.
• Если можно обойтись без AI — лучше обойтись без AI: есть логика, весовые модели принятия решений, ML и даже участие человека. Подходить с умом.
• Для каждого участка схемы выбираем подходящий способ автоматизации. Если принятое решение логическое (Да/Нет/И/Или/Если) — пусть принимает решение логический автомат с помощью прозрачного кода.
• AI попадёт только в те участки, где нужно принимать осознанные решения. На практике это 1 из 5-10 действий.
• Если разбить задачу на более простые участки, то некоторые участки могут выполнять более дешёвые и быстрые LLM-модели. Попробовать на практике, какая модель справится.
• Также работает наоборот — самые чувствительные и сложные участки отдавать более умным и дорогим LLM-моделям.
• Не забывать передавать полный контекст происходящего из памяти и прошлых шагов в агента.
• Проверить, какие персональные данные в какие AI и API мы отдаём. Постараться не передавать ненужную для принятия решения чувствительную информацию.
• Эксперименты демонстрируют, что LLM дает лучшие результаты, если его мотивировать. Поэтому в каждый промпт добавляем обещание денежного вознаграждения, повышения на работе и подчёркиваем значимость задачи в формулировке.
• Исследования китайских учёных показывают, что наилучшие результаты дают топологии с участием нескольких AI-агентов.
• Самый простой способ достичь качества — использовать на участке пару агентов Контролера и Исполнителя. Это эффективно устраняет нежелательные галлюцинации и другие сбои в ответах.
• На каждый участок схемы нужна своя пара агентов.
• Сложные топологии (звезда, дерево, mesh-сеть, рандом) улучшают качество, но в большинстве случаев можно ограничиться парой агентов.
• Если нужно переводить результат — делать это на самом последнем шаге непосредственно перед отправкой пользователю. Так избежим каскадного накопления неточностей перевода при обработке на разных шагах.
• Хранить все логи: сам запуск автоматизации, смена статуса, полученные после вставки переменных итоговые промпты (!), ответы AI. В общем, все шаги записывать.

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

Первый компьютер

Как советский ребёнок, я рисовал на перфокартах и читал энциклопедию профессора Фортрана. Но первый домашний компьютер появился у меня уже после советской власти, ещё до наступления эры PC.

В середине 90х был момент, когда умельцы собирали клоны ZX Spectrum с оперативной памятью 48 килобайт и их можно было приобрести. Каким-то чудом, мама решила, что мне нужен компьютер. Так в 13 лет я стал обладателем технологической инновации.
Спектрум представлял собой клавиатуру, внутри которой была вся начинка. Монитором для него служил телевизор, а в качестве носителя информации — аудио магнитофон с обычными с виду кассетами.
Комп понимал только BASIC, ввод с клавиатуры был мудрёным — клавиши печатали не только буквы, но и вызывали команды. Зато можно было подключить настоящий джойстик и с помощью команды начать загрузку игры с кассеты.
Звук загрузки с кассеты застрял в памяти наравне со звуками подключения модема. Кассеты были пиратскими, переписывали их подпольно и продавали на радиорынке. Игры загружались по 5-15 минут. Один сбой на десятой минуте загрузки и приходилось отматывать кассету и начинать загрузку с начала. Но если загружалась — фантастический мир компьютерной графики из 8 цветов и динамичных игр ждал меня. Играл в Mag Max, Dizzy, Boulder Dash, Arkanoid, BallBreaker, Saboteur.

Процесс загрузки игры и непередаваемый звук
Mag Max
Ballbreaker

Матрица роста агентства

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

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

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

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

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

Конвейер делает одинаковые штуки на потоке и с низким чеком. Кому не подходит конвейер — извините, следующий. Массовая настройка Авито или лендинг под ключ в этой категории.

SaaS / Продукт — мы хотим сделать один раз, а потом видеть от клиентов только деньги. Упаковываем накопленный опыт в продукт: в робота, сервис или набор методичек.

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

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