Читать книгу: «Фреймворк управления и анализа проектов DaShe»

Name: Фреймворк управления и анализа проектов DaShe
ISBN: 978-5-386-14997-0

Сергей Щеглов, Петр Давыденков

Шрифт:

Памяти Сергея Игоревича Щеглова
(1965–2021)

Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.

Project Management Body of Knowledge, PMBoK

0. Почему DaShe?

В один из долгих зимних вечеров, когда спать еще рано, а все дела уже сделаны, в мессенджер к исследователю власти постучался продакт-менеджер.
– Про Власть у тебя замечательно получилось, – написал он после обычных расшаркиваний, – но есть задачка потруднее.
– Еще труднее? – удивился исследователь. – И какая же?
– Управление проектами, – ответил продакт-менеджер. – Мы должны написать об этом книгу.
– Да этих книг уже столько написано… – начал было исследователь и вдруг остановился.
– Да, – подтвердил его догадку продакт-менеджер. – Именно поэтому.

Когда-то для жизни хватало умения пахать землю, стрелять зверя и строить избу. Промышленная революция заставила нас производить товары – больше, дешевле, надежнее. XX век потребовал сделать из товаров продукты – красивые, удобные, в привлекательной упаковке. А затем пришел век XXI, и выяснилось, что даже этого недостаточно. Теперь потребитель желает новых продуктов – модных, современных, не таких, как вчера.

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

«То, не знаю что» здесь не метафора, а точное описание задачи. От 80 до 95 % новых продуктов терпят неудачу на рынке – как раз потому, что их разработчики (и заказчики) не смогли узнать, чего же хотят потребители. Около 30 % проектов заканчиваются безрезультатно – задачу создания нового продукта не получается решить даже неправильно. В отличие от процессной деятельности по производству уже известных продуктов (в которой достаточно соблюдать правила – и результат будет), проектная деятельность до сих пор остается в значительной степени непонятной.

Сотни написанных книг по управлению проектами – лучшее тому подтверждение. Почти сто лет проектный менеджмент шел по стопам процессного (диаграммы Ганта придуманы в 1910-е годы, метод критического пути создан в 1950-е, первое издание PMBoK вышло в 1987 году), пока в самом начале XXI века не выяснилось, что это был путь в никуда. Аджайл-манифест, или манифест гибкой разработки продуктов, зафиксировал, что проектная деятельность является полной противоположностью процессной: люди в ней важнее регламентов, работающий продукт – важнее документации, готовность к изменениям – важнее согласованных планов. За следующие 20 лет аджайл-методологии стали мейнстримом (71 % компаний в 2020 году использовали для проектирования именно аджайл, а не PMBoK и аналогичные «тяжелые» методологии), и сегодня из трех собравшихся в баре проджект-менеджеров четверо оказываются скрам-мастерами, отвечающими за работу команды. Но в срок и в бюджет по-прежнему укладывается лишь треть проектов, а выпущенные продукты все так же чаще всего «не попадают» в цель. Отказ от процессных методологий оказался немногим более продуктивен, чем их бездумное применение.

А значит, нужно двигаться дальше.

0.1. Основная идея: сложность и риски

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

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

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

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

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

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

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

0.2. DaShe: методология – «швейцарский нож»

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

Прагматический подход, реализуемый в DaShe на основе парадигмы «сложность – риски», заключается в том, чтобы:

1) предоставить проджект-менеджеру достаточно обширный чек-лист потенциальных рисков и методов их минимизации;

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

Если PMBoK можно сравнить с целым заводом по производству проектной документации, а скрам (от англ. scrum – «схватка») – с курилкой при этом заводе, то DaShe окажется «швейцарским ножом» или чемоданчиком с инструментами, которые всегда полезно иметь под рукой.

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

Как система знаний DaShe состоит:

1) из концепции (парадигмы, принципов и постоянно употребляемых терминов);

2) фреймворка (последовательности применения методов при реализации проекта);

3) библиотеки методов (которые можно применять и независимо от фреймворка в целом).

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

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

