Рабочий процесс

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

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

Я уже упомянул, что не планирую развиваться дальше на управляющем поприще. Чем дальше ты идешь, тем меньше времени тратишь на то, что наиболее интересно. А я не вижу себя ни в какой другой роли. Да и на рынке труда в статусе сениор-разработчика из региона чувствую себя более уверенно: даже в Краснодаре в офисе можно быстро найти работу, не говоря уже о множестве предложений на удаленке. Руководителям в этом смысле сложнее. Так что я выполняю задачи тимлида, но стараюсь сохранить максимальную связь с разработкой.

7:00

Я - жаворонок, просыпаюсь вместе с солнцем часов в 6 или 7 утра.

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

10:00

В 10 утра мы проводим дейли с командой. Мы собираемся максимум на 15 минут. Если такая встреча затягивается, участники начинают отвлекаться, поэтому я сознательно останавливаю все затягивающиеся обсуждения. Под такие темы лучше запланировать отдельную встречу, позвав на нее только тех, кого этот вопрос касается непосредственно. Людей в команде много, у всех разный профиль, так что это сильно экономит время.

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

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

10:15

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

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

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

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

13:00

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

14:00

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

Хотя больше всего я люблю решать технические задачи, в статусе тимлида я очень редко сижу и что-то программирую. Обычно весь день занимаюсь решением разного рода вопросов - от установки конкретных версий на тестовый стенд, до внедрения новых технологий. Это огромный спектр задач. К примеру, начали мы вводить testcontainers - подключили библиотеку. Локально у разработчиков все работает, а с GitLab возникли проблемы (когда мы пушим наш код в GitLab, он тоже гоняет тесты, и там они не заработали). Разработчик сам не смог решить проблему из-за отсутствия доступа к конфигурации GitLab, так что тут пришлось подключиться мне. У меня доступа тоже не было, но с помощью коллег вопрос решили. И такие задачи заполняют почти целый день.

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

17:00

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

19:00

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

22:00

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

Автор статьи: Андрей Буров, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стране, а еще, разработчики КРОК и Группы НЛМК прежде не работали вместе.

Звучит как организационный ад, и это недалеко от истины. Но мы справились и теперь хотим поделиться опытом работы в объединенной команде НЛМК и КРОК в масштабном проекте по развитию информационных сервисов службы продаж.

На этот раз КРОК работал вместе с Группой НЛМК одной из самых крупных сталелитейных компаний с заводами в семи странах. Нашей объединенной команде предстояло масштабировать и усовершенствовать систему маркировки продукции так, чтобы, считав с этикетки QR-код, можно было получить исчерпывающую информацию о продукции через онлайн сервис.

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

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

Это не просто формальность. Сертификат качества в металлопродукции это как свидетельство о рождении и одновременно медицинская карта для человека. Без него сложно понять, например, подойдет ли арматура для строительства многоквартирного дома, выдержит ли она нагрузку.

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

Другое дело цифровой сертификат. Можно заверить его электронной подписью, добавить исчерпывающие характеристики товара и напечатать на каждой этикетке или бирке QR-код с уникальной ссылкой на все эти данные. А для проверки электронно-цифровой подписи существуют специальные общедоступные сервисы. В частности, подлинность ЭЦП не сложно проверить на портале Госуслуги.

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

Работа в тандеме

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

В НЛМК сложный IT-ландшафт на каждом заводе, в каждом цехе свой парк оборудования и связанные с ним MES (manufacturing execution system) системамы планирования и управления производством. Это десятки цеховых систем управления, которые работают в разных часовых поясах, предоставляют данные в разное время и в разных форматах, а также системы корпоративного класса (ERP, CRM и пр.)

Чтобы реализовать QR-кодирование продукции, нам нужно было найти общий язык с системами на четырех российских площадках Группы НЛМК: Новолипецком комбинате, НЛМК-Урал, НЛМК-метиз и НЛМК-Калуга.

