Как выживать на проектах со сжатыми сроками
Признавайся, приходилось работать на проекте со сжатыми сроками или над фичей с дедлайном через несколько дней? Если да – пост будет полезен для тебя. Если нет – тоже полезен (дайте этому парню «Оскар» за «Вот это поворот» 🐸).

Так как же бороться со сжатыми сроками?

Декомпозировать фичу. Под декомпозированием понимаем разбиение целого на части. Пример — декомпозиция пельмешка: много мяса, мало теста 🦁

Легче изучать не всю систему целиком, а разбить её на мало зависящие друг от друга части и рассматривать их отдельно. При декомпозиции мы детальнее прорабатываем фичу, параллельно изучаем подводные камни и имеем на выходе не одну большую систему, а группу связанных подсистем. 

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

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

Помни: джедай не тот, кто джедай. А тот, кто подсвечивает риски коллегам-джедаям и прорабатывает их совместно 🌌

Планировать работу. Оптимально распределять ресурс в выбранный промежуток времени работы над фичей.

Планирование помогает избежать качелей по нагрузке — когда её слишком много или слишком мало. Оно снижает уровень неопределенности и стресса от самого словосочетания «сжатые сроки». Ты просто спокойно идешь по чёткому плану: пресс качат, бегит, анжумания и так далее 🐺

Определить бизнес-цели. Значительная часть успеха – наличие четкой, понятной и достижимой бизнес-цели.

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

Когда ты знаешь, какой результат ожидается, автоматом закрывается большая часть вопросов. Не приходится думать «зачем я это делаю?», «заказчику точно нужно именно это?», «что будет, если медведь сядет в горящую машину?» 🐻‍ 

Сделать груминг. Перед тем, как приступить к разработке фичи, обязательно причеши её. Как это сделать без лака и расчёски, мы писали в прошлом посте.

Теперь ничего не должно гореть. А если продолжает гореть, то советуем закупиться огнетушителями и не сдаваться!

Как организовать работу команды аналитиков на проекте

Однажды к нам в Surf прилетела амбициозная задача: нужно было за полгода создать мобильное приложение, сайт, ERP-систему и CMS.

Мы посовещались и пришли к выводу: это реально, если над проектом будут работать несколько аналитиков.

Подключили команду аналитиков, начали разработку…

И внезапно оказалось, что работа идёт не так гладко, как планировалось: команда недовольна, в фичах много непроработанных «дыр» — и всё это очень уверенно катится к срыву сроков.

Стали экстренно искать, в чём причина. Оказалось — в той самой команде аналитиков. Нет-нет, это не они плохо работают, отнюдь: каждый — профессионал.

Просто работа в команде оказалась не совсем тривиальной задачей: нельзя было просто взять… и начать работать как привыкли в одиночку.

Почему чуть не случился фейл и как мы перестроили процессы, читайте в новой статье от нашего аналитика Анны Цветковой.

Читать статью >>

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

Что такое ретроспектива
Ретроспектива — это разбор проблем и успехов команды проекта, отдела или сотрудника. Она помогает улучшить процесс работы и результаты проекта.

Чаще всего ретроспективы проводят внутри конкретного проекта со всей командой, работающей на продуктом: обычно это разработчики, QA-отдел, аналитики, дизайнеры и менеджер проекта.

Мы с вами поговорим именно об аналитической ретроспективе внутри проекта.

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

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

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

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

В следующем посте расскажем, как проходит ретроспектива и какие плюсы она дает 🙌

Как проводить аналитическую ретроспективу
Возвращаемся к теме предыдущего поста — аналитической ретроспективе.

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

Важные моменты ⚠️

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

🔹 Лучше всего проводить во второй половине дня. Обычно утреннее время уходит на разбор срочных задач и багов: ближе к вечеру проще найти свободное время.

🔹 Рекомендуемая частота — раз в месяц или спринт, но не реже раза в квартал. Это поможет быстрее выявить проблемы и найти пути решения.

Проведение ретро

1️⃣ Модератор проходит по подготовленной повестке и обсуждает:

— что сделано или не сделано с прошлой ретроспективы,
— какие проблемы возникли по ходу работ, фиксирует их,
— выясняет, что стало лучше по сравнению с прошлым разом.

2️⃣ Формирует с командой план работ по улучшению на следующую итерацию проекта, выбирает ответственных.

3️⃣ Когда всё обсудили, завершает ретро и публикует результаты в рабочем пространстве, делится ими со всеми участниками.

4️⃣ Лучшие практики, требующие внимания всего отдела можно выделить отдельно и внедрить и в другие проекты.

Что дают аналитические ретро внутри проекта

Они помогают:
🔹 Контролировать качество процессов на проекте и  результатов.
🔹 Разобрать проблемы и успехи работы отдела на проекте, определить план решения проблем.
🔹 Составить повестку от отдела на общую ретро.
🔹 Выявить новые интересные практики, которые можно внедрить в другие проекты.

Забирайте себе и пользуйтесь на проектах 😉 А в следующем посте мы разберём роль ревьюера на ретро: кто это, что делает и какую пользу может принести.

Роль ревьюера в аналитической ретроспективе

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

Сегодня хотим поговорить о важной роли, которая присутствует на ретро, — роли ревьюера. 

Кто такой ревьюер 
Ревьюер — это аналитик с другого проекта, который делает аудит: 

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

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

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

Хотя иногда творческие сочетания тоже могут сработать: например, аналитик банкинга может привнести системности в ТЗ e-com проекта, а аналитик с e-com проекта предложить идеи улучшения UX на банковском проекте.

Чем полезна эта практика
🔹 Такая практика может помочь не только на текущем проекте, но и на проекте ревьюера: а именно — перенять опыт текущей команды себе и без ретро провести ряд улучшений
🔹 Аналитик в курсе особенностей работы с конкретным типом проекта и может предлагать идеи и проводить аудит, опираясь на свой опыт.
🔹 С помощью таких ретро аналитики на схожих проектах могут поддерживать свое комьюнити и делиться лучшими практиками.

❓ Расскажите, проводите ли вы такие ретро у себя на проектах?  как будете встречать Новый год?🎄

Аналитик на банковском проекте
И в чём отличие от привычной работы аналитика на других проектах типа e-com

1️⃣ Много подготовительной работы на старте. Нужно изучить стандарты от регулирующих органов типа НСПК (Национальной системы платёжных карт) и Центробанка, разобраться с регуляторными задачами, изучить формат банковских требований. 

2️⃣ Многоуровневая система согласования ТЗ и количество ЛПР — лиц, принимающих решение. В банке, как правило, согласование происходит через несколько подразделений. Большое количество ЛПР часто создаёт эффект «сломанного телефона», а замечания с разных слоёв противоречат друг другу.

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

4️⃣ Регуляторные задачи. Их нельзя не выполнить, иначе у банка могут отозвать лицензию. У них строгий дедлайн и жёсткие правила реализации, от которых нельзя отступать.

Как мы в Surf работаем с этими особенностями на банковских проектах, читайте в статье нашего аналитика Алисы Ковыршиной. 

Читать статью >>

Канал Surf on data waves переезжает

Так получилось, что по аналитике у нас в Surf есть два канала:
1️⃣ этот — Surf on data waves
2️⃣ и канал Летней школы аналитики.

Мы решили их объединить: на базе канала Летней школы сделали канал Surf BA Team.

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

👉 Добавляйтесь 👈