Отслеживание множества проектов.
Сегодня я собираюсь показать вам, как наш программ-менеджер отвечает за управление всеми проектами при помощи TFS, используя отчеты для отслеживания изменений в нескольких проектах сразу.
Для начала, позвольте мне рассказать вам немного о самом процессе.
Каждую неделю мы проводили встречи менеджеров, целью которых была проверка здоровья проектов, над которыми мы работали.
Проводил эти митинги Джим Бойл (Jim Boyle), который являлся программным менеджером нашей группы. Он – великолепный программ-менеджер с огромным опытом контроля за выполнением работы.
Каждую неделю Джим показывал нам отчет, который выглядел как этот. Он отображал все проекты, над которыми мы работали.
Некоторые разъяснения:
- Зеленый – процент завершенной работы по отношению ко всему проекту.
- Желтый – процент завершенной работы за последний отчетный период (обычно 1 неделя).
- Красный – количество часов предстоящей работы.
- Дата окончания работы над функционалом сопровождается названием исполнителя.
После того, как этот отчет выводился на экран, Джим начинал задавать вопросы вроде этих:
- Почему не видно никакого прогресса за прошедшую неделю?
- Почему так мало сделано?
- У вас осталось всего 1450 рабочих часов, при том, что дата окончания работы назначена на 3 января. Вы все еще думаете, вы уложитесь в эти сроки?
Джим вовсе не начинал стучать кулаком по столу и спрашивать «Какого хрена вы не ничего не делаете?». Приведенные данные показывали конфликт, и он просто озвучивал его.
Вот – некоторые ответы:
- «Я просто не обновил данные». Такой ответ был не приемлем. После такого ответа начиналась словесная порка с напоминанием о важности вовремя обновлять данные. Кстати, делалось это вовсе не Джимом, а нашим Product Unit Manager (читай – Брайаном Харри).
- «Нас выдергивали для выполнения других срочных работ на той неделе» — этот ответ был вполне приемлем. Хотя на таких встречах происходила и смена приоритетов. Другими словами, менеджмент мог понять, что данная срочная работа не так важна, как проект в целом. В такой ситуации, менеджмент имел более полное представление о статусе проекта.
- «Если все пойдет нормально и не возникнет сложностей и проблем, надеюсь, мы выполним все вовремя» — здесь мы видим, как кто-то изо всех сил старается верить, что он может удержать первоначальные сроки. Он не хочет сдвигать дату, поскольку это будет выглядеть не очень хорошо. В основном, ответом ему было: нам нужна дата, к которой работа будет сделана с максимальной вероятностью. Если вам нужно ее сдвинуть, нам лучше знать об этом сейчас, чем сдвигать ее позже.
Вы, возможно, заметили, что такой подход требует изменения культуры внутри команды. Прозрачность заставит вас проявить себя. При такой культуре открытости, руководство может пойти по пути «держать дату окончания работ любой ценой», а исполнители должны решить «показывать ли текущий статус проекта со всей открытостью» или «прятать плохие новости». Это был процесс обучения для обеих сторон.
Gregg Boer
Дополнение.
После публикации предыдущей статьи, меня попросили рассказать поподробнее об отчете, о котором я говорил. Я спросил приятеля, который работает над внутренними отчетами, и вот – его ответ (Спасибо, Даг!). Я также прикрепляю файл .RDL, который он мне передал.
Цитата:
«Ниже приведен текст запроса, который получает текущий объем завершенной и ожидающей работой на определенную прошедшую дату (и эта дата является параметром). Целью использования полей .[All] в нашей системе замеров, которая возвращает объем работы за период в N дней, является поиск сценариев, у которых название, продуктовая группа, текущее состояние и т.п. имели другое значение на указанную дату. По сути, мы говорим: дайте мне объем завершенной и ожидающей работы за период в N дней вне зависимости от значений фильтра на другие поля (например, статус и т.п.).
WITH
MEMBER [Measures].[ValueOfCompletedWorkAsOfNDaysAgo] AS
(
[Measures].[Microsoft_VSTS_Scheduling_CompletedWork],
[Work Item].[Microsoft_DeveloperDivision_Classifications_Group].[All],
[Work Item].[Microsoft_DeveloperDivision_Classifications_Project].[All],
[Work Item].[System_Title].[All],
[Work Item].[System_State].[All],
[Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[All],
STRTOMEMBER(@MDXDateForWorkCompletedSinceDate)
)
MEMBER [Measures].[ValueOfRemainingWorkAsOfNDaysAgo] AS
(
[Measures].[Microsoft_VSTS_Scheduling_RemainingWork],
[Work Item].[Microsoft_DeveloperDivision_Classifications_Group].[All],
[Work Item].[Microsoft_DeveloperDivision_Classifications_Project].[All],
[Work Item].[System_Title].[All],
[Work Item].[System_State].[All],
[Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[All],
STRTOMEMBER(@MDXDateForWorkCompletedSinceDate)
)
MEMBER [Measures].[FeatureEndDate] AS
EXTRACT(
NonEmpty(
[Microsoft_DeveloperDivision_Features_DateEnd].[Date].[Date] *
[Work Item].[System_Id].CurrentMember,
[Measures].[Current Work Item Count]
),
[Microsoft_DeveloperDivision_Features_DateEnd].[Date]
).Item(0).Member_Value
SELECT
Non Empty
{
[Measures].[FeatureEndDate],
[Measures].[Current Work Item Microsoft_VSTS_Scheduling_CompletedWork],
[Measures].[Current Work Item Microsoft_VSTS_Scheduling_RemainingWork],
[Measures].[ValueOfCompletedWorkAsOfNDaysAgo],
[Measures].[ValueOfRemainingWorkAsOfNDaysAgo]
} ON COLUMNS,
NonEmpty(
STRTOSET(@WorkItemMicrosoftDeveloperDivisionClassificationsGroup, CONSTRAINED) *
STRTOSET(@WorkItemMicrosoftDeveloperDivisionClassificationsProject, CONSTRAINED) *
[Work Item].[System_Id].[System_Id] *
[Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[Microsoft_DeveloperDivision_Features_RiskLevel] *
[Work Item].[System_Title].[System_Title],
[Measures].[Current Work Item Count]
) DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS
FROM [Current Work Item]
WHERE
(
[Work Item].[System_WorkItemType].&[Orcas Feature],
STRTOSET(@WorkItemSystemState, CONSTRAINED)
) »
FC-High-Level-Summary-of-Work.rdl
Gregg Boer
Отслеживание рисков
В прошлый раз мы говорили об отслеживании хода работы в нескольких проектах одновременно, в этом мы поговорим об отслеживании рисков в этих проектах.
Прежде всего, давайте посмотрим на закладку Progress записи типа Feature.
На этой картинке вы видите два поля, относящиеся к рискам. Risk Level (Уровень риска) – индикатор типа дорожного светофора. Зеленый = мы завершим работу вовремя. Желтый = есть риски. Красный = мы не завершим работу в срок. Второе поле содержит пояснительный текст.
Каждую неделю менеджер проекта должен был проверять даты, указанные в записи типа Feature и оценивать, может ли его группа выполнить работу в указанные сроки и, затем, установить Risk Level в соответствии с этой оценкой. Если было нужно, комментарии добавлялись в поле Risk Comments.
В итоге получается такой отчет:
Этот отчет был создан в Excel, который использовал запрос, где Risk Level <> Green. Цвет фона добавлен при помощи самого Excel.
Каждую неделю команда любого проекта, которая сама установила себя в отличную от зеленой зону риска, должна была объяснить остальным командам, как они дошли до такой жизни и что они делают (или должны сделать), чтобы вернуться в зеленую зону.
Если этот риск просто отражает изменения в графике, тогда он должен быть установлен в красную зону на одну неделю, чтобы каждый мог понять, что график был изменен, и почему это произошло, что дата окончания работы была обновлена. Затем этот риск возвращается в зеленую зону.
Вы можете подумать, что вышеуказанный отчет напоминает прогноз «снегопад/ледяной шторм». Мы в Сиэтле не очень хорошо справляемся со снегопадами. Возможно, вы просто посмеетесь над этим, однако, думаю, что местные меня прекрасно поняли. :)
Как заставить эту систему работать?
Вы можете спросить: почему собственно кто-то должен честно показывать свои риски, как желтые или красные? Почему бы просто не оставить их зелеными? Будет не так жарко, не правда ли?
У меня есть два ответа на это.
Первый. Конечно же, если у проекта проблемы, команде придется сдвинуть даты. Если вдруг их даты в один прекрасный день сдвинутся на 4 недели без предварительного изменения рисков, у других может возникнуть вопрос: «Почему вы не узнали об этом раньше?» или «Если вы знали об этом заранее, почему вы не сказали нам?». Это позволяет поддерживать честность между командами.
Второй – это измения в культуре. Изменения уровня риска не всегда означает, что вы делали что-то неправильно. Очень часто риски находятся вне вашего контроля. Однако в ваших силах сообщить об изменениях статуса. На самом деле люди несли ответственность за информирование, а не за риски проекта. Разумеется, если вы будете менять ваши даты очень часто, кто-нибудь из начальства обязательно поговорит с вами.
В следующий раз мы поговорим о том, как мы управляли качественными характеристиками (quality gates), используя эту систему.
