Зачем организациям оценка сроков

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

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

Если следовать этой модели, то вот несколько разумных правил поведения в ней:

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

Библиотека без кода

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

👉Подробная спецификация (высокоуровневые дизайн-принципы, требования по входу-выходу, обработке ошибок, описание логики работы и тестов для каждой функции)
👉Набор тестовых данных
👉Инструкция для агента

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

Я знаю, что вы сейчас в комментарии накидаете еще сотню ограничений – но попробуйте посмотреть на подход с открытыми глазами и сердцем, ведь круто же, ну!

Координация стоит дорого

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

Если нырять в детали, то вот что важно понимать:

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

Про CapEx и OpEx

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

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

Поводов усиленно думать стало меньше

Помните алгоритм решения проблем имени Фейнмана?

1. Запишите задачу
2. Хорошо подумайте
3. Запишите решение

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

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

Новые выпуски тимлидских подкастов

Помимо перечисленных ниже выпусков напоминаю про "Бреслава и Ложечкина" с разбором того, как подходить к личному целеполаганию – про этот выпуск я отдельный пост недавно писал.

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

В чем заключается работа тимлида

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

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

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

Что такое Context Graph

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

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

Вот тут в игру и вступает контекстный граф. Это автоматическая система трекинга того, как, почему и кем принимаются организационные решения, когда и какие исключения из них были приняты, каким образом были выданы аппрувы. Короче говоря, поиск релевантного контекста во всем огромном массиве организационных переписок и документов.

Пока это скорее идея, которая очень интересна большому количеству стартапов. В реальности я еще не видел, чтобы оно работало хорошо. Инфраструктура для чего-то похожего точно есть у Gleam, которым мы пользуемся на работе, но релевантность там пока оставляет желать лучшего – да и UX удобный точно еще надо будет придумывать.

Как сделать программиста счастливее

1️⃣Status – ощущение профессиональной значимости. На него влияют публичное признание вклада, конструктивная обратная связь, вовлечение в принятие важных решений, как технических, так и продуктовых.
2️⃣Certainty – предсказуемость и ясность. С этим помогают понятные цели, хотя бы на краткосрок, наличие смысла за задачами, логичные объяснения причин изменений, доверие к решениям менеджера.
3️⃣Autonomy – контроль над своей работой. Важно иметь возможность самому планировать и свою работу, и то, как она будет делаться, без микроменеджмента, контроля и советов под руку.
4️⃣Relatedness – чувство принадлежности и безопасности. Этот пункт про команду, которой ты доверяешь, с которой разделяешь общие цели, и вместе с которой тебе кайф работать.
5️⃣Fairness – ощущение справедливости. Больше всего его рушит чувство несоответствия между твоими усилиями и вознаграждением. Поэтому работать над этим менеджеру надо, устанавливая понятные правила игры для всех, компенсируя похожим образом похожие результаты, и оставаясь последовательным (см пункт про ясность и предсказуемость).

Расскажите, как вы используете AI

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

Конечно же, по нашей традиции среди всех участников я разыграю сертификаты на хорошие книги – на что еще тратить сэкономленное время, как не на чтение!

👉Ссылка на опрос

AI не уменьшает количество работы, а делает ее более интенсивной

In an eight-month study of how generative AI changed work habits at a U.S.-based technology company with about 200 employees, we found that employees worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day, often without being asked to do so.

Несколько мыслей по этому поводу:

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

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

Скорость разработки никогда не была проблемой

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

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

Вот и сейчас мы видим похожую историю. В подавляющем большинстве случаев внедрение AI не сильно изменит картину:

👉У людей внутри организации мало хороших идей, и много плохих. Вообще то, что идеи запиливать было долго и дорого, наоборот, могло вас спасать от некомпетентности.
👉У большинства ваших сотрудников нет особой мотивации быть суперпродуктивными и выкладываться на благо компании. Как и любые разумные люди, они работают 9-5, и идут домой к семье и своим делам.
👉Для нормальных людей польза от AI не в том, чтобы быть 10х эффективнее, закрывая продуктовый бэклог, а в том, чтобы тратить меньше своей ценной энергии.
👉Те несколько людей, которые действительно хотели свернуть горы, вместо этого сидят и ревьюят AI слоп, который нагенерировали все остальные, и постепенно выгорают.
👉И на фоне всего этого ваш финансовый директор постепенно начинает задавать вопросы про то, как так получилось, что все инженеры теперь стоят на несколько тысяч долларов дороже из-за токенов, которые они прожигают.

