Как аналитику быстро освоиться на новом проекте

1. Что нужно понять про проект в первую очередь и как это сделать?
2. В чём разница между новым, действующим и «горящим» проектом?
3. С чего начинать изучение документации и как её категоризировать?
4. Что делать, если документации слишком много или слишком мало?
5. Что нужно знать про работу команды и для чего?
6. Чек-лист погружения в новый проект.

К сожалению, невозможно освоиться на новом проекте по щелчку пальцев, но при грамотном подходе этот процесс можно ускорить. На быстроту и комфортность погружения в проект влияют три основных фактора.

1. Время — оно необходимо даже опытному специалисту для того, чтобы изучить, и структурировать всю информацию о новом проекте.
   
   
2. Желание новичка — от способности нового члена команды адаптироваться к новым условиям, от приложенных сил, любознательности и активности напрямую зависит скорость и качество интеграции.
   
   
3. Желание команды — изучение чего-то нового всегда сопровождается большим количеством вопросов. Чем быстрее ответы на вопросы будут получены, тем быстрее новичок станет полноценной частью команды и начнёт приносить пользу. Для этого команда должна осознанно выделять отдельные ресурсы на интеграцию нового сотрудника: обеспечивать доступность документации, помогать в поиске источников информации, давать возможность обсуждать непонятные моменты.

Ниже детально разберём основные аспекты погружения, применимые для новых и действующих проектов. «Горящие» проекты рассмотрим отдельно.

Планируя свою адаптацию, выделяйте два больших блока:

1. Предметная область в широком смысле слова и продукт / система, которую вы разрабатываете, развиваете или поддерживаете
   
2. Команда, в которой вы работаете
   

Что необходимо сделать, чтобы лучше понимать новых коллег:

1. Попросите словарь терминов и сокращений у непосредственного руководителя. В большинстве проектов какой-то глоссарий всё же ведётся. Скорее всего вы не найдёте там каких-то жаргонных слов, но официальные термины должны быть.
   
   
2. Составьте глоссарий. Если так случилось, что глоссария на проекте нет, то составляйте список непонятных слов и сокращений и идите с ним к наставнику или руководителю.
   
   
3. Спрашивайте у коллег непонятные вещи. Чем вы быстрее поймёте разницу, например, в сокращениях, тем вам легче будет ориентироваться в том, что происходит.
   
   
4. Обновляйте глоссарий, если в ходе изучения становится понятно, что в нём чего-то не хватает. Актуальная информация пригодится не только вам, но и следующим новичкам.
   

Где ещё можно найти информацию о предметной области?

1. Определите экспертов по бизнесу, которые есть в вашей компании. Выясните у них цели системы, контекст создания, сильные и слабые стороны.
   
   
2. Ищите различные документы, презентации, видео, где может быть описание бизнеса, в котором автоматизируют систему.
   
   
3. Интернет-сёрфинг — не самый хороший способ поиска информации в данном случае, но если эксперт вам не доступен и документов найти не удалось, то сёрфинг может помочь получить хоть какую-то информацию. Поскольку мы создаём по большей части не уникальные системы, есть вероятность, что подобное что-то уже создано и даже описано. Начните со статей про аналогичные системы и тех, где хороши раскрыты базовые термины.
   

В этом пункте рассмотрим ситуацию, когда система делается «на словах», без официальных документов и, возможно даже, без задач в таск-трекере. Это довольно распространённая ситуация на «горящих» проектах или на «горящих» этапах проектов. Что делать в этом случае?

1. Экспертиза коллег. Задавайте вопросы наставнику, коллегам, эксперту для выяснения необходимой информации. В нормальной ситуации тот, кто будет давать задачи, будет заинтересован, чтобы вы сделали их качественно.
   
2. Таск-трекер. Пользуйтесь поиском и смотрите задачи на интересующую тему. Например, чтобы дополнить деталями рассказ эксперта.
   
3. Чаты и письма. Изучайте чаты, к которым вас подключили, запросите у коллег письма, содержащие информацию о системе.
   
4. Ваш ИТ-продукт. Запустите систему и попытайтесь изучить, как она работает (если она уже существует). Если в системе ведётся логирование или аудит действий пользователей, то можно посмотреть их журналы: по ним можно понять частоту выполнения действий, порядок выполнения, время работы.
   

Документации слишком много и непонятно что актуально, а что нет. В данном случае придётся поработать над анализом документации.

• Уточните у руководителя / наставника что смотреть и в каком порядке.
• Посоветуйтесь с коллегами рядом.
• Попытайтесь разобраться самостоятельно. К этому пункту приступаем, если в предыдущих не получили помощи. Иначе вы можете потратить слишком много времени зря.

1. Важное / неважное
   
2. Старое / новое
   
3. По типу документов:
   

Советы по категоризации

• Смотрите даты создания документов, даты последнего редактирования, количества правок, просмотров — нам может помочь любая опорная информация, по которой мы можем понять насколько документ «живой». Подсказка: если проект длительный, то концептуальная документация должна была быть написана на начальных этапах проекта.
  
  
• Найдите документы, которые содержат изначальный замысел — концептуальную документацию. Ищем по ключевым словам: техническое задание / ТЗ, концепция, vision, scope, архитектура, концепция, цели.
  
  
• Ищите планы проекта, вехи проекта, roadmap. В них вы увидите порядок реализации разных блоков задач, временные диапазоны / трудоёмкость. Это поможет оценить важность какого-то блока системы.

