Как наладить взаимодействие с заказчиком. Часть 3: как закреплять договоренности с заказчиком
Третий пост из серии о коммуникации с клиентами 👥

Ситуация. При общении с заказчиком, на созвонах и в переписке возникает много бизнес требований, деталей, хотелок и уточнений. Как же закрепить договоренности с заказчиком, чтобы избежать изменений и недопонимания с заказчиком.
Задача. Наладить процесс закрепления договорённостей с заказчиком и командой.
Решение. Есть несколько нехитрых механизмов, которые помогают не терять контекст обсуждений и договоренностей. Например:
Вести документ, в котором прописываются результаты обсуждений.
Записывать минутки — краткие результаты обсуждения, записанные и расшаренные на команду и заказчика.

Мы чаще используем минутки, потому что их, как минимум, их быстрее и легче написать😜


Читайте также:
Как наладить взаимодействие с заказчиком. Часть 1
Как наладить взаимодействие с заказчиком. Часть 2

#tips

​​Всем привет! Как ваши выходные? Надеюсь все отдохнули, потому что мы припасли для вас сегодня интересную тему: согласование ТЗ с заказчиком 📝

Процесс согласования ТЗ обычно отличается на разных проектах и зависят от договорённостей с заказчиком🤝 Два наиболее распространённых варианта:

Заказчик принимает активное участие в процессе проектирования, внимательно читает ТЗ и понимает, что хочет от продукта 😻
Инициатива в общении исходит от исполнителя: он поддерживает общение с заказчиком, старается добиться понимания и участия в процессе согласования ТЗ😼

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

А какие полезные практики используете вы? Делитесь в комментариях👇

​​Surf и новички: как мы проводим онбординг
Сегодня мы поделимся с вами закулисьем процесса вхождения аналитика в Surf 🤟🏻

Наш отдел активно растёт: к нам регулярно приходит на работу много классных ребят. Нам важно, чтобы коллегам было комфортно, поэтому мы уделяем адаптации и онбордингу большое внимание💻

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

Теоретический блок 📖
Как устроена компании и глобальные рабочие процессы. Процессы отдела: изучение Wiki, артефактов аналитиков.
Ознакомление с техническим стеком мобильной разработки: термины, гайдлайны, технологии.

🤗 Если коллега в другом городе, приглашаем приехать в офис и со всеми познакомиться вживую 👋🏻


Увлекательная практическая часть 🚀
- На реализованном ранее в студии проекте проектируем API для фичи и пишем сваггер.
- Пишем ТЗ по стандартам, принятым в отделе.
- На примере реальных проектов смотрим реализацию фич, специфичных для мобильной разработки: например, работу с кэшем, геолокацией и так далее.
- Моделирование процессов: строим несколько диаграмм для разных фич.

Вуаля, готово! По итогам онбординга коллега имеет полное представление о процессах, которые есть в компании и отделе, и готов ринуться в бой!

P.S. Приходите к нам, у нас круто!😉

#team

​​🍼 Аналитика для самых маленьких. Секреты хорошего собеседования

Недавно проходил день открытых дверей ВГУ.
📈Рассказали про мобильную аналитику,
☕️ выпили 100+ чашек американо,
🧑‍🎓провели экспресс-собеседования со студентами.

Хотим поделиться инсайдами: на что обращали внимание на собесах. Тсссс, только никому 🤫

Секрет №1: софт-скиллс. Большая часть работы аналитика состоит из коммуникации с людьми: это одна из ключевых характеристик, которую мы искали в соискателе.

Совет: веди диалог, задавай вопросы (в нашей культуре это уже давно не признак «двоечника», а признак умного вдумчивого человека!), описывай релевантный для аналитики бэкграунд: например, если у тебя был опыт переговоров с заказчиком или проектирования API.

Секрет №2: системность. Мы обращаем внимание даже на речь: слова демонстрируют, есть ли системное мышление у кандидата. Ценим, когда в речи прослеживаются причинно-следственные связи, нет эмоционально-окрашенной лексики и большого количества воды 🌊

Секрет №3: подготовленность. На собес стоит приходить подготовленным: понимать, кто такой аналитик, какой ты хочешь видеть свою деятельность в профессии, какие скиллы пригодятся.

Умение программировать на Java, написание фанфиков и навыки юнит-тестирования — это круто 🤘 Но… Подумай, нужны ли эти знания в аналитике?