Почему быстро выпускать новые фичи – это плохо

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

В итоге, ускоряя команду, вы на самом деле создаете невидимый бэклог фич, которые сделаны, но не используются, растягиваете time-to-value, ну и постепенно роняете качество.

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

Как правильно отдыхать

Отдых – это не награда за какие-то действия, это часть полноценной и насыщенной жизни.

У меня лично с этим тезисом очень сложно – мне очень сложно прямо отдыхать-отдыхать, и я обычно имитирую это переключением между разными видами деятельности. Условно говоря, чтобы отдохнуть от работы, занимаюсь какими-то подкастными делами, или сажусь пописать код. Если вместо этого я трачу время "бесполезно" – я быстро начинаю чувствовать очень изматывающее чувство вины. Никому не рекомендую, сказывается на мне не очень хорошо. Я очень активно пытаюсь бороться с таким восприятием отдыха, но прогресс пока ниже среднего.

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

Я запускаю закрытый клуб про AI в разработке

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

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

👉Как это вообще работает. Каждую неделю – воркшопы и лайвкодинг с людьми, которые активно используют AI, и внедряют его в реальные продукты и компании. Разбор конкретных инженерных практик: как строить своих агентов, как работать по Spec-Driven Development, как собирать комбайн, превращающий таски в Jira в PRы, как масштабировать это и на небольшую команду, и на всю разработку в бигтехе.

Между встречами – сеть закрытых чатов в Telegram, клубные созвоны, совместные эксперименты.

👉Кто уже в программе. Черновое расписание на март-апрель собрано. Среди экспертов – инженеры из компаний разного масштаба: Степан Гончаров (xAI), Роман Елизаров (Яндекс), Андрей Володин (Gracia AI), Андрей Бреслав (CodeSpeak), Денис Неклюдов (Google), Макс Страхов (Meta) и много других крутых ребят.

👉Как попасть. Клуб платный, вход через список ожидания с отбором – нам интересно сделать сообщество именно для опытных разработчиков. Мы набираем участников постепенно – нам важно сохранить атмосферу, в которой можно открыто делиться опытом и проблемами. Стартуем уже с понедельника!

Отдельно подчеркну, что клуб делаем именно для инженеров – людей, которые большую часть своей карьеры писали код, решали технические задачи, принимали архитектурные решения, и жили с их последствиями. Я знаю, что на канал подписано довольно много технических менеджеров, и senior/staff/principal инженеров – вот этот анонс для вас!

Подробности, расписание и заявка – на сайте. А если есть какие-то конкретные вопросы, пишите прямо мне в личку, @etolstoy!

Про влияние тренировок на менталочку

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

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

Текст стал дешевым, и мы к этому не готовы

Управление большими корпорациями всегда строилось на довольно простом принципе – если что-то важно, это надо записать. Написать хороший связный разумный текст было сложно. Это требовало понимания проблемы, усидчивости, и, главное, это требовало от человека подумать. Текст работал как фильтр – если кто-то его написал, то скорее всего мысли, изложенные там, имеет смысл прочитать.

Генеративный AI все изменил. Текст любой длины можно сгенерировать за секунды, и само наличие письменного артефакта вообще не гарантирует, что кто-то туда вложил хоть частицу разумности.

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

Что конкретно с этим делать, пока не очень понятно. Автор поста предлагает развилку с двумя вариантами:

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

Amazon переводит стрелки с AI на людей

У Amazon за последнее время произошло несколько крупных падений, и как минимум в одном из них точно был замешан AI. Разработчик случайно оказался в продовом окружении вместо тестового, Kiro дернул команду не с теми флагами, и один из сервисов после этого лег. AWS во всех пресс-релизах после этого пытается всячески уйти от ассоциаций с AI, и говорит о том, что это человеческая ошибка – а в интернете на это смотрят как на попытку защищать AI.

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

Организации оптимизируют под комфорт

Любая система стремится оставаться в состоянии покоя. С инженерными организациями ситуация такая же. Они оптимизируют работу не под техническую корректность, а под комфорт.

Почему так происходит:

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