Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Мы, R&D Plarium Krasnodar, не занимаемся разработкой игр, а пилим разные полезные штуковины:
Back Office. Решения на все случаи жизни — от тикетной системы для нашей доблестной службы поддержки до редакторов игрового контента.
Data. Продукты и процессы, связанные с такими крутыми словами, как Big Data, Machine Learning, A/B Testing, Data Science и т. д.
Infrastructure. Инфраструктурные проекты.
Internal. Внутренние сервисы, которые делают нашу жизнь лучше.
Задач и идей у нас всегда хватало, желания работать тоже хоть отбавляй, но с менеджментом и координацией были проблемы.
Предыстория: как появились PM R&D
Изначально лиды профильных команд в R&D занимались всем — от сбора требований и общения со стейкхолдерами до планирования и прогнозирования сроков. Это было сложно для всего отдела. Проблемы копились, и в итоге привели к сниженной продуктивности.
И тут на помощь пришла команда PM. Формально она не является частью R&D, но очень тесно работает с нашим отделом. Ребята вели разные проекты, настраивали взаимодействие, а со временем стали частью профильных команд и сфокусировались на конкретной предметной области. Эта коллаборация позволила лидам сосредоточиться на технических и продуктовых вопросах, а PM — на выстраивании процессов и стандартов проектной деятельности.
Менеджмент в действии
С точки зрения планирования наши проекты делятся на группы:
Processes. Все процессные штуки: подготовка, доставка и хранение данных, инфраструктурные вопросы или devops-задачи.
Research. Получение новой информации или компетенций. Благодаря успешным исследованиям мы можем переосмыслить текущие проекты или начать разработку новых.
Product. Осязаемые продукты, у которых есть свои стейкхолдеры, пользователи, дорожная карта и т. д.
Как мы планируем работу по Processes- и Research-проектам
Планирование по таким проектам простое, ситуативное. В основе лежат месячные спринты и еженедельные синкапы.
Как мы проводим еженедельные синкапы
Продолжительность: 30–60 минут.
Участники: проектная команда, PM, руководитель R&D.
Порядок обсуждения:
1. PM демонстрирует доску проекта в Jira.
2. Специалисты рассказывают, каких успехов добились и с какими трудностями столкнулись. Также они могут предложить разбить задачу или добавить новую.
3. Свободное общение по теме. Если обсуждение какого-то вопроса затягивается, то команда прекращает диалог, PM фиксирует это и организовывает отдельное собрание.
4. PM устно подводит итоги встречи.
Действия после встречи:
1. PM отправляет follow-up (если нужно).
2. PM актуализирует список задач (если решили делать это не на синкапе).
3. PM назначает дополнительные собрания (если нужно).
Как мы планируем работу по Product-проектам
При работе с Product-проектами мы также проводим еженедельные синкапы, но с другими целями:
информируем команду о запуске, завершении или изменении параметров спринта;
выявляем вопросы, которые требуют отдельного обсуждения.
Сама работа состоит из этапов: подготовка, разработка, релиз.
Подготовка
Цель подготовительного этапа — синхронизировать всех участников разработки. Для этого мы составляем дорожную карту проекта. Стандартов оформления дорожных карт у нас нет, но чаще всего это таблица с пятью колонками:
Номер релиза. Обычно мы юзаем Gitflow, и номер релиза — это версия продукта.
Цели. Даем краткие и понятные ответы на вопросы: зачем мы это делаем и что нам даст новая версия продукта?
Содержание. Обозначаем основные изменения в продукте.
Статус. Определяем, на какой стадии находится работа над релизом: планируется, в процессе, уже опубликована.
Сроки. Выставляем желаемый или прогнозируемый дедлайн релиза.
Номер релиза | Цели | Содержание | Статус | Сроки |
0.1 | Разработать инструмент для сбора и хранения текстов с возможностью поиска. | - Тестовое наполнение базы текстов (файлы локализации для проектов «Викинги», «Трон»). - Поиск по строкам. - Хедер сайта. - Импортер текстов. - Админпанель: пользователи, проекты, роли. - Подготовка к выходу в продакшен в качестве сервиса для хранения текстов. | Готово | Разработка: 18.06.2021 Релиз: 21.06.2021 |
О том, как выставляются сроки, мы расскажем в отдельном пункте чуть ниже. А пока будем считать, что сроки — это общее мнение всех участников процесса. Главное, что нужно понимать, — их можно корректировать по ходу работы.
Разработка и релиз
После составления дорожной карты мы приступаем к самому интересному — формируем скоуп, оцениваем и распределяем задачи по спринтам.
Каких правил мы придерживаемся:
Помним, что качественная декомпозиция — основа хорошего планирования.
Используем метод набегающей волны.
Оцениваем задачи в часах.
Каждый день фиксируем успех по задачам, то есть логируем затраченные часы.
Помним, что завершение спринта — это не релиз, а достижение определенных целей.
Последний, релизный спринт запускаем без итоговой оценки.
Как мы группируем задачи:
На схеме видим несколько этапов:
Бэклог X версии продукта — динамический список задач, которые мы выполняем, чтобы выкатить новую версию продукта.
Спринты N — спринты разработки, каждый из которых имеет цель. Задачи спринта мы оцениваем и распределяем по исполнителям.
Релизный спринт — последний спринт в разработке версии. В рамках него выполняем приемочное тестирование, исправляем баги, делаем доработки, составляем чек-лист выкладки и определяем даты релиза.
Ресерч и документация — задачи, которые не приводят к изменению кодовой базы проекта. Такие задачи мы решаем без привязки к спринтам или релизам. Это бесконечный параллельный процесс.
Если взглянуть на все это с точки зрения процессов, то они будут такими:
Чем быстрее команда расправляется с задачами в бэклоге X версии продукта, тем быстрее происходит релиз. В свою очередь, чем лучше составлен первоначальный бэклог версии, тем легче прикинуть дату релиза.
Сроки релиза
Срок релиза — важный элемент дорожной карты. В начале пути сложно определить точную дату, поэтому мы предлагаем ориентировочную.
Ориентировочная дата — это квартал или диапазон дат. Чаще всего мы останавливаемся на определенном месяце. Точность оценки зависит от многих факторов, но на этом этапе конкретных дат никто не ожидает.
После согласования ориентировочного срока команда начинает разработку. Она ведется итеративно, в несколько спринтов. После завершения каждого спринта мы определяем финальную дату релиза, но не торопимся ее объявлять. Наша задача — понять, попадаем ли мы в первичную оценку.
Если да, то точную дату мы объявляем, когда приступаем к последним спринтам. Если нет, то PM собирает свои вещи и увольняется согласовывает изменение ориентировочной даты релиза.
Бывало, что первичное ожидание совпадало с фактической датой, а бывало, что сроки переносились по несколько раз. После каждого релиза мы проводим ретроспективу и делимся мнениями:
что было хорошо;
что было плохо;
что можно поменять или улучшить.
Заключение
Хорошее планирование — это когда ты получаешь ожидаемый результат в установленный срок. Но чтобы научиться выстраивать контролируемый и прогнозируемый рабочий процесс, надо много учиться и ошибаться. Поэтому напоследок мы хотим дать вам рекомендации, которые основаны на нашем опыте.
Для PM и лидов:
Смотрите в будущее. При разработке новой версии продукта планируйте работу на 1–2 спринта вперед. Проводите подготовительный этап, чтобы у вас был бэклог для следующей версии до того, как вы закончите разработку текущей.
Работайте с рисками и быстро реагируйте на любые ситуации, которые могут повлиять на итоговые сроки.
Снабжайте участников процесса необходимой информацией и держите всех на одной волне. Не допускайте разных трактовок одних и тех же вещей.
Отслеживайте прогресс по задачам и реагируйте на любые отклонения от графика.
Для специалистов проектной команды:
Любите свой продукт. Изучайте его не только изнутри, но и снаружи.
Проводите качественную декомпозицию. Если это невозможно, то не жалейте времени на ресерч.
Развивайте скилл оценки задач.
Общие советы для всех:
Используйте профессиональные инструменты для управления проектами. Трекер — это отражение вашей работы. Минимум 90% деятельности по проекту оформляйте в виде задач.
Разбивайте задачи, если по предварительной оценке они займут очень много времени.
Логируйте время по задачам. Так вы сможете объективно отслеживать прогресс выполнения.
Старайтесь работать так, чтобы коммиты были связаны с задачами из трекера.
На этом пока все. В следующей статье мы расскажем, как формируем спринты, отслеживаем прогресс и принимаем решения на основе данных. А если у вас есть советы по планированию работ над проектами, делитесь ими в комментариях.
