Моя первая видеоигра была аркадным автоматом. Мне было 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 / Продукт — мы хотим сделать один раз, а потом видеть от клиентов только деньги. Упаковываем накопленный опыт в продукт: в робота, сервис или набор методичек.

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

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

Сделай README сегодня же!

В этом месяце ко мне пришли три легаси проекта на аудит и разработку стратегии развития. Во всех трёх нет описания, документации и даже README. С автором одного из проектов связи больше нет.

В мире Open Source без README никуда — содержимое этого файла автоматически отображается в качестве описания на странице репозитория с кодом на GitHub. В качестве синтаксиса чаще всего используется Markdown, что позволяет использовать заголовки, ссылки, копируемые команды и примеры кода.

В мире продуктов, написанных "для себя" или "для клиента" часто описания нет. Или README без изменений унаследован от фреймворка, на котором собран проект. Это уже первая подсказка, но дальше разбираться нужно самостоятельно.
Разработчику кажется, что он — первый, последний и единственный посетитель репозитория. Нет смысла писать эти инструкции — для кого? А через несколько лет новый разработчик смотрит на папку с кодом и чешет затылок.

Что писать в README:
- Название проекта.
- Описание — ответ на вопрос, а что этот код делает и для чего.
- Зависимости и библиотеки, описать что под капотом и в какой среде это работает, требования к железу и среде.
- Архитектура — как это устроено?
- Инструкция по установке и первому запуску.
- Инструкция как разворачивать на сервере, если отличается от локального запуска.
- Ответьте на все вопросы, которые задаст новый разработчик в первый день работы с проектом.
- Примеры использования, типичный рабочий процесс.
- Полезные ссылки на официальную страницу, документацию, статьи.
- Контакты — с кем связаться, кто в курсе продукта, кто заказчик.
- Инструкция как вносить правки в код.
- Лицензионное соглашение для этого кода и для зависимостей (если применимо).

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

Я как раз собираюсь писать README для одного из проектов.
А для вдохновения коллекция лучших примеров, собранных по всему GitHub.

План выхода на миллион

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

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

Со средней покупки в этом направлении стартап зарабатывает 160 рублей — несколько процентов от сделки. Усилий по продаже практически нет, заказ оформляется клиентом без участия операторов и продавцов. Трафик условно бесплатный — мы уже получаем его через SEO. Чтобы заработать миллион, нам нужно продать 6500 заказов в месяц. Кажется, дохрена. Делим на 30 дней — примерно 220 заказов в день, теперь норм.

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

По опыту и анализу средний партнёр приведёт 200-300 заказов за месяц. Это почти совпадает с расчётом выше — 220 заказов в день. Условно, прикинем, что нам нужно 30 действующих средних партнёров в каждом месяце.

За прошлый год в нашей CRM было взаимодействие с 397 целевыми партнёрами, которым мы продали любую небольшую услугу. Задача ближайших месяцев — подключить 10% этой базы на новое направление.

Выглядит всё реально. Пойду делать.

Скрипт для проброса UTM-меток через лендинг во внешний сервис

Ситуация:
На лендинг из разных каналов заливается трафик, размеченный utm-метками.
Оформление заказа происходит на внешнем сервисе. На лендинге размещены кнопки [КУПИТЬ], по нажатию на которые посетитель покидает лендинг. Внешний сервис тоже умеет учитывать utm-метки.

Задача:
Проставить в ссылки на кнопках действия те же метки, с которым посетитель пришёл на лендинг.

Решение:
Скрипт автомагически добавит utm-метки ко всем ссылкам с указанной базой на странице.
Укажите базовую ссылку в переменной TICKET_URL_BASE.
Если utm-меток в адресной строке нет, ничего не произойдёт.

Для Tilda вставляем скрипт в блок HTML-код.
Для остальных сайтов — добавляем скрипт в подвал сайта.

