Быстрое погружение в новый проект — важный навык для любого специалиста.

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

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

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

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

Время на чтение статьи: 18 минут
Не любите читать? Посмотрите видео.

Оглавление

Введение
Основные проблемы адаптации
Что влияет на адаптацию?
Где я оказался?
Аспекты погружения
Погружение в предметную область
  Словарь и глоссарий
  Предметная область
  Документация и проектные артефакты
     Документации нет
     Документации слишком много
     Как делать анализ документации
     Неактуальная документация
     Изучаем разобранную документацию
Знакомство с командой
  Состав команды
  Как работает команда: процессы, принципы, традиции
   Неявные процессы
   Жесткие границы
   Отсутствие лидера
«Горящие» проекты
Выводы
Об авторе

Системный анализ и Разработка требований в ИТ-проектах

Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.

Посмотреть программу курса

Основные проблемы погружения
в новый проект

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

Независимо от типа проекта, сложности в адаптации можно разделить на одинаковые блоки.

1. Проблемы с документацией
Документация может быть некачественная, неполная, её может вообще не быть. Иногда, наоборот, её бывает так много, что найти что-то конкретное практически невозможно.

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

3. Проблемы со временем
Сроки самого проекта могут быть ограничены настолько, что времени на его изучение просто нет. В этом случае с вас могут сразу требовать решения конкретных задач, а у команды просто не остаётся времени на помощь в адаптации. Иногда на сроки может накладываться особенность культуры команды (например, завышенные ожидания, конкуренция и т. п.)

Чаще всего вы будете сталкиваться с комбинацией этих проблем в разных пропорциях.

Что влияет на адаптацию?

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

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

Важно понимать, что чем больше новичок и команда вкладываются в процесс адаптации, тем быстрее и легче он проходит для всех его участников. Да, это инвестиции, но они потом окупаются.

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

Отмечу, что погружаться в проект в знакомой или близкой предметной области проще. Самая сложная ситуация: незнакомая предметная область и проект-долгожитель с неактуальной документацией.

Где я оказался?

Первое, что надо понять, когда оказался на новым проекте — это контекст: что за система / проект, как она называется и кому можно задавать вопросы прямо сейчас, как получить доступ к проектной документации, к системе (если она есть) и на какой тип проекта вы попали.

0. База
К базовым знаниям можно отнести всё, что касается обеспечения вашей работы: доступ к корпоративной CRM-системе, ссылки на странички наиболее значимых сотрудников на корпоративном сайте, доступы к необходимым базам данных. В первую очередь получите контакты отдела кадров, HR, вашей команды и руководителя. И обязательно попросите экскурсию по офису, если ваш формат это предполагает.

Пример из жизни

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

1. Знакомство с проектом
Узнайте, какую систему / продукт разрабатывает команда и как она называется. Попросите, чтобы вам представили человека, к которому вы сможете обратиться за помощью. Таким человеком, скорее всего, будет ваш непосредственный руководитель, наставник или руководитель вашего проекта. Уточните, как с ними связаться и в каком формате лучше выстраивать коммуникацию.

2. Документация по проекту
Выясните, где находится вся проектная документация — велика вероятность, что вам не смогут отвечать на вопросы так быстро, как хотелось бы. Изучение информации по проекту — основная деятельность, которую нужно планировать в первые дни работы. Поэтому позаботьтесь об источниках заранее.

3. Система или продукт
Уточните, есть ли система, с которой вы будете работать. Выясните, какие могут быть варианты доступов в систему и какие нужны вам для выполнения ваших задач. Имейте в виду, что выдача доступов может растянуться на нескольких дней.

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

5. Тип проекта
От типа вашего проекта зависит стратегия вашего дальнейшего поведения: что и в какую очередь нужно изучать.

    1. Новый проект: находятся на начальных этапах разработки. Такие проекты отличаются достаточно свободными сроками реализации.

    2. Действующий проект: уже идёт какое-то время. В таких проектах уже есть определённый порядок работ, скорее всего, есть какая-то документация и всё ещё относительно свободные сроки реализации.

    3. «Горящий» проект: в подобном проекте сроки реализации очень жёсткие и работы необходимо выполнять очень быстро. Как правило, все проекты на завершающей стадии становятся «горящими».

