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

Расскажем историю. Реализовывали один элемент экрана на двух платформах.

👉 Android приступили к задаче раньше iOS, и сделали её за два часа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение: Записывать встречи (по согласованию с заказчиком). Иметь чек-лист и задавать вопросы по нему, чтобы ничего не упустить. Обязательно согласовывать дизайн и техническое задание.

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

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

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

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

Как выживать на проектах со сжатыми сроками

Что делать, когда приходится работать на проекте со сжатыми сроками или над фичей с дедлайном через несколько дней?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• «BABOK». Магнум-опус от аналитиков для аналитиков. Содержит все знания, компетенции, методы и техники аналитики с практической точки зрения.

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

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

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

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

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

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

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