<script>
  (function () {
    const TICKET_URL_BASE = 'https://moneymachine.com/777';

    const currentUrlParams = new URLSearchParams(window.location.search);
    const utmParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content'];

    const hasUTM = utmParams.some(param => currentUrlParams.has(param));
    if (!hasUTM) return;

    const links = document.querySelectorAll(`a[href^="${TICKET_URL_BASE}"]`);

    links.forEach(link => {
      const url = new URL(link.href);

      utmParams.forEach(param => {
        if (currentUrlParams.has(param)) {
          url.searchParams.set(param, currentUrlParams.get(param));
        }
      });

      link.href = url.toString();
    });
  })();
</script>

Почему 💾 обозначает Сохранить?

Удивительно, но в 2025 году мы всё ещё используем иконку дискеты как символ сохранения документов.

Но как дискета, прародитель флэшки из прошлого века, связана с сохранением файлов на моём компьютере?
Я начинал путь с ZX Spectrum, мне всё понятно и я сейчас объясню этот незаметный парадокс.

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

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

Созданный на компьютере файл нужно было "сохранять" — копировать из оперативной памяти на вставленную в дисковод дискету. Если этого не сделать, оперативная память стиралась при выключении и все труды терялись.
Для первых пользователей иконка дискеты была понятна, ведь она делала ровно то, что нарисовано — сохраняла на дискету. Образ менялся вместе с носителем и остановился на последнем массовом формате: 3,5-дюйма, 1,44 МБ.

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

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

Как быстро провести аудит чужого кода с помощью AI.

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

Моя версия, как сделать аудит кода с помощью AI:
Клонируешь репозиторий.
Запускаешь Cursor AI — форк VS Code с встроенным AI.
Ждёшь пока Cursor проиндексирует код и построит локальную базу.
В это же время в чат с ChatGPT загружаешь файлы package.json, composer.json, requirements.txt, gitlab-ci.yml, docker-compose.yml или что у вас там в корне лежит.
Формулируешь задание написать промпт на английском языке для другого AI, который будет проводить аудит кода. Указываешь все аспекты и особенности, на которые хочешь обратить внимание. Можно попросить сфокусироваться на безопасности или тех долге.
GPT пишет промпт на пару страниц и этот промпт вставляешь в Cursor AI.

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

PS: Очень полезно запускать такой аудит на своём проекте.

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

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

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

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

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

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

В агентство чаще всего не на что брать инвестиции. Самая популярная попытка "вложиться" в агентство — потратить бюджет на маркетинг самого агентства в новом рекламном канале.

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

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

Агентство (особенно маленькое) сложно продать — персонал и контракты могут быстро уйти на рынок после покупки. Покупатели это понимают.

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

Прибыльное агентство: Отказ от уникальных услуг.

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

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


Как превратить услугу во внутренний продукт:
- Берём одну типовую услугу, которую мы точно умеем оказывать и на которую есть спрос.
- Документируем весь процесс оказания.
- Выделяем шаги, которые требуют высокой квалификации.
- В этих шагах заменяем квалифицированного специалиста на полуфабрикаты — заготовки, готовые рецепты, чеклисты, шаблоны. Теперь он делает заготовки, а не уникальные решения.
- Добавляем границы кастомизации. За границы не выходим — это уже другой процесс.
- Обучаем менее квалифицированных сотрудников проходить по шагам весь процесс.
- Добавляем контроль качества — чтобы стандарт не падал при росте объёмов.
- Повторяем с правками и улучшениями до тех пор, пока процесс не будет работать без вмешательства специалиста и руководителя.

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


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


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

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

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

Я считаю, что лучшее решение — гибрид.
- Работает конвейер: основатель-специалист преодолел себя и построил скучную, но маржинальную услугу.
- Цены не потоковые, а чуть выше рынка.
- В отделе продаж происходит сортировка клиентов. Уникальные и сложные случаи переводятся в проектный отдел — с другими процессами, командой и бюджетом.

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

CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить?

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

Очевидные метрики, которые придумает HR:
- Присутствие на рабочем месте.
- Количество выполненных задач.
- Количество часов, затраченных на выполнение этих задач.
- Уложился ли в план.

