Фальшивые догмы

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

👉Не переизобретайте колесо и берите готовые библиотеки. На самом деле, это трейд-офф, на другой стороне которого – ценность хорошего понимания кода, и безопасность от supply chain атак.
👉Каждый PR кто-то должен заревьюить. Цена обязательных ревью очень высокая, поэтому, хоть они и поднимают качество кодовой базы, не нужно доводить это правило до абсолюта и ревьюить тривиальные вещи.
👉Все современные команды должны работать короткими спринтами. Не всегда тот факт, что вы работаете по спринтам, делает вас гибкими. Более того, не вся разработка должна быть гибкой.
👉Каждая фича должна быть за флагом. Точно нет, так как огромное количество флагов усложняет даже самый тривиальный код, а ценность от них есть не всегда.

Полезные правила работы с календарем

👉Решайте конфликты между накладывающимися друг на друга встречами максимально рано. Чем раньше вы отклоните один из них, тем удобнее будет для всех его участников.
👉Используйте цветовое кодирование для митингов разного типа. Например, их можно делить по требуемому уровню фокуса, формату, решаемой проблеме, роли или еще чему-то, что имеет смысл именно для вас.
👉Используйте эту категоризацию для бюджетирования времени – например, на уровне одной недели можно поставить ограничение на количество собеседований.
👉Бронируйте слот на обед.
👉Делайте события в календаре редактируемыми всеми участниками по умолчанию, так их будет проще переносить.
👉Если у вас есть и личный, и рабочий календарь, слоты в которых пересекаются, используйте Reclaim для их автоматической синхронизации.
👉Забронируйте первый день после отпуска под то, чтобы снова въехать в контекст и разобрать все накопившееся, иначе встречи не дадут этого сделать.

Почему нанимать джунов стало выгоднее

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

Джун – это ставка с определенным уровнем риска. Вы нанимаете неопытного человека, вкладываете в него время и ресурсы кого-то опытного из команды, и не можете быть на 100% уверены, что по итогу эти вложения оправдаются.

Красная линия на графике – профит от джуна. Первое время он отрицательный, и, если вам повезет, когда-то выйдет в плюс. Сократить эту отрицательную область можно с помощью правильного онбординга и обучения, которые будут помогать быстрее приносить пользу, поддерживая достаточный уровень качества. Так вот, AI как раз с этой частью отлично помогает – если вы еще не использовали тот же Claude Code для онбординга в незнакомый код, обязательно попробуйте.

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

Реорг на вайбе

У реоргов есть несколько очень частых проблемы:

👉Оргструктура редизайнится на основе ощущений и вайбов, а не на основе детального системного анализа. Иногда эти ощущения верны, но иногда растут из когнитивных искажений и попыток повторить чужие лучшие практики.
👉Проблемы и решения обсуждаются без участия людей, находящихся внутри организационной структуры – и это делает ощущения еще менее надежными.
👉Реорг – очень понятное действие, которое маскирует реальные проблемы с пониманием, куда надо дальше двигать продукт. Рисовать квадратики и переименовывать команды просто и приятно, но проблем со стратегией это вообще не решит.
👉Аналогично и с культурой – она не изменится за несколько месяцев только как результат реорга.

Как думать про компенсацию

Мне нравится, как автор сформулировал цель процесса компенсации:

Создать самую талантливую и мотивированную команду, которую только позволит вам ваш бюджет.

Это значит, что следующие вещи не являются самоцелями:

❌Сделать сотрудников счастливыми
❌Сохранить команду любой ценой
❌Сэкономить на ФОТ
❌Платить на уровне рынка, или на уровне какой-то конкретной компании
❌Соответствовать ожиданиям сотрудников
❌Платить всем одинаково

Если подумать над целью более рационально, то вам важно обязательно соблюдать следующее:

👉Платить самым ценным членам команды на уровне, на котором им будет сложно найти на рынке другую работу
👉Не допускать нечестной компенсации, использовать понятные и прозрачные зарплатные уровни
👉Быть готовым объяснить любое свое зарплатное решение
👉Максимизировать выравнивание интересов людей и компании через equity и performance-based бонусы

Как разные роли используют AI

Сценарии использования AI инструментов довольно сильно отличаются в зависимости от роли человека:

👉Продакты – подготовка PRD, прототипипование, коммуникации.
👉Дизайнеры – работа с исследованиям. пользователей, генерация текстового контента, генерация идей.
👉Фаундеры – помощь в принятии решений, генерация продуктовых идей, стратегия.
👉Инженеры – написание кода, архитектура, документация.

Тимлидов спросить забыли, но мы ведь понимаем, что в основном для написания перфоманс ревью!

Про мораль корпораций

На этой неделе весь Reddit обсуждает анонимный пост от сотрудника какого-то крупного приложения доставки еды, в котором рассказано про какие-то совсем неэтичные практики:

👉Фича priority delivery, которая на самом деле не влияет ни на что, кроме флажка, отправляемого на сервер.
👉A/B тесты с замедлением скорости доставки неприоритетных заказов.
👉Автоматическое определение курьеров, которые готовы браться за заказы любой стоимости, и занижение им оплаты.
👉Чаевые, которые целиком уходят в карман платформы.

Спустя несколько дней после того, как я написал черновик поста, выяснилось, что история – не правда, а просто байт на комментарии. Но будем честными – никого не удивило бы, если бы это оказалось правдой. В большинстве крупных корпораций единственный способ оценки правильности действий – это то, как они влияют на ключевые метрики. Если активация, ретеншн или MRR растут – все замечательно. Если кого-то волнует этичность действий, система его автоматически отфильтровывает – без импакта нет повышений, без повышений нет влияния на принимаемые решения.

