Не так давно у меня уже выходил пост на тему онбординга. Он посвящен тому, как осмотреться на местности, чтобы понять куда именно прилагать усилия. Однако проект как кодовая база сам по себе мало описывает детали вашей рабочей жизни, её перспективы и возможности. Он — всего лишь небольшая часть ваших ежедневных обязанностей.
Чтобы разобраться с остальным, вам нужно провести несколько разговоров на разные темы. Сделать это лучше раньше, пока проект у вас на «испытательном сроке», чтобы вы могли выбрать правильную линию поведения. Всего вам нужно пять встреч. Какие-то можно сделать формальными и забукать под них время в календаре, какие-то можно провести «у кулера». Как, зачем и почему — сейчас все расскажу.
Разговор о контексте и правилах игры
С кем поговорить: тимлид, CTO
О чем спрашивать: текущее состояние кода, архитектурные решения, болевые точки
Хочется верить, что ваш лид рядом каждый день и может проконсультировать по срочным вопросам в режиме реального времени. Темой же такого разговора должны стать вопросы более глобальные, системные.
Вам нужен разговор про контекст. Спросите не «что мы делаем», а «почему мы это делаем». Почему этот модуль написан так, как написан? Какие шишки здесь уже набили? Что происходит с технический долгом, который мы осознанно не трогаем, потому что «работает — не трогай»?
Проведя несколько таких разговоров, вы поймете что у проекта «болит». При этом тимлид может предоставить видение тактических проблем, а CTO — стратегических. Вашей же задачей будет способствовать их решению. И только.
Разговор о ценностях и деньгах
С кем поговорить: продакт-менеджер, владелец продукта
О чем спрашивать: бизнес-цели, источники дохода, пользователи
Даже если вы готовы работать «за идею», то проект не может существовать без денег. Так или иначе, в рыночной экономике, прибыль — цель любого корпоративного действия. Понимание того, откуда в проект течет ручеек с деньгами, даст осознание какие ваши усилия будут оценены выше всего. Приведу пример.
Допустим на вашем хайлоад-проекте есть какой-то запрос, который отрабатывает 30 секунд. Смотря на него глазами ответственного синьор разработчика бэкенда, вы захотите немедленно все бросить и докопаться до рефакторинга. Однако может выясниться, что эту ручку использует 1 человек 1 раз в месяц, да и тот работает в вас в компании. А тем временем есть целый недописанный модуль, что блокирует подписание контракта на сумму с неприлично большим количеством нулей.
Всё это может «болеть» у вашего продакта. А даже если не «болит», то вы узнаете много о том, как проект зарабатывает деньги, за что его любят и используют.
Разговор о подводных камнях и истории
С кем поговорить: самый «старый» разработчик (старожил проекта)
О чем спрашивать: реальное положение дел, неописанные проблемы, уникальные решения
Это, пожалуй, единственный тип разговора, который нужно проводить неформально, по случаю, но регулярно. Дело только в том, что в один (пусть даже полуторачасовой) слот вся «тайная» информация об устройстве проекта не влезет. А если влезет, то не запомнится. Лучше постепенно, за обедом или чашечкой кофе (если разговоры о таких вещах не портят вам аппетит).
Странствуя по кодовой базе вы можете натыкаться на странные модули, встречать невозможные изобретения, видеть несоответствия технической и бизнес-документации. Старожил проекта, который пока еще находится рядом с вами в здравом уме и твердой памяти, сможет рассказать о том, почему они все еще существуют и как он видит дальнейшую работу с ними.
Для вас, как для технического специалиста, такой разговор несет огромную ценность. Вы перенимаете знания, опыт и можете прощупать почву на предмет готовности к изменениям, которые вы хотели бы предложить.
Разговор о доставке и проблемах
С кем поговорить: сотрудники техподдержки, пользователи, смежные команды, девопсы
О чем спрашивать: что бесит людей, которые пользуются вашим продуктом
Ваш код и результаты его работы рано или поздно становятся видны людям. Это или смежный сервис, или конечный пользователь. Понять, насколько хорошо результаты вашей работы показывают себя в «бою» важно для того, чтобы найти критически важные модули, «узкие горлышки».
Спец поддержки подскажет, какие из проблем раздражают пользователей больше всего и добавляют ему рутинной работы. Смежные команды могут поведать о раздражающих костылях (кода, процесса), на которых стоит какое-никакое межсервисное взаимодействие. Девопс может рассказать, например, про вечно падающие на деплое тесты.
Понимая что болит, вы поймете как лечить.
Разговор о будущем и ожиданиях
С кем поговорить: нанимающий менеджер
О чем спрашивать: насколько ваши результаты совпадают с ожиданиями
Этот разговор лучше проводить с определенной регулярностью. Первый раз — лучше через пару спринтов после начала работы. Цель — узнать у человека, который доверил вам определенные обязанности, насколько он доволен своим решением о вашем найме.
Это разговор не о том, «хороший» вы или «плохой». Это разговор о том, в правильном ли направлении вы двигаетесь. Возможно, вас нанимали чтобы править древние баги (представление о которых у вас уже есть), а вы сфокусировались на рефакторинге архитектуры. Возможно, от вас ожидали больше командной игры, а вы тащите в одного.
Если вы не синхронизируетесь первый раз через месяц, дальше будет только хуже. Лучше узнать об этом как можно раньше и скорректировать курс, чем через полгода услышать, что вы не оправдали надежд.
Что в итоге
Пустая «контурная карта» в ходе каждого разговора обрастала отметками о залежах тех или иных возможностей и перспектив. Конечно, ее нужно уточнять и дополнять и дальше. Однако базовая версия теперь у вас на руках и вы можете понимать, как строить своё будущее на текущем проекте, какие навыки стоит развивать, какие — уже применять. До связи!