Кстати, если ты студент 1–2 курсов 👶, не стесняйся ходить на собеседования: ты увидишь точки роста и узнаешь, что на самом деле важно работодателям (это может отличаться от того, что говорят в универе).

🤫 Это были наши маленькие секреты, надеемся они были для тебя полезными.

❓ Как ты думаешь, какие ещё скиллы мы ценим в аналитиках? Напиши свой вариант в комментах, и мы добавим его в следующую подборку 🥰

#tips

​​🍼 Аналитика для самых маленьких. Как быстрее погрузиться в мир аналитики и подготовиться к собеседованиям


1️⃣ Смотреть подборки об аналитике на ютубе, посещать вебинары и летние школы.
Рекламная пауза: советуем посмотреть летнюю школу аналитики Surf на нашем канале 🥸

Плюсы: Начинаете путь в аналитике не с книг, а с советов от реальных людей.

Они расскажут о рабочих кейсах, особенностях профессии и важных навыках на примере реальных проектов🤓 Что еще полезнее — поделятся промахами в начале пути и помогут понять, «как начать действовать» 🧚‍♀️

2️⃣ Не зацикливаться на одном авторе: читать и смотреть разных 🧐

В аналитике полезно использовать разные подходы, инструменты и артефакты: выбор зависит от компании и проекта 🤪

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

3️⃣ Прокачивать ключевые аналитические навыки: умение работать в команде, тайм-менеджмент, ведение деловых переговоров

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

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

​🍼 Аналитика для самых маленьких. Книги для буста в профессии аналитика

Решили поделиться книгами, которые любим сами и советуем начинающим коллегам. Они помогут понять профессию аналитика и устройство рабочих процессов.
👽

«Путь аналитика. Практическое руководство IT-специалиста» Перерва Андрей, Иванова Вера. Книга помогает познакомиться с аналитикой, выбрать вектор развития или продолжить погружение в профессию, если есть общая база знаний😼

«Как привести дела в порядок. Искусство продуктивности без стресса» Аллен Дэвид. Грамотный тайм-менеджмент для аналитика — 50% успеха. Прочитай книгу и узнай, как грамотно планировать ресурсы и успевать решать рабочие задачи в положенный срок ✏

«Разработка требований к программному обеспечению. Руководство» Вигерс Карл. Для новичков это — полный гайд о работе аналитика. Для ветеранов дела — карманный справочник «проблема — решение». Здесь собрана база аналитических подходов, кейсов и требований 🤘

«Требования для программного обеспечения. Рекомендации по сбору и документированию» Корнипаев Илья. Книга для тех, кто хочет научиться эффективно работать с требованиями при сборе, документации и проверки 🔎

«BABOK». Магнум-опус от аналитиков для аналитиков. Бабук (не путать с Бабадук👹) содержит все знания, компетенции, методы и техники аналитики с практической точки зрения.

Какие полезные ресурсы для изучения аналитики используете вы? Делитесь в комментариях 🙋‍♀️

Для тех, кто хочет БОЛЬШЕ полезной информации, читайте другие посты из серии «Аналитика для самых маленьких»:

🔹 Секреты хорошего собеседования
🔹 Как быстрее погрузиться в мир аналитики и подготовиться к собеседованиям

​⏰ Уже завтра: Международная конференция по системному и бизнес-анализу

Привет! 27–28 мая пройдёт Международная конференция по системному и бизнес-анализу: ANALYST DAYS / 14🤩

За 2 дня выступит более 50 спикеров👩‍🎓 Они расскажут:
— Как собирать и описывать требования.
— Как строить архитектуру систем и предприятий, разрабатывать интеграции.
— Какой аналитику нужен минимальный набор знаний и методов.
— Много других интересных тем😉

Surf тоже поделится опытом🤓
На конференции выступят с докладами:
🔹Эллина Сатурова, руководитель отдела бизнес-анализа. Она расскажет, как в Surf помогают стажёрам прокачать софт-скиллы. Доклад подойдет новичкам в профессии и опытным аналитикам, которые занимаются стажировками.
🔹Айдар Власов, ведущий аналитик. Расскажет, как провести предпроектное исследование, чтобы точнее определить потребности заказчика и объём работы на будущем проекте.

