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

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

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

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

(15) Метод «Назначение индикативных зарплат»

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

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

Результат. Создается обоснованное впечатление, что все зарплаты в проекте выше рыночных.

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

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

(16) Метод «Задача о „разборчивой невесте“»

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

Применительно к найму сотрудников это решение выглядит так:

1. Определяется предельное время, которое ПМ может потратить на подбор кандидатов (например, месяц). Делится на 2,718, и в итоге получается время на «вхождение в тему» ( = 11 дней).

2. Оценивается производительность ПМ (число собеседований в день, например шесть), рассчитывается общее число «калибровочных» собеседований и рабочих собеседований (66 и 114), делится на количество вакансий (например, три). Получается количество собеседований на вакансию (22 и 38).

3. Составляются (запросом к профильным сервисам или через объявления) списки кандидатов на каждую вакансию. Если по какой-то вакансии кандидатов меньше, чем планировалось, то плановые значения других вакансий пропорционально увеличиваются.

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

5. По результатам калибровочных собеседований отсеиваются все кандидаты. Исключения: 1) кандидат, которого нельзя упустить (квалифицированный, мотивированный и идеально вписывающийся в уже собранную команду); 2) в случае длительного проекта (больше шести месяцев) – кандидат с высоким IQ (> 135). Впрочем, такие исключения встречаются крайне редко, хорошо если в одном из десяти проектов.

6. По результатам основных собеседований отсеиваются все кандидаты, кроме того, кто оказался лучше всех из калибровочной выборки и из сегодняшней группы. Если такой кандидат обнаружился, ему звонят сразу после подведения итогов: «Когда вы сможете выйти на работу?»

7. В случае если ни один из кандидатов не оказался лучше калибровочной выборки, принимается лучший из последней группы. Разбивка кандидатов на группы производится именно для уменьшения риска неудачного распределения: если бы собеседования велись по одному, пришлось бы брать одного последнего, а так остается выбор хотя бы из шести человек.

Результат. Максимальная вероятность не упустить лучшего из кандидатов.

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

(17) Метод «Проведение собеседований»

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

1. Вежливость и уважение. Будущему разработчику должно быть приятно общаться с ПМ – что впоследствии перерастет в «приятно общаться по поводу проекта» и в «приятно делать проект в такой компании».

2. Заинтересованность. Полезно узнать о кандидате какой-нибудь факт, не относящийся к его профессиональной деятельности, и упомянуть его в разговоре. Это покажет, что: 1) кандидат интересен ПМ как личность; 2) ПМ располагает временем и желанием обсуждать отвлеченные темы, а значит, к нему можно обращаться с личными вопросами.

3. Благожелательность. Каждый раз, когда в ходе собеседования возникает повод похвалить кандидата или выразить положительную эмоцию по поводу его слов или действий, это нужно делать.

4. Особое внимание общему интеллекту. Профессиональная квалификация – это владение неким набором компетенций. Высокий интеллект (IQ > 135) – это способность быстро освоить любую требуемую компетенцию. В ходе проекта требуемые от разработчиков компетенции меняются очень часто («а давайте попробуем ХХХ»), поэтому любой фиксированный набор компетенций окажется недостаточным, и разработчика с низким IQ придется менять. Для проектов продолжительностью от одного года и более интеллект становится единственным критерием, исходные компетенции попросту несущественны.

Общий принцип: собеседование – это первый рабочий день кандидата в проекте, а не соревнование «кто лучше споет песенку».

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

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

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

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

После закрытия всех вакансий становятся известными личные профили всех аффилянтов проекта и пути доступа ко всем инфраструктурным ресурсам. Это позволяет создать организационно-ресурсную схему проекта, что представляет собой матрицу 3 × 3, в которой остаются незаполненные клетки.

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

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

1.3. Определение требований и ограничений

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

Требованиями в DaShe называются позитивные условия осуществления проекта («обеспечить такую-то функциональность», «использовать такую-то технологию», «произвести пробное внедрение в такой-то компании»), а ограничениями – негативные условия («потратить не больше миллиона», «сделать не позже 7 ноября», «никакой утечки информации к конкуренту ХХХ», «офис закрывается в 20:00, всех выгоняем», «использовать только легальное программное обеспечение»). Например, когда Ашот хочет, чтобы разработка велась в современном красивом open space, куда постоянно ходили бы журналисты, – это требование; а когда Семен желает, чтобы о разработке знало как можно меньше людей, – это ограничение. Совместить требования и ограничения в одном и том же проекте непросто, но это и есть часть работы ПМ. Ну а чтобы совместить, нужно сначала их определить.

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

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

Ограничения могут возникать и из уже выявленных свойств аффилянтов. Например, под проект может быть выделена отличная команда разработчиков; но что, если тимлид этих разработчиков вдрызг разругался с ПМ несколько лет назад? Ресурс в виде «лучших разработчиков» оказывается ограничен уровнем сотрудничества тимлида. Или если финансовый директор явно продвигает интересы банка ХХХ: его настойчивые требования «пусть клиенты берут кредиты в правильных банках» обязательно войдут в противоречие с другими требованиями к продукту, и появятся ограничения либо на финансирование, либо на свойства продукта.

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

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

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

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

В случае если в проекте обнаруживается худший сценарий – политический конфликт между стейкхолдерами, – применяется метод «Проект смерти».

(18) Метод «Проект смерти»

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

1. Пишется служебная записка (или другой официальный документ) о том, что наступление «крайне маловероятного события Х» (которое ПМ ожидает в случае реального возникновения политического конфликта) является угрозой успешности проекта.

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

3. Всем аффилянтам, заинтересованным в успехе проекта (прежде всего – потенциальным потребителям), сообщается, что существует риск «события Х», которое может воспрепятствовать созданию замечательного, всеми ожидаемого продукта.

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

Результат. ПМ «играет на стороне проекта» и пытается изменить настроения стейкхолдеров в пользу проекта («сведем счеты в другой раз, тут, кажется, намечается успех, который всем пригодится»).

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

В случае если повод не может быть устранен (личный конфликт, вызванный прошлыми событиями), необходимо избегать его путем использования других, не столь токсичных ресурсов. Например, если заранее известно, что один из разработчиков точно не сработается с другим, от кого-то из них следует отказаться. Или когда становится ясно, что поставщик бесплатного ресурса может перекрыть кислород, если его пожелания к продукту не будут выполнены, от такого бесплатного ресурса также следует отказаться.

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

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

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