25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
Контроль — это костыль
Этот пост — реклама курса «Стать Тимлидом». Как всегда — полезная: прочитайте, если как и я, боитесь ошибок и лечите это гипер-контролем
Тут Марьяна рассказывает, как на горнолыжном склоне училась не бояться собственных ошибок. Это действительно очень полезный навык: страх ошибки на работе может парализовать так же, как и на склоне — так, что с места не сдвинешься.
У меня, при переходе в управление, страх ошибок был немного другим (хотя и синдром самозванца тоже приходил). Дело в том, что на склоне, как и в программировании, всё довольно бинарно: упал — ошибка, доехал до конца — молодец. А в управлении от этой бинарности не остаётся и следа: о том, что ты испортил отношения с бизнесом начинаешь понимать через месяц после первой встречи, на которой всё пошло не так. Что команда без тебя начала говнокодить, можешь узнать только когда бизнес-задачи уже встанут колом. Обратная связь если и приходит, то очень медленно.
Сначала пытался справиться со страхом очевидными способами — уведомления на почту, выдуманные KPI, напоминалки, чтобы проверить, что эти уведомления пришли. В общем пытался всё контролировать. Как можете догадаться — довольно безрезультатно.
В какой-то момент я всё-таки дошёл, что контролировать я могу исключительно себя. Вряд ли я заставлю бизнес на себя не обижаться — зато если сфокусируюсь на своём собственном поведении, начну их слушать, превращать проблемы в таски и помогать команде эти таски закрыть, то скорее всего всё будет хорошо. Кароче, ушёл качать скиллы.
Помогло — вернулось чувство контроля, появились силы на профессиональный рост. Когда вырос — перенёс этот подход на предпринимательство, где определённости ещё меньше: опираюсь на скиллы и качаю те, которых не хватает.
———
Если тоже замучил страх ошибок — приходите к нам на «Стать Тимлидом». В безопасной среде прокачиваем ключевые навыки, нужные ответственным программистам — работу с командой, найм, управление проектами и умение общаться с бизнесом.
Где начинали — там и общайтесь
Типичная ситуация: у компании есть трекер задач, слак и ещё личная телега у сотрудников. Изобилие коммуникаций приходит к тому, что ни в одном месте нет ни одной завершённой. Заходишь в трекер и видишь, что задачу двигают уже три спринта. Пытаешься понять в чём дело — а последний раз по ней писали что-то как раз те самые три спринта назад.
Или ищешь ссылку, которую коллега давал по задаче. Вроде общались в слаке, всё обыскал и ничего не нашёл. А она была в комментах к трекеру, потому что вспомнили о ней на планировании спринта. Или наоборот, в личной телеге, потому что говорили о ней после работы.
Кароч, если не получается удалить лишние средства общения, поддерживайте хотя бы консистентность:
— Если задача стоит в трекере, старайтесь общаться там же.
— Наоборот, если начали в слаке — не обманывайте себя, что уйдёте оттуда, сделайте хотя бы удобный тредик.
— Если начали в трекере, а в процессе работы переехали куда-то ещё — дублируйте в трекер хотя бы ключевые договорённости.
Сэкономите кучу времени на поиске информации, не говоря уж о том, что перестанете выглядеть наружу как кучка молчунов.
---
Напоминаю, что идёт набор на «Стать Тимлидом», где мы рассказываем, как завоёвывать доверие у коллег и бизнеса, в том числе и такими мелкими хаками
Кастомный воркфлоу не нужен
Я тут недавно решил поменять монитор — честно служивший 8 лет LG UltraFine поменял на Apple Studio Display. Оказалось довольно трудозатратно — поменялось очень много паттерном использования.
Старый монитор был довольно маленьким — 21“ хватало только, чтобы воспроизводить привычный экран ноутбука. Работа за ним по сути ничем не отличалась от ноута — всегда было открыто 2–3 спейса с одним окном, максимум — с двумя. На 27“ фигни входит гораздо больше, поэтому я решил заняться её организацией — вспомнил любимый линуксовый dwm и тайлинг в целом.
Оказывается в macOS есть куча инструментов, чтобы управлять тайлингом — юникс-вейный yabai, фреймворк для скриптования Hammerspoon, или Aerospace как решение всё-в-одном. Можно сделать клёвый статус-бар на SketchyBar или настроить любые хоткеи через shkd, Karabiber или BTT. Можно даже сделать всё то же самое, просто накупив программ в AppStore!
Беду с этими инструментами я осознал ближе к десятой помидорке, которую на них потратил — огромный порог входа и совершенно непрогнозируемая стоимость поддержки. Получается настолько же сложно, как какая-нибудь средненькая среда разработки, вместе с IDE, CI и таскраннером.
Правда, когда занимаешься DevEx на рабочем проекте — ты получаешь прогнозируемый выхлоп в виде того же TTM. А вот выхлоп от автоматического тайлинга я спрогнозировать не могу, хоть и проработал на нём больше 5 лет. Кажется, в итоге я сделаю гораздо больше работы, если 3 лишних минуты в день буду возить мышкой, чем если буду раз в месяц тратить по паре часов на починку фичей, которые отвалились из-за очередного обновления.
Программисты вообще любят всё настраивать — от цветов в консоли до статусов в жире. И если цвета вредят разве что зрению, то статусы и другие кастомные воркфлоу жрут вполне измеримое время. Я программист уже не настоящий (надеюсь), так что посижу на встроенном UI.
Затаскивать проекты, а не людей
Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.
Неклёво затаскивать людей. Не работать вместе над общим делом, а всей командой обходить неумение кого-то одного писать код или выполнять обещания — перераспределять нагрузку, какделировать несамостоятельных, выкидывать работу не потому, что неважно, а потому, что не успеваем.
Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.
Когда затаскиваешь людей — ты просто тратишь время на то, чтобы принести результат.
Готовые комплекты вещей
Самое смешное бытовое открытие прошлого года — это готовые комплекты вещей. К примеру, комплект проводов и зарядок для поездки. Раньше нужно было подумать, какие устройства я с собой беру (нужен ли 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 и поди пойми, зачем она вообще существует.
О коде нужно думать как редактор или дизайнер. Цикломатическая сложность, чистота по дяде Бобу или <любая ваша метрика> — это базовая гигиена, как отсутствие грамматических ошибок в тексте у редактора. Гораздо важнее высокий уровень — как будущие программисты будет решать свои задачи в нашей кодовой базе. Если надо будет пилить новую бизнес-логику, поймут ли они, в каком формате у нас это принято делать — сервисыные объекты\контролелры\микросервисы? Сколько времени будущие программисты будут разбираться, как у нас прокидываются настройки из рантайма? Если надо будет что-то делать с БД, поймут ли как у нас работают миграции схемы?
Дедлайны в трекере не нужны
В любом таск-трекере у задачи есть поле с дедлайном. Если его заполнить — трекер начинает напоминать о задаче: вот неделя осталась, вот уже завтра, вот уже на два дня проёбано. Иногда с дедлайнами выстраивают красивые календари: типа вчера вот эту задачу проебём, завтра вон те 10 проебём.
Не могу вспомнить ни одного случая, когда это поле приносило пользу. Зачем дедлайн программисту, если у него спринт и все задачи с одним дедлайном, либо канбан, где WIP-лимиты, либо бизнес которому надо вчера? Зачем дедлайн менеджеру, если при постановке задачи дедлайн с ним никто не согласовывает?
Получается поле есть, совершает какие-то действия, создаёт какую-то уверенность («вот же, дедлайн установили»), а пользы не приносит. Подозреваю, что это какой-то глобальный заговор владельцев таск-трекеров. А может просто таск-трекер без дедлайна в задачах никто не купит — это ж несерьёзно как-то.
Переубедите меня?
Стать Тимлидом
В последнее время из разных мест слышу, как тяжело менеджерам без технического бекграунда становится искать работу, связанную с управлением программистами. Думаю, это неплохо — клёво, когда руководитель приносит ценность в проект, а не просто следит, как бы чего не вышло.
Думаю, следующие в очереди на ненужность — программисты без менеджерского опыта. Когда-нибудь на собеседованиях вместо литкода начнут ковырять проактивность, рефлексивность и умение отвечать за результат — умения, которые в отличие от вращения деревьев, нужны каждый день.
Когда я в 19 году уходил из ГдеМатериала, я оставил 10 человек без руководителя. Не было даже тимлида. Очень гордился тем, как, прощаясь с командой, сказал, что каждый из них сам вполне может быть себе CTO. Хотя большой моей заслуги в этом и нет (просто ребята золотые), до сих пор идеал программиста для меня — это сотрудник, который сам себе если уж не CTO, то тимлид: сам договорится с бизнесом, поучаствует в собеседовании, а если дадут нерадивого коллегу — спокойно и ненавязчиво организует его время.
Из этого убеждения в 20 году у нас с Марьяной и появился курс «Стать Тимлидом» — мы собирали в одном месте пачку софтскиллов, нужную, чтобы выполнять работу без внешних костылей. С тех пор курс мы полностью переписали, но идея осталась прежней — отучившись 5 недель действительно можно разобраться чего не хватает, чтобы стать тимлидом, если не для крутой команды, то для себя — уж точно. Курс построен вокруг типичных лидерских вопросов: как договариваться с людьми, как быть, когда ребята не тянут, как поддерживать порядок; при этом не работая за всех круглые сутки.
Основная часть курса — это 5-недельный интенсив. За это время вы получите набор знаний, который выручит, когда нужно будет взять ответственность или провернуть что-то сложное на работе.
Смотреть программу →
Вторая, и самая важная, часть, происходит после курса — вы уходите применять знания, а сталкиваясь с проблемами, возвращаетесь в LMS. Материалы построены вокруг вопросов, с которыми рано или поздно сталкивается любой тимилд: начнёте нанимать — вернётесь к разделу про найм; получите доступ к бизнесу — перечитаете, как выстраивать с ним отношения; унаследуете хаос в процессах — перечитаете блок про управление проектами.
Стартуем 19 марта. По промокоду LEADYOURSELF действует 10% скидка до конца выходных.
Два новых выступления
1) Как не превратиться из хорошего программиста в плохого менеджера: рассказываю о двух профессиональных путях — «лидерах» и «хакерах»: https://www.youtube.com/watch?v=XWs-Iwe8wuc
2) Ищем, куда девается время программистов: как при помощи анализа пользовательских сценариев можно находить места, в которых программистам неудобно: https://www.youtube.com/watch?v=rZvtwKShR7U
Императивный и декларативный бизнес
Вообще этот пост — реклама курса о 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, а мы напишем в ответ, как только определимся с датой и темой.