Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Новые выпуски тимлидских подкастов Помимо перечисленных ниже выпусков напоминаю про "Бреслава и Ложечкина" с разбором того, как подходить к личному целеполаганию – про этот выпуск я отдельный пост недавно писал. 👉Подлодка про СДВГ – как этот синдром диагностируется, почему его так много среди айтишников, и как вообще работать с такими людьми 👉Три тимлида заходят в бар про делегирование – как к нему правильно подойти, как адаптироваться под культуру компании и чем занять освободившееся время 👉Едим слона целиком про известных менеджеров в истории – Ивана Грозного, Георгия Жукова, Александра Суворова и других

Поводов усиленно думать стало меньше Помните алгоритм решения проблем имени Фейнмана? 1. Запишите задачу 2. Хорошо подумайте 3. Запишите решение Если говорить про разработку, то возможностей активировать второй пункт из этого списка стало существенно меньше. Даже в тех случаях, когда вы можете вручную написать более эффективный код, чем AI, часто это будет не рационально – вы потратите существенно больше времени, а выигрыш будет не очень большим. Если вы относитесь к тому типу людей, кого мотивирует именно самостоятельный процесс поиска решения для сложных задач, то новости плохие – в ближайшие годы эта потребность вашей работой перестанет закрываться.

Про CapEx и OpEx Когда я был разработчиком, про CapEx и OpEx я не просто не думал – я вообще не знал об их существовании. Весь процесс и тонкости финансов существовали где-то в абсолютно другой вселенной. Поэтому, когда, став менеджером, я попал на встречу с обсуждением бюджета на следующий год, и люди начали со мной разговаривать на странном финансовом наречии, я почувствовал себя абсолютно потерянным, и просто кивал головой и загадочно улыбался. Все оказалось, конечно же, просто – базовая терминология и принципы корпоративных финансов хорошо достаются из нескольких статей по теме. Самое интересное – это конкретные соглашения и эвристики, действующие именно в вашей компании, потому что именно тут кроются все нюансы. Какие проекты считаются операционными затратами, а какие – капитальными? Как организована структура кост и профит центров? В общем, советую как-нибудь вам вытащить на рандом кофе кого-то из ваших финансистов, будет интересно!

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

Библиотека без кода Держите классный эксперимент на спичках по тому, как может выглядеть библиотека вообще без кода, реализацию которой на нужном языке напишет ваш агент. Из чего она состоит: 👉Подробная спецификация (высокоуровневые дизайн-принципы, требования по входу-выходу, обработке ошибок, описание логики работы и тестов для каждой функции) 👉Набор тестовых данных 👉Инструкция для агента Понятно, что такой подход пока что работает только для очень простых utility-штук – в этом примере библиотека переводит дату в строчки. Но, кажется, в будущем основными ограничениями будет не столько комплексность бизнес-логики, сколько высокие требования к перфомансу, сложности в тестировании и вероятность появления редких, но неприятных багов. Я знаю, что вы сейчас в комментарии накидаете еще сотню ограничений – но попробуйте посмотреть на подход с открытыми глазами и сердцем, ведь круто же, ну!

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

Про доверие к исследованиям Я часто напоминаю и себе, и всем остальным, что сам факт существования опубликованного исследования, пусть даже прошедшего peer review, и с наличием ссылок на него из других исследований, вообще не показывает, что ему можно доверять. Если вы действительно хотите на него опираться, недостаточно просто прочитать вводную часть и выводы, нужно внимательно вкатиться в методологию и понять, а доверяете ли вы ей. Ну а вообще – опираться на единичное исследование в целом такое себе, и по-хорошему надо искать появления мета-исследований. На прошлой неделе произошел еще один скандал, который этот тезис подтверждает. В чем суть – есть исследование 2014 года под названием "The Impact of Corporate Sustainability on Organisational Processes and Performance". Его авторы заявляли, что компании, которые серьезно относятся к социальной ответственности, не только делают добро, но и зарабатывают больше денег для акционеров, причем таких сверхдоходов аж 40%, и это видно на горизонте 20 лет. Это исследование стало безумно популярным – 6000 ссылок, цитирование разными топ-менеджерами, финансистами и политиками. Но оказалось, что в нем есть ряд фатальных недостатков: 👉Ключевой результат, помеченный как статзначимый, на самом деле не был таким. 👉Описанный в исследовании аналитический метод на самом деле не соответствовал тому, что делалось реально. 👉Часть важных статистических проверок просто не были проведены. 👉Независимая попытка воспроизвести исследование провалилась. 👉Результаты не проходят стандартную проверку на ошибку выжившего – потому что для него отбирались только компании, дожившие до наших дней. Причем с академической системой все настолько плохо, что даже эти выявленные проблемы не повлекли за собой ни отзыв исследования, ни публикацию критики в оригинальном журнале, ни принятие его авторами этой критики. Поэтому не забывайте, что за любым рисерчем стоят люди, со своими когнитивными искажениями, желанием подтвердить свои личные убеждения, и собственной агендой.

Как AI влияет на формирование навыков программирования 52 джуна разделили на две группы, каждая из которых решала одинаковую задачу, и после этого отвечала на тестовые вопросы по теме: 1️⃣Группа без доступа к AI. Они часто ошибались в задаче, но лучше справлялись с итоговым тестом. Получается, что в процессе работы они учились. 2️⃣Группа с доступом к AI. Эти лучше справлялись с прогарммированием, но по итогу ничего не поняли. Какие дополнительные интересные выводы появились: 👉Хуже всего справились с заданиями те, кто делегировал AI и решение задачи, и дебаг, и не пытался вникнуть в суть решаемых проблем. 👉Участники, которые помимо генерации кода, использовали AI, чтобы понять, как и почему он работает, справлялись существенно лучше. Короче говоря, все ожидаемо – если вы просто бездумно будете вбивать задачи в агента, то ничему не научитесь – поэтому внедрять джунам AI нужно не бездумно, а подкреплять его нормальными инженерными практиками, помощью коллег, и совместным обучением с AI.

Почему разработчики выгорают, а фаундеры нет Вспоминаем понедельничную статью про то, как со стабильным успехом взламывать систему перфоманс ревью. Все те советы действительно могут помочь получать чуть больше денег, чем если им не следовать – но они только чуть-чуть и на короткое время прикрывают зияющую дыру в душе человека, который продает свое время за деньги. Вся проблема в выгорании – отсутствие смысла в том, что мы делаем каждый день. Если вы не видите четкой связи между движением задач в Jira и созданием понятной вам ценности, которой можно гордиться, то вы будете искать замену этому – пытаться делать пет-проекты, заниматься нужным только вам самому рефакторингом, пытаться гордиться своими оценками перфоманса. У фаундеров это работает проще – они всегда явдяются авторами того, что делает компания, и видят связь своих действий, успеха компании и качества своей жизни. У программистов такого авторства нет, они исполнители в чужом замысле. А когда ты не являешься причиной происходящего, зачем вообще стараться.

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

Тот самый проект на 100.000 строк, написанный полностью с помощью Claude Code (оригинал).

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