Есть проекты, где команда к финалу выходит на отличный уровень работы. Общение собрано в одном канале, где всем виден контекст. Трекер задач ведется аккуратно, со связями и приоритетами. Разработка движется по устоявшимся правилам, понятным каждому. Все это складывается к последним неделям проекта, когда основные сроки уже позади, а часть работы сделана хуже, чем могла бы.
Правильные практики команда обычно знает с самого начала: как вести коммуникацию и трекер, как вовремя обсуждать работы с заказчиком и коллегами, как готовиться к встречам. Все это вроде заводится на старте, но теряется по ходу проекта, потому что сложно удержать эффективность этих процессов. Предлагаем разобрать этот феномен.
Как практики вводят и теряют
Дальше четыре случая из нашей практики. В каждом команда взяла хорошую, всем известную практику, но процесс вокруг нее не настроила, и результат вышел совсем не тот, которого ждали.
Флекс скоупа в FFF
Проекты обычно ведут по какой‑то методологии. Возьмём для примера FFF: срок и бюджет фиксированы, гибким остается объем разрабатываемой функциональности. Когда все задуманное в релиз не помещается, дату не двигают и людей не добирают, а решают, что из фич упростить, что отложить в следующую очередь, что убрать совсем. Флекс скоупа здесь штатный инструмент, и пользоваться им предполагается постоянно.
Вот только работает он, пока есть что упрощать и переносить.
Получается, что реально полезные фичи приходится излишне флексить ближе к концу проекта. Практика вроде бы есть, методология ее требует, а пользы от нее ноль, потому что подключают ее слишком поздно.
Контракты по API-first
Контракты между бэкендом и фронтендом можно устроить по-разному. Один из распространенных подходов называется API-first: бэкенд сначала фиксирует контракт (список эндпоинтов, модели запросов и ответов) и отдает его фронту, а тот сразу начинает реализовывать макеты, не дожидаясь готовой логики на сервере. Подход особенно хорош, когда фронтенд двигается намного быстрее бэкенда. Бэк делает контракты, и фронты могут сделать задачу комплексно. Когда бэк дойдет до реализации логики, переделывать либо вообще ничего не придется, либо изменения будут минорные. На длительной дистанции это заметно помогает проекту.
Например, эндпоинт «список заказов» пока ничего не считает и отдает пустой ответ, но форма его уже зафиксирована, и фронт по ней работает. Пока контракт держат в актуальном состоянии, обе стороны идут параллельно и экономят время. Стоит перестать за ним следить, например вовремя не обновить при изменениях, и подход оборачивается против команды. Фронт строит экраны по устаревшему контракту, потом все переделывает, а бэкенд снова становится узким горлышком.
Груминг
На груминге разработка, аналитика и дизайн вместе разбирают будущую фичу до того, как она уйдет в работу. Смысл в том, чтобы заранее вскрыть сложности и договориться, что упростить, пока, например, макеты еще не утверждены. Но все это работает при одном условии: участники приходят подготовленными. Если разработка впервые видит макеты прямо на созвоне, вникнуть в сложность связей между сущностями на лету не выходит, и встреча идет вхолостую. Тему формально обсудили, а детали так и не проработали. Чтобы груминг давал результат, вокруг него нужен процесс: заранее разослать адженду, дать людям время посмотреть материалы.
Общение в общем чате
Обмен рабочими вопросами в команде редко налаживается сам собой. Распространенная рекомендация: выносить всё в общий чат, чтобы контекст был виден всем и не оседал в личных переписках и устных разговорах на дейликах. Практика известная и разумная, но сама по себе приживается не всегда. Разработчики, особенно менее опытные, неохотно пишут вопросы при всех. Кому‑то неловко, кто‑то не любит общаться в большой группе. Если это не поддерживать, не показывать пример, не заводить треды по направлениям, не возвращать людей из лички в общий канал, общение снова расползается, и контекст перестает доходить до команды.
Во всех четырех случаях практика сама по себе правильная и известная. Разница только в том, поддержан ли вокруг нее процесс.
Почему процесс разваливается
Если приглядеться к примерам, видно, что практики отваливаются по вполне предсказуемым причинам, и халатность тут почти ни при чем. Причин три.
Давление сроков. Как только проект уходит в отставание, все внимание команды переключается на то, чтобы нагнать план. И первым под нож идет то, что не горит прямо сейчас. Подготовка к грумингу, обновление контракта, спокойное обсуждение, что упростить. Да, сейчас эти вещи стоят времени и их игнорирование аукнется потом. Но это будет потом. Под давлением сроков отложенная во времени выгода почти всегда проигрывает сиюминутной экономии, и поддержание практик откладывается. Хотя именно в отстающем проекте продуктовые практики нужны сильнее всего, а удерживать их там труднее всего.
Нет ответственного. Поддержание практики — отдельная работа, и обычно это работа руководителя: проследить, что груминги готовятся, что контракт обновили, что вопросы выносят в общий чат. Если роли на проекте распределены нечетко или заняты людьми без нужного опыта, следить за этим оказывается некому. Каждый занят своими задачами, а практика, за которой никто не закреплен, живет ровно до первого сбоя. Никто вроде бы и не отказывался ее вести, просто это не было ничьей обязанностью.
Ощущение, что практика уже работает. Есть распространенное заблуждение: практику считают внедренной в тот момент, когда о ней договорились. Договорились выносить вопросы в общий чат — значит, вопрос закрыт. Но договоренность — это только старт. Практика требует постоянного возобновления, поддержки. Момент, когда практика перестала соблюдаться, обычно никто не замечает, потому что формально-то она есть.
Насколько сильно все три причины бьют по проекту, во многом зависит от зрелости команды.
Если люди уже работали по методологии, которую используют на проекте, и видели, чем заканчивается брошенный груминг или устаревший контракт, они поддерживают практику сами.
Бэкендер без напоминаний обновляет контракт, потому что знает, во что обойдется переделка на фронте. Под давлением сроков такая команда тоже что‑то срезает, но понимает, чем жертвует, и возвращает отложенное, как только становится полегче. Руководителю в зрелой команде заметно проще: за практиками следит не он один, и одна пропущенная проверка ничего не ломает. В команде, где много новичков или людей, которые с этими подходами раньше не сталкивались, все держится на руководителе, и любая из трех причин наносит вред быстрее.
Зачем ретро отстающему проекту
Заметить, что практика начала отваливаться, проще всего на регулярном ретро. Команда раз в спринт разбирает, что мешало работать, и проблемы всплывают раньше, чем успевают стать привычными. Когда проект отстает, ретро кажется лишней тратой времени всей команды. Но именно там оно окупается быстрее всего: одна вовремя замеченная проблема экономит недели.
На одном из наших проектов и API-first, и подготовка к грумингам из примеров выше появились как раз после ретро. С грумингами, правда, эффект продержался ровно до тех пор, пока за подготовкой следили.
Похожая история вышла с правками заказчика: на демо он пытался поменять уже утвержденные макеты и логику, и такие мелкие переделки сильно выматывали команду. Среди прочего завели файл, где отмечали, какие макеты и какая функциональность согласованы с заказчиком, чтобы при попытке что‑то поменять опираться на зафиксированное. Это не помогло. С таким документом нужно уметь работать, а ни у тимлида на старте проекта, ни у первого PM такого опыта не было.
Что помогает практике удержаться
Обычно перелом наступает, когда на проекте появляется человек с опытом, который берет удержание на себя. То есть человек, который видит, что практику пора вернуть в работу, и знает, как это сделать. С его приходом разрозненные попытки вести общий чат превращаются в устойчивую привычку, трекер задач из свалки тикетов становится системой со связями и приоритетами, а код приводят к единому стилю.
Но у по-настоящему закрепленной практики есть более надежный признак: она продолжает работать, даже когда тот, кто ее внедрял, отходит от проекта. Проверка следующая. Отпустите тимлида в отпуск на пару недель где-нибудь в середине проекта и посмотрите, что изменится. Если, условно, общение по-прежнему идет в общем канале, груминги готовятся, контракты обновляются без напоминаний, значит, практики встроены в процесс. Но лучше этот эксперимент проводить в середине проекта. Отпуск тимлида перед релизом ударит по проекту сильнее любой проверки. А если за эти две недели что‑то поломается, процессы еще успеют поправить, пока до конца далеко.
Отсюда и понимание, что вообще значит «удержать практику». Ручной контроль — промежуточная стадия: он нужен, чтобы практика прижилась, но пока все держится на внимании конкретного человека, конструкция остается хрупкой. Закрепленной она становится тогда, когда встроена в то, как команда работает по умолчанию, и не требует, чтобы кто‑то ежедневно ее подпирал.
Сильный руководитель это понимает и с самого начала настраивает работу так, чтобы команда могла действовать автономно, а не замыкалась на нем.
Что в итоге
Умение удерживать практики приходит с опытом, а опыт чаще всего набирается ровно на таком проекте, где половину практик растеряли по дороге и поняли это задним числом. К финалу команда скорее всего выправится и нагонит темп, но будет, конечно, поздновато. Зато будет и опыт 🙂
Вывод простой. Методологические инструменты, всякие контракты и правила взаимодействия между сервисами, подготовка к встречам, практики общения в команде доступны каждому. И опытность команды определяется не объемом этих знаний. Отличает способность удерживать практику под давлением сроков, когда проще всего ее бросить.
Практику приходится возобновлять снова и снова, особенно тогда, когда на это меньше всего времени. Поэтому закладывать стоит не только саму практику, но и того, кто будет за ней следить, и встраивать ее в работу так, чтобы она держалась без ежедневного ручного контроля.