Катанка, моталка, прокатка, бунт, швеллер и подмотка лишь некоторые термины и слова, которые вошли в мой словарь за время работы с НЛМК, Марина Зиновьева, аналитик проекта, КРОК.

В подобных случаях необходимы и большой опыт системной интеграции в промышленности, и знание конкретного производства. Так что, обычный аутсорсинг здесь мало применим. Группа НЛМК предпочитает интегрированный подход над проектом работает объединенная команда разработчиков.

В нашем случае часть команды со стороны Группы НЛМК отвечала за общее видение системы, архитектуру и архитектурный контроль, инфраструктуру. Они предоставили экспертизу по MES. DevOps, проектирование, планирование работы и собственно разработка были на стороне КРОК.

Для разработчиков КРОК это был первый масштабный проект в такой тесной связке с командой НЛМК. И что могло пойти не так?

Старт проекта

Разработчики Группы НЛМК провели большую подготовительную работу, связались с ключевыми клиентами и выяснили их потребности, изучили процедуру выпуска сертификатов, продумали архитектуру будущей цифровой платформы.

Они ожидали от партнера такой же погруженности. Поэтому для команды КРОК проект стартовал будто с места в карьер. Через несколько часов после окончания конкурса раздался звонок:

Добрый день! Присылайте план проекта.

Здравствуйте, приятно познакомиться, сейчас пришлем.

Не спали ночь, но прислали.

Первые три недели команда КРОК планировала пустить на изучение текущих наработок и IT-ландшафта предприятия, но оказалось, что нужно показать первые результаты разработки уже через две недели после старта проекта. Это было жестко.

Для НЛМК проект оказался так важен, что они провели собеседования с каждым членом нашей команды, Ярослав Репной, менеджер проекта, КРОК.

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

Пара коротких спринтов на практике доказала, что разработчики КРОК и Группы НЛМК могут продуктивно работать вместе. Появилось время, чтобы познакомиться с новыми коллегами и вникнуть в нюансы задачи.

Важно подчеркнуть, что разработка велась на базе Единой Цифровой Платформы (ЕЦП), которая развернута в НЛМК как целевая экосистема для внедрения новых цифровых продуктов. В основе подходов к созданию ЕЦП лежит гибридная IT-архитектура, задачей которой является сочетание коробочных IT-компонентов и открытой платформы. Платформа обеспечивает унифицированные технические компоненты и данные для построения сквозных сценариев, создания цифровых продуктов и приложений.

Не у каждой IT-компании есть аналогичные решения. Как правило, приходится внедрять такие решения у заказчика самим. Это сильно ускорило нашу работу в ЕЦП все спроектировано, задумано и внедрено удобно. Спорить с НЛМК в части ЕЦП не приходилось вообще OpenShift, Kafka, S3 всё на месте, всё как мы любим.

Учитывая, что и другие продукты уже начинали запускаться параллельно с нами, ЕЦП в НЛМК можно называть зрелой экосистемой. Ни одной значимой технической проблемы в проекте не было. Вместо этого, нас ждали организационные вызовы.

Аджайл VS реальность

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

Проект состоит из семи этапов, так что мы разбили работу на параллельные потоки:

1. тираж QR-кодирования сертификатов качества и готовой продукции на трех производственных площадках;

2. разработка сервиса для утверждения сертификатов качества электронной подписью;

3. разработка стартовых веб-страниц для экспортной продукции группы НЛМК;

4. разработка мобильного приложения для фотографирования транспортных средств и готовой продукции;

5. API для интеграции сервиса с информационными системами покупателей;

6. разработка тартовой страницы для предоставления информации по продукции, маркируемой DataMatrix-кодами;

7. разработка сервиса для автоматизации работы с несоответствиями готовой продукции (подача претензий по QR-кодам).

Фактически ребята ведут семь 7 потоков параллельно. Одну задачу разрабатывают, другую проектируют, третью выводят на демо, а по четвертой ждут результаты от зависимых систем, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

Вскоре стало ясно, что при таком количестве задач двухнедельных спринтов не хватает, чтобы довести макеты до релиза. Пришлось удлинить спринты до 3 недель.

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

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

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

