Текст книги "Фреймворк управления и анализа проектов DaShe"

1. Ресурсы

– Почему вы сдали крепость?

– На то было много причин. Во-первых, у нас не было пороха…

Один из вариантов бородатого анекдота

Желание запустить проект может возникнуть у стейкхолдеров по любому поводу. «Есть свободные деньги, надо инвестировать их в какой-нибудь стартап». «Пора уже переделать корпоративную систему работы с клиентами». «До следующего большого заказа целый год, надо занять чем-то разработчиков, чтобы не разбежались», и т. д., с бесконечным числом вариантов. Но какой бы ни была начальная идея, каждый раз речь идет о чем-то таком, чего в практике стейкхолдеров еще не было и что нельзя создать простым указанием: «С сегодняшнего дня начинайте отгрузку изделия ХХХ». Речь идет о создании не просто нового продукта, но и о создании организации, которая его сделает, – команды проекта.

«Перед тем как ехать, нужно собрать машину». Управление проектом отличается от управления производством не только необходимостью каждый день изобретать что-то новенькое, но и тем, что изобретать это новенькое поначалу просто некому. В случае производства управляемая система – отдел, цех, предприятие – уже существует; известен и производимый ею продукт, и технологии его производства, требуется лишь обеспечивать соблюдение этих технологий. Классический менеджмент можно сравнить с ежедневной поездкой на автомобиле по одному и тому же маршруту: да, некоторые улицы закрывают на ремонт, в дороге встречаются пробки, автомобиль иногда ломается, но в целом и автомобиль, и улицы, и пункт назначения одни и те же. А вот в начале любого проекта никакой управляемой системы не существует; команды проекта еще нет, используемые технологии не выбраны, и даже конечный результат обрисован весьма приблизительно. Проектный менеджмент – это каждый раз сборка нового «автомобиля», наилучшим образом подходящего для одной-единственной поездки, причем сборка эта осуществляется прямо во время движения. Помните анекдот про автомеханика и хирурга, когда последний заводит машину и говорит автомеханику: «Вот теперь – чини!»? Точно так же отличается работа просто менеджера и проджект-менеджера.

Реальная «сборка машины» в DaShe производится на этапе разработки, поскольку только на нем становятся понятны все требования и ограничения, существующие в проекте. Но чтобы такая «сборка» оказалась успешной, для нее нужно подготовить «комплектующие» (ресурсы) и задать «маршрут» (бэклог). Тогда станет более-менее понятно: делать для машины обтекаемый корпус и гнать по шоссе или же оснащать ее большими колесами на автономной подвеске и пробираться по бездорожью. Обратите внимание: точно так же, как разные маршруты требуют разных автомобилей, разные продукты должны создаваться разными командами; успех какой-то команды в проекте «по шоссе» – скорее минус, чем плюс, для проекта «по бездорожью»!

Даже из этой простой метафоры становится очевидно, что ресурсов на начало разработки должно быть как можно больше (неизвестно ведь, по какой дороге потребуется ехать), а конечная цель должна быть определена как можно точнее. Но определение конечной цели (продукта в терминах DaShe) – тоже часть разработки (и довольно объемная, см. раздел 2), требующая существенных ресурсов. Поэтому начинать проект нужно с задачи, для решения которой достаточно уже имеющегося ресурса: рабочего времени проджект-менеджера (далее – ПМ). Начинать нужно с анализа ресурсов, завершающегося составлением организационно-ресурсной схемы проекта.

1.1. Проект: власть, люди, инфраструктура

Ресурсом в понимании DaShe является любой компонент проектной деятельности, влияющий на успешность проекта. Самым очевидным типом ресурсов является инфраструктура: помещения, оборудование, информационные технологии, электричество, тепло, расходные материалы, производственные технологии, сырье, комплектующие и все прочее, что чаще всего фигурирует в расходных строках бюджета. Отсутствие или недостаток какого-то инфраструктурного ресурса хорошо заметны (нет электричества – какая работа?), поэтому на них выделяются достаточные средства.