Analyst Days пройдёт 27–28 мая офлайн в Москве и онлайн.
Подробнее о конференции >>

​​👌 Скажи «Да» сервису Dadata

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

В арсенале — много полезного: определение города по IP-адресу, получение полных данных по адресу из официального реестра ФИАС и другие вкусняшки 😋

Расскажем об опыте работы с одной из фич: как грамотно подготовиться к работе с сервисом подсказок по адресам. Подсказки — это когда вводишь в поисковую строку «Кощ», а тебе предлагают «Кошка пушистая с пятью подушечками на лапке» 😼

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

Вопросы. Вместе с заказчиком определитесь: 
▪️ Будет ли фронт взаимодействовать с dadata напрямую или через сервер?
▪️ Какие из полей ответа на запрос подсказок по адресам нужны для отображения на фронте? 
▪️ Какие из данных по подсказкам требуются серверу: только те, что отображаются на фронте, или расширенная модель? Гео-координаты, почтовый индекс и так далее?

Лайфхак. Если в приложении уже есть исправно работающие фичи по определению города, населенного пункта или района — не спеши их выпиливать🦈 С помощью этих данных возможно сузить круг поиска при работе с подсказками в Dadata. Как это сделать 

Пример: когда это может пригодиться? Допустим, ты ищешь в приложении свою родную улицу Ленина, д. 2, но в нашей стране почти в каждом городе есть такая улица👉👈

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

Это был маленький совет по тому, как подготовить проект к работе с Dadata. В следующих постах продолжим😉

Давно не виделись 🤟

Хотим сегодня обсудить тему, которая коснулась непосредственно нас и с которой встречаются многие — эмоциональное выгорание😩

Что такое эмоциональное выгорание? Это состояние «‎я устал и меня ни на что не хватает»🏹

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

Составили список советов, которые помогают нам. Верим, что помогут и вам:

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

Найти новую деятельность на работе. Это может быть проведение мероприятий, обучение стажёров, новый курс по вашему направлению — что-то, что станет перезагрузкой и даст вдохновение🐉

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

Подумайте, правильно ли распределены зоны ответственности на проекте. Может быть, вы перерабатываете на постоянной основе и выполняете чужие задачи? Если так — попробуйте поменять подход, поговорите с коллегами и распределите зоны ответственности заново 🙋‍♀️

А что вам помогает справляться с эмоциональным выгоранием и не «падать» в него?

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

​Жёсткие последствия отсутствия «‎мягких навыков»
Или как начинающему аналитику прокачать софт-скиллы

Бизнес-аналитику нужны софт-скиллы. И точка😁
А именно:
🔹 самоорганизация,
🔹 коммуникативные навыки,
🔹 лидерство,
🔹 решение конфликтов,
🔹 системное мышление,
🔹 принятие решений,
🔹 адаптируемость.
Этот набор высечен в камне библии аналитиков — BABOOK. И тут никаких разногласий нет.

Самое интересное начинается, когда софт-скиллам нужно научить с нуля или подтянуть отстающие. Как это делать, единой методики нет. А вот нам удалось выстроить систему, по которой мы обучаем стажёров. Путь был тернист — скажем честно.

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

Заинтригованы? Тогда посмотрите запись нашего выступления на конференции Analyst Days. Руководитель отдела бизнес-анализа Surf Эллина Сатурова рассказала обо всём без утайки😉

Смотреть видео о прокачке софт-скиллов >>

​💇 Кто и зачем причёсывает фичи. Спойлер: не парикмахер

Расскажу историю. Реализовывали один элемент экрана на двух платформах. 👉 Android приступили к задаче раньше iOS, и сделали её за два часа.

👉 Когда iOS принялись за задачу, оказалось, что согласованные заказчиком ТЗ и дизайн-элементы не нативны. Их можно сделать только через костыли, но ТЗ и макеты придется апнуть под особенности платформы. Запросили оценку у iOS, получили 14 часов ☠

Этого можно было бы избежать, если бы мы заранее провели груминг фичи и выявили проблему 🕵️‍♂️

Что такое груминг фичи:
1️⃣ Собираем требования от продакт-оунера.
2️⃣ Устраиваем скрам с разработчиками и тестировщиками.
3️⃣ Рассказываем суть фичи, основные сценарии использования и проходимся по прототипам дизайна, если они готовы (если нет, не переживай, всё будет 🐺).

