25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
Затаскивать проекты, а не людей
Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.
Неклёво затаскивать людей. Не работать вместе над общим делом, а всей командой обходить неумение кого-то одного писать код или выполнять обещания — перераспределять нагрузку, какделировать несамостоятельных, выкидывать работу не потому, что неважно, а потому, что не успеваем.
Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.
Когда затаскиваешь людей — ты просто тратишь время на то, чтобы принести результат.
Готовые комплекты вещей
Самое смешное бытовое открытие прошлого года — это готовые комплекты вещей. К примеру, комплект проводов и зарядок для поездки. Раньше нужно было подумать, какие устройства я с собой беру (нужен ли lightning? а зарядка для часов?), посмотреть, отыскать всё это, проверить чтобы все провода были совместимы со всеми устройствами, а после поездки — вернуть на место. Сейчас достаточно взять маленькую сумку с зарядками, которая всегда собрана.
Или наушники. Раньше нужно было не забыть наушники, когда идёшь в кофейню, отыскать их перед походом в спортзал, и проследить, чтобы они не сели во время зум-созвона. Сейчас достаточно взять наушники для встреч (самые лёгкие и без шумоподавления, которое не нужно дома), в дороге — достать походные наушники, а в спортзале — взять спортивные, которые так и живут в спортивной сумке.
Дошёл до этого после идеи с айпадом для одиночества. Вы не представляете, сколько времени, а главное — энергии я стал экономить, когда перестал собирать электронику в поездки.
В комментах к посту про список проектов, куда я ввязался, задали интересный #вопрос — как фокусироваться и при этом оставлять пространство для slack-time. То есть времени где можно расфокусироваться и проявлять любознательность или просто пофаниться?
Я конечно тот ещё эксперт по тайм-менедменту, но попробую ответить как это устроено у меня. Время любознательности и развлечения — это вообще главное время в дне. Для меня возможность поизучать что-то новое и приятное — это награда, к которой я иду через другие дела. Новое и приятное может быть каким угодно — новые либы\языки, перестановка в кабинете или способы открытия LLC в США.
Я довольно зависимый человек, и если сажусь за что-то дофаминово-любознательное, мне тяжело останавливаться. Поэтому стараюсь не планировать такие вещи на утро — иначе рискую целый день проковыряться в чём-то несрочном, но безумно интересном.
Конечно же, изучение новых вещей — это такой же проект, в который я ввязался. И на еженедельном обзоре я ограничиваю количество таких проектов так же, как и всех остальных.
Хочется добавить, что главное в любой науке о продуктивности — это всё-таки не писать планы и не пытаться с лицом Льва Толстого за ними следовать, а прислушиваться к себе. Если я с утра понимаю, что сегодня день расфокуса — стараюсь не насиловать себя, а заниматься интересным.
Кстати, вопросы лучше всего задавать на fborshev@pm.me. Ответы выкладываю по понедельникам.
Скиллы и над-скиллы
Это — ласт-колл на 4 поток нашего флагманского курса «Анализ Систем».
Когда я собеседую программистов, я редко смотрю на хард-скиллы, которые они рекламируют в резюме. Что толку, если программист знает десяток фреймворков, если он не умеет подбирать тот, который подходит задаче? Гораздо важнее не скилы, а «над-скиллы»: насколько программист интересуется происходящим в индустрии, как умеет сравнивать инструменты друг с другом, умеет ли вообще задавать вопросы?
То же самое и со знаниями: можно несколько лет читать про DDD и не научиться разбивать систему на элементы и уж тем более, делать это в сооветствии с потребностями бизнеса.
«Анализ Систем», мы делали как раз для того, чтобы не складывать в резюме аббревиатуры (хотя они тоже будут), а чтобы прокачивать над-скиллы. Вместе с Ибрагимом и котом-критиком вы будете решать большие архитектурные задачи, получить которые в реальной жизни довольно сложно, не имея опыта. Обратную связь на свои решения тоже можно не ждать по несколько лет, а получить сразу.
Стартуем 16 января, учимся 5 недель. Учебная нагрузка — примерно 10 часов в неделю (у кого-то сильно больше, но точно не меньше) — мы рекомендуем брать отпуск на работе как минимум на один день каждую неделю обучения. Если хотите серьёзного буста в над-скиллах — берите тариф «в тусовке». К слову, «Долями» подняли нам лимиты, и теперь оплачивать тариф «в тусовке» частями могут не только клиенты Т-банка, но и все другие. От юрлица и из-за рубежа тоже можно.
Следующий поток будет не раньше лета
Группа про социальную тревогу
Немного нестандартное для канала объявление — мои хорошие друзья набирают психологическую группу, посвящённую социальной тревоге. Приглашают всех, кто напрягается от смоллтока, боится выступлений и разговоров с начальством, кому встреча с незнакомыми людьми может испортить вечеринку, а необходимость звонить в банк заставляет поменять банк.
Кто не знает, психологическая группа — это способ сэкономить на психотерапевте и почувствовать себя неодиноким за счёт товарищей с такими же проблемами.
Группа расчитана на год, максимум 12 человек. Стоимость — 4000 рублей за занятие, проходят раз в две недели, онлайн. Чтобы пройти собеседование — запишитесь здесь, ребята вам напишут.
Команда ценнее клиента
За небольшую историю нашего аутсорса мы несколько раз отказывались от денежных клиентов, которые подходили по стеку и задачам. Иногда на этапе продажи, а иногда — уже в процессе работы. И я говорю не об этике — даркнетчики и скамеры к нам даже не обращаются из-за ценового порога.
Дело в том, что бывают клиенты, которые вредят команде. Начиная от тематик, которые никто не хочет иметь в резюме (к примеру оборонка, которую не любили и до 22 года), и заканчивая токсичной коммуникацией и кривой постановкой задач. Вообще найм команды и HR — сама важная, после продаж, компетенция в аутсорсе. Нам эта компетенция важна больше, чем другим — из-за асинхронной коммуникации. Из 20 программистов, которые умеют писать хороший код, найдётся от силы двое, которые умеют ещё при этом выполнять обещания, и 1 из них ещё будет не готов к работе в аутсорсе несмотря на все наши условия.
У меня нет точных цифр, сколько стоит потеря одного сильного программиста, но явно больше стандартной таксы кадровых агентств — 2–3 месячных зарплат. И это я ещё не говорю о стоимости создания неизмеримых факторов, вроде комфортной и дружелюбной среды с понятными задачами — приходится вкладываться, чтобы конкурировать с бигтехом.
Так что выбирая между командой и клиентом, я выбираю команду.
Наверное в этом можно услышать, что находясь в клиентском бизнесе, я плюю на клиентов, но нет — клиентам же нужна команда профессионалов, а не джунов за еду. А чтобы удержать профессионалов, нужно создавать им комфортные условия, в том числе и комфортных клиентов.
Анализ Систем — 4
В школе появился флагман. Его берут в образовательные премии, половина запросов в сапорт — «когда откроете поток?», а постоянные b2b-клиенты разбирают ВИП-тариф ещё до официального запуска. Думаю так получилось потому, что в курсе сошлось всё вместе — знания Антона, которые он собирал несколько лет, наше с Марьяной желание сделать радикально новый образовательный опыт, и редактура прекрасного Тимура Зарудного. Ну и ещё наверное потому, что system design — горячая и актуальная тема, хотя курс и не совсем про это.
Мы уже анонсировали новый поток в почте, но напишу и здесь. Обучение стартует 16 января, покупать лучше сейчас: во-первых это дешевле, во-вторых — в декабре работодатели проще компенсируют расходы на обучение, потому что у всех остаются излишки бюджетов под конец года. Налоговый вычет, кому надо, тоже можно получить этим годом.
На курсе мы говорим о стратегическом анализе бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций между сервисами. Про ADR и документацию тоже говорим. Самая любимая тема — распил монолитов: ему посвящён четвёртый урок. Ради него мы когда-то затеяли курс, но потом получилось то, что получилось — интересная история Ибрагима и его кота, вдумчивое изучение которой даёт мета-навык — умение слушать бизнес и не кодить лишнего.
Стартуем 16 января, учимся 5 недель. Учебная нагрузка — примерно 10 часов в неделю — мы рекомендуем брать отпуск на работе как минимум на один день каждую неделю обучения. Учиться лучше в тусовке — наблюдая за чужими домашками, вы вынесете из курса гораздо больше знаний, чем если просто прочитаете материалы. До вечера пятницы 13 декабря действует промокод IBRAHIMSCAT на 10% скидки. Следующий поток не раньше лета.
Смотреть программу и отзывы →
И мы туда же (чёрная пятница)
Вот уже четвёртый год радуюсь, сколько новых учеников знакомятся с нашими курсами на чёрную пятницу. Наверное больше ребят приходит только через пиратов, но те, увы, статистики не публикуют.
Если вы ещё у нас не учились и сомневаетесь — в ближайшие три дня можно купить любой наш курс кроме «Анализа Систем» и «Без Ерунды» со скидкой 25%. Промокод BLACKFF, выбирать тут.
P.S. Кстати, если приобрели наш курс у пиратов, и он вам помог — можно тоже что-нибудь купить, нам будет приятно.
Режим саджестов в ноушене
Ноушен недавно выкатил странный режим саджестов — когда ты не просто правишь какой-то текст, а предлагаешь к нему изменения. Потом коллега их смотрит и принимает. Ну или не принимает, или делает новые саджесты. По-моему, эта штука противоречит всей идее совместного редактирования текстов.
Дело в том, что их режим саджества — копия старого режима саджеста из Ворда: он построен вокруг букв, слов или абзацев. А когда люди пишут тексты вместе, они правят не буквы, а смыслы. Когда мы с Марьяной пишем лонгриды в школе, мне совершенно всё равно, какие слова в тексте она меняет. Гораздо важнее, как она обогащает смыслы — чем делает текст полезнее для учеников, насколько легче стало его воспринимать, насколько короче сформулировала мысль. А режим редактирования мне рассказывает, что Марьяна добавила слово «когда» после буквы «а». Как будто с высокоуровневого фреймворка на C перешёл, чесслово.
В Ворде можно хотя бы переключиться в режим итогового текста — смотреть не на правки, а на их результат, без ужасной цветной разметки. А в ноушене такого режима, я вынужден одновременно читать два, смешанных друг с другом, текста, и при помощи цвета декодировать, какой из них актуальный. При редактировании то же самое — я вроде бы что-то удаляю, а оно не удаляется, а краснеет. Ужас.
Наверное этот полезно для юристов, у которых докапываться до букв — это основная работа. Но вряд ли среди пользователей ноушена много юристов: юристам им с вордом ок. Продактам notion конечно виднее, но с моей позиции их фича выглядит довольно странно — даже обычная история редактирования в текущем виде выглядит полезнее. Ну и уж точно я никому не буду присылать текст в режиме изменений.
Опора для коллег
Важная функция руководителя — быть опорой для коллег. Когда прод лежит, а сроки горят — тимлид должен приносить в команду спокойствие, а не тревогу. Когда прибыль падает, и CEO топчет ногами — COO должен поддерживать коллег, а не грозить всех уволить. Когда инвесторы отказываются от раунда, CEO должен верить в будущее, а не пропадать из офиса с бутылкой.
Собственник бизнеса имеет право на свою прибыль именно потому, что обязан оставаться спокойным и трезвым в любой ситуации. Даже когда когда корабль тонет и бизнес разоряется — команда должна видеть уверенного капитана, чтобы спокойно вычёрпывать воду.
Самое сложное в том, что надо не просто демонстрировать спокойствие и искриться улыбкой, а действительно быть таким внутри, иначе люди быстро распознают хуйню и станет только хуже. Это довольно сложная работа — чтобы выполнять её в собственных бизнесах, мне понадобилось 10 лет ежедневного руководства командами и 5 лет психотерапии. До сих пор есть, куда расти.
Мой идеал спокойствия — Людвиг Быстроновский, арт-директор, с которым я когда-то давно работал в студии. Судя по его рассказам (посмотрите его цикл лекций о шторме) — человек довольно взрывной внутри. Несмотря на это, всегда когда у меня случался полный пиздец (а в клиентской работе полные пиздецы случаются раз в неделю), если на проекте был Людвиг — я успокаивался гораздо быстрее. Он не применял никаких специальных инструментов — просто спокойно разговаривал о проблемах. Наверное это работало где-то на уровне химии и языка тела, не знаю. Часто мне даже не надо было с ним разговаривать — я садился писать ему письмо и, даже не дописав, понимал что делать. Сейчас я стараюсь быть таким же для своих коллег — давать уверенность и спокойствие, что бы ни происходило в бизнесе.
Так вот, к чему это я: если начали руководить даже двумя людьми — учитесь приносить им спокойствие. Тревоги им и без вас достаточно.
Firefox!
Я тут внезапно перешёл на сабж и ничего не случилось.
С самого первого дня на маке я юзал Сафари — мне очень нравилась скорость и интерфейс без лишних кнопочек. Ради этих двух вещей я почти 10 лет мирился с некорректным рендерингом некоторых сайтов, невнятными адблокерами (сначала опенсорсный Ka-Block, потом вообще 1Blocker), и корявыми расширениями, вроде Cascadea для юзерстилей или глючного 1password.
Последний и стал причиной перехода — в какой-то момент создатели 1password вынудили меня перейти с 7 на 8 версию (говно на электроне). Поскольку деваться было некуда, и лучше сделать это заранее, чем ловить глюки от разных версий, основное рабочее место я тоже перевёл на 1password 8. После танцев с бубном завелось всё, кроме плагина для Safari — он ужасно глючил. Так я и перешёл на Firefox, который решил последние мои проблемы: у него расширение работает как часы (насколько это применимо к говну на электроне). Выбрал его из-за приватности — в нём гораздо легче отключить гугловую телеметрию и другие плюшки вроде автохода в гугл.
Firefox тут же напомнил про забытые за 10 лет возможности — вроде нормального адблокера вместо 1blocker или работающего Consent-O-Matic вместо корявых решений для Safari. Зарабоали даже штуки, аналогов которых для Сафари я просто не знал — вроде SponsorBlock и DeArrow для ютуба. Работает всё так же быстро, как раньше, и даже интерфейс удалось сделать (почти) таким же чистым.
Теперь у меня два основных браузера — FF для сёрфинга и Brave, когда надо поковыряться в потрохах чьего-нибудь фронтенда или поработать с Metamask.
Учиться у редакторов и дизайнеров
Каким бы отменным вкусом ни обладал дизайнер, в профессии он не будет стоить ничего, если этот дизайнер не умеет смотреть на макеты глазами конечного пользователя. У редакторов так же — хоть изучи наизусть весь словарь Даля и прочитай всю русскую классику — если ты пишешь тексты непонятно для кого непонятно о чём — ты никому не нужен.
А вот программистов этому не учат. Не в смысле делать хорошие тексты и интерфейсы (хотя и не помешало бы), а в смысле смотреть глазами потребителя их кода — другого программиста в будущем. Открываешь модуль — а в нём 3 класса, 5 функций и ещё сколько-то кода выполняется при импорте. Почему они все вместе? Что делает модуль? Непонятно. Или читаешь функцию — а там 50 строк, 10 if и поди пойми, зачем она вообще существует.
О коде нужно думать как редактор или дизайнер. Цикломатическая сложность, чистота по дяде Бобу или <любая ваша метрика> — это базовая гигиена, как отсутствие грамматических ошибок в тексте у редактора. Гораздо важнее высокий уровень — как будущие программисты будет решать свои задачи в нашей кодовой базе. Если надо будет пилить новую бизнес-логику, поймут ли они, в каком формате у нас это принято делать — сервисыные объекты\контролелры\микросервисы? Сколько времени будущие программисты будут разбираться, как у нас прокидываются настройки из рантайма? Если надо будет что-то делать с БД, поймут ли как у нас работают миграции схемы?
Читать о продуктивности вместо того, чтобы делать дела
Пришёл я недавно к Антону комментить статью про Obsidian — я потихоньку делаю лонгрид о том, как использовать его в качестве личного дневника, и очень заинтересовался паттернами Антона.
Довольно обидно стало, когда Антон, вместе с благодарностью за коммент, рассказал, что эта статья — самая комментируемая у него него за последнее время. Обидно — потому, что я знаю у себя привычку к такого рода прократстинации — вместо того, чтобы пойти и сделать работу, потратить время на то, чтобы сделать эту работу на 2% *эффективнее* — как тот линуксоид, который за 2 часа напишет скрипт, который за 5 минут сделает то, что юзер руками делал бы час.
В профессиональной деятельности я эту привычку вроде бы обуздал. Предпринимательство вынуждает фокусироваться на важном и откидывать любую деятельность, которая не имеет отношения к результату — иначе я просто разорюсь. Ну а 20 лет в программировании не позволяют мыслить совсем уж поверхностно — всё-таки создавать долги я ненавижу на уровне условных рефлексов.
В личном плане всё хуже. Кроме Обсидиана, есть ещё классические примеры — вроде покупки абонемента в спортзал вместо занятий спортом. Или вот недавно потратил 4 часа на выбор струн для бас-гитары, пока не сообразил, что занимаюсь хернёй — если бы я это время просто играл мажорные гаммы — продвинулся бы гораздо дальше.
Знаю точно, что я не один страдаю привычкой к полировке продуктивности — статистика из канала Антона это просто ещё одно подтверждение. И, к сожалению, не знаю универсального рецепта, как справиться с этой привычкой. Пока самое действенное средство — это тот самый личный дневник: когда садишься вечером и вспоминаешь, на что потратил день, занятия хернёй становятся очень заметны. Главное не стесняться себе в этом признаться.
#вопрос не расту на работе, уже джва года ничего не происходит — ни обязанностей не прибавляется, ни зарплаты. Подумываю уволиться. Что делать?
———
Сочувствую! Я и сам был в такой ситуации — топтался на месте и понимал, что никому мой рост не нужен, и боссам достаточно, чтобы я просто ходил на работу и закрывал привычные обязанности. Сейчас, когда я сам дошёл до этапа босса, я их понимаю — мне бы бизнесом заниматься, а не следить, чтобы каждому было интересно. Я, конечно, стараюсь это делать — но это, увы, далеко не первым приоритетом.
Предположу, что самый очевидный шаг — поговорить с тимлидом/боссом и попросить новых обязанностей, — вы уже выполнили, и результата не получили.
Следующий шаг — принять факт, что никто вас вперёд толкать не будет. Хотите делать больше и интереснее — ищите как. Я тогда занялся ростом самостоятельно — построил план роста на год: выучить питон и джангу, потренироваться в общении с людьми через random coffee и личные встречи с предпринимателями. Всё это прекрасно уложилось в рабочее расписание — я вложился, настроил дела так, чтобы работали с минимальным участием и честно пошёл заниматься своими делами.
Увольнялся я бы только в третью очередь — только после того, как исчерпал все другие возможности. Дело в том, что ваше текущее состояние — отличный способ потренировать проактивность: когда вы не ждёте, что желаемое сваливается на вас с неба (или приходит вместе с новой работой), а добиваетесь этого сами. Это отличный навык, который пригождается в любом деле, и не только на работе.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Мы сами виноваты в говнокоде
Этот пост — ласт-колл на второй поток «Стать Тимлидом 2.0». 18 сентября в 16:00 MSK — встреча потока, где мы все знакомимся. Ещё можно успеть купить за свои деньги, а потом вернуть на работе по чеку.
Большинство программистов, которые беспросветно сидят на легаси, обвиняют в этом свой бизнес. Типа мы бы и написали хороший код, да злые дядьки не дают — диктуют правила, давят сроками, не выделяют время на техдолг. Это не так.
Бизнес, каким бы он ни был — довольно прагматичная система, которая умеет принимать решения. Если заставить бизнес выбирать между наймом людей или стагнацией — он выберет найм людей. Когда понадобится выбрать одного подрядчика из 10 доступных на рынке — бизнес опишет требования и выберет самого подходящего.
Так почему же между работающей системой и вставшей колом разработкой, которая сама не может разобраться в своей сложности, бизнес часто выбирает второе, да ещё насильно заставляет программистов говнокодить сверху? Да потому, что он им не доверяет.
Представьте, что у вас дома прорвало канализацию. Приходит сантехник, говорит «изян», и пропадает. Вызываете другого — тот жалуется на первого, обещает всё исправить и тоже пропадает. А из трубы-то льётся! Где-то после третьей итерации вы уже сами пойдёте перекладывать трубы хоть во всём доме — и пофиг, насколько эти трубы будут соответствовать правилам и стандартам: вам бы от запаха избавиться. Так и бизнес пишет руками программистов — просто, чтобы перестало литься.
Легаси — это следствие пропасти между бизнесом и разработкой. Отсутствие этой пропасти — не гарантия чистого кода, но если разработка умеет говорить с бизнесом, то качество кодовой базы будет ограничено только профессионализмом программистов. Наш курс — как раз про то, как сузить эту пропасть, и приблизить программистов к бизнесу: научиться разговаривать с «той стороной», брать ответственность за сроки и решать проблемы с командой.
Приходите
Императивный и декларативный бизнес
Вообще этот пост — реклама курса о Developer Experience, который мы доработали по итогам обратной связи от живого потока и теперь открыли продажи. Но вообще — это часть моего (внутреннего пока) исследования о том, какие ещё концепции из программирования можно притащить в управление бизнесом. На этот раз хочу поговорить о декларативном и императивном программировании.
Своим первым отделом я начал руководить, страшно подумать, 15 лет назад. И первым моим шагом, конечно же, была разработка регламентов. Даже не задумывался, зачем (KPI мне никто не ставил) — просто делал, потому что так принято. И пофиг, что в отделе 5 человек, а во всей компании — 15: я начал писать страшные бумаги, что-то вроде «если приходит срочная задача, то постановщик должен лично подойти к исполнителю». Довольно похоже на первый код, который пишут джуны: «if user.has_access_to_action() then perform_action()»
У этих регламентов есть одна общая проблема с джуновым кодом — все случаи жизни if-ами не покроешь. Если попытаешься — выйдет длинная портянка, которую ни один нормальный человек читать не будет. Чтобы решать проблемы в императивном коде, давно придумали целый арсенал — от дяди Боба до YAML.
А вот с людьми абстракций не наделаешь: фреймворков, чтобы залезать в голову и управлять каждым шагом исполнителя, пока не изобрели. И тут есть два диаметрально разных подхода: можно назвать их конвейерный и стапельный.
В конвейерном подходе всё как в коде: инструкции прячутся за механизмы, которые вроде как обеспечивают их выполнение. Прежде, чем ставить рабочего к конвейеру, его прогоняют через обучение и экзамен. Результат работы постоянно проверяют, самого рабочего — тоже. Периодически меняют инструкции, людей переаттестуют или вообще заменяют на роботов. Такой подход работает при массовом выпуске — на автомобильных заводах, к примеру.
Стапельный подход — более штучный. Мы не пытаемся прописать каждый шаг исполнителя, а дизайним среду, в которой исполнитель будет выполнять то, что нужно. Работает со штучными производствами. В автомобилях, к примеру — в тюнинг-ателье, где каждый автомобиль уникален.
В разработке (думаю и в любой другой творческой работе) действует только штучный подход. Чтобы люди хорошо закрывали клиентские задачи, им нужна удобная среда — доверие, нормальные инженерные практики, минимальная коммуникация, свободное время, много автоматизации, а в идеале ещё и мало контроля. Создавая такую среду в аутсорсе, мы делаем то самое тюнинг-ателье, которое сегодня обшивает потолок майбаха алькантарой, а завтра вкорячивает 37” колеса на джип.
Грустно смотреть на коллег, которые этого не понимают, и вместо линтеров делают стандарты разработки, а вместо асинхронной коммуникации — дейли-митинги и контроль времени.
---
Собственно курс о среде для штучного производства называется «Без Ерунды», состоит из четырёх писем — о доверии, инженерных процессах, внимании и работе с клиентом. Если вы покупали курс раньше — все обновления уже у вас в LMS. Если сомневаетесь — гляньте отзывы из вложения
Перестал вести учёт расходов
С 2015 года я вёл учёт личных расходов — каждый понедельник садился, открывал банковскую выписку и разносил все платежи за прошлую неделю по категориям — еда и хозяйство, одежда, развлечения и т.д. Иногда пропускал неделю, один раз — пропустил целых три. В 2024 году, спустя ровно 9 лет после начала, я перестал это делать.
Базовый принцип «лучше больше зарабатывать, чем меньше тратить» я понял году в 2017, но продолжал вести расходы. А недавно понял, что не принял ни одного решения на основе данных о расходах. Что толку знать, что каждый месяц я трачу на жильё 1500 евро, если принимая решение об ипотеке, я и так могу легко посчитать стоимость всех арендных платежей? Что изменится от того, что в прошлом месяце я потратил на еду 700 евро вместо 400? Зачем знать, сколько обходится автомобиль, если идиоту понятно, что такси в Москве стоит дешевле?
Если я не принимаю решений, то смысла в этих расчётах нет. Разве что в процессе: садишься записывать расходы, и как бы 20 минут напоминаешь себе — все траты предсказуемы, ни одна копейка не уйдёт без твоего ведома. Как мантра.
Но это же неправда! Завтра могут заболеть родственники, центробанк может опустить ставку, я захочу сделать идиотски дорогой подарок супруге, сосед сверху зальёт квартиру, или я сам залью квартиру соседу снизу. Контроля над этим у меня нет.
Получается, что записывать расходы — это работать с прошлым. Так что лучше я буду 20 минут работать с будущим — к примеру начну тратить это время на более качественное планирование недели. Или просто подольше сидеть в кресле и ничего не делать.
Coupling и cohesion в бизнесе
Наверное самая полезная концепция, которую я принёс из программирования в бизнес — это каплинг и кохежн. Бизнес — это такая же система, которая состоит из разных подсистем, связанных по некоему API (чат в вацапе — это тоже API, просто кривое).
Так вот, когда менеджер по продажам, чтобы выставить счёт, должен сходить в бухгалтерию — это высокий каплинг. Для пары счетов в месяц ещё норм, для пары счетов в день — уже очень много. Кохежн тоже есть — если, к примеру, поручить бухгалтерии самой расчитывать зарлптау, получая на вход только данные о зарплате и всякие кадровые документы — получается вполне изолированная система, сконцентрированная только на выполнении своей ответственности.
Зум-встречи на 8 человек, многоступенчатый документооборот, финдир, который требует рапорта на каждую трату — это тоже высокий каплинг: когда кто-нибудь из этой цепочки начинает вести себя неэффективно, ломается вся цепочка.
Чаще всего высокий каплинг возникает в финансах и взаимодействии с государством: поленился подстроить процессы бухгалтерии под возможности встроенной в эквайринг интеграции с ОФД — и ловишь бесконечное количество проблем с потерянными и неправильными чеками от кастомного решения. Или завязал управленческую отчётность на интерфейс конкретного банка — и всё, не можешь его поменять даже когда он попал под санкции.
Каплинг и кохежн — такие же важные метрики, как рентабельность или стабильность кешфлоу. Жаль только, измерить их не так просто.
Сервисы: netdata
В 22 году перед аутсорсом встала техническая проблема — существенная часть клиентов больше не могла использовать datadog. У нас на него было завязано практически всё — и мониторинг хостов, APM, и даже алёрты работали напрямую через него. Отказывались от него грустно, у каждого проекта по своему — где-то продолжали платить, где-то переходили на клиентскую графану, где-то — пробовали APM из Sentry (говно) и uptrace.dev (норм).
Всё это время я страдал — чем гетерогеннее стек у наших клиентов, тем хуже каждый экземпляр настроен. Когда все в компании знают, как готовить Датадог или условную Графану — она у всех клиентов будет хорошая. А если каждый раз настраивать всё с нуля — результат будет дорогой и обычный.
Уже почти решился городить собственный инсталл графаны, но вовремя остановился, наткнувшись на netdata. Самый главный плюс для меня — не надо ничего держать в своей инфраструктуре: только агент на тачках.
— Удобно как у датадога — агент сам видит всё, установленное на тачке — докер, постгрес, редис и т.д.
— Чего не подхватилось само — можно конфигурировать через централизованный интерфейс. Это лучше датадога, в котором приходится прокидывать yaml внутрь докер-контейнеров, чтобы прописать недефолтный доступ к постгресу.
— Готовые дешборды на всё. Думать не надо.
— Можно прокидывать метрики через стандартное API прометеуса. Я, к примеру, быстро добавил мониторинг температуры для пары андроид-устройств, которые лежат у меня на полке.
APM пока нету, но для мониторинга хостов это кажется недорогим и удобным решением, так что мы переходим. Напишу здесь ещё через 3–4 месяца, как зайдёт.
Проекты, в которые я ввязался
Важнейший скилл, который я никогда не перестану качать — это умение не ввязываться в лишнее. Не начинать проектов с непонятной целью, не отвечать на неинтересные предложения, не делать сложного, когда есть простое, не брать кредитов, не иметь дверного звонка и уведомлений на телефоне.
Вместе с отсутствием управленческих долгов, это даёт возможность концентрироваться. Не важно, чему я решил посвятить день — настроить отчётность в компании, провести его с семьёй или просто погулять по городу — я хочу делать это на 100%, не отвлекаясь на чужие проблемы. У пилотов есть «стерильная кабина» — в кабине самолёта запрещено разговариавать о чём-то кроме полёта. У меня вместо стерильной кабины — умение не ввязываться: не допускать в локус внимания ничего, что не имеет отношения к задачам, какими бы они ни были в данный момент.
Возможность не ввязываться — важнейший смысл асинхронной коммуникации. Сложно не посмотреть на новый проект хотя бы одним глазком, когда тебя поймали с ним в переговорке. И наоборот, гораздо легче думать о важном в продуктивное время и с осознанным письмом.
Несколько лет я веду список, который так и называется — «проекты, в которые я ввязался». Сверяюсь с этим списком во время еженедельного обзора, и когда удаётся что-то из него выкинуть или хотя бы делегировать — считаю себя молодцом.
#вопрос Где вы с Саматом взяли первых клиентов для аутсорса?
Я вроде собирался больше не отвечать на бизнес-вопросы про аутсорс, но чё-т опять не могу молчать.
Отвечу кратко — аутсорс вам начинать не стоит. Это очень неблагодарный бизнес с низкой маржой и высокой конкуренцией. Конечно не продажи на вайлдберис, но радости тоже мало.
1. Из-за низкой маржи образуется пропасть между начинающими, которые до конца жизни будут делать сайты для автомоек и лидерами, которые прочно сидят на больших контрактах и потихоньку превращаются в интеграторов. Если вы не знаете, как попасть в подрядчики к условному ВК — всю жизнь останетесь в красном океане маленьких региональных аутсорсеров.
2. На рынке (особенно в красном океане) все привыкли к кабальным контрактам — когда вы подписываетесь под результат в мире клиента, но никак не фиксируете объём работ («ТЗ» не в счёт, его не юристы пишут). Time&Material заходит очень тяжело, чтобы его продавать, нужно иметь репутацию на рынке. На автомойках репутацию не наберёшь. Есть вариант с аутстафом, но у аутстаферов маржа ещё ниже, а от больших контрактов они зависят ещё больше.
3. Низкая маржа и кабальные контракты ведут к плохому качеству. Чаще всего долгосрочные проекты превращаются в гору дерьма, которая растекается раз в месяц и пахнет так, что заказчик просит включить в договор штрафы за сорванные сроки и падения прода. Управлять джунами, которы обложились говнокодом — штука безысходная: нужно или иметь железные нервы, или совсем не иметь совести и человеколюбия.
4. Не-джунов брать негде. Рынок пылесосят Яндекс, ВК и Сбер. Вы никогда не сможете конкурировать с ними за условия труда.
Нам с Саматом удалось взломать эту модель просто потому, что у Самата был огромный нетворк, а у меня умение очень быстро и эффективно писать код (первые 3 проекта я писал сам). А ещё мы вместе не ссали использовать странные модели вроде асинхронной коммуникации и четырёхдневной рабочей недели. Мы всё ещё очень далеки от лидеров рынка, и у нас нет стратегии, как туда попасть — есть только примерные попытки.
Написал это и думаю, что такое можно сказать про любой развивающийся бизнес. Но в своём мнении я честен — лучше поищите что-нибудь более благодарное.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Как дела
Давно не писал сюда не рассказывал как дела. А у меня на самом деле предпринимательская жизнь бьёт ключом:
— Дописали с Марьяной курс «Без ерунды». Сегодня выходит последний лонгрид, скоро откроем продажи для тех, кто не пришёл на поток. Теперь снова могу писать в канал и не бояться прокрастинировать лонгрид!
— Впервые в жизни подал в суд на заказчика! Судимся уже три месяца. Подробности напишу, когда станут публичными.
— Напоролись с Саматом на классический кейс с револютом — без объяснения причин заблокировали счета, карты и API ключи. Сапорт тоже по классике игнорит. Перетаскиваем контракты на новые реквизиты.
— В аутсорсе у нас появился COO (Настя, привет!). Тревожно и восторженно отдавать управление производством. Восторженно — потому что это путь к дальнейшему росту. Тревожно — потому что как же оно без меня-то, а? Пойду «Самому не проще» перечитаю.
Конфликт творцов и продюсеров
Почти в любой творческой работе есть два лагеря — творцы и продюсеры. Творцы что-то производят, а продюсеры сидят рядом и смотрят, чтобы произведение претендовало на коммерческий успех. Иногда продюсер включается в творческий процесс, иногда ограничивается тем, что просто задаёт направление. Иногда в парах творец-продюсер люди меняются местами: сегодня я пишу, а ты смотришь, завтра ты пишешь, а я смотрю. Иногда продюсеров называют по-другому: к примеру у дизайнеров роль продюсера часто играет арт-директор, у программистов — продакт или QA, а в книжном деле — издатель.
Находясь в позиции творца, принято не любить продюсеров. Типа ты такой изобретаешь что-то прорывное, вот-вот скажешь новое слово для всего человечества. А продюсер приходит с умным видом и командует — «вон то удали, вот тут переделай».
Не любить продюсеров — большая ошибка.
Даже самый авангардный художник-концептуалист хочет, чтобы его работу увидел и похвалил кто-нибудь, кроме мамы. А для этого надо не забывать про рынок — кто, в каких условиях, и для чего будет эту работу смотреть. Можно играть по правилам рынка, можно эти правила ломать, но их нельзя игнорировать: никто не будет читать неинтересную книгу, написанную плохим языком, не станет делать покупки на лендосе без внятного предложения, не станет смотреть невидимые картины, нарисованные невидимыми красками в голове автора.
Когда творишь что-то новое, о конечном потребителе думать тяжело — либо творчество превращается в попытки забрать спрос, либо совсем отрывается от реальной жизни. В итоге такого творчества получаются посредственные вещи: у музыкантов получается кальянный реп, у маркетологов — скидки, а у ИТ-школ — курс «Учим питон за полчаса». Творить и продавать — это два разных состояния мозга, которые не пересекаются так же, как творческая работа не пересекается с тупняком в инстаграме.
Не забывайте о продюсировании своей работы. Не воспринимайте продюсера как злого начальника — это ваш помощник, не меньше вас заинтересованный в том, чтобы сделать качественный продукт.
Ласт-колл на «Без ерунды» — курс о DevEx, который состоит только из диалогов
Есть знания, которые хорошо передаются через любые барьеры — к примеру техническая документация, которую можно читать хоть на телефоне. Есть знания, которые, наоборот, передаются только через личное общение — обычно это телесные навыки, типа спорта (кто хоть раз пробовал удалённого фитнес-тренера, тот меня поймёт), игра на музыкальных инструментах.
А есть знания, которые лучше всего передаются через обычные разговоры — очно в офисе или по зуму. Работаешь рядом с человеком и тренируешь мозги делать так, как делает он — сначала копируешь, потом развиваешь свой стиль. Такое хорошо работает в руководстве, в управлении людьми, в стратегическом мышлении. Последнее — вообще кайф: мне кажется, что Теория Ограничений так хорошо отпечаталась у меня в голове именно потому, что Голдрадт её подал в виде кусочка жизни обычных людей, которые ты проживаешь вместе с ними во всех трёх «Целях».
Мы с Марьяной замахнулись на похожий формат — весь курс о DevEx получается в виде разговора двух главных героев. Сергей и его падаван Настя говорят с людьми вокруг — программистами и безопасниками, представителями бизнеса, CTO. В диалогах они решают одну большую задачу — привести команду программистов из состояния, в котором они ничего не релизят, потому что весь день занимаются фигнёй в состояние, в котором бизнес доволен происходящим.
За 4 письма герои через призму DevEx применяют все инструменты, которые нужны управленцам — раскладывают работу команды через JTBD, чинят онбординг и передачу знаний, разруливают проблемы с продуктивностью и, наконец, чинят коммуникацию с бизнесом. По дороге — практикуются переговорах и стратегии.
Получается лёгкий курс, с огромным объёмом полезных знаний. Первое письмо — в эту пятницу, всего их 4, раз в неделю. Пока мы только пишем курс, цена совсем небольшая — потом будет намного дороже.
Смотреть программу →
Опять про DevEx
Кароч, мы тут сделали курс по Developer Experience. В посте рассказываю, зачем мы его сделали, чем он отличается от прошлогоднего (маленького) вебинара, и зову купить билеты. Они недорогие — хотим, чтобы наши письма были как аптечка, доступны каждому.
В ИТ-тусовочке складывается очень узкое понимание понятия Developer Experience. Типа чтобы стать специалистом по DevEx, достаточно написать пару скриптов для команды, поправить конфигу таскраннера и заменить Elastic APM на Datadog. Получается так же, как стало с DevOps — когда целую систему взаимодействия между разработкой и эксплуатацией превратили в новое название для системного администрирования, потеряв по дороге большую часть смысла.
DevEx — это не (только) про инструменты, это — про повышение эффективности разработки. То есть про то, как уменьшенить когнитивную нагрузку, создать комфортную рабочую среду и безопасный контекст. Что-то вроде современной гигиены труда, помноженной на грамотное управление творческими людьми. Опыт в DevEx (может быть даже несформулированный) — это то, чем отличаются управленцы, вышедшие из разработки. Если обычные менеджеры в случае проблем склонны нанимать больше программистов, то управленцы из разработки — наоборот, создавать более удобную среду, в которой меньшее количество программистов делает ту же работу.
Вот об это и наш курс — как работать быстрее, но не растить команду. Курс получился довольно коротким и лёгким — всего 4 письма за 4 недели. Говорим о JTBD, когнитивной нагрузке и онбординге, разбираем, чем удобные инструменты отличаются от неудобных. Последний модуль — о современных Agile-ритуалах: как подчинить разработку требованиям бизнеса, не жертвуя удобством программистов. Писали его для тимлидов, CTO, менеджеров и синьёров. Мидлам и околопрограммистам — если хотите больше понимать, что происходит вокруг или расти в управление. Джунам смысла нет.
Смотреть программу →
Если были на прошлогоднем вебинаре — смысл есть: материал полностью новый, его больше, и подан он более вдумчиво и легко.. Стартуем 15 ноября (это уже через 2 недели). Учимся 4 недели. До 7 ноября действует промокод CRUNCH на 10% скидки.
А давайте встретимся в Алмате?
В понедельник, 21 октября, проводим открытый митап с CTO kolesa.kz Николаем Киндяковым. Повестки нет — хотим просто собраться в офлайне и поразгонять на тему конфликта бизнеса и разработки, поотвечать на вопросы или позадавать их вам.
Встречаемся по адресу ул. Шевченко 155/6, в понедельник, в 18:30 UTC+5. Если хотите прийти — заранее зарегистрируйтесь
А помогите нам получить премию
Мы подали «Анализ систем» ещё на одну премию — School of Education. Результаты оцениваются по итогам голосования, но там нужно не просто нажать кнопку, а написать содержательный отзыв на 100 слов. Если вам понравился курс — потратьте 3 минут на отзыв (или хотя бы на промт).
Для всех, кто оставит голос, мы сделаем с Антоном Давыдовым факультатив на какую-то тему, которая касается курса — присылайте скрины на support@tough-dev.school, а мы напишем в ответ, как только определимся с датой и темой.
OpenWRT и сисадминство
Я давно расстался с сисадминской привычкой сисадминить всё вокруг себя — выбираю iOS вместо Android и мак вместо линукса, езжу на свежей Toyota вместо старой BMW и предпочитаю готовые инструменты собственным огородикам (даже в последние 2 года). Понимаю, что контроль за инструментами — это не только возможность, но и обязанность: когда сломается BMW — её надо починить, а в линуксе нужно будет периодически чинить отвалившийся WiFi или сканер отпечатков пальцев.
После 12 сентября, когда сразу куча зарубежных сервисов перестали работать из России, пришлось перерешивать одну из таких проблем, которую я считал закрыто. Уже лет 7 у меня дома стоит замечательный роутер Amplifi, который за всё это время ни разу не завис и позволял мне не думать о качестве приёма внутри квартиры. Но, увы, промышленность не выпускает роутеров, которые умеют заворачивать в shadowsocks, выборочные маршруты, а теперь без этого комфортно работать не получается. Поэтому пришлось переходить на OpenWRT.
Пока ждал роутер (выбрал Mikrotik Hex) — в голову лезли вьетанские флешбеки сисадминские мысли:
— А давай воткнём в роутер SD-карту, чтобы можно было установить питон и обновлять маршруты автоматически?
— Если не SD-карту, то давай хотя бы скрипт перепишем на micropython.
— О, а ещё есть старый LTE-модем. Давай сделаем второй интернет, на случай если откажет первый?
— А в списке пакетов есть ещё cloudflared! Клёво будет ходить на роутер, даже когда он переключится на запасной интернет!
— И ещё надо сделать автовыбор эндпоинтов для VPN — чтобы переключаться с одного на другой, если они начнут отказывать.
— О, может ещё тем для luci поставить?
К счастью, здравый смысл победил — всей этой хернёй я заниматься не стал. Особенно смешны были мысли про второй интернет — за последние 4 года даунтайм моего домашнего провайдера составил 15 минут.
Жалею конечно, что пришлось отказаться от старого проверенного решения, но выбора у меня, кажется, не было. Ну и горжусь, что смог не насисадминить лишнего даже с OpenWRT, которая буквально подталкивает к этому.
Как хорошо оценивать задачи
Когда речь идёт о хорошей оценке задач, многие представляют себе эксперта-сметчика с годами наработанной интуицией, который обложился доверительными интервалами и матмоделями, оценил в жизни 100 проектов и может за пару часов погрузиться в кодовую базу любого проекта.
Наверное где-то такие люди и существуют, но я их ни разу не видел и ставлю под сомнение их тотальную необходимость. Конечно где-то есть проекты, которые можно сделать только с чёткой и точной оценкой, но среднему бизнесу (если это не аутсорс по фиксированной цене) от прорграммиста нужна не оценка, а предсказуемость.
Как в стройке — содрал старые обои, и выясняется, что стены кривые. Закупил ламинат — понимаешь, что стяжку надо переделывать. Опытный прораб сначала проверит качество стяжки, а потом уже поедет в Леруа за материалом. А плохой — умолчит, положит как-нибудь так, а когда замки не закроются или пол начнёт скрипеть — будет делать вид, что так и должно быть.
Применительно к программированию это значит две вещи. Первая — постоянно искать, где сейчас самая большая зона неопределённости и пытаться её снять. Делаем интеграцию с новым сервисом — сначала накидываем вручную запрос на основе данных из системы, а потом уже пишем оболочку. Меняем модель данных — сначала проводим миграцию на продовых (или максимально близких к ним) данных, а потом уже дописываем код под неё. Пишем код неделю в отрыве от команды — сначала мёрджим мастер. И т.д.
Вторая — быть прозрачным. Видим риск, который не получается снять за 5 минут — сигналим бизнесу. Прошло 50% времени и не сделали 50% работы — сигналим бизнесу. Всё вроде бы идёт хорошо, но интуиция подсказывает, что будут проблемы — сигналим бизнесу.
В большинстве своём даже такая минимальная прозрачность успокоит бизнес и создаст вам репутацию надёжного исполнителя. А матмодели оставьте людям, которые делают самолёты.
Не как у других: почему любят наши курсы
Каждый второй человек, который приобрел курс в нашей Школе сильных программистов, в течение полугода покупает что-то еще. И большая часть из них приобретает в среднем 3-4 курса. Это высокий показатель, учитывая, что у нас нет широкого ассортимента курсов.
Когда я спрашиваю, почему они возвращаются, чаще всего слышу: «Это полезно» и «У вас не так, как у других». Полезность понятна, но вот что именно они имеют в виду под «не так, как у других», расшифровать сложно.
В прошлом году, участвуя в премии Digital Learning (об этом я писала здесь), я четко осознала наши отличия: подход, дизайн, тон общения. Тогда я подумала: «Вот в чем мы другие». Я даже сказала Феде: «Мы настолько отличаемся, что либо возьмем первое место, либо останемся за бортом». И мы победили.
Однако меня не покидала мысль: разве только внешний вид и стиль могут объяснить, почему люди к нам возвращаются снова и снова, доверяя нам? На прошлой неделе я выступала перед аудиторией, состоящей в основном из людей, которые занимаются созданием образовательных продуктов. Рассказывая о нашей школе, о том, как и что мы делаем, я, кажется, поняла причину.
Готовясь к выступлению, я осознала: мы погружаемся в контекст каждого ученика, и это влияет на процесс создания курсов. Сейчас поясню.
На мой взгляд, многие курсы на рынке напоминают сложные академические книги. Ты читаешь — и страдаешь. Материал часто подан так, будто его слушатель должен обладать невероятной силой воли, чтобы абстрагироваться от всего и полностью погрузиться в обучение. Но курс не учитывает, что ты мог целый день писать код, провести стратегическую сессию или, устав, прийти домой, чтобы продолжать учиться. И если материал подан сложно, уже через 10 минут ты выдыхаешься.
Или другой пример: на этой неделе ты активно вовлечен в обучение, но на следующей — отпуск или завал на работе, и вернуться к курсу уже не получается. И это не говоря о множестве других жизненных обстоятельств. При этом большинство из нас не учили эффективно учиться ни в школе, ни институте. Хоть много всего давно уже рассказали ученые. Взять хотя бы моего любимого Мортимера Адлера «Как читать книги» или супер полезный курс на курсере от Барбары Оакли.
Мы же всё это стараемся учитывать: как в содержании курсов, так и в том, как они устроены, и в дополнительных материалах. Заранее даем ответы на вопросы, которые ученикам может быть неловко или страшно задать. Помогаем построить образовательный трек и создать безопасную среду, где можно ошибаться, пробовать и не чувствовать вину за то, что не дошел до конца курса.
С нами людям комфортно. Поэтому около 70% наших студентов выполняют домашние задания и доходят до финала курсов, а затем возвращаются снова. Даже если курс сложный, требует много времени и усилий, люди готовы работать по ночам или брать отпуск, чтобы всё успеть.
Я очень рада, что у нас так получается, и верю, что в будущем мы станем ещё лучше. Мы постоянно ищем новые способы сделать процесс обучения проще и эффективнее.
Кроме того, что постоянно копаем тему обучения взрослых и залезаем даже в нейробилогию, привлекаем редакторов, чтобы становиться понятнее — я перманетно ищу возможность дотянуться до какой-то мировой звезды в индустрии. Из недавнего, пытаюсь попасть на закрытую лекцию Барбары Оакли, которая внезапно будет в Тбилиси этой осенью.
Мой вывод такой: многие образовательные программы устроены так, будто их ученики — это суперлюди, которые могут без усталости и безошибочно двигаться к цели. Они требуют от нас полной самоотдачи, не учитывая реальных жизненных обстоятельств.
Мы, напротив, показываем реальную картину: не требуем невозможного, а создаем условия, в которых человек сможет вносить реальные изменения в свою жизнь и работу. Двигаясь шаг за шагом, и в итоге — добиваться ощутимых результатов.
Очень рада, что это сформулировала — под этим углом буду более сфокусированно смотреть в текущем потоке «Стать тимлидом».
#фичи_курсов