С момента выхода «Человеческого фактора» (Peopleware, 1987) Демарко и Листера хорошо известно, что проекты редко терпят неудачу из-за недостатка материальных ресурсов (денег или времени); куда чаще в качестве причины провала упоминается политика. Неуемная активность одного из стейкхолдеров, интересующаяся дизайном племянница другого, ревнивая жена тимлида (специалиста, который руководит командой разработчиков) – подобные «мелочи жизни» на деле влияют на проект куда сильнее, чем периодически заканчивающаяся бумага в принтере. А если в проекте продолжается застарелый конфликт между стейкхолдерами или ведущий разработчик вдруг ссорится с представителем заказчика – политика начинает проявляться в полную силу и способна поставить проект под угрозу закрытия.

За словом «политика» скрывается тип ресурсов, которому редко уделяется должное внимание. Проектом занимаются люди, связанные между собой определенной сетью полномочий и коммуникаций, которая и делает их командой проекта. В эту команду входят не только непосредственные исполнители, но и стейкхолдеры, и потенциальные заказчики, и сотрудники смежных отделов, и даже, на первый взгляд, посторонние лица, чьи родственники или знакомые как-то связаны с проектом. Чтобы возникающие по ходу любого проекта творческие задачи были успешно решены, разработчики должны обладать нужной квалификацией, быть мотивированными и в любой момент точно знать, что делать. Но разработчики, стейкхолдеры и другие аффилянты (те, которые контролируют ресурсы) проекта – живые люди, у которых, помимо профессиональной квалификации, есть свои интересы и особенности. Поэтому в работе команды неизбежно возникают сбои – начиная с конфликтов между участниками и заканчивая внезапными изменениями требований в интересах одного из стейкхолдеров.

Классический пример из упомянутого «Человеческого фактора» – требование работать в open space и в любой момент быть готовым отчитаться о текущем задании. Такой де-мотивирующий регламент постоянно возникает в проектах в угоду «священной корове» процессного менеджмента – тотальному контролю над работниками. Стейкхолдер, настоявший на таком регламенте, может прекрасно понимать его несовместимость с творческой деятельностью; но если в его KPI (Key Performance Indicator – ключевой показатель эффективности) прописана регулярная отчетность о ходе проекта – он будет обеспечивать именно ее, а не хорошие условия для разработчиков. Вопреки ожиданиям («взрослые же люди, сами должны разобраться»), человеческие ресурсы требуют куда более тщательного подбора и «настройки», чем инфраструктурные. Помещения, оборудование и программы не обижаются друг на друга и не преследуют собственных целей; а вот каждый человек в команде проекта обязательно будет этим заниматься. Надеяться на то, что «интересы дела» возьмут верх над эмоциями, может только очень неопытный и наивный ПМ; на деле он должен заранее предусмотреть возможные проблемы и сформировать команду таким образом, чтобы минимизировать последствия этих проблем.

Однако это еще не самое сложное. Настоящая политика начинается тогда, когда ход или результаты проекта могут повлиять на власть – то есть на распределение должностей, полномочий или на сферу влияния высокопоставленных лиц. Успех любого проекта улучшает карьерные перспективы инициатора и тем самым ухудшает позиции конкурентов. В случае если эти конкуренты сознательно играют «за себя», а не «за компанию» (то есть составляют «властную группировку»), они объективно заинтересованы в срыве проекта. Например, если проект продвигает А, его конкурент Б может рассматривать то, что предлагает и делает А, как способ получить пример его некомпетентности. В этом случае Б может использовать свое влияние в компании для лоббирования неудачных решений (разумеется, так, чтобы ответственность за них лежала на ПМ или была распределена между всеми стейкхолдерами) и тем самым вести дело к срыву проекта.

Рассмотрим классическую схему аппаратной интриги против ПМ и дружественных ему стейкхолдеров.

1. За счет властного ресурса блокируется возможность решить задачу Х официальным путем (пример: не дадим доступ к системе привлеченному разработчику).

2. На ПМ оказывается давление: «Когда задача Х будет выполнена?»

3. Если ПМ решает проблему обходным путем (пример: разрешает разработчику работать под чужим аккаунтом), этот факт документируется и представляется всем стейкхолдерам как свидетельство нелояльности.

Чтобы не попасть в подобную ловушку (а попасть в нее – значит поставить под удар не только себя, но и весь проект), требуется осознавать «аппаратный» смысл возникающих ситуаций – то есть понимать распределение властных ресурсов в компании.