Замечу, что первые два типа проекта на определённых этапах тоже могут становиться «горящими». Это довольно распространенная история, когда вначале проекта никто не торопится, а тут раз — и дедлайн.

Аспекты погружения

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

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

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

Погружение в предметную область.
Словарь и глоссарий

Изучение предметной области стоит начать со словаря и глоссария. Это довольно важный аспект, поскольку в каждой сработавшейся команде есть определённый жаргон и сокращения, которые используются в повседневной работе. И они не всегда понятны новому сотруднику. Не забывайте, что сокращения имеют свойство менять своё значение от проекта к проекту. Они могут звучать одинаково, но иметь совершенно разный смысл.

Пример из практики

В одном из проектов, где я работала, есть сокращение «СЗ». В одном случае — это сменное задание, а в другом — страховой запас. Всё зависело от контекста.

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

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

Предметная область

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

1. Новый проект. В этом случае изучение предметной области происходит более простым способом, более естественно. В ходе работы вы начинаете общаться с бизнес-заказчиком, узнаёте чем он занимается, его потребности, что он хочет и какие у него проблемы. То есть помимо постановки задач, заказчик попутно расскажет какие-то детали своей деятельности.

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

Пример из практики

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

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

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

Документация и проектные артефакты

Документация — один из самых важных аспектов, поскольку является основным инструментом работы аналитика. Документация может быть очень больших объёмов, и уметь разбираться в ней — базовый навык любого специалиста.

Документы в различных форматах, статьи в wiki/confluence, картинки, презентации, видео, задачи в таск-трекере (система управления задачами), письма, чаты — проектных артефактов множество.

Код — это своего рода тоже вид документации, с ним могут быть ровно те же проблемы, что и с традиционными форматами.

Документации нет

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

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

Документации слишком много

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

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

Как делать анализ документации

Если разбираться в документации приходится самостоятельно, начинайте с категоризации.

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

    — общая / концептуальная документация
    — частные спецификации / постановки
    — эксплуатационная документация
    — пользовательская документация
    — протоколы совещаний
    — разное

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

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

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

— он давно не редактировался (также это признак части системы, которая давно не менялась).
— есть другой документ, который описывает эту же часть или пересекается с этим документом. Чтобы это понять, придётся внимательно вчитываться. Если есть возможность, проверьте в самой системе, как работает эта функциональность. А если вы разбираетесь в программировании, то посмотрите код.

Нашли устаревший документ? Пожалуйста, пометьте его устаревшим. Упростите жизнь своим будущим коллегам.

Неактуальная документация

Изучение неактуальной документации позволит вам узнать историю развития системы, помочь в понимании решений, которые сейчас кажутся странными.

Если другой информации нет, то лучше такая документация, чем никакая. При этом ключевой критерий полезности — точно знать, что она неактуальна.

Пример из практики

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

Изучаем разобранную документацию

Когда вы разделили документацию на разделы, отделили актуальную часть от неактуальной, вам остаётся только погрузиться в чтение документов. И в этот момент чаще всего возникает вопрос: «С чего начать?».

1. Изучаем концептуальную документацию.
Здесь описываются верхнеуровневые цели системы, назначение, укрупнённо описана функциональная структура, связи и зависимости.

2. Расширяем знания по каждому функциональному блоку.
Важно не пытаться изучать всё сразу. Выберете один конкретный блок и изучайте его базовый процесс и самые крупные ответвления. Для первичного знакомства этого достаточно; детали будет проще освоить в процессе работы.

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

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

Знакомство с командой.
Состав команды

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

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

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

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

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

Допустим, вы нашли список участников проекта. Это формальная часть узнавания людей в проекте, и это не всё. Иногда бывает так, что формальная роль / должность участника не соответствует его реальным функциям, поэтому спрашиваем и внимательно наблюдаем.

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

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

Отдельно добавлю про экспертов. Дело в том, что когда эксперт нужен, он чаще всего очень занят. Поэтому любая возможность общения с ним имеет особенную ценность. Привлекайте своего руководителя для организации встреч с экспертом и обязательно готовьтесь к этой встречи. Заранее составьте список вопросов и договоритесь с экспертом об удобном способе сотрудничества (очная встреча, email, телефонный разговор и тому подобное) — так вы сможете извлечь максимум пользы от такой коммуникации. Во время встречи возвращайте разговор к согласованной повестке, минимизируя возможные отступления.

