Что хочешь изменить с переходом на новый проект?

Что хочу изменить с переходом на новый проект

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

1. Раньше включать Data & Analytics в планирование

Что было раньше:

• Требования приходили в полностью готовом виде (Product Manager уже всё решил)
• Я приходил в конце для документирования, не для влияния на решение
• Нередко обнаруживал проблемы в требованиях только во время разработки

Что хочу изменить:

• Быть с самого начала (на этапе idea validation)
• Предложить данные для решения: "Давайте сначала проверим эту гипотезу через user research"
• Помочь Product Team избежать наивных идей через аналитику
• Пример: вместо слепой разработки фичи, провести опрос 30 пользователей за неделю и затем уже идти в разработку

Как это повлияет:

• Меньше переделок во время разработки
• Выше шанс успеха фичи на рынке
• Я как аналитик получу role of advisor, а не исполнителя

2. Лучше структурировать documentation & requirements

Проблема в прошлом:

• Писал requirements в виде длинных документов (20-30 страниц)
• Разработчики не читали до конца, потом спрашивали вопросы
• Было сложно отследить изменения в требованиях
• Документ быстро устаревал

Что хочу сделать:

• Документация по слоям:

  • Jira → для разработчиков (конкретные таски, описание, критерии готовности)
  • Confluence → для аналитики и знаний (контекст, решение, альтернативы)
  • Figma → для дизайна и UI (макеты, состояния)
  • Storytelling → для стейкхолдеров (зачем это, что выиграет бизнес)

• Использовать ADR (Architecture Decision Records):

  • Для каждого значимого решения писать: Контекст → Варианты → Выбор → Последствия
  • Это помогает новым людям в проекте быстро понять историю

• Эволюция вместо переписывания:

  • Требования живут в коде (docstrings, type hints) и системе (Jira)
  • Confluence — только для контекста и истории, не для текущего состояния

Пример того, как должно быть:

• Jira Issue: "Добавить фильтр по статусу в таблицу"
  • Description: "Пользователи теряют время на поиск нужного статуса вручную"
  • Acceptance Criteria: "1. Фильтр работает для Active/Inactive/Deleted. 2. Выбор сохраняется в localStorage. 3. Поддерживает multi-select."
• Confluence страница: "Почему фильтр нужен" (данные о потере времени, user research, альтернативы)
• Figma: макеты с фильтром в разных состояниях

3. Ближе работать с Engineering на требованиях

Проблема:

• Часто приносил requirements в полностью готовом виде
• Разработчики находили проблемы ("это невозможно за 2 недели", "нужна БД миграция")
• Потом требования переделывались

Что хочу изменить:

• Collaborative requirements gathering:

  • На ранней стадии просить input: "Это технически возможно? Есть ограничения?"
  • Не диктовать, а обсуждать варианты реализации
  • Пример: вместо "добавить real-time уведомления", спросить: "Нужны ли real-time или polling в 5 сек приемлем?"

• Техдолг в requirements:

  • Не игнорировать техдолг, включать его в estimates
  • Если фича требует рефакторинга — это учитывается в timeline
  • Лучше отложить фичу на неделю, чем делать костыль

• Continuous refinement:

  • Спринт 1: baseline требования
  • Спринт 2-3: refinement на основе feedback разработчиков
  • Спринт 4+: итерация на основе того, что встречаем в коде

4. Больше фокуса на метрики успеха с самого начала

Что было:

• Требование готово, но непонятно, как его успех измерять
• Запускаем фичу, но метрик нет, пока не настроим аналитику
• Трудно понять, сработала ли фича

Что хочу делать:

• Metrics framework для каждой фичи:

  • Primary metric: главная метрика успеха (например, retention на +2%)
  • Secondary metrics: поддерживающие (например, DAU, feature adoption)
  • Guardrails: что должно не упасть (например, не потерять скорость сайта)
  • Пример для фичи "Фильтры": Primary = time to find task ↓ 30%, Secondary = feature adoption ≥ 40%, Guardrails = page load time ≤ 2s