1) общее понимание проектной деятельности, позволяющее увидеть главные риски в любой ситуации;

2) ее онтология (набор категорий), позволяющая понять, к какой сфере относится возникшая проблема;

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

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

В 1988 году профессор Университета Талсы (США) Поль Левицки (Paul Lewicky) опубликовал результат экспериментов, связанных со способностью людей определять сложные зависимости. Эксперимент заключался в том, что перед испытуемым помещался экран, разделенный на четыре части, и на каждом шаге только в одной из них появлялся крестик (Х). Испытуемый должен был угадать, в каком месте появится следующий крестик. В случаях, когда алгоритм был простым (например, по часовой стрелке или зигзагом), испытуемые его быстро разгадывали и сообщали экспериментатору, где появится крестик. А вот если алгоритм оказывался более сложным («крестик не появляется в одном и том же квадрате, не появившись в двух других»), испытуемые начинали его «чувствовать» (и угадывать чаще), но не могли объяснить, как именно они определяют, где появится крестик!

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

1) формулировать какие-то правила и им следовать;

2) обучаться интуитивно, без возможности сознательно сформулировать, почему надо нажимать именно эту кнопку, – и как раз этот способ и отвечает за творчество.

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

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

Онтология (набор категорий) DaShe используется для распределения методов по этапам проекта. Проект в DaShe – это сущность, состоящая из следующих компонентов:

1) ресурсы;

2) продукт;

3) проектная деятельность.

Проектная деятельность, в свою очередь, разделяется на разработку и сопровождение; однако в последнее время наблюдается тенденция сразу переходить к сопровождению, выбрасывая на рынок совершенно «сырые» продукты, чтобы как можно раньше получить от потребителей обратную связь. Тем не менее в любом проекте существует этап изготовления MVP (Minimum Viable Product – минимально жизнеспособный продукт), на котором реальных пользователей у него еще нет и применение методов сопровождения не требуется.

Полный жизненный цикл проекта состоит из следующих итерационно повторяющихся этапов:

1) поиск и привлечение ресурсов;

2) создание продукта (бэклога);

3) разработка MVP;

4) «непрерывная интеграция» (сопровождение и развитие продукта).

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

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

1) объективность;

2) «принцип одной лодки»: проблемы любого аффилянта – это проблемы проекта в целом;

3) «принцип самолета»: с момента запуска проект непрерывно летит, расходуя ресурсы, даже когда не приближается к результату;

4) все люди разные, поэтому каждый проект уникален, и для каждого нужен свой собственный комплект «дискурс + нарративы»;

5) «недеяние» (созерцательная пассивность), «сад талантов», подстрижка, подкормка, создание условий и т. д. в определенное время.

0.3. В любой непонятной ситуации: самый востребованный метод

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

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

В таких случаях одного и даже десяти запросов недостаточно, и поиск необходимо вести по определенному алгоритму. В DaShe этот алгоритм называется «Погружение в тему» и представляет собой процесс конкретизации описания предметной области от самого общего (несколько слов) до пригодного к использованию в проекте (детальное описание плюс коллекция веб-страниц). Пригодность результата оценивается по критерию “Five Ws + Two How” – то есть по наличию ответов на семь контрольных вопросов. Благодаря этому результатом погружения в тему оказывается не найденная где-то в Сети случайная веб-страница с информацией, а сформированное в ходе поиска понимание предметной области, которое, как правило, решает исходную проблему.

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

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

(1) Метод «Погружение в тему»

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

1. Формируется первичный (заведомо недостаточный) список ключевых слов («металлорежущие станки» и найденные по словарю синонимы).

2. На полученных в выдаче веб-страницах ищутся:

1) источники информации по теме (сайты, книги, журналы, форумы, новостные агрегаторы и т. д.);

2) новые ключевые слова, более подходящие для целей поиска.

3. Источники информации внимательно прочитываются, ключевая информация помещается в отдельный файл со ссылками на источник. Появившиеся по ходу чтения идеи записываются туда же.

