;
Иван Алякскин

Чек-лист для Knowledge Transfer

15.05.2017 4278
IBS Training Center Telegram
Подписывайтесь на наш канал в Telegram:
больше материалов экспертов, анонсы бесплатных вебинаров и задачки для IT-специалистов
Подписаться
Добрый день! Был большой перерыв в публикациях. Связан напрямую с темой сегодняшней заметки.

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

• Структура команды:
  • Состав команды;
  • Иерархия и зона ответственности, репортинг;
  • Контактные лица у заказчика / в соседних командах / у вендора.
• Бизнес-требования, стараюсь получить доступ к:
  • Описанию бизнес-требований;
  • Пользовательской документации;
  • Тест-кейсам.
• Исходный код:
  • Адреса репозиториев;
  • Создание учетных записей со всеми правами;
  • Получение всех конфигурационных скриптов и требований для рабочих станций разработчиков;
  • По возможности создание автоматических скриптов развертки окружения либо же создание образов систем – чтобы не тратить драгоценное время разработчиков.
• Техническая документация:
  • Архитектура системы;
  • Архитектура подсистем;
  • Архитектура с точки зрения технических примитивов;
  • Архитектура с точки зрения бизнес-задач, use cases;
  • Технический долг команды;
  • Все технические изыскания и предложения по существующей системе;
  • Возможно провести эксперимент, и новой команде дать задание создать «выкройку» системы с целью выделить инфраструктурные компоненты, обеспечивающие работоспособность системы, а также наложить на это бизнес-требования – по своему опыту - народ въезжает в проект быстрее.
• Система поставки и окружения:
  • Сервера CI/CD;
  • Тестовая инфраструктура;
  • Варианты сборок.
• Информационные системы, очень важны:
  • Система обработки пользовательских запросов;
  • Система bug-трекинга;
  • Система хранения знаний / информационный портал;
  • Система мониторинга;
  • Система аналитики пользовательских действий;
  • Очень важно выявить контактных лиц по всем вопросам, связанных с каждой системой;
  • А также все процедуры и церимонималы: flow-обработки пользовательского запроса; flow-согласования новой технической документации.
Процессы и список лиц, принимающих решения (ЛПР):
  • Процедуры и список ЛПР, связанных с ежедневными рутинами;
  • Процедуры и список ЛПР, связанных с закрытием спринта / итерации / этапа работ;
  • Процедуры и список ЛПР, связанных с планированием нового релиза / итерации;
  • Процедуры, связанные с обработкой Change Requests, и список ЛПР;
  • Процедуры и церимониалы, связанные с выпуском нового релиза.
Тестирование, команда качества:
  • Необходимо получить доступ ко всем базам тестовых сценариев;
  • Необходимо получить описание процедур выпуска релизов.
Учетные записи – выделяю отдельно, чтобы не потерялись:
  • Тестовые / стейджинг / продакшн пользовательские учетные записи для тестирования продукта;
  • Учетки в системы аналитики / системы вендоров / партнеров.
Поле деятельности:
  • План работ;
  • Роадмап;
  • Целеполагание с технической точки зрения;
  • Целеполагание с точки зрения продукта.
Третьесторонние сервисы, вендоры, партнеры:
  • Доступ ко всем третьесторонним системам в правах администратора – для возможности добавлять своих пользователей;
  • Контакты всех вендоров и партнеров, их ЛПР, график взаимодействия с ними, структура их команды, зон ответственности, а также краткое описание предметной области взаимодействия и целей команды.
Цели – очень важный раздел:
  • Что требуется от команды разработки, тестирования, поддержки;
  • Какие задачи стоят перед новой командой.
Конечно же современные фреймворки ведения разработки крайне помогают в ведении проекта, и в целом все церемониалы и роли в команде известны, но мир не идеален, поэтому лучше разобраться в деятельности команды от начала и до конца.
Стоит заметить, что лучше всего получается провести KT, когда возможно параллельно держать 2 команды, тогда возможно всей команде постепенно влиться в процесс разработки, разобраться совместно с носителями знаний с конфигурированием систем, процессными системами – к примеру с JIRA: разобраться с жизненным циклом дефекта и т.д.

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

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



Расскажи друзьям:

Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!
Спасибо.
Вы подписаны на ежемесячный дайджест.
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.