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

Для меня этот урок важен потому, что почти все знания в нём — мои личные. Другие знания из курса я по большей части получал извне — говорил с умными людьми, слушал выступления, читал в книгах и адаптировал к практике. А вот о том, как строить отношения с бизнесом, у нас в индустрии говорить почему-то не принято. За всю жизнь я нормально говорил об этом только с одним человеком (Али, спасибо, если читаешь).

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

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

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

Запрыгнуть в последний вагон →

The winner takes it all или почему я убежал из венчура

Одна из причин, по которой я решил уйти из венчурного стартапа и в будущем не связываться с инвестициями в свои проекты — мысль Талеба из (кажется) «Шкуры на кону».

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

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

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

Мне гораздо комфортнее линейная зависимость — когда я никому не обязан строить САМУЮ БОЛЬШУЮ ШКОЛУ и САМУЮ ПЛАВУЧУЮ ГАЛЕРУ: то, что я построю, принесёт мне столько денег и счастья, на сколько хорошо я сделал свою работу. И даже если сделал я совсем чуть-чуть, мои результаты никогда не умножатся на ноль просто из-за законов жанра.

Google → Kagi

Недавно прошло два месяца с тех пор, как я не искал ничего в Гугле. Перед уходом я каждый месяц натыкался в нём на какую-нибудь новую хрень — то подсунут ссылки на Дзен или другой SEO-мусор вместо результатов; то нагенерят таких ответов через GPT, что мозги от одного взгляда на них разжижаются.

Раньше я несколько раз пробовал DuckDuckGo, но уходил примерно через день. А недавно попробовал Kagi, и на нём и остался.
— SEO-мусора почти нет, а если что-то вылезает — можно вручную забанить.
— Саммарайзер работает отлично и на русском, и на английском. Особенно кайфово прогонять через него всякие бухгалтерские и юридические статьи.
— Фильтры (они называется lenses). Можно искать только среди научных статей, или только в рамках small web — авторских блогов живых людей.

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

Конечно есть и косяки — путает Грузию и Джорджию (даже когда ищешь что-то в Тбилиси), невозможно настроить саджесты на iOS. В остальном — база, как гугль лет 15 назад. И всего за 12 баксов.

#вопрос Расскажи, какие технологии и знания помогли уйти в собственный бизнес?

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

Знания хардовых технологий вроде python/js мне не помогли совсем — я очень мало написал коммерческого кода для клиентов: может быть за всё время потратил несколько недель. Причём, если бы умения писать код у меня не было — я бы обошёлся и без них. Возможно помогло понимание devops и любовь к DevEx — с самого начала существования аутсорса мы делали программистам удобно: юзали удобные хостинги вроде heroku\netlify (сейчас перешли на vercel), много вкладывались во внутреннюю разработку. За счёт этого достигли довольно высокой для аутсорса рентабельности — программисты у нас работают действительно эффективно.

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

Самый неочевидный навык, который мне помог в аутсорсе — умение письменно выражать свои мысли. Использую его постоянно — от внутренних регламентов до публичных анонсов наших проектов (хотя последние пишут уже сами ребята). Без умения писать точно было бы гораздо сложнее.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Творческая безопасность

Мы с Марьяной в прошлую пятницу выпустили последний урок «Стать Тимлидом 2.0». Пост гордости напишу чуть позже, когда отрфеклексируем вместе, а пока хочу рассказать об очень важной концепции, которую я нащупал, пока писал курс.

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

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

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

Такую же творческую безопасность я стараюсь поддерживать и в своих командах — никогда не общаться пассивно-агрессивно; писать максимально развёрнуто; не критиковать идеи, а предлагать улучшения, и т.д. Получается не всегда (даже у нас не все умеют в асинхронную коммуникацию), но об этом напишу как-нибудь отдельно.

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

#вопрос Насколько вы часто пользуетесь электронной почтой? Кажется, что этот инструмент уже рудимент, покрытый десятками непрочитанных писем у миллионов пользователей.