• Смотрите на наименования документов, структуру папок, категории Wiki, пространства Confluence, теги — всё, что задаёт структуру и иерархичность документов. Возможно, есть какой-то шаблон в наименованиях, пример, «Проектное решение № 3…». Сразу понятна последовательность создания таких документов.
  
  
• Отделяйте актуальную документацию от неактуальной. Пожалуй, это самый сложный пункт. Хорошо, если вам скажут коллеги или в документе явно указано, что он устарел. Если нет, ориентируйтесь на косвенные признаки неактуального документа:

Как определить важность блоков в документации к масштабной системе:

• Обратите внимание на частоту упоминания блоков в концептуальной документации. Скорее всего те, что упоминаются чаще, будут важнее.
  
  
• Изучите таск-трекер, обратите внимание на блок с наибольшим количеством задач или ошибок. Вероятнее всего, наибольшее количество ошибок будет в самом важном блоке.
  
  
• В планах работ можно посмотреть порядок реализации блоков. Как правило, наиболее важные блоки реализовываются на начальных этапах разработки системы.
  

Команда — это тот аспект, без которого в принципе невозможна разработка системы, за исключением крайне редких случаев. От умения следовать принятым правилам, достигать взаимопонимания и своевременно синхронизироваться с коллегами, зависит эффективность работы команды. Что нужно сделать на данном этапе, чтобы быстрее адаптироваться в новой команде?

В первую очередь нужно понять:

1. Кто есть на проекте
   
2. За что каждый из участников отвечает
   
3. Как организована работа в целом

Как определить ключевых участников?

• Выяснить у руководителя / наставника, кто работает над проектом с вашей стороны, а кто — со стороны заказчика
• Поискать в документации состав участников: это может быть какой-то отдельный документ или план работ
• Выяснить, кто является автором доступных вам документов
  

В команде проекта стоит искать следующие типы участников:

• Принимающие решения. Имеют ключевое влияние на проект, их мнение / позиция самая важная. Запоминаем. Можно ли к ним обращаться за помощью в случае проблем?
  
• Знающие больше всех — сотрудники-эксперты. Главный источник информации. Насколько большая загрузка, насколько готовы делиться информацией?
  
• Готовые делиться знаниями. Это могут быть как эксперты, так и специалисты, которые не так давно в проекте, но знают чуть больше, чем вы. С последними аккуратнее — они сами могут ещё многого не знать. Чем полезны: могут указать протоптанную дорожку, скорее всего у них больше времени на помощь вам, чем у эксперта.
• Участники-коммуникаторы. Чем полезны: знают, что и где можно узнать. На конкретный вопрос могут не ответить, зато направят в нужную сторону или дадут контакты того, кого можно опросить.

Когда мы уже немного узнали про систему, познакомились с предметной областью и с членами команды, приходит время разобраться с тем, как работает эта самая команда.

Список вопросов по работе команды

• Где и как брать задачи: назначает руководитель / любая понравившаяся в Jira
  
• Какой процесс работы над задачей: какой таск-трекер мы используем или не используем, как там найти свои задачи, какие кнопки нажимать, как брать следующие задачи
  
• Регламент работы команды и взаимодействия участников: есть ли статусы, оценки, ретроспективы и так далее
  
• Практики, принятые в команде: правила, шаблоны оформления документов, соглашения о наименованиях и так далее
  
• Можно ли записывать на видео- или аудионосители встречи с заказчиками
  
• Дополнительное ПО и инструменты, необходимое для работы: visio, enterprise architect, miro, figma и так далее
  

По мере погружения в работу команды вы можете обнаружить определённые трудности, связанные с особенностями рабочих процессов:

1. Неявные процессы или их отсутствие
   
2. Жёстко поделённые границы
   
3. Отсутствие лидера
   

Универсальные принципы поведения для новичка:

• Повторите задачу своими словами, сделайте упор на ожидаемый результат, попросите подтверждения.
• Обсуждайте задачи в письменном виде, чтобы не только у вас, но и руководства осталось однозначное подтверждение границ задачи.
• Если не понимаете зоны ответственности, обязательно уточните этот вопрос у коллег и не берите на себя задачи, пока не поймёте, кто их у вас будет принимать.

«Горящие» проекты — это отдельная большая тема, опишу только ключевые моменты. Проекты, в которых поджимают сроки, встречаются довольно часто и в какой-то степени уже становятся нормой.

К сожалению, далеко не всегда сжатые сроки чем-то действительно обоснованы. Чаще они являются банальной ошибкой планирования или результатом политики компании-исполнителя или политики заказчика.

Основные признаки «горящих» проектов:

• Документации нет
  
• Сроки сжаты
  
• На новичков начинают вешать функции других сотрудников

Погружаясь в новый проект, настройтесь на то, что вам нужно время. Не день и не неделя, а несколько месяцев.

Как уже написано выше, начните с определения вашего проекта (новый, действующий, «горящий»). После этого изучите всё, что поможет вам адаптироваться на проекте:

• Проектный словарь и глоссарий
  
• Предметную область
  
• Документацию
  
• Как работает команда