Очень подробно про это рассказано в вышедшей в прошлом году книге Careless People, в которой бывший топ-менеджер Meta делится байками про то, как Цукерберг и компания принимают решения и разруливают происходящий по их вине геноцид (и даже не один). Если вот эта история про доставку еды показалась вам нереалистичной, очень советую прочитать!

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

Законы разработки софта

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

👉Закон Каннингема – Самый лучший способ получить полезный и правильный ответ в интернете – не спрашивать, как правильно, а запостить неправильный ответ.
👉Закон Стерджена – 90% чего угодно это мусор (ну получается как минимум один пост в две недели в нашем канале должен быть годным).
👉Закон Хайрума – от любого, пусть даже незадокументированного поведения вашего API, кто-то будет зависеть. Про этот закон мы пару лет назад классно поговорили в выпуске Подлодки про дизайн API.
👉Эффект Рингельмана – чем сильнее растет группа, тем сильнее снижается продуктивность отдельных ее участников.

За что инженеры ненавидят своих менеджеров

👉Бесконечные синки и митинги, которые вырывают из состояния потока
👉Нетехнические менеджеры, которые не понимают сложности задач, но при этом дают обещания по срокам
👉Менеджеры, которые присваивают себе чужие достижения, фразами вроде "вот что я зарелизил в этом квартале"
👉Фидбэк про зоны роста, который дается раз в год менеджером, который вообще слабо прелставляет себе вашу работу

Уроки 14 лет работы в Google

👉Лучшие инженеры думаю в первую очередь про решение проблем пользователей.
👉Быть всегда правым – легко. Настоящая сложность в том, чтобы прийти к правильносу решению вместе с командой.
👉В первую очередь выбирай действие – лучше сделать что-то, чем вообще ничего. Плохую фичу можно исправить, отсутствующую – нет.
👉Признак сеньорности – ясность. Сложность решения приносит накладные расходы.
👉Новизна – это кредит, который оплачивается сбоями и лишней когнитивной нагрузкой.
👉Ваш код не покажет всем, какой вы классный – это делают люди.
👉Лучший код – тот, который не написан.
👉На большом масштабе даже у ваших багов появляются пользователи, и их починкой вы кому-то навредите.
👉Проблемы медленных команд чаще всего в том, что они не выровнены с остальными.
👉Фокусируйтесь на том, что можете контролировать. Остальное игнорируйте.
👉Абстракции не избавляют от сложности. Они просто прячут ее до того дня, когда абстракция протечет, и вам надо будет разбираться, что находится под ней.
👉Письмо ведет к ясности. Лучший способ научиться чему-то – попробовать научить других.
👉Работа, которая разблокирует другую работу бесценна, и при этом невидима.
👉Если вам кажется, что вы выигрываете в каждом споре, скорее всего вы просто постепенно накапливаете сопротивление людей.
👉Когда метрика становится целью, она перестает быть честным показателем.
👉Признать то, что вы не знаете чего-то, дает больше безопасности, чем притворяться наоборот.
👉Сеть ваших знакомств переживет всю вашу смену мест работы и с вами навсегда.
👉Большая часть способов улучшения протзводительности лежит в избавлении от чего-то, а не в добавлении слоев сложности.
👉Процессы существуют для того, чтобы снижать неопределенность, а не ради бюрократии.
👉В какой-то момент карьеры ваше время станет дороже зарабатываемых денег, так что готовьтесь к этому и берегите его.
👉В накоплении знаний и опыта старайтесь не срезать углы, а наоборот, полагаться на сложный процент.

А если ваша стратегия не выдержит следующий год?

Стратоплан задумал открытую конференцию для всех, чтобы детально поговорить о стратегии (в частности, об IT-стратегии). И не просто поговорить, а совместно сформулировать принципы её устойчивости и антихрупкости

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

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

29–31 января 10:00–15:00 GMT+3, онлайн
Бесплатная регистрация здесь

Среди спикеров: Никаких теоретиков! Только фаундеры, СЕО, СТО, HRD и эксперты Стратоплана, которые сами проходили через кризисы и знают, как строить стратегию на годы

Бонус:
3 онлайн-воркшопа про разработку и внедрение стратегии, в том числе от сооснователей Стратоплана — Вячеслава Панкратова и Александра Орлова.

Приходите и проверьте, действительно ли ваша стратегия устойчива

Прокрастинация, и как с ней справляться

Если кого-то и читать про прокрастинацию, так это Максима Дорофеева. В статье он постепенно выводит ее определение:

Я прокрастинирую, когда я решаю:
- сделать дело Y, показавшееся более важным, чем X,
- вместо дела X, впоследствии показавшееся более важным, чем Y и …
- испытываю неприятные чувства из-за этого

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

👉Почему вы считаете дело Х важным для себя? Важно ли оно само по себе, или является средством достижения другой цели?
👉Всегда ли вы занимаетесь разными делами вместо Х, или одним и тем же? Как они связаны?
👉В каком состоянии вы находитесь во время приступа прокрастинации? Типичное ли это состояние в момент принятия решения, что делать дальше?
👉Есть ли у вас состояние, в которгм нет приступов прокрастинации? Как вы его расходуете?
👉Какие аргументы в пользу дела У проскакивают в вашем уме во время прокрастинации?