Как управлять IT-командами на удалёнке — системно и через людей.
Работаю с существующими командами и собираю новые. Процессы под контекст.
EM, 10+ лет управления командами.
Ментор: getmentor.dev/mentor/andrey-nechaev-6317
Связь: @a2nechaev
Post #378
339
♟ Передача знаний в сжатые сроки
Итак, у нас уходит человек с бас-фактором — единичка. На то, чтобы забрать знания из его головы, у нас две недели. Проект пусть будет большой, иначе это и не проблема вообще.
После попыток остановить эту подставу вливанием дополнительных финансовых средств в семейный бюджет сотрудника, этапа «ёб твою мать, мы в жопе» и мимолётной мысли уволиться вслед за ним переходим к этапу рационального решения проблемы.
Мы на стадии принятия, и принять нужно будет следующее:
☝️Это невозможно.
✌️Сроки по этому проекту поедут, ну или хотя бы задачи по нему будут делаться дольше обычного (возможно, в разы).
🤟Надеяться, что уходящий сотрудник самостоятельно качественно передаст знания, так же наивно, как верить в Деда Мороза (он уже мысленно получает похвальный лист на новой работе).
А дальше мы начинаем собирать процесс онбординга в проект на коленке. Всё передать мы не можем, но вполне реально верхнеуровнево погрузить в него и довольно быстро.
Что нам для этого понадобится:
1. Необходимые доступы для работы над проектом.
2. Информация о том, как разворачивать эту систему.
3. Верхнеуровневый продуктовый обзор этого функционала (что он вообще делает, для кого, какие есть основные возможности).
4. Понимание процессов работы над этим проектом.
5. Верхнеуровневое погружение в архитектуру проекта (где что лежит, где точка входа…).
6. Сотрудник, который будет в состоянии перенять работу. Если в проекте полно легаси, то передавать его джуну нет никакого смысла — он не вывезет.
Эти пункты можно (как будто у нас есть выбор) организовать в первые три дня.
Так как получение знаний — это только часть процесса, нам нужно организовать практику. Это обязательно. Оставшееся время тратим на выполнение задач по проекту.
Вспоминаем о том, что нам может помочь:
👉 Парное программирование. Передаём навыки работы с проектом на практике. Хорошо подойдут баги и решение вопросов поддержки.
👉 ИИ. Правильный запрос к бездушной машине поможет организовать базовую информацию по проекту. Например, можно вдохновиться DevEx-практикой с помощью ИИ: https://t.me/teamleadonline/328
Также не забываем сообщить стейкхолдерам об этой ситуации и предупредить о последствиях.
Обнял, разложил по полочкам. — Нечаев
#системы@teamleadonline
Telegram Тимлид на удалёнке ✱ Андрей Нечаев Сегодня дропну книгу Артема Мухина по Claude Code с точки зрения DX-инженера.
Чтиво увлекательное, приведу несколько зашедших мне цитат:
Всё, что можно сделать кодом - делай кодом. 80% hooks и скрипты, 20% AI.
AI усиливает, не чинит. Плохие процессы +… Про процесс передачи знаний нужен отдельный пост. Не просто за 2 недели даже понять, что надо передать. Тем более передать столько данных.
Итак, у нас уходит человек с бас-фактором — единичка. На то, чтобы забрать знания из его головы, у нас две недели. Проект пусть будет большой, иначе это и не проблема вообще.
После попыток остановить эту подставу вливанием дополнительных финансовых средств в семейный бюджет сотрудника, этапа «ёб твою мать, мы в жопе» и мимолётной мысли уволиться вслед за ним переходим к этапу рационального решения проблемы.
Мы на стадии принятия, и принять нужно будет следующее:
☝️Это невозможно.
✌️Сроки по этому проекту поедут, ну или хотя бы задачи по нему будут делаться дольше обычного (возможно, в разы).
🤟Надеяться, что уходящий сотрудник самостоятельно качественно передаст знания, так же наивно, как верить в Деда Мороза (он уже мысленно получает похвальный лист на новой работе).
А дальше мы начинаем собирать процесс онбординга в проект на коленке. Всё передать мы не можем, но вполне реально верхнеуровнево погрузить в него и довольно быстро.
Что нам для этого понадобится:
1. Необходимые доступы для работы над проектом.
2. Информация о том, как разворачивать эту систему.
3. Верхнеуровневый продуктовый обзор этого функционала (что он вообще делает, для кого, какие есть основные возможности).
4. Понимание процессов работы над этим проектом.
5. Верхнеуровневое погружение в архитектуру проекта (где что лежит, где точка входа…).
6. Сотрудник, который будет в состоянии перенять работу. Если в проекте полно легаси, то передавать его джуну нет никакого смысла — он не вывезет.
Эти пункты можно (как будто у нас есть выбор) организовать в первые три дня.
Так как получение знаний — это только часть процесса, нам нужно организовать практику. Это обязательно. Оставшееся время тратим на выполнение задач по проекту.
Вспоминаем о том, что нам может помочь:
👉 Парное программирование. Передаём навыки работы с проектом на практике. Хорошо подойдут баги и решение вопросов поддержки.
👉 ИИ. Правильный запрос к бездушной машине поможет организовать базовую информацию по проекту. Например, можно вдохновиться DevEx-практикой с помощью ИИ: https://t.me/teamleadonline/328
Также не забываем сообщить стейкхолдерам об этой ситуации и предупредить о последствиях.
Обнял, разложил по полочкам. — Нечаев
#системы@teamleadonline
- 👍 7
- 🤔 1