Каждый участник может задавать вопросы по фиче.➡️ Как правило, выявляются 3–4 основных момента, которые значительно меняют аналитику.

Как груминг фичи оптимизирует процесс

1. Снижается время отладки ТЗ: нереализуемые моменты выявляем до начала работы над ТЗ, а не когда пишем код.

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

3. Меньшее количество багов 🤖, по которым консультируются с аналитиком: снижается степень расхождения ожидаемого и фактического вижена функционала.

4. Аналитика меньше привлекают к вопросам для написания проверок: тестировщики сами знают основные сценарии работы системы.

Не повторяйте наших ошибок — учитесь на них!

​Как это было: выступление на конференции Analyst Days
Рассказывает Эллина Сатурова, руководитель отдела бизнес-анализа в Surf

Тема доклада
Я выступала с докладом «Жёсткие последствия отсутствия мягких навыков». Как видно из названия, это о софт-скиллах. Тема близка сообществу: всем понятно, какие софт-скиллы нужны, а вот как их развивать — это уже вопрос.

У нас в Surf есть стажёрский курс для аналитиков: ребята учатся хардам и софтам на примере реальных проектов. Проект приносит хорошие результаты: стажёры, которые прошли курс, становятся джуниорами и под руководством старших аналитиков работают в реальных коммерческих проектах компании.

Я захотела поделиться с комьюнити методиками по развитию софт-скиллов, по которым мы обучаем стажёров в Surf. Так родилась идея выступить на конференции и тема.

Подготовка
Подготовка к докладу заняла около 20 часов: прогоны с куратором, внутри команды Surf, дописывание и переписывание материала.

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

Выступление
Я выступала во второй день. В первый мы пришли на конференцию, я посмотрела, как всё устроено, как много народу, — и стало страшно.

Во второй день я успокоилась: выступление неотвратимо, будь что будет😁 Поэтому выдохнула, поднялась на сцену и начала рассказывать.

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

Советы
Не тренироваться слишком много🙈

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

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

Запись доклада Эллины >>

​Как общаться в команде

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

Подготовили несколько правил 🤓

1️⃣ Поддерживать общий эмоциональный фон в команде. Короткие разговоры на созвонах о жизни, выходных, хобби помогают расслабиться и сбавить напряжение на общих встречах.
2️⃣ Организовывать совместные выезды на природу, кафе, парки: это сближает, помогает команде работать слаженно и получать удовольствие от совместной работы.
3️⃣ Не игнорировать проблемы в общении и недопонимания, которые есть в команде. Можно инициировать созвон и поговорить с ребятами, если что-то идёт не так. Проблема будет решена, и всем станет комфортнее работать: никто не будет тратить ресурсы на обиду, грусть, агрессию.
4️⃣ Помогать друг другу в команде: круто, когда каждый знает, что всегда можно обратиться за помощью к коллеге. Задачи сразу будут решаться быстрее и эффективнее.
5️⃣ Обсуждать с командой важные моменты вместе, выслушивать мнение каждого, находить оптимальное решение: каждый член команды может внести интересное предложение или подход.

Такие правила мы стараемся соблюдать у нас в команде: они кажутся простыми, но очень важны и работают почти всегда.
#tips

​Как общаться с руководителем

Тему «‎Как общаться с руководителем» обсуждают редко. Правильнее даже сделать приписку в «IT», потому что именно в этой сфере общение с руководителем организовано обычно эффективнее, чем в других.

1️⃣ Говорите о своих идеях и планах с руководителем, не стесняться предлагать новое. Можно найти поддержку идеи и помощь в реализации. Руководитель сориентирует куда двигаться дальше.
2️⃣ Попросите дополнительные обязанности, когда чувствуете, что у вас достаточно времени и ресурсов. Руководитель обязательно найдет что-то интересное и подходящее под ваши навыки и опыт.
3️⃣ Старайтесь сразу сообщить руководителю или лиду, если что-то идёт не так: и не важно, начинающий вы аналитик или за вами закрепилась репутация «непобедимого мастера БА». Лучше не стесняться и попросить помощи, чем долго и безуспешно пытаться решить проблему самому.
4️⃣ Помните, что руководитель — это человек, который заинтересован в ваших успехах на проектах и в отделе так же, как и вы. Он всегда готов помочь и найти лучшее решение.
#tips

