Привет! Меня зовут Инесса. Я — аналитик в компании fuse8. Предлагаю сегодня поговорить о том, как встроиться в уже сработавшуюся команду. По моему опыту, это всегда испытание. Почти как игра в русскую рулетку: не знаешь, как команда примет новичка и как быстро он подстроится под общий ритм. Новому человеку нужно время на адаптацию, обучение и погружение в процессы. И только потом можно по-настоящему оценить его вклад.
Когда в команду приходит аналитик, ситуация усложняется. Его появление почти всегда приводит к изменению привычных процессов, которые команда, возможно, долго и старательно выстраивала до этого. А ломать привычное всегда неприятно. Поэтому на старте аналитик сталкивается с двойной нагрузкой: ему самому нужно влиться в коллектив, и при этом помочь команде принять перемены.
Совсем недавно я сама оказалась в такой ситуации — была тем самым аналитиком, пришедшим в уже готовую команду. В этой статье я поделюсь своим опытом: расскажу, как аналитику органично влиться в коллектив, выстроить взаимодействие с каждой ролью и со временем стать по-настоящему «своим».
Зачем команде аналитик
Основа крутого продукта закладывается на моменте определения его цели и формирования требований, которые к нему выставляются. И вот этих самых требований может быть очень много… А еще часто они расплывчаты и неточны. Иногда даже сам заказчик не знает, чего именно он хочет. А если никто не понимает, каким должен быть итог, как вообще оценить результат?
И вот тут появляется аналитик — человек, который переводит «хочу» заказчика на язык команды. Он превращает идеи в чёткие и понятные требования, помогает всем участникам одинаково понимать цели и представлять, каким должен быть продукт.
Если аналитика в команде нет, его функции размазываются по всей команде. Например:
дизайнер собирает требования и параллельно делает макеты;
проджект-менеджер описывает эти требования для разработчиков, хотя сам их напрямую не собирал;
тестировщик придумывает критерии приёмки, исходя из чужих слов и собственных догадок.
В итоге то, что должен делать один человек, выполняют несколько, теряя по дороге важные детали. Каждый при этом тратит время и внимание не только на свои прямые обязанности, но и на дополнительную работу, которую не всегда делает качественно, просто потому что это не его зона экспертизы.
Аналитик устраняет этот хаос. Он отвечает за весь жизненный цикл требований — от сбора до проверки реализации. И делает так, чтобы ни одна важная деталь не потерялась. Благодаря этому команда работает спокойнее, быстрее и с меньшим количеством недопониманий, а продукт развивается предсказуемо и последовательно.
Первые шаги
Если случилось так, что вы пришли в команду, работающую без аналитика — поздравляю! Впереди вас ждёт много всего интересного! Главное — не спешить что-то менять. Сначала разберитесь, как всё устроено, и только потом аккуратно предлагайте улучшения.
Вот несколько шагов, с которых можно начать:
1. Наблюдайте и изучайте процессы.
Первые недели посвятите тому, чтобы понять, как устроена работа внутри команды: кто за что отвечает, как ставятся задачи, как принимаются решения. Смотрите, где возникают сложности или недопонимания — возможно, именно там вам и предстоит что-то поменять.
2. Не бойтесь задавать вопросы.
Даже если кажется, что вопрос глупый, а ответ на него знают все (кроме вас). Ваши коллеги — не экзаменаторы, а партнёры. Совсем скоро вы вместе будете работать над крутым продуктом, и чем быстрее вы проясните детали, тем раньше сможете принести пользу.
3. Предлагайте изменения постепенно.
Когда вы разобрались в процессах, можно осторожно предлагать улучшения. Не стоит перестраивать всё под себя. Важно сохранить баланс между новыми идеями и уже устоявшимися подходами. И уж точно не стоит ломать то, что хорошо работает, просто ради самого факта изменений.
4. Учитывайте интересы всей команды.
Например, вам может казаться полезным проводить больше встреч для погружения в новый функционал. Но разработчики, как правило, не любят длительные созвоны, и это важно учитывать.
Начните с малого: договоритесь о коротких еженедельных встречах для обсуждения новых задач. А для небольших уточнений используйте асинхронные каналы — рабочие чаты или комментарии в задачах. Если вопрос не требует коллективного обсуждения или фундаментального решения, проще и быстрее закрыть его письменно. Это экономит время всех участников и снижает усталость от бесконечных митингов.
5. Помните о цели: не ломать, а улучшать.
Ваша задача не навести порядок любой ценой, а сделать жизнь команды проще и понятнее. Чем мягче вы будете внедрять изменения, тем быстрее вас начнут воспринимать не как чужака, а как человека, который помогает.
Ниже я расскажу, как стать «своим» для каждого члена команды.
Взаимодействие с заказчиком
Знакомство с заказчиком — всегда волнительный и ответственный момент. Теперь именно вы тот человек, который будет его слушать, уточнять, задавать вопросы и искать истину.
Основа отношений с заказчиком — это прозрачный процесс сбора и обработки требований. От того, насколько чётко и системно он выстроен, зависит не только результат проекта, но и уровень доверия между вами. Ведь именно на этом этапе решается, появится ли в итоге нужный продукт, или команда скатится в бесконечные переделки из-за недопонятых, несогласованных или даже утерянных требований.
Чтобы этого избежать — внедряем регулярные встречи по сбору требований. На них аналитик:
задаёт уточняющие вопросы;
фиксирует договорённости и формирует отдельный документ с требованиями;
презентует этот документ заказчику, чтобы убедиться, что всё понято и зафиксировано верно;
получает явное «согласовано».
Только после этого требования можно превращать в задачи и передавать команде.
У нас процесс взаимодействия с заказчиком выглядит так:
Понедельник — встреча по сбору требований.
Вторник — подготовка документа по итогам встречи.
Среда — груминг документа с командой.
Четверг — демо дизайна (по предыдущей функциональности) и демо документа по итогам встречи в понедельник.
Пятница — подготовка проектной документации по результатам демо в четверг.
Дальше все зависит от объема каждой конкретной фичи. Если она объемная — продолжаем проработку на следующей неделе. Если нет — переходом к обсуждению новых требований по тому же циклу.
Важно
Новые идеи у заказчика появляются спонтанно, а не только на специально выделенных встречах. Это может произойти в любой момент: во время демо, обсуждения дизайна или даже в неформальном разговоре. Для заказчика важно, чтобы его мысли и предложения не терялись, а были услышаны, зафиксированы и проработаны. Поэтому, если идея прозвучала между делом, зафиксируйте её сразу. А обсудить детально можно будет уже на регулярной еженедельной встрече.
Взаимодействие с дизайнером
Дизайнер — это человек, который визуализирует плоды ваших встреч с заказчиком. Чтобы сделать это качественно, ему важно понимать:
бизнес-ценность требований;
полный путь пользователя;
возможные сценарии масштабирования.
Поэтому задача аналитика — донести всю эту информацию чётко, структурно и без двусмысленностей. Чем лучше дизайнер понимает контекст, тем точнее он передаёт смысл в интерфейсе.
Первое, что нужно сделать — это договориться о порядке взаимодействия. Идеальный сценарий выглядит так: аналитик собирает новые требования, пока дизайнер занят проектированием и согласованием прошлых. Так процессы идут параллельно, без простоев.
Но мы-то знаем, что идеально не бывает почти никогда. Часто дизайнер и аналитик вынуждены одновременно работать над одной и той же функциональностью. Тут главное — не мешать другу другу и помнить, что у каждого своя зона ответственности:
аналитик документирует и уточняет;
дизайнер проектирует и визуализирует.
Чтобы не терять синхронизацию, можно договориться, чтобы дизайнер тоже присутствовал на встречах по сбору требований. Это поможет ему заранее знакомится с будущими фичами и, если приоритеты вдруг резко меняются, быстро включаться в работу уже по новым требованиям.
Важно
Документация и макеты не должны противоречить друг другу. Текст — это описание будущего продукта, а дизайн — его визуализация. Чтобы минимизировать расхождения, важно проверять друг друга на соответствие ещё до передачи задач в разработку. Если небольшие несостыковки всё же возникают, у нас принято считать главным дизайн — ведь в итоге заказчик согласует именно макеты. В таких случаях документация просто обновляется под финальный вариант дизайна.
Взаимодействие с разработчиками
Разработчики — ваши друзья и союзники. С ними вы будете часто созваниваться, договариваться и, возможно, даже спорить ?
В работе с ними есть три главных принципа.
1. Сперва разберитесь, как задачи попадают к разработчикам сейчас.
Для начала проследите, в каком виде задачи доходят до команды. Соберите обратную связь: что в текущем формате удобно, а чего не хватает.
Например, у нас в команде до появления аналитика разработчики брали задачи в работу, опираясь только на согласованные макеты. Дизайнер старался прописывать функциональные и нефункциональные требования прямо в комментариях к макетам, но это занимало очень много времени.
2. Предлагайте улучшения аккуратно.
После того как вы поняли, как устроен процесс, можно предлагать изменения. Но помните: до вас команда работала по-своему, и появление аналитика — это вмешательство в привычный порядок вещей. И да, иногда его могут воспринимать настороженно.
Например, я предложила разгрузить дизайнера: часть описания требований на макете взять на себя и фиксировать их в описаниях задач для разработки.
Дизайнеру идея понравилась. А вот разработчики сначала напряглись. До этого они ориентировались только на макет, где всё было в одном месте, а теперь пришлось ходить между описаниями задач и макетами. Какое-то время мы поработали в таком формате, но позже совместно его доработали.
Оказалось, хранить требования в описаниях задач очень неудобно: задачи закрываются, макеты переходят в интерфейс, и информация постепенно теряется в общем скоупе. Поэтому в итоге мы сложили все в одном месте — в документации к модулю: бизнес-описание функциональности, ТЗ на разработку, ссылки на макеты и связанные задачи. В описании задачи остались только ссылки на конкретный раздел документации, макеты + критерии приемки.
Вот так, методом проб и ошибок, и, что самое главное, всей командой, мы смогли выработать процесс, который подошел всем.
3. Покажите пользу новых процессов
Не расстраивайтесь, если ваши идеи встретят сопротивление. Спокойно объясняйте, зачем нужны изменения и какую пользу они принесут команде — в скорости, прозрачности и качестве результата.
На практике быстро становится заметно, что проработанные задачи с документацией брать в работу проще и приятнее. Разработка таких задач идёт быстрее, потому что уходит меньше времени на уточнение деталей.
Чтобы понимать, насколько задача готова к работе, удобно использовать критерии Definition of Ready (DoR).
У нас считается, что задача готова к передаче в разработку, когда:
готова документация;
проведён груминг;
согласован макет;
дана оценка;
в задаче прописаны критерии приёмки.
С такими задачами начинать новый спринт — одно удовольствие! И скоро ваша команда это почувствует и поймет.
Взаимодействие с тестировщиками
Появление аналитика в команде очень обрадует тестировщиков. Тестировать проработанные задачи значительно проще, а если аналитик ещё прописывает критерии приёмки, то это просто подарок!
Ваш главный союзник в работе с QA — качественная документация. Бывает, что аналитик и дизайнер уже ушли на сбор требований по новой функциональности, а тестировщик только приступает к проверке задач по предыдущим требованиям. У него появляются вопросы, на которые, кроме вас, как хранителя знаний, никто не сможет ответить.
Если документация хороша, вы легко сориентируетесь и быстро поможете закрыть все вопросы без долгих поисков и уточнений. А если и тестировщик хорош и достаточно автономен — он сам сможет обратиться к документации и найти всё, что ему нужно ?
Еще один ценный для тестировщика артефакт — критерии приёмки. Когда они прописаны подробно и чётко, тестирование идёт быстрее, а недопонимания становятся редкостью. Тестировщик не тратит время на догадки, что именно ожидалось от функциональности, а проверяет ровно то, что было согласовано.
Хорошая документация и чёткие критерии приёмки делают процесс тестирования понятным и прозрачным. А довольный тестировщик — верный признак того, что аналитик всё делает правильно.
Как понять, что аналитик успешно встроился
Поздравляем — вы прошли игру и стали «своим»! Пришло время подвести итоги и понять, действительно ли вы на одной волне с каждым участником команды.
Лучший способ это проверить — спросить саму команду. Запросите обратную связь на ретро или просто пообщайтесь с коллегами лично: их слова лучше любых метрик покажут, насколько комфортно и эффективно вы встроились в процесс.
Вот какие сигналы будут говорить о том, что всё получилось:
Дизайнер: «Мне больше не нужно тратить время на проработку всех деталей. Я могу абстрагироваться и творить на макетах, зная, что есть человек и документ, к которым можно обратиться».
Разработчик: «Вместо того чтобы тратить время на уточнения, я просто беру задачу и работаю. Все сценарии описаны, критерии понятны».
Тестировщик: «Каждая задача снабжена критериями приёмки. Я не трачу часы на догадки — могу сосредоточиться на проверке качества. А если что-то не понятно — обращусь к документации».
Главное — продолжайте слушать и слышать коллег. Аналитик стоит в самом начале жизненного цикла задачи и сопровождает её до конца. Поэтому именно в его власти сделать процесс работы над ней лучше, прозрачнее и эффективнее для всей команды.