AI делает разработчика быстрее.
Но вместе со скоростью он добавляет новую ответственность: управлять тем, что ты просишь у модели, и отвечать за то, что потом попадёт в продукт.
Похоже, в эпоху AI хороший разработчик — это уже не только тот, кто умеет писать код.
Это тот, кто умеет руководить маленьким очень быстрым, очень уверенным и иногда очень ошибающимся помощником.
И, возможно, это главный навык, который командам придётся прокачивать дальше: не просто “уметь пользоваться AI”, а уметь ставить ему задачи, проверять результат и не терять инженерное мышление по дороге.
Потому что AI может написать код за тебя.
Но ответственность за этот код всё равно останется на тебе.
А у вас в команде уже обсуждали правила для AI-кода или пока каждый использует как привык?
Но вместе со скоростью он добавляет новую ответственность: управлять тем, что ты просишь у модели, и отвечать за то, что потом попадёт в продукт.
Похоже, в эпоху AI хороший разработчик — это уже не только тот, кто умеет писать код.
Это тот, кто умеет руководить маленьким очень быстрым, очень уверенным и иногда очень ошибающимся помощником.
И, возможно, это главный навык, который командам придётся прокачивать дальше: не просто “уметь пользоваться AI”, а уметь ставить ему задачи, проверять результат и не терять инженерное мышление по дороге.
Потому что AI может написать код за тебя.
Но ответственность за этот код всё равно останется на тебе.
А у вас в команде уже обсуждали правила для AI-кода или пока каждый использует как привык?
❤3💯1
Команда не должна читать мысли тимлида
Одна из частых ошибок руководителя — держать ожидания у себя в голове.
Как будто команда каким-то магическим образом должна сама понять:
— что для тебя важно;
— как ты относишься к срокам;
— чего ждёшь от 1:1;
— когда нужно эскалировать проблему;
— что для тебя значит ownership;
— где у команды свобода, а где красная линия.
А потом начинается классика жанра.
Тимлид раздражается:
«Ну это же очевидно».
Команда удивляется:
«А откуда мы должны были это знать?»
И все дружно играют в корпоративную версию “угадай мелодию”, только вместо мелодии — невысказанные ожидания менеджера.
В статье How to make your team read your mind Anton Zaides пишет про идею Manager’s ReadMe — документа, в котором руководитель описывает, как с ним работать и чего он ждёт от команды.
Не для того, чтобы повесить это на стену как конституцию маленького офиса.
А чтобы убрать туман.
Что туда можно включить:
— роль тимлида в команде;
— как проходят 1:1;
— ожидания по коммуникации;
— правила доступности в рабочее и нерабочее время;
— отношение к планированию и оценкам;
— что значит владеть фичей;
— как команда должна поднимать проблемы;
— какие решения можно принимать самостоятельно.
Мне нравится в этой идее не сам документ, а принцип.
Если ожидание не проговорено, странно требовать его выполнения.
Да, опытные люди многое считывают по контексту.
Да, культура команды постепенно формируется через действия.
Да, не всё нужно регламентировать до уровня “как правильно дышать в Jira”.
Но есть большая разница между живой культурой и набором скрытых правил, которые человек узнаёт только после ошибки.
Manager’s ReadMe помогает сделать ожидания видимыми.
И заодно заставляет самого тимлида подумать:
— я правда так считаю?
— я сам соблюдаю эти правила?
— команда это знает?
— это помогает работе или просто отражает мои личные заморочки?
Последний пункт особенно неприятный, поэтому обычно самый полезный.
Важно: такой документ не должен звучать как ультиматум.
Скорее как черновик договора:
«Вот как я сейчас вижу нашу работу. Давайте обсудим, где это полезно, где спорно, а где я сам себе придумал красивую управленческую галлюцинацию».
Потому что цель не в том, чтобы команда идеально подстроилась под тимлида.
Цель — чтобы у людей было меньше поводов тратить силы на угадывание правил игры.
А больше — на саму работу.
Статья: https://zaidesanton.substack.com/p/how-to-make-your-team-read-your-mind
Одна из частых ошибок руководителя — держать ожидания у себя в голове.
Как будто команда каким-то магическим образом должна сама понять:
— что для тебя важно;
— как ты относишься к срокам;
— чего ждёшь от 1:1;
— когда нужно эскалировать проблему;
— что для тебя значит ownership;
— где у команды свобода, а где красная линия.
А потом начинается классика жанра.
Тимлид раздражается:
«Ну это же очевидно».
Команда удивляется:
«А откуда мы должны были это знать?»
И все дружно играют в корпоративную версию “угадай мелодию”, только вместо мелодии — невысказанные ожидания менеджера.
В статье How to make your team read your mind Anton Zaides пишет про идею Manager’s ReadMe — документа, в котором руководитель описывает, как с ним работать и чего он ждёт от команды.
Не для того, чтобы повесить это на стену как конституцию маленького офиса.
А чтобы убрать туман.
Что туда можно включить:
— роль тимлида в команде;
— как проходят 1:1;
— ожидания по коммуникации;
— правила доступности в рабочее и нерабочее время;
— отношение к планированию и оценкам;
— что значит владеть фичей;
— как команда должна поднимать проблемы;
— какие решения можно принимать самостоятельно.
Мне нравится в этой идее не сам документ, а принцип.
Если ожидание не проговорено, странно требовать его выполнения.
Да, опытные люди многое считывают по контексту.
Да, культура команды постепенно формируется через действия.
Да, не всё нужно регламентировать до уровня “как правильно дышать в Jira”.
Но есть большая разница между живой культурой и набором скрытых правил, которые человек узнаёт только после ошибки.
Manager’s ReadMe помогает сделать ожидания видимыми.
И заодно заставляет самого тимлида подумать:
— я правда так считаю?
— я сам соблюдаю эти правила?
— команда это знает?
— это помогает работе или просто отражает мои личные заморочки?
Последний пункт особенно неприятный, поэтому обычно самый полезный.
Важно: такой документ не должен звучать как ультиматум.
Скорее как черновик договора:
«Вот как я сейчас вижу нашу работу. Давайте обсудим, где это полезно, где спорно, а где я сам себе придумал красивую управленческую галлюцинацию».
Потому что цель не в том, чтобы команда идеально подстроилась под тимлида.
Цель — чтобы у людей было меньше поводов тратить силы на угадывание правил игры.
А больше — на саму работу.
Статья: https://zaidesanton.substack.com/p/how-to-make-your-team-read-your-mind
❤3
RACI: как понять, кто за что отвечает, пока всё не развалилось
Есть неприятный момент в командной работе.
Пока всё идёт нормально, кажется, что все всё понимают.
Кто делает задачу.
Кто принимает решение.
Кого надо спросить.
Кого просто поставить в курс дела.
А потом что-то ломается.
Задача зависает.
Релиз едет.
Решение не принято.
Баг всплыл уже на проде.
Бизнес спрашивает: “А кто за это отвечает?”
И внезапно в комнате становится очень тихо.
Потому что “мы же все договорились” часто означает “каждый понял договорённость по-своему”.
Вот тут полезен RACI.
Не как большая бюрократическая табличка на 40 строк, которую никто не откроет после встречи.
А как простой способ заранее проговорить роли.
RACI — это четыре вопроса:
R — Responsible
Кто реально делает работу?
A — Accountable
Кто отвечает за итоговое решение и результат?
C — Consulted
С кем надо посоветоваться до решения?
I — Informed
Кого нужно просто держать в курсе?
На бумаге звучит очевидно.
В жизни именно на этом часто всё и ломается.
Например, команда делает новую фичу.
Разработчик пишет код.
Аналитик уточняет требования.
QA проверяет.
Тимлид помогает с техническими решениями.
Продакт ждёт результат.
Бизнес хочет “чтобы к пятнице”.
И вроде бы все участвуют.
Но кто принимает финальное решение, можно ли резать скоуп?
Кто отвечает за то, что требования достаточно понятны?
Кого надо обязательно спросить перед изменением поведения?
Кого достаточно просто предупредить?
Если это не проговорить, начинаются знакомые симптомы:
— “я думал, это продакт решает”
— “я ждал подтверждения от аналитика”
— “мы не знали, что это важно для поддержки”
— “почему нас не позвали на обсуждение?”
— “а кто вообще должен был это проверить?”
RACI хорош тем, что быстро подсвечивает серые зоны.
Особенно в местах, где много пересечений:
— релизы
— инциденты
— технический долг
— изменения требований
— интеграции между командами
— найм
— онбординг
— production-ready критерии
— спорные продуктовые решения
Самая частая ошибка — путать Responsible и Accountable.
Responsible — делает.
Accountable — отвечает за итог.
Например, разработчик может быть Responsible за реализацию задачи.
Но Accountable за техническое решение может быть тимлид или техлид.
Или QA может быть Responsible за проверку сценариев.
Но Accountable за качество релиза всё равно может быть команда целиком или конкретный владелец релиза.
Ещё одна ошибка — назначать слишком много Accountable.
Если за итог “отвечают все”, часто не отвечает никто.
В RACI на одну активность лучше иметь одного Accountable.
Не потому что остальные не важны.
А потому что в спорный момент должно быть понятно, кто принимает финальное решение.
И наоборот: Consulted не должен превращаться в “давайте согласуем со всеми”.
Если каждого человека делать обязательным участником решения, процесс быстро встанет.
Иногда человеку достаточно быть Informed: знать, что решение принято, но не блокировать его.
Для тимлида RACI полезен не тем, что добавляет ещё одну управленческую модель.
Он полезен тем, что помогает задавать простые вопросы до того, как начался пожар:
Кто делает?
Кто принимает финальное решение?
Кого надо спросить заранее?
Кого просто предупредить?
Я бы не стал тащить RACI на каждую маленькую задачу.
Но если задача пересекает несколько ролей, команд или зон ответственности, 10 минут на такую раскладку могут сэкономить несколько дней переписок потом.
Мини-упражнение на завтра:
возьмите одну текущую задачу, которая уже начала буксовать, и попробуйте разложить её по RACI.
Не идеально.
Просто честно.
Кто сейчас Responsible?
Кто Accountable?
Кого почему-то не спросили?
Кого, наоборот, зря держат в согласовании?
Очень часто уже на этом этапе становится понятно, почему задача стоит.
Не потому что люди плохо работают.
А потому что команда не договорилась, кто за что отвечает.
А у вас в команде роли обычно проговорены заранее или выясняются уже в момент пожара?
Есть неприятный момент в командной работе.
Пока всё идёт нормально, кажется, что все всё понимают.
Кто делает задачу.
Кто принимает решение.
Кого надо спросить.
Кого просто поставить в курс дела.
А потом что-то ломается.
Задача зависает.
Релиз едет.
Решение не принято.
Баг всплыл уже на проде.
Бизнес спрашивает: “А кто за это отвечает?”
И внезапно в комнате становится очень тихо.
Потому что “мы же все договорились” часто означает “каждый понял договорённость по-своему”.
Вот тут полезен RACI.
Не как большая бюрократическая табличка на 40 строк, которую никто не откроет после встречи.
А как простой способ заранее проговорить роли.
RACI — это четыре вопроса:
R — Responsible
Кто реально делает работу?
A — Accountable
Кто отвечает за итоговое решение и результат?
C — Consulted
С кем надо посоветоваться до решения?
I — Informed
Кого нужно просто держать в курсе?
На бумаге звучит очевидно.
В жизни именно на этом часто всё и ломается.
Например, команда делает новую фичу.
Разработчик пишет код.
Аналитик уточняет требования.
QA проверяет.
Тимлид помогает с техническими решениями.
Продакт ждёт результат.
Бизнес хочет “чтобы к пятнице”.
И вроде бы все участвуют.
Но кто принимает финальное решение, можно ли резать скоуп?
Кто отвечает за то, что требования достаточно понятны?
Кого надо обязательно спросить перед изменением поведения?
Кого достаточно просто предупредить?
Если это не проговорить, начинаются знакомые симптомы:
— “я думал, это продакт решает”
— “я ждал подтверждения от аналитика”
— “мы не знали, что это важно для поддержки”
— “почему нас не позвали на обсуждение?”
— “а кто вообще должен был это проверить?”
RACI хорош тем, что быстро подсвечивает серые зоны.
Особенно в местах, где много пересечений:
— релизы
— инциденты
— технический долг
— изменения требований
— интеграции между командами
— найм
— онбординг
— production-ready критерии
— спорные продуктовые решения
Самая частая ошибка — путать Responsible и Accountable.
Responsible — делает.
Accountable — отвечает за итог.
Например, разработчик может быть Responsible за реализацию задачи.
Но Accountable за техническое решение может быть тимлид или техлид.
Или QA может быть Responsible за проверку сценариев.
Но Accountable за качество релиза всё равно может быть команда целиком или конкретный владелец релиза.
Ещё одна ошибка — назначать слишком много Accountable.
Если за итог “отвечают все”, часто не отвечает никто.
В RACI на одну активность лучше иметь одного Accountable.
Не потому что остальные не важны.
А потому что в спорный момент должно быть понятно, кто принимает финальное решение.
И наоборот: Consulted не должен превращаться в “давайте согласуем со всеми”.
Если каждого человека делать обязательным участником решения, процесс быстро встанет.
Иногда человеку достаточно быть Informed: знать, что решение принято, но не блокировать его.
Для тимлида RACI полезен не тем, что добавляет ещё одну управленческую модель.
Он полезен тем, что помогает задавать простые вопросы до того, как начался пожар:
Кто делает?
Кто принимает финальное решение?
Кого надо спросить заранее?
Кого просто предупредить?
Я бы не стал тащить RACI на каждую маленькую задачу.
Но если задача пересекает несколько ролей, команд или зон ответственности, 10 минут на такую раскладку могут сэкономить несколько дней переписок потом.
Мини-упражнение на завтра:
возьмите одну текущую задачу, которая уже начала буксовать, и попробуйте разложить её по RACI.
Не идеально.
Просто честно.
Кто сейчас Responsible?
Кто Accountable?
Кого почему-то не спросили?
Кого, наоборот, зря держат в согласовании?
Очень часто уже на этом этапе становится понятно, почему задача стоит.
Не потому что люди плохо работают.
А потому что команда не договорилась, кто за что отвечает.
А у вас в команде роли обычно проговорены заранее или выясняются уже в момент пожара?
🔥2