• Инструменты:

  • Трекировать метрики от дня 1 запуска
  • Использовать A/B тест, если есть альтернативы
  • Собирать qualitative feedback параллельно (user interviews, surveys)

• Review после запуска:

  • Через 2 недели: смотрим метрики, есть ли insights
  • Если успешно → масштабируем, если нет → итерируем или откатываем

5. Меньше встреч, больше асинхронной работы

Проблема:

• В прошлых проектах много встреч: планирование, обсуждение требований, синки, retro
• Часто встречи неэффективны (не все готовы, нет повестки, дублирование)
• Теряется время на переключение контекста

Что хочу:

• Правило "нет встречи, пока нет документа":

  • Перед встречей есть Confluence страница для review
  • Люди приходят с вопросами, не с пустой головой
  • Встреча → уточнения, не обсуждение с нуля

• Асинхронные решения:

  • Slack для quick decisions
  • RFC (Request for Comments) для больших решений
  • Async feedback на документы (комментарии в Confluence)

• Встречи только для:

  • Complex problem solving (не один-два человека могут решить)
  • Сложные переговоры (conflicting opinions)
  • Bonding с командой (retro, планирование спринта)

6. Развивать soft skills: влияние и persuasion

Что осознал:

• Правильное требование — это только половина успеха
• Вторая половина — убедить stakeholder-ов, что это правильное решение
• Без persuasion skills даже хорошее решение может быть отклонено

Что хочу улучшить:

• Storytelling:

  • Вместо: "Данные показывают, что фильтр нужен" (скучно, непубличное)
  • Лучше: "У нас есть 3 типа пользователей: новички ищут 10 минут, опытные — 3 минуты, power users — 30 секунд. Фильтр поможет всем, но особенно новичкам. Это может быть нашей точкой для onboarding." (story, контекст, actionable)

• Адаптация к аудитории:

  • Для CEO: ROI и метрики по бизнесу
  • Для Product: feature impact и user feedback
  • Для Engineering: technical feasibility и timeline
  • Для Design: user delight и aesthetics

• Управление возражениями:

  • Вместо защиты: слушать, что беспокоит
  • Найти компромисс: "Для MVP делаем базовый фильтр, потом добавим advanced"
  • Привести примеры из других проектов

7. Экспериментировать больше, доверять интуиции меньше

Паттерн из прошлого:

• Слышу мнение Product Manager: "Пользователи хотят эту фичу"
• Верю на слово, без валидации
• Фича выходит, но флопит (users don't use it)

Что хочу делать:

• Гипотеза → тест → вывод:

  • Гипотеза: "Добавление фильтра по статусу сократит время поиска на 30%"
  • Тест: Провести 10 интервью с пользователями (качественное) + A/B тест в продакшене (количественное)
  • Вывод: Если верна → делаем, если нет → ищем другое решение

• Cheap experiments:

  • Landing page для фичи (сколько кликов "Хочу эту фичу") — дешево
  • Survey 50 пользователей — дешево
  • Mock-up в Figma с user testing — дешево
  • Полная разработка фичи — дорого

• Failing fast:

  • Если гипотеза не подтвердилась — не стыдно
  • Быстро двигаться дальше, не зацикливаться

Итог

В новом проекте хочу быть не просто исполнителем требований, а стратегическим партнёром для Product, Engineering и Business. Это значит:

1. Включаться рано в планирование
2. Структурировать работу так, чтобы знания сохранялись
3. Сотрудничать с Engineering, а не диктовать
4. Явно определять метрики успеха
5. Работать асинхронно, экономя время на встречи
6. Улучшать свои коммуникационные skills
7. Валидировать гипотезы вместо слепого следования интуиции

Это не революция в подходе, а эволюция на основе того, что сработало, и то, что не сработало в прошлом.