Основная сложность в анализе властных ресурсов заключается в том, что аппаратные интриги, как правило, осуществляются не одиночками, а группировками из нескольких человек, один из которых («сюзерен») обеспечивает административное «прикрытие», а другие («вассалы») осуществляют непосредственные действия, которые со стороны выглядят как обычные лень, глупость или некомпетентность. В этом случае анализ личных симпатий и интересов человека не поможет предсказать, что он вдруг начнет вставлять палки в колеса; требуется еще знать, на кого он на самом деле работает. Разумеется, узнать это получается далеко не всегда, но если существует возможность хоть немного снизить соответствующие риски, ею обязательно нужно воспользоваться.

Поскольку по степени влияния на проект властные и человеческие ресурсы намного превосходят инфраструктурные, подготовка проекта начинается именно с них.

Властные и человеческие ресурсы всегда связаны с конкретными людьми. Даже властный ресурс, принадлежащий группировке, все равно соприкасается с проектом через какого-то конкретного человека и может быть пущен в ход только с его подачи. Человеческие ресурсы, такие как компетентность, коммуникабельность или квалификация, тем более принадлежат конкретному специалисту и только ему. Поэтому для работы с властными и человеческими ресурсами используются одни и те же методы: составление списка аффилянтов, сбор сведений о каждом из них, составление психологических портретов, определение вытекающих из них ограничений и требований. Подробно эти методы описаны в пунктах 1.2 и 1.3, но перед тем, как переходить к ним, следует зафиксировать общие принципы работы с человеческими и властными ресурсами.

Во-первых, властные и человеческие ресурсы можно описывать и классифицировать. Вопреки распространенным мнениям о том, что «чужая душа потемки» и что «все люди разные», разнообразие человеческих реакций не слишком велико, и они могут быть с приемлемой точностью предсказаны заранее. Для этого нужно всего лишь не самоустраняться от решения соответствующей задачи и узнать о человеке как можно больше, составить на основе полученных знаний индивидуальный психологический портрет. Дальнейшее тривиально: если Петя любит выпить, а Вася – завязавший алкоголик, то как сложатся их рабочие отношения? Если Коля лютый антисемит, а Иосиф – мальчик из хорошей семьи? Если Гоша фанатичный бабник, а Маша ненавидит служебные романы? Наконец, если Иван Иванович поставлен стейкхолдером присматривать за проектом изнутри, а Сеня демонстративно унижает всех, кто слабее его профессионально? Никакой магии, не правда ли?

Во-вторых, властные и человеческие ресурсы бывают не только негативными (как в приведенных выше примерах), но и позитивными. Там, где один человек может создать проблемы (начиная с мелких, вроде неполадок корпоративной сети перед релизом, и заканчивая крупными, вроде открытия уголовного дела за нарушение режима секретности), другой человек с соответствующим ресурсом может эти проблемы решить (распорядившись властью начальника, «включить сеть» или организовать звонок в прокуратуру откуда следует). Власть, когда она работает на проект, а не против, – мощнейший позитивный ресурс. Именно власть позволяет стейкхолдерам наделять ПМ различными полномочиями, именно использование власти («под мою ответственность») позволяет быстрее всего решать текущие проблемы. Поддержка действий ПМ со стороны стейкхолдеров, обладающих наибольшей властью, – критически важное условие успеха проекта. Вопрос лишь в том, как мотивировать стейкхолдеров на использование этой власти.

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

В тех (достаточно редких) случаях, когда ПМ имеет возможность влиять на состав команды проекта (примеры: с ПМ советуются, каких соинвесторов брать в проект; ПМ определяет состав и полномочия разработчиков; ПМ располагает кредитом доверия от стейкхолдера с доминирующим властным ресурсом), он должен ее использовать, чтобы собрать наиболее производительных участников. Когда такой возможности нет, ПМ должен выстраивать коммуникацию с учетом индивидуальных особенностей коллег, минимизируя возможные риски.

Например, если среди стейкхолдеров возможны «политические» интриги (а они всегда возможны, если есть хоть какие-то противоречия между интересами), следует выявить властные группировки и их позиции по отношению к проекту, после чего ориентироваться на группировку, заинтересованную в успехе проекта. Если в силу личных особенностей между какими-то разработчиками вероятен конфликт, коммуникации между ними нужно строить через других людей (использовать посредников). Если какой-то разработчик обладает высоким ресурсом обучения, полезно с самого начала планировать возрастание его роли в проекте; напротив, узких специалистов имеет смысл привлекать на срочные контракты под конкретные задачи по мере их возникновения. Таким образом, анализ властных и человеческих ресурсов – основа для построения эффективной команды проекта.