4. Проверяется достаточность понимания темы. Критерий – способность ответить на все семь контрольных вопросов: кто, что, где, когда, как, почему и сколько (Five Ws + Two How). В нашем примере с металлорежущими станками нужно получить перечень типов субъектов, принимающих решение о закупках (кто), количество и типы заключаемых ими сделок (что), места их профессионального и личного общения – форумы, аккаунты в соцсетях (где), бюджетные циклы и сезонность сделок (когда), порядок подготовки и принятия решений (как), мотивы субъектов, принимающих решение о закупках (почему), и, наконец, примерные объемы закупок (сколько).

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

5. Если понимания недостаточно для ответа на все вопросы, шаги повторяются начиная с пункта 1, но уже с новым набором ключевых слов.

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

На этом краткое знакомство с DaShe закончено. Дальше начинается сам фреймворк.

1. Ресурсы

– Почему вы сдали крепость?
– На то было много причин. Во-первых, у нас не было пороха…
Один из вариантов бородатого анекдота

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1.1. Властные и человеческие ресурсы

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

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

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

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

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

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

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

1.1.2. Инфраструктурные ресурсы

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

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

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

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

1.1.3. Организационная схема проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2.1. Составление перечня аффилянтов

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

(2) Метод «Картотека аффилянтов»

Бумажная картотека аффилянтов проекта содержит краткую информацию о конкретном человеке. Составление перечня на бумаге требуется потому, что общее число контактов даже одного человека (обычно более 100) намного превышает число, которое он способен держать в кратковременной памяти (3–7). Без составления полного списка можно пропустить даже аффилянтов, контролирующих критически важные ресурсы. Бумажные карточки (а не записи в таблице Excel) необходимы для максимальной активизации ассоциативной памяти; ощущение бумаги, ее шорох, почерк, которым написано имя человека, размещение слов – все это уникально для каждой записи и вызывает из памяти не только имя-фамилию, но и все, что было продумано при составлении карточки.

1. ПМ заготавливает листы бумаги формата A6.

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

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

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

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

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

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

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

Пример классификации по типам ресурсов: стейкхолдеры – «власть», сам ПМ – «люди», знакомый менеджер в дата-центре, где можно арендовать виртуальную машину, – «инфраструктура».

Следующий шаг ПМ – расширение списка аффилянтов до максимума, достижимого в приемлемые сроки (1/10 срока проекта).

1.2.2. Расширение перечня аффилянтов

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

1) предоставить стейкхолдерам информацию о возможных рисках проекта;

2) расширить список аффилянтов.

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

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

(3) Метод «Углубление в социальную сеть»

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

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

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

3. Проводит интервью со всеми дополнительно упомянутыми лицами, до которых удается добраться.

4. Пункты 2 и 3 повторяются до тех пор, пока ПМ не сможет заполнить карточку аффилянта по памяти, не заглядывая в конспекты интервью.

Результат. Карточка аффилянта, с которым ПМ лично не знаком.

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

Полный перечень аффилянтов – основа для последующего анализа ресурсов.

1.2.3. Анализ властных ресурсов

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

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

(4) Метод «Объективка»

Объективка – собранные в одном документе сведения о конкретном человеке, полученные из интернета (сайты и социальные сети). При ее составлении следует руководствоваться двумя принципами:

1) объективностью (записываются только прямые цитаты из сторонних источников);

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

Состав объективки

1. Ближайшие родственники.

2. Аккаунты в социальных сетях.

3. Хронологический «жизненный путь» человека, с указанием:

мест основного пребывания в определенный период (семья, места учебы, работы, клубы или тусовки;

людей, стоящих в тех же местах выше или на том же уровне по должности/статусу;

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

4. Если удается найти, примеры (включаются полные тексты):

личных высказываний (интервью, посты в социальных сетях, статьи) длиннее 50 слов;

участия в обсуждении каких-либо спорных вопросов (диалоги в комментариях, ответы на критические замечания).

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

Результат. Файл на несколько страниц со всеми необходимыми ссылками.

На основе сведений, содержащихся в объективке, производится оценка вероятности вхождения конкретного аффилянта в какую-либо властную группировку.

(5) Метод «Пространство KPI»

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

1) успех выполняемого по DaShe проекта;

