Добрый день! Был большой перерыв в публикациях. Связан напрямую с темой сегодняшней заметки.

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

• Структура команды:

• Состав команды;
• Иерархия и зона ответственности, репортинг;
• Контактные лица у заказчика / в соседних командах / у вендора.
  

• Бизнес-требования, стараюсь получить доступ к:

• Описанию бизнес-требований;
• Пользовательской документации;
• Тест-кейсам.
  

• Исходный код:

• Адреса репозиториев;
• Создание учетных записей со всеми правами;
• Получение всех конфигурационных скриптов и требований для рабочих станций разработчиков;
• По возможности создание автоматических скриптов развертки окружения либо же создание образов систем – чтобы не тратить драгоценное время разработчиков.
  

• Техническая документация:

• Архитектура системы;
• Архитектура подсистем;
• Архитектура с точки зрения технических примитивов;
• Архитектура с точки зрения бизнес-задач, use cases;
• Технический долг команды;
• Все технические изыскания и предложения по существующей системе;
• Возможно провести эксперимент, и новой команде дать задание создать «выкройку» системы с целью выделить инфраструктурные компоненты, обеспечивающие работоспособность системы, а также наложить на это бизнес-требования – по своему опыту - народ въезжает в проект быстрее.
  

• Система поставки и окружения:

• Сервера CI/CD;
• Тестовая инфраструктура;
• Варианты сборок.
  

• Информационные системы, очень важны:

• Система обработки пользовательских запросов;
• Система bug-трекинга;
• Система хранения знаний / информационный портал;
• Система мониторинга;
• Система аналитики пользовательских действий;
• Очень важно выявить контактных лиц по всем вопросам, связанных с каждой системой;
• А также все процедуры и церимонималы: flow-обработки пользовательского запроса; flow-согласования новой технической документации.
  

Процессы и список лиц, принимающих решения (ЛПР):

• Процедуры и список ЛПР, связанных с ежедневными рутинами;
• Процедуры и список ЛПР, связанных с закрытием спринта / итерации / этапа работ;
• Процедуры и список ЛПР, связанных с планированием нового релиза / итерации;
• Процедуры, связанные с обработкой Change Requests, и список ЛПР;
• Процедуры и церимониалы, связанные с выпуском нового релиза.
  

Тестирование, команда качества:

• Необходимо получить доступ ко всем базам тестовых сценариев;
• Необходимо получить описание процедур выпуска релизов.
  

Учетные записи – выделяю отдельно, чтобы не потерялись:

• Тестовые / стейджинг / продакшн пользовательские учетные записи для тестирования продукта;
• Учетки в системы аналитики / системы вендоров / партнеров.
  

Поле деятельности:

• План работ;
• Роадмап;
• Целеполагание с технической точки зрения;
• Целеполагание с точки зрения продукта.
  

Третьесторонние сервисы, вендоры, партнеры:

• Доступ ко всем третьесторонним системам в правах администратора – для возможности добавлять своих пользователей;
• Контакты всех вендоров и партнеров, их ЛПР, график взаимодействия с ними, структура их команды, зон ответственности, а также краткое описание предметной области взаимодействия и целей команды.
  

Цели – очень важный раздел:

• Что требуется от команды разработки, тестирования, поддержки;
• Какие задачи стоят перед новой командой.
  

Конечно же современные фреймворки ведения разработки крайне помогают в ведении проекта, и в целом все церемониалы и роли в команде известны, но мир не идеален, поэтому лучше разобраться в деятельности команды от начала и до конца.
Стоит заметить, что лучше всего получается провести KT, когда возможно параллельно держать 2 команды, тогда возможно всей команде постепенно влиться в процесс разработки, разобраться совместно с носителями знаний с конфигурированием систем, процессными системами – к примеру с JIRA: разобраться с жизненным циклом дефекта и т.д.

Если команда работает по Scrum или Scrumban, я рекомендую провести 1-2 спринта с соблюдением всех церемониалов: planning, groomings, triage, retrospectives, demos.

В целом все, спасибо за внимание!