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

Введение

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

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

Таким образом, в компании заказчика трудилось множество команд разработчиков, а также отдельная команда DevOps-инженеров, которая занималась развертыванием приложений в общий кластер. В контексте этой статьи термин “проект” можно приравнивать к термину “приложение”. За каждым из инженеров, в том числе и за мной, был закреплен свой список проектов. Отсюда возникла необходимость взаимодействовать с большим количеством команд. Одно время число проектов, за которые я отвечал, превышало 20, но в обычном режиме взаимодействовать приходилось в среднем с 10 командами. Зачастую работа это интенсивная и очень интересная за счет большого количества коммуникаций с разными людьми. 

Их много и все такие разные

Большое количество есть разнообразие, большое разнообразие есть хаос.

То, что мы называем хаосом — это всего лишь закономерности, которые мы не сумели распознать. (с) Чак Паланик, "Уцелевший"

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

• Состав.

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

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

• Распределение ролей.

  В одних командах может быть четко выделенная роль лида. Тогда все решения согласуются с ним, и не возникает никакой путаницы, в других - ответственность берет на себя один из разработчиков, либо процессом управляет РП. В одной команде привыкаешь к одним правилам взаимодействия, в других - все совсем иначе. Это сложно предугадать до того, как столкнешься с конкретной ситуацией. Остается только быть более гибким и искать свои подходы в каждом случае.

• Слаженность работы, взаимодействие.

  Если работа по проекту согласована и активно продвигается, а у РП возникают вопросы почему "до сих пор ничего не работает", - значит проблема в коммуникации. Иногда об этом узнаешь из жалобы руководству.

  Одно из моих любимых (теперь) воспоминаний, когда в первые дни работы мне позвонил незнакомый человек. На повышенных тонах предъявлял претензии, что у них "все время что-то ломается" и требовал объяснить, почему все так плохо. Потом я узнал, что это руководитель проекта. 

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

• Различный темп и активность на проектах.

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

• Количество мессенджеров и чатов.

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

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

Как справиться с работой в таком режиме?

Безусловно, первое время (как на любом новом проекте) было тяжело. 

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

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

• Записывать всё, что делаешь.

  Поскольку общение с разработчиками происходит в диалогах, в огромном потоке легко потерять, чем конкретно ты занимался в текущий день. Особенно в первое время. Такие детали нужно записывать. Это поможет впоследствии с будущими задачами:

  • детально описать трудозатраты в конце дня;

  • не потерять ни одной задачки, даже если она растянется на несколько дней или недель (недель);

  • создать подробную историю проекта.

• Вести историю задач каждого проекта.

  Продолжение предыдущего пункта. Удержать в оперативной памяти статусы по 10 проектам - нереально (в первые месяцы). Зачем это может пригодиться?

  • Описать в реальном времени состояние проекта;

  • Передавать задачи по проектам внутри команды.

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

• Использовать собственную систему задач.

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

  Этот пункт вкупе с предыдущими позволил 4-5 часов в неделю, которые тратились на орг. моменты, сократить до 1 часа.

• Всегда проверять входные данные.

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

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

• Настаивать на простых и прозрачных решениях.

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

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

• Заранее обозначать сроки.

  Выше я описывал возникновение ситуаций с переполненным бэклогом. В связи с этим на простую задачу (15-30 минут) может уйти намного больше времени. И в такой ситуации лучше обозначить заранее, через какое время приблизительно она будет решена. Потому что второй раз РП в гневе могут пойти сразу к руководству с жалобами на игнорирование их самого важного проекта! Таким способом мы сразу даем понимание ситуации авторам задачи и уменьшаем вероятность возникновения конфликтов в дальнейшем.

• Описывать статусные вещи в общий чат.

  Даже если обсуждение решения происходило во время созвона с разработчиком, о принятом решении следует отписать резюме. Это очень помогает держать коллег (и особенно РП) в курсе всего что происходит, даже если они не участвуют в решении непосредственно. Также, если решение затрагивает кого-то еще, они могут высказать свое мнение, задать вопросы и внести корректировки до того, как это будет реализовано и возникнет следующая проблема.

• Посещать ежедневные встречи крупных проектов.

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

Заключение

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

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

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

Кстати, подписывайтесь на наш Telegram-канал DevOps FM, там мы публикуем не только авторские статьи, но также актуальные новости мира DevOps.