2) экономия 100 тысяч долларов на его финансировании.

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

Сведения о пространстве KPI собираются методами «Погружение в тему» и «Углубление в социальную сеть». Ищутся примеры соответствующих событий в истории организации или стейкхолдеров.

Примерный список возможных KPI:

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

2 Вакантные и потенциально вакантные должности (те, которые можно занять, и те, которых можно лишиться).

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

4. Пиар-кампании (анонсы проектов, назначений известных лиц и т. п.).

5. Внутренние показатели компании, влияющие на карьеру (лояльность, бесконфликтность, агрессивность, комплементарность с руководством – здесь разброс вариантов практически неограничен).

Результат. «Пространство KPI» – перечень и взаимные связи основных KPI, используемых в организации.

На основе построенного таким образом «пространства KPI» производится оценка возможных мотивов (локализации в пространстве KPI) каждого властного аффилянта и вытекающего из них отношения к проекту.

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

(6) Метод «Матрица влияния»

Аффилянты, контролирующие властные ресурсы, делятся на четыре категории, укладывающиеся в матрицу 2 × 2:

Последовательность классификации аффилянтов:

1. Определяется возможная принадлежность к группировке. Признаки принадлежности (на основе объективки):

наличие в послужном списке руководящих должностей в организациях из разных сфер деятельности, вес = 0,5;

наличие в организации или группе стейкхолдеров одного или нескольких человек, с которыми аффилянт пересекался на предыдущих местах работы; вес = 0,3;

субъективный фактор (насколько самостоятельным выглядит человек в различных обсуждениях), вес = 0,2.

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

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

3. Определяются мотивы группировок. Из пространства KPI выбираются наиболее значимые для человека с максимальным статусом в группировке. Этот человек может не входить в перечень аффилянтов, но он будет определять отношение к проекту у всех участников своей группировки.

4. Определяются мотивы карьеристов. Из пространства KPI выбираются значимые для конкретного аффилянта.

5. Определяется отношение к проекту. Если успех проекта положительно сказывается на KPI, он выгоден группировке/аффилянту. А иначе (даже в случае отсутствия какой-либо связи) – не выгоден (ресурсы отвлекать придется, а пользы никакой).

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

7. Определяется сравнительный вес группировок как сумма веса ее установленных участников.

Результат. Таблица 2 × 2 с именами всех аффилянтов, контролирующих властные ресурсы, объединенными во властные группировки, и указанием аппаратного веса и целевых KPI аффилянтов и группировок.

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

(7) Метод «Выявление базовых ценностей аффилянта»

1. Определяется (личным контактом или углублением в социальную сеть) тип личности по категориям экстраверт/интроверт.

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

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

Между аффилянтами со схожими базовыми ценностями будет более высокий уровень доверия, и они с большей вероятностью будут формировать коалиции.

Результат. Составленная матрица влияния является основой для формирования требований и ограничений на этапе 1.3.

1.2.4. Анализ человеческих ресурсов

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

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

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

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

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

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

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

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

1. Технологические стереотипы: любимые или нелюбимые технологии (имейл, Slack, парное программирование, совещания и прочее).

2. Социальные стереотипы: стандарты приятной и неприятной внешности, языка (дискурса или нарратива), национальность, пол, возраст.

3. Поведенческие стереотипы: конформизм – нонконформизм, референтность, компенсаторность, утомляемость, процессность.

4. Мотивация: в координатах «безопасность – секс – доминирование», две составляющие – локальная и глобальная.

5. Способ познания мира: таблица «активность/интерес» – линейный, затухающий, убегающий, активный.

6. Психотип: ремесленник (технарь), гуманитарий (торговец), коммуникатор (жрец), силовик (воин), трудяга (общинник).

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

(8) Метод «Определение технологических и социальных стереотипов»