Индивидуальные особенности человеческих ресурсов являются основной причиной того, что одни и те же люди работают по-разному (иногда даже катастрофически по-разному) под руководством разных менеджеров (задающих разные структуры коммуникаций). Методология DaShe предусматривает значительные затраты времени и сил на выяснение всех особенностей человеческих ресурсов и их учет при «сборке» команды проекта.

Как уже отмечалось, даже самая лучшая команда проекта ничего не сможет сделать, если нет электричества. Инфраструктурные ресурсы являются необходимым (но не достаточным) условием успеха проекта и должны быть в любом случае обеспечены. Работа с ними также предполагает следование некоторым принципам. Во-первых, реальная цена задействования ресурса всегда выше, чем сумма в соответствующей строке бюджета. Чтобы получить ресурс (то же подключение электричества), мало заплатить деньги, нужно сначала эти деньги аккумулировать в каком-то месте, а затем проконтролировать получение результата. Все это требует (пусть поначалу неочевидных) затрат других ресурсов (чаще всего времени, причем, что особенно скверно, рабочего времени самого ПМ, а оно не резиновое) и иногда обусловлено выделением «отрицательных» ресурсов («мы вам даем электричество со скидкой – так учтите наши пожелания в продукте»).

Во-вторых, цена инфраструктурного ресурса определяется субъектом, который им распоряжается. Чаще всего таким субъектом является структура – организация или подразделение, работающие строго по регламенту. Счет-оплата-отгрузка, договор-оплата-подключение, заявка-резолюция-выделение – во всех этих случаях цена известна заранее и сводится к деньгам и времени исполнения заказа. Большинство предоставляющих инфраструктурные ресурсы субъектов относятся именно к этой категории: подразделения исполняют регламенты, сторонние подрядчики – договоры, поставщики доставляют комплектующие когда сказано.

Значительно сложнее оценить ресурсы, которыми распоряжаются конкретные люди, имеющие право принимать самостоятельные решения. Те самые люди, чья подпись запускает работу структуры, или же те, которые внутри этой структуры могут себе позволить игнорировать любые подписи. Владельцы компаний, частные инвесторы, друзья и родственники «больших людей», должностные лица с большими полномочиями, боссы преступного мира и жена/муж самого ПМ – все они имеют возможность передумать в любой момент и, можете не сомневаться, охотно этой возможностью пользуются. Цена ресурсов, контролируемых физическими лицами, зависит от их мотивации (интересов) и личных отношений с ПМ и может колебаться в очень широких пределах (от нескольких часов личного времени ПМ до физического насилия в адрес того же ПМ, по незнанию позарившегося на особо ценный ресурс). Поэтому и в случае инфраструктурных ресурсов требуется сбор информации об их владельцах с использованием методов, описанных в предыдущем разделе.

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

Ресурсы выявляют, анализируют и привлекают ради создания команды проекта, той самой «машины», которая доставит проект к успеху. Чтобы при этом отличать более ценные ресурсы от менее ценных, полезно с самого начала составить некую схему проекта, содержащую ячейки для заполнения ресурсами. Схема проекта в DaShe состоит из трех компонентов, соответствующих уже описанным типам ресурсов.

Во-первых, на схему наносится вся внешняя среда проекта: стейкхолдеры, потенциальные клиенты, организации-субподрядчики, сторонние консультанты, государственные органы, общественные организации и разнообразные сообщества (включая сетевые), имеющие отношение к проекту или продукту. В схеме заранее предусматриваются роли «сторонников проекта» и «противников проекта».

Во-вторых, в схему включается организационная структура проекта. В большинстве случаев проекты реализуются на базе какой-либо организации, принадлежащей стейкхолдерам или управляемой ими, и представляют собой ее временное подразделение с соответствующим штатным расписанием. Это временное подразделение (во главе с ПМ) и все связанные с ним подразделения базовой организации и составляют оргструктуру проекта. В случае если для реализации проекта создается новая организация, в ее оргструктуру включаются только те позиции, которые однозначно заданы стейкхолдерами; все прочие должны создаваться под конкретных людей, найденных на этапе привлечения ресурсов. В организационную схему входят профессиональные роли (дизайнеры, маркетологи, программисты, электронщики, механики и т. д.), соответствующие компетенциям, требующимся для реализации проекта.