Если взять ТЗ от заказчика и сделать ровно по нему, недовольны будут все
Как понять, что на самом деле хочет заказчик, и реализовать это

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

Как итог:
😢 План работ съезжает по срокам.
😢 Увеличивается стоимость разработки.

Как стартовать разработку правильно 
👍 Поможет нулевой спринт — предпроектное исследование в заказной разработке.

Он нужен, чтобы:
✅ Уточнить бизнес-цели проекта: какую основную потребность хочет закрыть заказчик приложением.
✅ Определить целевую аудиторию.
✅ Проанализировать существующие процессы и артефакты. 
✅ Спроектировать архитектуру сервера. 

Тема про нулевой спринт важная, но в одном посте её не раскрыть. Посмотрите подробное видео >>

Как это было: выступление на конференции Analyst Days
Рассказывает Айдар Власов, бизнес-аналитик в Surf 

Тема доклада — важность нулевого спринта в заказной разработке
Что такое нулевой спринт, мы писали в предыдущем посте. 

Подготовка
Подготовка к докладу заняла 40 часов. Каждую неделю мы созванивались с куратором и с командой внутри Surf. 

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

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

Были отдельные моменты, когда нужно было переключиться на свободный рассказ «вот здесь такая табличка» — и всё получалось живее. В дальнейшем буду стремиться к тому, чтобы живой рассказ был на протяжении всего выступления.

Советы
1️⃣ Не соглашаться на самое позднее время. Я выступал последним перед закрытием конференции. Некоторые хотели целенаправленно прийти на моё выступление, но не смогли из-за розыгрышей и других активностей: просили почту, чтобы выслал презентацию.

2️⃣ Добавлять в презентацию комментарии к слайдам. Если что-то вылетит из головы, комментарии помогут продолжить рассказ.

3️⃣ Не заучивать текст выступления наизусть, но хорошо подготовить материал, потренироваться в меру — и тогда на выступлении получится живая речь, которую интересно слушать. 

Полезные ссылки
🔹Презентация про нулевой спринт
🔹Запись выступления про нулевой спринт

​​Работа BA в команде🤝

Привет! Как ты думаешь, сколько аналитиков обычно требуется на проекте: один или несколько?

У нас в Surf частый вариант ответа — «несколько». И это не потому, что мы настолько сладкие булочки, что слиплись вместе, и нас трудно друг от друга отделить (хотя это чистая правда 🥐). Просто задач по проектам много, и делать их надо быстро.

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

👩‍👧Senior + Junior
Комбинация опытного и начинающего аналитиков

➕ Опытный освобождается от рутинной работы, начинающий набирается опыта под присмотром. Подходит для спокойных проектов: чтобы у опытного аналитика хватало времени делать ревью ТЗ и отвечать на вопросы, а у начинающего — изучать новую информацию.
➖Не самое большое усиление команды в моменте. Джун снимает часть нагрузки со старшего аналитика, но одновременно с этим сеньор отвлекается на помощь джуну, а джуну нужно больше времени, чтобы начать приносить максимальную пользу проекту.

👯‍♀️ Analyst + Analyst
Несколько аналитиков на одинаковых ролях

➕Отличный вариант для масштабных проектов, когда одному аналитику сложно прорабатывать и поддерживать все фичи. Скоуп можно поделить на зоны: за каждую отвечает один аналитик.
➖Риск дважды разработать одну и ту же фичу (шутка). На самом деле есть риск по-разному реализовать переиспользуемые элементы: из названия понятно, что они не должны реализовываться каждый раз заново. А если один из членов команды уйдёт в отпуск, другим будет не так просто подхватить его задачи.

Лечение от подобных недугов предусмотрено: помогают совместные груминги, перекрёстные ревью ТЗ и создание в спецификации раздела «Общее по приложению». Однако надо понимать, что эти увеселительные мероприятия занимают достаточно много времени: один аналитик может думать, что они того стоят, а другой с ним будет не согласен.

В следующем посте разберём три менее очевидных модели взаимодействия между аналитиками на проекте. Не переключайтесь🙌

​​Работа BA в команде: часть 2🤝

Продолжаем разбирать, как можно выстроить взаимодействие между аналитиками, когда на проекте их несколько.
В первой части поговорили о двух классических моделях:  
🔹Сеньор + джун
🔹Равноправные аналитики

