Управление проектами

Старт проекта

1. 1.

   Формируем команду под нужды разработки

   В каком формате мы собираем команды:

   • Полностью команда True Engineering

     Мы подбираем специалистов внутри компании специально под проект – с нужными навыками и опытом работы.

   • Совместная команда True Engineering и заказчика

     Мы организовываем совместную работу смежной команды в разном соотношении специалистов. Это могут быть только разработчики на нашей стороне, при этом аналитики, дизайнеры – на стороне заказчика, может быть соотношение 50 на 50 и любое другое.

   • Команда True Engineering совместно с командами заказчика и подрядчика

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

2. 2.

   Настраиваем трекер

   В True Engineering внедрены внутренние стандарты работы в трекере: все наши команды «говорят на одном языке» благодаря единообразному подходу к ведению проекта. Мы профессионально владеем инструментом управления работой – TFS Azure DevOps. Выработали свой шаблон, в котором заложили стандарты и вариации настроек.

   • Контроль всего процесса разработки ведется либо только в нашем трекере, либо интегрируемся в обе стороны с трекером заказчика
   • Стандартный процесс работы над каждым рабочим элементом (от аналитики до релиза)
   • Автоматизация движения рабочих элементов по статусам (In Dev, In Test, Ready for Release и т.д.)
   • Сквозная привязка кода, тест-кейсов, релизов к рабочим элементам
   • Автоматическое формирование release notes (уведомлений) сразу после релиза
   • Учет рабочего времени
   • Подсчет метрик разработки и метрик скорости выпуска задач в прод
   • Контрольные дашборды для измерения здоровья команды в процессе разработки.

   • 

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

   В нашей статье мы рассказали про наш путь к единому шаблону проекта.

3. 3.

   Организовываем взаимодействие с внешними командами

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

   • Настраиваем интеграцию с трекером заказчика – так, один из наших заказчиков работает с Jira, и мы полностью синхронизировали процесс TFS-Jira.

   • Умеем настраивать коммуникации так, что заявки из вашего инструмента будут попадать напрямую к нам в трекер проекта.

   Недавно мы синхронизировали Loop заказчика с нашим TFS: когда заказчик создает заявку в боте Loop, она автоматически приходит к нам в TFS, и команда техподдержки оперативно берет ее в работу без временных простоев.

Управление процессом разработки

1. 1.

   Мы работаем по гибкой методологии и адаптировали ее под бизнес, который планирует бюджеты

   • Управляем бэклогом
   • Работаем спринтами
   • Внимательны к постановкам задач: их декомпозиции и ожидаемому результату
   • Планируем исходя из ресурсов и сроков
   • Проводим план-факт анализ
   • Работаем прозрачно и предоставляем доступ ко всему перечисленному
    

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

2. 2.

   Настраиваем внутрикомандные коммуникации и коммуникации с заказчиком

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

Проведение регулярных демонстраций и отчетность

Техническая и продуктовая стратегия развития продукта

1. 1.

   Создаем и поддерживаем стратегии в актуальном состоянии на разных стадиях жизненного цикла продукта

   При старте разработки проектируем дорожную карту создания продукта и очерчиваем границы MVP в соответствии с приоритетами бизнеса и бюджетным планированием.

    

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

2. 2.

   Техническая стратегия на старте и в развитии продукта

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

    

   По мере развития продукта регулярно оцениваем состояние архитектуры, проводим актуализацию стека и проводим рефакторинг, формируем бэклога техдолга.

3. 3.

   Аудит безопасности

   На старте настраиваем инструменты и следим за безопасностью кода с самого старта разработки. После ввода эксплуатацию регулярно проверяем продукт на предмет безопасности.

   Подробнее >>

Работа с продуктовыми целями

1. 1.

   Управляем на основе бизнес-смысла продукта, а не списка задач 

   • Проактивно подстраиваем декомпозицию и этапы разработки для получения результата после каждого спринта

   • Фокусируемся не только на функционале, а еще и UX части и отказоустойчивости в необходимом объеме

   • Ориентируемся на бизнес-результат и измеряем его: мониторинг метрик после релиза (бизнес KPI продукта), формулирование этих KPI для каждой фичи

   • Приоритизируем бэклог на основе бизнес KPI

   Это позволяет бизнесу четко понимать результат каждой запущенной функциональности, не дожидаясь обратной связи от пользователей.

2. 2.

   Настраиваем метрики пользовательского поведения

   Работаем с аналитическими инструментами – например, Яндекс.Метрика, Looker Studio, где анализируем пользовательские сценарии и планируем бизнес-задачи исходя из них.

3. 3.

   Собираем отзывы пользователей

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

Контроль производственных метрик