Каков реальный статус вашего проекта в процентах?
Уверен, каждому из вас хотя бы раз и на любом уровне карьерной лестницы приходилось отвечать на вопрос:
Каков статус проекта, над которым вы работаете, в процентах?
Вы хотели бы дать ответ, подкрепленный точными данными, возможно, сгенерированными инструментами, созданными именно для этого, но не смогли. И в конце концов, по крайней мере, один раз ответил на этот вопрос, дав случайный процент. 5%, потому что вы только начали, 50%, если вы все еще работаете над этим, или 90%, потому что вы почти закончили.
Предположим, что все в компании организовывали и управляли проектами только с помощью одного инструмента. В этом случае всем, кто сотрудничает, чтобы поддерживать свой статус в актуальном состоянии и в хорошей форме, не нужно было бы задавать этот вопрос, потому что каждый мог бы легко вычислить ответ.
Бьюсь об заклад, вы также испытали это:
Как вы думаете, когда вы собираетесь доставить его?
Если вы являетесь разработчиком, поддерживающим философию сначала код, а затем понимание, вам будет сложно ответить на этот вопрос. Написание кода без понимания требований будет заставлять вас открывать что-то новое каждый день и входить в бесконечный цикл кодирования.
Если вы являетесь владельцем продукта, у вас может не хватить технических знаний, чтобы оценить работу или понять технические зависимости.
Чтобы ответить на этот вопрос, требуется сотрудничество людей на разных уровнях с высоким уровнем сотрудничества и общения. Как технический специалист, вы должны тратить большую часть времени на сбор требований, изучение зависимостей и возможных проблем. Как владелец продукта или менеджер проекта, вы должны управлять всей информацией, обсуждаемой на встречах, или различными каналами связи в одном месте, легкодоступном для всех. После того, как любой аспект проекта собран вместе, наконец-то можно оценить необходимое время и получить более точный процент статуса проекта.
Как мы все можем начать давать более точные проценты?
- Каждый должен правильно использовать один инструмент управления проектами. Каждая заметка или решение, написанное в других каналах, должны там сливаться.
- Начиная с высшего руководства, все должны добавлять свои фрагменты информации в один и тот же инструмент, чтобы улучшить общение и сотрудничество.
- Каждый должен держать все в курсе.
Вам нужен один инструмент
Многие компании имеют множество инструментов для отслеживания статуса проектов. Я видел файлы Excel, диаграммы Ганта, доски Trello, Sharepoints, Google Sheets, Microsoft Teams, доски Jira и многие другие. В большинстве случаев все они используются одновременно и никогда не связаны друг с другом. Обычно Владельцы Продукта называют одну дату, Разработчики — другую. Скрам-мастера и менеджеры проектов находятся в середине, пытаясь синхронизировать эти даты во всех местах.
В командах, которые планируют в соответствии с методологиями SCRUM, проекты основаны на датах, а не на спринтах, итерации не выполняются, потому что срок выполнения может приходиться на несколько дней после окончания спринта или на его середину.
Вам нужен один инструмент, чтобы все выровнять. И это не так сложно, как вы думаете.
Что ожидает высшее руководство
На высоком уровне высшее руководство заинтересовано в том, чтобы команды могли выполнить работу вовремя. Он хочет отслеживать возможные задержки, и его могут заинтересовать зависимости, исходящие от нескольких команд, участвующих в этом. Чем точнее будет статус каждого проекта, тем легче будет донести обновления до генерального директора. Ожидается, что менеджеры проектов соберут требования и дадут оценку времени.
Что могут сделать менеджеры проектов и владельцы продуктов
Руководителям проектов и владельцам продуктов интересно знать процент выполнения каждого проекта. Обычно они управляют более чем одним проектом. Некоторые задачи могут быть связаны друг с другом или должны начинаться после завершения предыдущей.
Эпопея и вехи
Поскольку у них был обзор всех из них, они могли начать создавать эпики и вехи.
Эпос подобен контейнеру для всех предметов. Каждый проект можно легко связать с одним из них, со всем необходимым для его выполнения на высоком уровне.
Вехой может быть группа историй одного и того же эпоса, которые могут быть представлены одновременно. Выпуск альфа-версии может быть примером возможной вехи, как выпуск бета-версии или общих выпусков, каждый из которых определяется датой начала и окончания. Как только все вехи пройдены, проект можно считать выполненным, а эпопею можно закрыть.
Хорошее начало полдела откачало
Их непосредственный контакт с высшим руководством может добавить важную информацию о желаемом поведении каждого проекта. Менеджеры проектов и владельцы продуктов могут начать оценивать запланированную дату начала и дату выполнения и убедиться, что для работы над ними достаточно времени и людей. Они могут связывать эпики в случае зависимостей или подсвечивать, какой из них должен быть запущен или завершен первым. Они могли бы начать писать определение DONE для этого проекта. Они могут добавлять определенные ярлыки, чтобы идентифицировать определенные категории и проверять, все ли имеет смысл или чего-то не хватает с высокой точки зрения. Они могли бы начать создавать пользовательские истории, чтобы начать делить проект на более мелкие задачи и этапы. Пользовательская история — это то, что должно быть завершено и доставлено за один спринт.
Если эта часть не управляется правильно, вся цепочка уже разорвана. Информация перейдет на следующий уровень без полного представления о том, что должно быть сделано, и последствия будут значительными: зависимости будут обнаружены слишком поздно, проекты будут выполнены с другим определением выполненных работ, неправильные оценки, проекты не будут выполнены или завершены с недостающие функции или паршивое качество.
Где менеджеры и технические руководители могут помочь
Менеджеры и технические руководители следят за тем, чтобы команда выполнила проект качественно и в сроки, оговоренные и согласованные с владельцем продукта. Они должны участвовать в собраниях, когда проект определен, и дополнять менеджеров проектов и продуктов. Менеджеры и руководители хотели бы иметь больше времени для качественной реализации проекта. Менеджеры проектов и продуктов хотели бы иметь более короткие сроки поставки. Только вместе они могут договориться об одном посередине. И только вместе они могут решить любые вопросы, которые могут возникнуть у обеих сторон. Для этого можно использовать подход BDD.
Менеджер и Технический Лид должны донести эпопею до команды разработчиков. Вместе они могут проанализировать его, создать дополнительные истории и подзадачи, проверить, все ли понятно, и, наконец, зафиксировать первую оценку или предложить новую дату. Если все в цепочке хорошо справились со своей работой, не должно быть большого сюрприза.
Скрам-мастер следит за тем, чтобы статус каждого элемента был актуальным и каждый элемент имел правильный статус. Благодаря повторяющимся встречам с участием менеджера, владельца продукта и менеджера проекта любое изменение даты может быть немедленно рассмотрено. Процент проекта можно легко рассчитать по завершенным Story Points или количеству закрытых на данный момент элементов.
Когда менеджер и технический руководитель не участвуют с самого начала, существует риск того, что сроки, запланированные продуктовой командой, не могут быть соблюдены, поскольку у них недостаточно технических знаний. Разработчиков заставят работать больше и в спешке, менеджеру придется иметь дело с напряженными и несчастными людьми, владелец продукта будет постоянно сдвигать сроки, а проект будет сдан некачественно.
Все в компании должны сотрудничать
Получить точную оценку состояния проекта непросто. Это требует сотрудничества всей лестницы, где каждый вносит незначительный вклад. Разработчики не будут оценивать, если они не знают, что им нужно делать. Вы увидите, как они создают новые элементы для спринта каждый раз, когда обнаруживают что-то новое. Менеджер будет изо всех сил стараться сделать людей счастливыми и предложить определение «готово». Владелец продукта и менеджер проекта будут продолжать спрашивать статус, получая случайное число, которое, вероятно, всех обрадует, но это не точно.
Должна быть культура, в которой каждый осознает свои обязанности. Разработчик должен не только писать код, но и обновлять статус задач. Скрам-мастер должен не только спрашивать, что было сделано накануне, но и управлять командой, помогая отвечать на вопросы и устраняя блокираторы. Владельцы продукта и менеджеры проектов должны постоянно обновлять бэклог, эпики и истории. Они должны сосредоточиться на одном инструменте и собрать все необходимые требования для создания хорошего продукта. Непрерывные комментарии к элементам одного и того же инструмента, написанные всеми членами команды, могут улучшить совместную работу и держать всех в курсе ее статуса.
Если кто-то разорвет цепочку, игра окончена.
Если кто-то разорвет эту цепочку, вы можете заметить, что сроки выполнения постоянно задерживаются, проекты частично завершены или недостаточно протестированы. Использование двух или более инструментов для отслеживания состояния и зависимостей одного проекта, хотя на первый взгляд выглядит многообещающе, в конечном итоге внесет путаницу в таблицу.
Подумайте о простом случае, когда определением выполнения на более высоком уровне цепочки является «Создать форму входа», и этот проект отслеживается более чем в одном инструменте, каждый с дополнительными комментариями и описаниями, доступными не всем. Команда внутренних разработчиков считает работу завершенной после написания кода API. Для другой группы, работающей над пользовательским интерфейсом, работа будет считаться выполненной в другое время и с другими требованиями. Предположим, у каждой команды есть разные элементы на разных досках, не связанные между собой. В этом случае вы можете легко понять, насколько сложно было бы узнать, когда именно работа будет завершена в соответствии с первоначальной предполагаемой датой и желаемым определением готовности. Вы также легко можете себе представить, сколько проблем с коммуникацией может возникнуть в структуре, в которой более одной команды заперты в одном ящике, работая над разными аспектами одного и того же проекта, с различными инструментами или системами для его отслеживания.
Как нам правильно ответить на вопрос?
Многие инструменты включают возможность создания отчетов, включая все элементы с их статусом по умолчанию. С помощью простого запроса вы можете точно оценить процент завершения на основе количества элементов или баллов. Вам нужно использовать только один такой инструмент и связать все проекты и истории в соответствии с их зависимостями.
Если у вас есть один эпик для каждого проекта, с полным списком историй и каждой связанной зависимостью, каждый может легко увидеть фактический статус проекта, все в режиме реального времени, не задавая никаких вопросов и не придумывая никаких поддельных процентов.
Каждый может быть в курсе того, что делают другие команды. Зависимости будут легко контролироваться и обнаруживаться. Просто связывая элемент с другим, в основном, если зависимость лежит в другой команде, каждый может понять, можно ли запустить эту задачу или нет. Каждый комментарий можно отправить в одном месте, что улучшит сотрудничество между людьми в разных командах.
Вы также можете создать определенные страницы на вики-странице, где вы можете создать страницы, показывающие все элементы, которые были выполнены за один спринт или определенный диапазон дат.
Если каждый в компании сделает свою маленькую часть, вы увидите, как легко правильно ответить на этот вопрос.