Стереотипами в DaShe называются устойчивые установки человека, определяющие его отношение к другим людям на основе каких-либо формальных признаков. Например, для кого-то неряшливость в одежде собеседника ничего не значит, а для кого-то сразу ставит на таком человеке крест. Одним программистам без разницы, какой язык использовать, а другие считают всех использующих PHP «быдлокодерами». Так вот, у тех, кому не все равно, наличествуют явные стереотипы, которые нужно брать на карандаш.

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

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

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

3. Чек-лист для социальных стереотипов: PESTLE (Political, Economic, Social, Technological, Legal, Environmental), то есть такие свойства других людей, как политические убеждения, принадлежность к экономическим стратам, пол, возраст, расовая, национальная, религиозная или социальная принадлежность, принадлежность к культурной или поведенческой группе и т. д.

Результат. Формализованный список стереотипов, который можно использовать для дополнительной мотивации или учета мотивации человека.

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

(9) Метод «Определение поведенческих стереотипов»

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

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

На работу в проекте влияют любые стереотипы, но специально отслеживать рекомендуется следующие пять.

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

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

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

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

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

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

(10) Метод «Определение структуры мотивации»

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

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

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

1. Ранее собранная информация (объективка) анализируется с точки зрения факторов притягательности предыдущих мест работы. Долгие периоды работы со стабильной зарплатой – «безопасность»; много мест работы с интересными коллегами – «секс»; смена работ с усложнением решаемых задач – «доминирование».

2. Доступные в Сети высказывания человека анализируются с точки зрения мотивации автора. «Мне за это не платят»; «так можно и с работы вылететь» – «безопасность». «У нас на работе такой начальник, а на предыдущей был такой человек»; «главное в офисе – кофе и курилка» – «секс». «Тупая работа рисовать формочки»; «зато проект был интересный» – «доминирование».

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

Результат. Короткая запись из трех букв, определяющая относительную важность уровней мотивации: Д-Б-С или С-Д-Б.

TODO: добавить локальную/глобальную мотивации (модификатор) и подчеркнуть, что «ачиверы» – лучшие работники (только их и мотивировать сложнее).

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

Знать способ познания мира, привычный для каждого разработчика, – значит иметь представление о том, кого можно, а кого нельзя «бросать» на непонятные или непривычные задачи.

(11) Метод «Определение способа познания мира»

В DaShe способы познания мира структурируются в виде матрицы 2 × 2, состоящей из двух бинарных метрик:

общей психической активности (в других терминах – энергичности, проактивности);

интереса к новому (в других терминах – инициативности, поисковой активности).

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

1. Активность измеряется на основе собранной ранее объективки путем анализа сведений о высказываниях и действиях человека на предмет преобладания в них немедленных эмоциональных реакций на какие-либо раздражители. Человек, постоянно лайкающий чьи-то посты в «Фейсбуке» ¹, несомненно, более активен, чем человек, изредка выкладывающий на своей странице какие-нибудь отвлеченные соображения. В личном общении метрика измеряется путем немотивированной смены темы: активный человек ее сразу подхватит, менее активный – почувствует себя неловко или даже начнет протестовать.

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

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

Результат. Пометка в виде одной из четырех последовательностей: «− −» («меньше знаешь – лучше спишь»), «+ −» («чего думать, трясти надо»), «− +» («есть проблема, но и без нее забот хватает»), «+ +» («бросаем все, принимаем меры»).

Четыре типа познания мира можно проиллюстрировать следующей метафорой. Есть четыре разработчика, получившие одинаковое техническое задание. Первый сделал все стандартными методами, так сказать, по ГОСТу. Второй кое-что добавил от себя, но тоже обратился к стандартным методам. Третий – по ГОСТу, но методы использовал новые, потому что скучно одно и то же делать. Четвертый – в рамках ГОСТа, но с кучей дополнений, придумав по ходу собственный фреймворк.

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

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

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

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

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

1.Здесь и далее упоминается Facebook (также «Фейсбук»), который принадлежит компании Meta, признанной экстремистской организацией и запрещенной на территории РФ. – Прим. изд.

Бесплатный фрагмент закончился.