Помогают ли дэйлики

Держите результаты интересного рисерче по одной из наших любимых холиварных тем:

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

Я пробежался по другим бумагам, прямо хорошего мета-анализа нет, но нет и каких-то опровергающих исследований. Так что, коллеги, встречаемся в понедельник в 9 утра на 15 минутный созвон!

Главные уязвимости агентских приложений

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

1️⃣Подмена цели – атакующий манипулирует тем, какие задачи преследует агент, или тем, как он принимает решения.
2️⃣Эксплойты тулов – агент оперирует в изначально установленных пользователем рамках, но использует один из предоставленных ему тулов не так, как предполагалось – например, для удаления ценной информации, вызова дорогого API, выборочной передачи приватной информации.
3️⃣Абьюз систем IAM – здесь много всего, начиная от использования привилегий агента в злонамеренных целях, заканчивая кражей учетных данных.
4️⃣Уязвимости цепочек поставок – тоже большой класс уязвимостей, к которому можно отнести как дырки, заложенные в веса моделей или логику агентов, так и взлом через установку агентом скомпрометированных библиотек в ваши приложения.
5️⃣Выполнение небезопасного кода – то самое, что в первую очередь приходит на ум. Агент пишет код, вы его исполняете, а где-то в нем оказывается написана логика по выдаче рутового доступа к вашему серверу кому-то со стороны.

Как менять поведение систем

Донелла Медоуз – автор очень известной книги про системное мышление "Thinking in Systems". Есди вы ее не читали, то вот это ставшее уже классическим эссе про то, какие рычаги для изменения поведения систем существуют, даст довольно хорошее представление о материале.

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

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

👉Не переизобретайте колесо и берите готовые библиотеки. На самом деле, это трейд-офф, на другой стороне которого – ценность хорошего понимания кода, и безопасность от 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.
👉Эффект Рингельмана – чем сильнее растет группа, тем сильнее снижается продуктивность отдельных ее участников.