В случае если у ПМ возникают сложности с определением требуемых компетенций, он опрашивает всех доступных лиц, взвешивая их рекомендации по релевантности (наличию у лица опыта аналогичных разработок).

Третий компонент схемы проекта – иерархическая структура работ, представляющая собой декомпозицию всего объема проекта на отдельные подзадачи. Первый уровень декомпозиции задан фреймворком DaShe (ресурсы, продукт, реализация, сопровождение). Последующие уровни детализируются исходя из специфики предметной области проекта; при этом уточняются профессиональные роли, соответствующие ключевым инфраструктурным ресурсам (облаку серверов, биохимическому процессу или ядерному реактору).

Резюме. Организационная схема проекта – первоначальное описание потребностей в ресурсах, позволяющее оценивать уровень полезности ресурсов, выявляемых на следующем этапе.

1.2. Выявление и анализ ресурсов через аффилянтов

Подготовка проекта начинается с выявления ресурсов. На этом этапе неизвестно, какие «запчасти» понадобятся для собираемого «автомобиля» (команды проекта), поэтому чем больше потенциальных ресурсов удастся обнаружить, тем лучше. Юридическое оформление, квалифицированные работники, помещение, рабочие места с оборудованием, фонд заработной платы, технологии – эти наиболее очевидные ресурсы, как правило, готовы предоставить стейкхолдеры. Но реальное пространство ресурсов намного шире: всегда существует возможность раздобыть и офис дешевле, и программное обеспечение в условно бесплатное пользование, и важную информацию в обмен на другую информацию. Все зависит от конкретных субъектов, распоряжающихся соответствующими ресурсами, и условий, на которых они готовы их предоставить. Чтобы в проекте появился ресурс, кто-то должен передать его в распоряжение ПМ (разработчик – сделать фичу, то есть придумать какую-то фишку или изюминку, финансовый директор – подписать, бухгалтерия – перечислить, руководитель отдела – поручить, сисадмин – настроить, сторонний консультант – проконсультировать, сторонний подрядчик – сдать компонент и т. д.). Решение о передаче ресурсов принимают люди, которые этими ресурсами распоряжаются; поэтому выявление ресурсов начинается с составления списка аффилянтов – людей, имеющих отношение к проекту.

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

– У нас есть ресурс ААА, но только за сто тысяч…

– Есть вариант получить его за десять тысяч благодаря такому-то контакту.

Скорее всего, после этого стейкхолдеры вспомнят свои связи и пополнят список аффилянтов новыми людьми; в результате количество потенциально доступных ресурсов заметно вырастет.

Однако для создания эффективной команды требуются не просто отдельные ресурсы, а их эффективное (бесконфликтное) объединение. Если условием предоставления бесплатного офиса оказывается просьба «возьмите сына моего приятеля на работу», бесплатность становится далеко не очевидной. Поэтому на следующем этапе необходимо проанализировать каждого из аффилянтов на предмет реальной цены, в которую обойдется привлечение контролируемого им ресурса. Чем более дефицитным (незаменимым) или ценным (экономящим все остальные) ресурсом распоряжается аффилянт, тем больше времени можно потратить на его «профилирование». Напомним в связи с этим, что наиболее важными в проекте являются властные и человеческие ресурсы (в списке аффилянтов – стейкхолдеры и ключевые разработчики), а вовсе не пресловутый офис и прочая инфраструктура. В случае если ПМ имеет возможность участвовать в подборе разработчиков (не говоря уже о составе стейкхолдеров), эту возможность следует использовать по максимуму.

Затраты времени (которые могут быть весьма существенными!) на профилирование аффилянтов имеют смысл по двум причинам. Во-первых, тщательный анализ комплементарности позволяет избежать большинства конфликтов и противоречий между аффилянтами. Во-вторых, в случае возникновения каких-то неожиданностей в проекте требуется быстро привлекать дополнительные ресурсы, и времени на анализ их цены может не хватить. Когда большинство потенциальных аффилянтов заранее проанализированы и сведены в таблицу, риск привлечь для затыкания дыры слишком дорогой ресурс заметно снижается. Анализ аффилянтов проводится в самом начале, когда время на него еще есть, – после того, как проект наберет обороты, выкроить время будет намного сложнее.

Когда психологическое профилирование (на глубину, соответствующую ценности ресурсов) закончено, полученный список аффилянтов используется для выявления требований и ограничений, которые и составят реальную цену соответствующих ресурсов в рамках проекта.