Я возглавляю команду из 20 человек, создающих финансовые продукты на платформе крупного маркетплейса. За два с половиной года наша доля финансовых продуктов в экосистеме маркетплейса значительно выросла. Управление кросс-функциональными проектами в рамках таких масштабных продуктов — это сложный и многогранный процесс, который требует четкого подхода, детальной проработки и учета множества факторов.
В таких проектах важно работать не только с техническими аспектами разработки, но и с продуктовой частью, следить за взаимодействием различных команд и учитывать потенциальные риски. Вот несколько инсайтов и стратегий, которые помогают мне управлять такими проектами, особенно в сегменте финансовых продуктов.
1. Определите цель проекта и донесите ее до команды
Первым шагом при запуске кросс-функционального проекта должно стать четкое определение его цели. В нашей команде каждый новый проект начинается с подробного объяснения того, как он вписывается в долгосрочную стратегию маркетплейса. Мы обсуждаем не только сам продукт, но и ключевые метрики, которые помогут оценить его успех. Важно сразу определить, каких результатов мы хотим добиться, как в продуктовой части, так и в технической.
Такой подход дает два ключевых преимущества. Во-первых, это позволяет заранее включить в скоуп проекта изменения, необходимые для оценки его успеха. Во-вторых, ясное понимание цели значительно повышает мотивацию участников команды, что, в свою очередь, способствует большей эффективности проекта.
2. Проработайте архитектуру и минимизируйте риски
Одной из распространённых ошибок при старте проектов является стремление сразу приступить к написанию кода после получения задачи в виде продуктовой постановки. Такой подход кажется быстрым и простым, создавая иллюзию ускоренного достижения цели.
Однако на практике погружение в детали часто выявляет множество краевых случаев и неочевидных сценариев. Нередко оказывается, что системы работают несогласованно, и уже реализованную часть приходится дорабатывать или, в худшем случае, полностью переделывать. Чем больше компонентов и систем затрагивает проект, тем выше риск ошибок, поскольку сложность системы растет экспоненциально по мере увеличения количества вовлеченных элементов.
На нашем маркетплейсе большинство изменений требуют работы с большим числом компонентов, что существенно увеличивает сложность реализации. Чтобы минимизировать риски ошибок, мы добавляем промежуточный этап в процесс разработки — проектирование архитектуры.
На этапе проектирования принимаются ключевые решения: какие компоненты нужно будет модифицировать или создавать с нуля, как изменится модель данных, и каким образом будут адаптированы интерфейсы взаимодействия между компонентами. Особое внимание уделяется проработке краевых случаев, так как именно они чаще всего становятся источником проблем и существенно влияют на сроки разработки.
Результатом проектирования становится документ или диаграмма, которые обсуждаются со всеми заинтересованными сторонами. Главная цель здесь — не столько создать подробную документацию, сколько донести верхнеуровневое архитектурное решение до максимально широкого круга участников. Визуализация играет ключевую роль в упрощении восприятия.
Как руководитель разработки, я всегда настаиваю на том, чтобы архитектура была тщательно проработана до начала разработки. Если какой-то аспект вызывает сомнения, это сигнал о наличии риска. В таких случаях важно заранее продумать возможные проблемы и подготовить план их решения.
Особенность кросс-функциональных команд заключается в том, что ни один участник не обладает полным пониманием всей системы. Например, мобильный разработчик редко глубоко разбирается в бекенде, а бэкенд-разработчик — в особенностях клиентских приложений. Поэтому на этапе финализации архитектуры крайне важно собрать обратную связь от всех вовлеченных сторон, чтобы учесть их опыт и компетенции.
Пример: Взаимодействие между клиентской и серверной частью — это отличный пример аспекта, который требует тщательной проработки. У нас используется JSON-based HTTP взаимодействие. Изначально в нашей команде бекенд- и фронтенд-разработчики обменивались только примерами запросов и ответов, иллюстрирующих изменения. К детальной проработке контрактов приступали уже на этапе написания кода. Однако такой подход нередко приводил к ошибкам: на фронтенде не хватало данных для реализации полного объема функциональности, а доработки на стороне бекенда могли оказаться затратными и значительно увеличивали сроки проекта.
Чтобы избежать подобных проблем, мы изменили подход. Теперь контракты описываются не только с помощью примеров, но и в стандартизированном формате OpenAPI. Кроме того, мы начали проводить их ревью как на стороне фронтенда, так и бекенда до начала разработки. Это нововведение позволило минимизировать случаи недопонимания, повысить точность оценки сроков и улучшить взаимодействие между командами.
3. Трезво оценивайте сроки и учитывайте детали
Оценка сроков — это одно из самых сложных и ответственных заданий в управлении проектами. Люди часто недооценивают время, необходимое для выполнения задач, что происходит из-за отсутствия полного понимания всех деталей и потенциальных проблем до начала работы.
Эффективным способом борьбы с этим явлением является подробная декомпозиция задач, при которой крупные цели разбиваются на небольшие, легко оцениваемые части. Такой подход позволяет получать более точные временные оценки.
Кроме того, важно учитывать зависимости между отдельными этапами проекта. В небольших проектах это может быть очевидно, но в крупных, с ростом количества платформ и компонентов, такие зависимости становятся значительно сложнее. Их игнорирование приводит к серьезным погрешностям в сроках. Поэтому для ключевых проектов, где важно уложиться в дедлайны и оперативно отслеживать отставания, критически важно составлять детализированный план с учетом всех зависимостей. Мы активно используем диаграммы Ганта, чтобы визуализировать эти зависимости и держать их под контролем.
Я всегда настаиваю на том, чтобы задачи разбивались на небольшие, четко определенные элементы, которые можно оценить по времени. Такой детализированный список помогает не только получить более точные сроки, но и выявить возможные задержки из-за зависимостей.
На практике мы часто сталкиваемся с тем, что для каждого проекта нужно проходить похожие этапы, такие как проработка архитектуры, согласование дизайна или синхронизация с командой безопасности. В условиях большого количества одновременно запущенных проектов, например 20, легко забыть или упустить что-то важное.
Именно поэтому мы разработали концепцию проектного чеклиста. Каждый проект по умолчанию создается с набором обязательных пунктов, которые заполняются проектным менеджером или ведущим разработчиком. Незакрытые пункты чек-листа помогают избежать пропуска критически важных шагов.
Пример: В нашем продукте очень важна консистентность дизайна интерфейса. Поэтому перед запуском мы обязательно показываем финальное решение дизайнеру проекта. Если забыть об этом этапе и показать дизайнеру демо в последний момент, то его замечания могут потребовать существенных правок, что способно задержать запуск.
После нескольких подобных ошибок мы включили демонстрацию дизайнеру в базовый проектный чеклист. Это помогло избежать подобных сбоев в дальнейшем и повысить стабильность выполнения проектов в срок.
4. Настройте регулярную синхронизацию и гибкую адаптацию к изменениям
На практике даже самое тщательное планирование не способно учесть абсолютно все нюансы. Во-первых, это крайне сложно. Во-вторых, собрать всю информацию для принятия решений заранее зачастую невозможно. В-третьих, вводные данные неизбежно меняются: появляются новые обстоятельства, запускаются смежные проекты, сотрудники могут заболеть или даже сменить место работы.
Единственный способ справляться с подобной неопределенностью — регулярная синхронизация участников проекта. Ее основная цель — оперативно зафиксировать изменения, понять, как они влияют на текущие задачи, и быстро среагировать.
В нашей практике мы используем два уровня синхронизации: командную и на уровне лидов.
Синхронизация на уровне команды – это стандартные ежедневные митинги, где участники делятся тем, что было сделано, и обсуждают возникшие проблемы. С накоплением опыта и благодаря ретроспективам мы обнаружили, что интенсивность синхронизаций возрастает ближе к завершению проекта. За две недели до релиза мы переходим в режим максимальной концентрации: ежедневные встречи, детализированные статусы, четкое распределение задач и ответственных. Хотя такой подход увеличивает организационную нагрузку, он значительно снижает риски недоразумений и помогает успешно довести проект до конца без серьезных задержек.
Синхронизация на уровне лидов охватывает взаимодействие между лидерами проектов и направлений. Ежедневные встречи здесь не подойдут из-за высокой занятости участников и недостатка повестки для частых митингов. Вместо этого мы используем другие инструменты: делимся планами в специальном канале, проводим регулярные 1-на-1 встречи с ключевыми участниками смежных направлений. Такой подход позволяет выявлять потенциальные конфликты и коллизии на ранних стадиях.
Пример:
Во время реализации крупного проекта по переработке функциональности BNPL (покупка сейчас, оплата позже) на странице оплаты через месяц после старта разработки выяснилось, что инфраструктурная команда начала перенос логики этой страницы с клиента на бэкенд. Это могло серьезно повлиять на наш проект. И так как команды не пересекались обнаружить это во время проектных митингов было невозможно. Благодаря ранней синхронизации на уровне лидов удалось своевременно выявить эту коллизию и создать роадмап, который учел интересы обеих сторон и позволил согласовать действия с ключевыми стейкхолдерами.
5. Продумайте, как вы будете обеспечивать качество
Тестирование — неотъемлемая часть процесса разработки, без которого проект нельзя считать завершенным, даже если все компоненты уже реализованы. Оно требует времени, которое важно заранее заложить в роадмап проекта. Однако одной только проверки недостаточно. Важно чётко определить, что именно вы будете тестировать, какие сценарии нужно пройти и какие условия должны быть выполнены, чтобы считать тестирование успешным. Всё это описывается в тестовом плане. Создание тестового плана —- отдельная задача, которая требует времени, но ее можно начинать еще до завершения разработки.
Мы подключаем тестировщиков на ранних этапах, сразу после этапа проработки архитектуры. Такой подход имеет несколько преимуществ. Во-первых, тестировщик, погружённый в детали проекта, может предложить свежий взгляд и указать на краевые случаи, которые могли быть упущены. Во-вторых, для некоторых сценариев тестирования могут понадобиться дополнительные настройки, которые изначально не включены в скоуп проекта. Например, может потребоваться эмуляция отказа какой-либо подсистемы. Если такие настройки учесть заранее, это не только упростит тестирование, но и увеличит его покрытие, позволяя выявить больше багов до того, как их обнаружат пользователи.
В крупных проектах часто ведется параллельная разработка множества компонентов, которые должны взаимодействовать между собой. Один из вариантов — это дождаться завершения всех компонентов и приступить к тестированию уже после их интеграции. Однако такой подход может привести к затяжному процессу стабилизации, поскольку источник ошибок может скрываться в любой из множества частей.
Альтернативным решением является поэтапное тестирование отдельных компонентов. Это требует дополнительных усилий, но они могут оправдать себя, поскольку упрощают стабилизацию системы, разделяя её на более мелкие этапы. Выбор стратегии тестирования зависит от состояния готовности компонентов и особенностей проекта.
С запуском новой функциональности работа над проектом не заканчивается, а переходит в новую фазу сопровождения. Мы сопровождаем продукты на всех этапах их жизненного цикла, от разработки до поддержки. Этап поддержки включает в себя решение новых задач, отличающихся от задач этапа разработки. Пользователи начинают активно использовать функциональность, выявляя баги, которые необходимо оперативно исправлять. Также важно уметь быстро и точно отвечать на вопрос: "Все ли в порядке с нашим сервисом?" Это становится особенно критично, когда поступает свежая информация о воспроизводящей проблеме, требующей оценки ее масштабов и критичности. Способность оценить массовость проблемы и её влияние на пользователей становится ключевым навыком.
Как технический руководитель, я всегда настаиваю на том, чтобы подходы к мониторингу системы и отладке потенциальных проблем были проработаны еще до запуска проекта. Да, такой подход может несколько увеличить объём работы на этапе реализации, но это увеличение связано с задачами, которые в любом случае придется решать. Разница лишь в том, что продумать и реализовать мониторинг и инструменты отладки заранее гораздо менее стрессово, чем устранять проблемы в условиях реального инцидента, когда нехватка необходимых инструментов становится серьезным препятствием.
Заключение
Управление кросс-функциональными проектами в условиях масштабного продукта — это не просто выполнение набора задач, а сложный процесс, требующий продуманного подхода на всех этапах. Четкое определение целей, внимание к архитектуре, адекватная оценка сроков, качественное тестирование и своевременная синхронизация команд позволяют минимизировать риски и достичь высокой эффективности.
Опыт работы с финансовыми продуктами показал, что ключом к успешной реализации проектов является системный подход: постоянное взаимодействие между участниками, готовность адаптироваться к изменениям и тщательная проработка деталей. Это помогает не только успешно завершать проекты, но и создавать устойчивую основу для их дальнейшего сопровождения, что особенно важно в условиях растущей сложности экосистемы.
Комментарии