💃🏻🕺🏼BA + SA + PA
Аналитики делят зоны ответственности не по фичам, а по уровням

Такой вариант разделения мы в Surf не используем: в зависимости от проекта аналитик может выполнять больше функций BA или больше функций SA, но чёткой границы нет — аналитик Surf должен уметь всё. В других компаниях команды могут работать с разделением функций, поэтому мы не могли не упомянуть этот вариант.

👩‍👧‍👦Lead + Analysts team
Лид во главе команды аналитиков

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

👨‍👩‍👦‍👦 Lead Analyst + Analyst + Analyst + Junior
На самом деле все варианты можно комбинировать и смешивать как угодно: главное — закрыть потребности проекта😉

​​Как аналитику и проджект-менеджеру эффективно работать вместе 🙌

У аналитиков и проджект-менеджеров разные обязанности и задачи, но в работе они тесно соприкасаются. К сожалению, при непонимании зон ответственности BA и PM могут мешать друг другу. 

Рассказываем, как правильно распределять зоны ответственности и как это может бустануть команду. 

1️⃣ Обсуждение требований к задаче с заказчиком 
Аналитик:
— согласовывает и уточняет требования,
— управляет требованиями,
— предупреждает о сложностях реализации, 
— отвечает за логику фич,
— ведёт бэклог.

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

2️⃣ Обсуждение требований с командой 
Задача аналитика — проговорить с командой флоу, обсудить спорные вопросы по реализации и закрепить основные поинты. 

Задача PM — проследить, как новые требования и уточнения влияют на сроки и бюджет задачи, собрать оценки команды. 

3️⃣ Решение конфликтных ситуаций с заказчиком
В основном за защиту команды перед заказчиком отвечает PM. Но если ситуация сложная, аналитик может присоединиться к обсуждению и помочь: здесь BA и PM работают вместе и помогают друг другу.

4️⃣ Согласование результатов работы
PM ведёт переговоры и вызывает аналитика как эксперта и консультанта по отдельным вопросам.

Что важно
⚠️ Заранее обсуждать задачи и цели проекта, требуемую конфигурацию. По  необходимости корректировать зоны отвественности. Например, в каких-то случаях аналитик может стать ответственным за сдачу работ — если сдача работ равна сдаче ТЗ.
⚠️ Не вмешиваться в зоны ответственности друг друга
⚠️ Не замалчивать проблемы, если возникло ощущение, что процессы ухудшились.

Страхи аналитика

Привет! Я — Юлия Зубова, тревожный аналитик Surf. Хочу помочь начинающим и продолжающим аналитикам и поделиться моими самыми частыми страхами в работе.

Страхи бывают у всех, и это нормально. Главное — знать, как с ними работать. 

Страх №1. Я напишу плохое техническое задание, и коллеги будут мной недовольны. Разработчики и тестировщики будут ворчать (все равно будут) и обвинять меня в том, что по ТЗ невозможно работать.

Решение: Показать шаблон ТЗ команде, обсудить недостатки и внести изменения. Придерживаться шаблона: теперь критических косяков точно не будет.

Страх №2. Я не так пойму заказчика и придётся всё переделывать. На этапе приёмки окажется, что я упустила пласт функциональности или неправильно поняла цели и требования заказчика.

Решение: Записывать встречи (по согласованию с заказчиком). Иметь чек-лист и задавать вопросы по нему, чтобы ничего не упустить (кэп!). ОБЯЗАТЕЛЬНО согласовывать дизайн и техническое задание.

Страх №3. Я ничего не успею. На проекте сжатые сроки, я не успею качественно выполнить свою работу и тогда — привет, страхи №1 и №2.

Решение: Декомпозировать крупные задачи на мелкие, оценить сроки и без стеснения заложить достаточно времени на риски. Не поддаваться давлению руководителя проекта и заказчика сделать побыстрее: объяснить им, что в таком случае может пострадать качество.

Страх №4. Я ничего не знаю и подведу команду. У меня недостаточно компетенции для работы на новом сложном (как мне кажется) проекте.

Решение: Не бояться! У всех когда-то бывает первый (и не первый) сложный проект. Ошибки — это нормально: такова цена за профессиональный рост и классный опыт. Кстати, никто не отменял помощь коллег и учебные материалы в интернете.

❓А какие страхи в работе есть у вас? 😨