Неочевидные метрики, которые добавит CTO:
- "Бизнес ценность" — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса.
- "Стори пойнты" — баллы трудоёмкости. Разработчики собираются на "Покер Планирования" и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32).
- Количество багов в коде, написанном разработчиком.
- Скорость — любые баллы делим на время.
- % отклонения от собственной или командной оценки.

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

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

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

Что с этим делать?
- Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку.
- Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них.

Матрица "Винни-Пух" для Отдела продаж.

Понять, как продавать клиенту, можно за 5 минут — если представить его героем «Винни-Пуха». Мы давно применяем эту матрицу в продажах и работе с клиентами. Подсмотрено у Павла Гительмана на курсе по маркетингу.

Итак, к нам пришёл новый клиент.
Определяем его положение в матрице по двум осям — открытый/закрытый и
уверенный/неуверенный.

Результат легко соотносим с персонажами сказки Винни-Пух и все-все-все.

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

Пятачок — Открытый + неуверенный в себе. Чтобы Пятачок что-то купил, ему нужен Винни-Пух и его вера в успех.
Пятак, мы уже ходили за мёдом много раз, тут всё то же самое. Бери меня за руку, бери ружьё, оплачивай счёт и запускаем проект.

Ослик Иа — Закрытый + неуверенный в себе.
А вы точно не мошенники? Покажите сертификаты. Есть ли возврат денег? У вас там неточность в реквизитах. Ослик — самый сложный случай. Под него стоит сделать лендинг, подготовить список частых ответов, но продавать ему ­тяжелее всего.

Кролик или Сова — Закрытый + уверенный в себе. Этот клиент сам всё знает, он пришёл подготовленным. Расскажите про скидки и команду.


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

Почему Fix Price — это ловушка

По данным PMI, средний большой IT-проект превышает бюджет на 45%, сроки на 7%, а выхлоп даёт на 56% меньше ожидаемого.
В исследовании Harvard Business Review, каждый шестой IT-проект обошёлся более чем на 200% дороже и вышел за сроки более чем на 70%.
Люди плохо оценивают трудозатраты. Не учтены все внешние факторы, слишком оптимистично оценивается время и ресурсы. В процессе работы с проектом приходит более глубокое понимание предметной области и деталей.
Мы интуитивно ожидаем нормальное гауcсово распределение по срокам, но в реальности у нас распределение с тяжёлым хвостом. Это значит, что редкие, но очень долгие проекты — не исключение, а закономерность.

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

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

Проекты по модели Fix Price можно брать, но если есть ряд условий:
- Вы уверены, что в проекте нет рисков.
- В проекте очень мало неопределенности. Например, у вас уже почти всё готово, осталось прилепить логотип заказчика сверху стандартной заготовки.
- У вас наценка от 500% на качественно просчитанную себестомость.

Точная оценка нового проекта — иллюзия. Большой проект с неопределённостью нельзя брать по фиксированной цене. Каждый раз, когда вы берёте большой проект по Fix Price в надежде, что получится заработать, вы играете в рулетку.

К недавним воспоминаниям про ZX Spectrum добавились свежие новости и неизвестные факты.

В 1980-х игры и программы можно было получить по радио! Буквально записать FM-эфир на аудиокассету. Такие передачи выходили на BBC и других национальных радиостанциях по всей Европе.

Поскольку версии языка BASIC отличались на ZX, Commodore, Atari и других платформах, был создан универсальный стандарт BASICODE. В этом формате шло вещание. Для воспроизведения таких записей нужно было вначале загрузить BASICODE, а затем записанную программу.

В мае 2024 года игру для ZX Spectrum вновь передали в эфире Словенского радио.

А в октябре 2024 вышел документальный фильм про историю ZX Spectrum "Чудо с резиновыми кнопками", деньги на съемки которого собрали на Кикстартере.

Интересные ссылки:
- BASICODE на Wikipedia
- Новость об эфире с игрой
- Фильм The Rubber-Keyed Wonder (англ.)
- Фильм Чудо с резиновыми кнопками (перевод на русский язык)