Хочу рассказать о том, как мы все можем сделать работу над кросс-проектами в нашем IT более предсказуемой, понятной и более эффективной. Работая над проектом по запуску постаматов, наша команда накопила кое-какой опыт. В этой статье постараюсь донести все полезные наработки, которые может использовать каждый сотрудник IT подразделения.

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

Почему именно разные функциональные модули и разные команды? Все просто: в рамках одного модуля у нас постоянно происходит взаимодействие между разными командами. Например, между бэком и фронтом. Это уже настолько обыденная ситуация, что было бы странно объявлять это кросс-проектом и как-то по-особому с ним работать. Тоже самое касается и "разных команд": если одна и та же команда работает над двумя модулями, то у нее тоже вряд ли возникнут проблемы в реализации, особенно, если писать код или аналитику будет один и тот же разработчик или аналитик. Но если команды разные и модули разные – тут уже вполне могут начаться проблемы…

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

Быстро выяснилось, что так или иначе задействованы будут практически все модули ЭК5 и интеграции. Одних только аналитиков было задействовано 19 человек! При этом изначально вся наша команда: я в качестве PM и Мария Колесникова как главный аналитик проекта.

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

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

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

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

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

Я не сказал о еще одной важной роли в любом кросс-проекте, затрагивающем бизнес-функционал: о Владельце Продукта от бизнеса. Максимально важно, чтобы это тоже был один человек с пониманием целей и способов их достижения. Огромное количество вопросов, особенно на этапе аналитики, всегда обращается к бизнесу. Если нет "главного за бизнес вопросы" – будет очень сложно довести проект до успешного запуска. Но! Важное замечание: за исключением случая, когда мы внедряем какой-нибудь внутренний технический проект. Например, переход на шаблон модуля – здесь человек от бизнеса нам не нужен.

Представленная выше схема охватывает большие проекты, где участвует множество модулей, команд и людей. Если вы запускаете фичу на 3 часа разработки с участием двух команд бэка, то, наверное, нет смысла собирать часовой созвон на 6-8 человек, где в торжественной атмосфере будут назначаться "главные за фичу". Вот если команды уже три, а фича тянет на несколько дней разработки только внутри твоей команды, уже стоит поинтересоваться у менеджера: к кому же все-таки обращаться с вопросами и кто носитель базовой информации по фиче?

1. Убедись, что понимаешь, что и зачем тебе нужно сделать. Если нет – самое время спросить у главного по твоему направлению.


2. Если нет главного – стоит спросить об этом своего менеджера. И о том, что непонятно и о том, почему нет главного по направлению. Менеджер не любит вопросов (фи-и-ить, щютка), так что он, наверняка, быстро организует назначение "точки входа".


3. Убедись, что ты и твои коллеги составили план работ – понятный всем и выполнимый (хотя бы на ближайшую перспективу). Если нет – подними этот вопрос сам в общем чате или же снова напомни о себе менеджеру (надеюсь, меня не побьют и не отравят).


4. Если что-то меняется в проекте – не забудь предупредить об этом коллег по проекту. Может быть, это даже не у тебя меняется, а ты где-то на митинге услышал об этом: если считаешь, что это может что-то задеть в проекте – лучше "перебдеть" и лишний раз переспросить.


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


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