Почта — мой основной рабочий инструмент уже лет 15. Я исповедую пустой инбокс, и настроил всё так, что мне туда падают все рабочие уведомления: из гитхаба, бейскемпа, и даже из банка.

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

Конечно, многие люди действительно относятся к почте, как к помойке — хранят в инбоксе по 20 000 пустых писем от маркетплейсов, сервисов и госуслуг, а для рабочего общения предпочитают рабочие чатики. Раньше я жёстко топил против рабочих чатов и даже пытался их запрещать в своей компании. Сейчас успокоился — если человек хочет работать с загаженным сознанием — не мне его отговаривать.

Единственное, что я сейчас делаю — создаю среду, дружественную для таких, как я — плачу за бейскемп с его супер-удобным Hey (не почтой) и разделением синхронной а асинхронной коммуникации через Campfire, и за гитхаб, который позволяет гибко настраивать потоки уведомлений. Ну и периодически напоминаю, что срочно отвечать никому ни на что не нужно.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Ненавижу Metabase

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

Но вот как этот инструмент сделан для администратора — это просто отвратительно. К примеру их команда тратит кучу сил на то, чтобы данные можно было ковырять без знания SQL. Идея крутая — типа дадим пользователям все данные, а они уже сами себе соберут дешборды. Но вот реализация просто отвратительная — все эти инструменты не работают даже на нашем простом сетапе.

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

Но эти модели не работают! Может быть один раз данные из них получить и можно, но вот построить из них более или менее полезный дешборд уже не получится. Данные в моделях нельзя нормально фильтровать, с ними не получается писать SQL: итоговые запросы получаются настолько корявыми, что когда они падают, нет никакого способа их отладить. То есть у ребят получились материализованные вьюхи, которые толком не работают, да ещё и материализуются где-то вне БД, то есть не контролируются миграциями.

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

В итоге так мы и пишем SQL-запросы, выводя их результаты в дешборды. Получается грустно — у нас нет нормального data lake, и мы делаем выборки просто с продовой базы, а значит не можем делать серьёзные изменения в структуре данных, не сломав всю аналитику. Раз в год я пытаюсь заюзать фишки метабейза, которые позволяют избавиться от этой зависимости, трачу на это 3–4 часа и бросаю.

Может посоветуете замену, которая подходит маленьким ребятам, которые пока не доросли до выделенных ETL-пайплайнов? Или уже доросли и пора делать?

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

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

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

Мы запускаем третий поток курса «Анализ систем», который как раз об этом — как собирать бизнес-требования и делать максимально простые системы, которые их выполняют. Для этого мы много говорим о стратегическом анализе бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Изначально мы задумывали курс ради четвёртого урока, в котором мы дали пошаговые рекомендации по распилу монолитов, но сейчас поняли, что гораздо важнее мета-навык — умение слушать бизнес и не делать лишнего.

Стартуем 13 июня, учимся 5 недель. Учиться рекомендуем в тусовке — наблюдая за чужими домашками, вы вынесете из курса гораздо больше знаний, чем если просто прочитаете материалы. До вечера четверга действует промокод SAD10 на 10% скидки.

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

А давайте поговорим об этом?

В четверг, в 16:00 MSK, говорим с Антоном про роль архитекторов в компаниях, и о том, что проектирование — это про бизнес, а не про втыкание кешей и кафок.

Подробной программы нет — просто соберёмся в телеге. Заодно расскажем, чего ждать на третьем потоке Анализа Систем, зачем на него идти, а зачем — нет, и поотвечаем на вопросы.

Количество подписчиков == оборот бизнеса

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