Пример из практики

Один из экспертов в моём проекте помимо рабочих задач преподавал теорию проектирования БД. Однажды я пришла к нему на назначенную встречу с каким-то своим вопросом. Он сидел один в кабинете и на столе лежала распечатанная на листочках А4 и склеенная в огромный ватман структура БД, а рядом список вопросов, который он заготовил. В итоге моя встреча превратилась не в интервью с экспертом, а в экзамен по теории проектирования БД. Он снова и снова закидывал меня вопросами по типу: «Здесь должна быть связь один ко многим, а у вас — многие ко многим, почему?». Так моё время на то, чтобы узнать необходимую мне информацию, было потрачено на разбор вопросов, которые волновали эксперта.

Ну и универсальный совет: даже если вы интровертны, старайтесь налаживать контакт с коллегами. Если кто-то сам предлагает помощь, не отказывайтесь и благодарите независимо от итоговой полезности.

Как работает команда:
процессы, принципы, традиции

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

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

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

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

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

Неявные процессы

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

Основной плюс — такая ситуация даёт больше свободы, вы сможете заниматься смежными для себя задачами, попробовать себя в другой роли.

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

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

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

Жёсткие границы

Помимо основных членов команды, часто приходится взаимодействовать с другими подразделениями. Здесь вы можете столкнуться с другими ценностями и подходами в организации работы. У некоторых может быть жёстко зарегламентированный процесс, в котором у каждого участника будет своя роль с конкретным набором функций. Также мы можете столкнуться с тем, что вас не допускают к какой-то информации.

Для начала организуйте групповой созвон, чтобы уточнить позицию коллег, и попробуйте выявить того специалиста, который всё-таки готов вам помочь. Если вы понимаете, что это не помогло и согласование вашей документации зашло в тупик из-за отсутствия контакта с «закрытым» источником информации, постарайтесь обратиться к коллегам в более неформальной обстановке.

Отсутствие лидера

Если на проекте нет лидера, то при возникновении ситуаций, где нужно оперативно принимать решения и выполнять задачи, могут появиться ни к чему не приводящие совещания, затягивание сроков и накопление нереализованных задач.

Единственное решение в таком случае — попробовать найти неявного лидера. Проанализируйте команду: неявным лидером может оказаться разработчик, тестировщик, другой аналитик. Обязательно наладьте с ним контакт. Через месяц работы станет точно понятно, насколько вы готовы работать в проекте с таким подходом к управлению.

«Горящие» проекты

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

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

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

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

Если вы попали на этот проект в качестве «экстренной» помощи (вам прямым текстом об этом сказали), то не тратьте время на изучение и погружение. Вас взяли временно на выполнение конкретных задач, которые необходимо выполнить с минимальной вероятностью переделки. В этом случае задачи будут ставятся по принципу «сделай хорошо». Чтобы их сделать действительно хорошо, выясняете критерии качества и регулярно уточняйте их актуальность.

Если же это новый проект и вы на него попали не как временная помощь, то примите взвешенное решение, нужно ли вам участвовать в данном проекте. Нагрузка и переработки могут быть такими, что обесценят все «плюшки», которые за него обещают.

Но плюсы в такой работе тоже есть. Интенсивная работа и возможность совмещать роли даёт возможность быстро освоить какие-то вещи, которые вы бы осваивали гораздо дольше, находясь в более спокойных условиях. А если в компании принято оплачивать переработки, то за такой проект вы можете получить хорошую компенсацию.

Выводы

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

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

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

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

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

По мере изучения информации оставляйте после себя артефакты: обновляйте неактуальную информацию, пишите заметки, переносите документы в логичные места. Это поможет не только вам, но и вашим коллегам, которые присоединятся к проекту позже.

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

Программа переподготовки

«System Analyst Bootcamp»

Курс для тех, кто хочет сменить профессию и начать работать в ИТ с хорошими перспективами, занимаясь исследованием задач и проблем бизнеса и постановкой задач на автоматизацию

Посмотреть программу курса

Автор

Мария Щекочихина

Бизнес-аналитик, преподаватель и автор курсов

В ИТ 15 лет: прошла путь от разработчика через аналитику в руководителя тимлидов
Основные бизнес-домены: МДМ, ЭДО, проведение тендерных процедур, управление имуществом, налоги, планирование поставок и логистика