Распределенная команда

Со стороны КРОК в проекте участвовало 11 человек. Ядро команды Группы НЛМК состояло из 24 IT специалистов. Получилась гибкая и разносторонняя команда, но постепенно в проект оказалось вовлечено больше 100 сотрудников из других подразделений НЛМК: эксперты от производства, интеграторы MES, инженеры, специалисты и руководители по продажам и начальники цехов.

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

Ачивмент: встать в шесть утра, чтобы зарядить разработчиков из Иркутска.

У техподдержки, например, на Урале свои: задачи, сроки и проблемы. Им приходилось одновременно участвовать в нескольких крупных проектах, решать текущие вопросы и поддерживать системы. Они оказались очень загружены.

Вы мне про аджайл, а мне оборудование настраивать надо, инженер Группы НЛМК, пожелавший остаться неизвестным.

Конечно, можно было форсировать работу через начальство, но так не добиться заинтересованности в результате, да и можно помешать другим проектам Группы НЛМК.

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

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

Сложности коммуникации

Участники объединенной команды были разбросаны от Минска до Иркутска. Даже не будь пандемии, собраться вместе мы бы не смогли. Так что в начале проекта Skype-конференции стали основным каналом связи. Календарь состоял из непрерывных встреч и обсуждений. Времени на разработку не оставалось.

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

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

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

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

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

Вместо заключения

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

Для нас КРОК близкие друзья, мы учимся у них гибкости и неформальному подходу к решению задач, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

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

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

В ближайшем будущем клиенты Группы НЛМК на базе Единой Цифровой Платформы смогут мгновенно получать сертификаты качества, отслеживать поставки товаров, автоматически учитывать их при поступлении на склад при помощи API и быстро сообщать о дефектах продукции через личный кабинет на портале НЛМК.

Этот проект направлен на повышение удовлетворенности и создание максимально удобного сервиса для наших клиентов, партнеров и конечных потребителей продукции. Например, он позволяет нашим оптовым партнерам осуществлять упрощенную процедуру складского учета продукции, а также позволяет сделать прозрачным ее дальнейшую продажу, Борис Ашрафьян, начальник Управления Проектный офис, Группа НЛМК.

Это был непростой проект, но благодаря ему мы многое поняли. Если возьметесь за совместную разработку:

1. Выделите время на плавный старт

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

2. Убедитесь, что все одинаково хорошо понимают цели и задачи проекта

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

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

Главное создать vision of future, когда все понимают, осязаемо понимают, что мы собираемся делать, Игорь Кораблев, энтерпрайз-архитектор, НЛМК.

3. Изучите команду

Пока вы не знаете, кто за что отвечает и что умеет, решение даже самых простых вопросов будет похоже на скучный, утомительный квест.

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

4. Вовлекайте в совместную работу

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

5. Доверяйте друг другу

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

Если это не касается каких-то внутренних ограничений информационной среды, нужно давать подрядчику творить так, как он считает нужным, Олег Богданов, куратор проекта, бизнес-заказчик, НЛМК.

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

6. Держите руку на пульсе

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

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

7. Обучайте и обучайтесь

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

Мы научились ставить задачи друг другу и работать, как единое целое. Я вижу взаимный профессиональный рост разработчиков КРОК и НЛМК, Дмитрий Лаптев, технический менеджер, КРОК.

8. Создайте единое информационное пространство

Электронная почта не самый удобный канал для общения внутри команды, а групповые звонки часто затягиваются и отнимают массу времени.

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

9. Не пытайтесь решить проблемы на 100%

Привычные подходы могут плохо работать в объединенной команде, но нет такого способа спланировать спринт, чтобы работа всегда шла гладко. Какую бы практику вы ни внедрили, она не даст 100% результат и не избавит разом от всех проблем.

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

P.S. Если у вас остались вопросы, можете написать на ipopkov@croc.ru.

Кстати, а вы работали в объединенных командах? Пожалуйста, поделитесь своим опытом в комментариях.