Допустим у кого-то бизнес с оборотом 500 миллионов рублей в год, из которых 200 уходит на закупку товаров, 200 на зарплаты, а 95 — на обслуживание кредитов. Получается внушительная цифра, но вот прибыли не много. Или возьмём бизнес в 10 раз меньше — 50 миллионов в год, о при этом затрат у него только 10 миллионов. Второй бизнес хоть и выглядит скромнее, но гораздо более прибыльный. Я-то уж точно выберу второй.

Так же и с количеством подписчиков в телеге. Есть каналы с десятками тысяч людей, которых читает от силы 1000 человек. И наоборот, бывают каналы по 2000 человек, где просмотров больше, чем подписчиков. Среди SMM-щиков этот показатель называется уровнем вовлечённости — средний процент просмотров относительно общего количество подписчиков.

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

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

Сравните две крайности — у Тонского маленький канал с супер-интересными срачами в комментах, а у Лебедева — гигантская площадка медийного уровня, но вот услуги студии он там давно не продаёт.

Рассказать о вакансии в баре

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

Первая проблема — безликие, ничего не говорящие утверждения, типа «бекенд на node.js», «проптех для США». Проптех может оказаться как скучной CRM для риелторов, так и экосистемой, которая закрывает все потребности от выбора и покупки квартиры до обещания с арендатором, да ещё и с высокой нагрузкой от доски объявлений. Представьте сами, куда вам больше хочется откликнуться — на безымянный бек на ноде или подробный рассказ с версиями TS, процентами тестового покрытия и парой слов о способе коммуникации сервисов?

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

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

Так получается потому, что вакансию воспринимают как заклинание, которое нужно кастануть, чтобы получить кандидатов. Я так в школе писал сочинения — если накастовать в тетрадке заклинания из сборника «100500 сочинений», то учитель отстанет.

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

Лучший Курс По Питону от Никиты Соболева

Редко публикую здесь чужой контент, но всё, что делает Никита Соболев вокруг питона точно стоит упоминания. Никита начал делать фундаментальный курс — выкладывает на ютуб видосики, где до косточки разбирает одну конкретную тему. К примеру есть отдельное видео про bool и отдельное про int, и даже видос на 25 минут про плюс. Каждый видосик разбит на 3 части — для джунов, мидлов и синьёров.

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

В общем переходите по ссылкам и подписывайтесь на канал, а лучше — ещё и на бусти, там есть тариф за 100 рублей в месяц.

Невозвратные билеты

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

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

Разница между обычным авиабилетом и невозвратным — как между обычным опционом и бинарным. В первом случае мы покупаем право совершить перелёт, а во втором — обязанность. Вне зависимости от того, понадобится перелёт или нет — отказаться от него стоит столько же, сколько мы за него заплатили. Купил невозвратный билет за 100 тысяч? Опоздать в аэропорт стоит 100 тысяч. Заболеть стоить 100 тысяч. Опоздать на стыковочный рейс по вине другой авиакомпании — тоже 100 тысяч. Можно, конечно, как-то побороться и вернуть хотя бы часть денег, но это точно не то, чем хочется заниматься в деловой поездке или отпуске.

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

Среди программистов принято гордится сложностью своих решений — типа поставил Кафку и рассказываешь об этом на конференции, не упоминая ни слова о том, какую бизнес-проблему ты ей решил. А вы видели где-нибудь ещё профессию, в которой принято гордиться сложностью своих произведений? Может писатели, которые гордятся, какую непонятную книгу написали? Или туристы, которые гордятся тем, что тащат в рюкзаке 10 лишних килограммов? Наверное с ходу могу вспомнить только автомобильных инженеров — те тоже любят делать трёхцилиндровые двигатели, сенсорные переключатели и двери без ручек.

Я догадываюсь, откуда это происходит — помню, когда мне было 13 лет, мой преподаватель по информатике показал, какую сложную программу на 50 экранов он написал. Конечно я захотел так же, и потом долго думал, что чем круче программист, тем более сложные штуки он делает. К тому же 50 экранами гордится гораздо легче, чем 3, которые решают ту же задачу.

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

Старею, похоже