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

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

© Щеглов С. И., наследники, 2023

© Давыденков П. И., 2023

© Издание, оформление. ООО Группа Компаний «РИПОЛ классик», 2024

Памяти Сергея Игоревича Щеглова

(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. Активность измеряется на основе собранной ранее объективки путем анализа сведений о высказываниях и действиях человека на предмет преобладания в них немедленных эмоциональных реакций на какие-либо раздражители. Человек, постоянно лайкающий чьи-то посты в «Фейсбуке» [1], несомненно, более активен, чем человек, изредка выкладывающий на своей странице какие-нибудь отвлеченные соображения. В личном общении метрика измеряется путем немотивированной смены темы: активный человек ее сразу подхватит, менее активный – почувствует себя неловко или даже начнет протестовать.

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

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

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

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

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

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

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

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

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

(12) Метод «Определение психотипа»

Практический смысл имеет выделение пяти основных психотипов.

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

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

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

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

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

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

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

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

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

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

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

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

(13) Метод «Таблица потенциальных конфликтов»

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

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

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

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

Таблица потенциальных конфликтов представляет собой разреженную (то есть со значениями далеко не в каждой клетке) матрицу N × N, где N – число аффилянтов проекта. Составляется она последовательным сопоставлением карточек аффилянтов между собой: если среди социальных и поведенческих стереотипов есть конфликтующие (компенсаторность – подпадание под категорию, за счет которой компенсируется; технологические предпочтения – полярная разница и т. д.), то соответствующая пара аффилянтов помечается как конфликтная. Как и везде, 80 % потенциальных конфликтов возникают за счет 20 % аффилянтов. Если конфликтными оказываются разработчики, которых можно поменять, – им следует поискать замену (добавляются соответствующие вакансии). Если это стейкхолдеры или поставщики ресурсов – потенциальные конфликты учитываются на этапе анализа требований и ограничений.

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

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

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

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

(14) Метод «Составление карты доступа к инфраструктурным ресурсам»

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

1. На основе схемы проекта составляется список необходимых инфраструктурных ресурсов (далее просто ресурсов).

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

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

4. Некоторые ресурсы могут остаться без варианта. Это нормально (см. далее).

Результат. «Карта доступа»: перечень инфраструктурных ресурсов с ранжированными по совокупной цене вариантами их получения.

1.2.6. Привлечение дополнительных человеческих ресурсов

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

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

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

(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 придется менять. Для проектов продолжительностью от одного года и более интеллект становится единственным критерием, исходные компетенции попросту несущественны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3.1. Конфликты между аффилянтами

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3.2. Технические ограничения

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

1.3.3. Требования и ограничения PESTLE

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

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

1.3.4. Экономические требования и ограничения

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

1.3.5. Временны́е ограничения

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

1.3.6. Финансовые ограничения

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

1.3.7. Организационно-ресурсная схема с ограничениями

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

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

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

2. Продукт

Мы упорно трудились больше года, жертвуя вечерами, ночами и выходными. По ходу дела наша команда пополнила портфель Hewlett-Packard несколькими отличными патентами. Мы разработали софт, соответствующий чрезвычайно высоким стандартам качества HP. Мы сделали продукт доступным для международных пользователей и адаптировали его для нескольких языков. Мы обучили и подготовили команду продаж. Разместили предварительную информацию о новой технологии в СМИ и получили отличные отзывы…

Только вот проблема: продукт никто не покупал.

Марти Каган. «Вдохновленные»

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

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

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

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

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

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

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

Разработка продукта проводится в DaShe в четыре этапа:

1. Определение целевой аудитории и ее потребностей.

2. Разработка идеи (концепта) продукта.

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

4. Оценка затрат на реализацию компонентов и выделение минимально жизнеспособного продукта.

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

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

2.1. Анализ ожиданий пользователя

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

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

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

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

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

2.1.1. Определение целевой аудитории

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

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

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

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

(19) Метод «Облако смыслов»

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

1. Составляется список кратких названий продукта.

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

2. Формируется «облако смыслов».

Словарный запас среднего человека не превышает 30 тысяч слов, между тем как в языке реально используется 100–200 тысяч. Исходное представление о продукте всегда ограничено личным словарем разработчиков, следовательно, есть риск упустить что-то важное вне этого контекста. Поэтому необходимо максимально расширить доступный словарь за счет применения синонимайзеров и статистики запросов в поисковиках.

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

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

2) подбираются уточняющие слова по статистике запросов в поисковиках («Яндекс Wordstat»). Синонимы подбираются к каждому слову, встречающемуся в вариантах названий. Уточняющие слова ищут к кратким названиям и их вариантам-синонимам. Все подходящие по смыслу ключевые слова записываются. Поиск продолжается, пока не будет найдено нужное количество ключевых слов (не меньше 100). Результат – «облако смыслов», или список из 100–500 (для простых/сложных продуктов) ключевых слов или словосочетаний.

3. Составляется список сущностей.

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

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

Поиск продолжается до получения достаточного количества сущностей – 100 для простого и 1000 (да, тысяча, ведь задача операции – ничего не пропустить!) для сложного проекта.

4. Список сущностей ранжируется по упоминаемости.

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

На первом шаге определяется (по числу страниц в выдаче по запросу) самое популярное из кратких названий продукта. После этого в качестве ранга сущности используется количество страниц, выдаваемых поисковой системой по запросу: {самое популярное название продукта} + {наименование сущности}.

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

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

2.1.2. Кластеризация аудитории по осям нарратива

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

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

Таким пространством координат в DaShe служат оси нарратива.

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

(20) Метод «Оси нарративов»

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

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

1. Ищутся высказывания представителей целевой аудитории.

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

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

2. Выявляются ценностные координаты и кластеры в полученном пространстве.

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

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

3. Выявляются основные нарративы.

Если исходная выборка текстов была достаточно большой, их метрики распределятся в пространстве неравномерно: бóльшая часть текстов попадет в один или несколько кластеров с повторяющимися ценностными координатами и схожими позициями (например, «удовольствия 0,2..0,4 – социальный статус 0,6..0,8»). Средний вектор такого кластера в пространстве ценностных координат называется нарративом целевой аудитории. В документации проекта нарратив сокращенно записывается как вектор – список ценностей со значимостями в диапазоне (0..1).

Нарративы ранжируются по суммарному весу попавших в них сущностей (каждый текст имеет автора, каждый автор относится к какой-либо сущности, ранг сущностей определен на предыдущем этапе).

Результат. Ранжированный список основных нарративов (не более семи).

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

2.1.3. Формирование портретов персонажей

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

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

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

(21) Метод «Портрет персонажа»

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

Назначение портрета – сформировать у разработчиков единый и объективный образ потребителей продукта.

1. Строятся портреты персонажей.

Портрет персонажа включает в себя следующий минимальный набор характеристик:

• фотография;

• фамилия и имя;

• возраст;

• место жительства;

• род занятий (профессия, место работы);

• биография (родители, образование, семейное положение);

• основные занятия в свободное время (развлечения, хобби);

• ценности, мотивация, отношение к жизни (собственно нарратив).

ценности, мотивация, отношение к жизни (собственно нарратив).

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

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

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

2. Персонажи тестируются на существование.

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

3. Персонажи ранжируются по совокупной платежеспособности.

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

4. Определяются цели персонажей по отношению к продукту.

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

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

2.1.4. Определение каналов получения информации и ограничений дискурса

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

(22) Метод «Информационные каналы»

Информационный канал – любой повторяющийся способ получения персонажем какой-либо информации.

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

1. Определяются основные каналы.

Берется (находим в интернете) достаточно полный перечень типовых информационных каналов (50–100 позиций; communication channels, или каналы общения). Для каждого из персонажей на основе его портрета отбираются и ранжируются используемые им каналы. Для этого:

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

анализируется статистика запросов к поисковикам по ключевым словам из портрета.

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

Дополнительно каналы оцениваются по удобству их использования для продвижения разрабатываемого проекта. Ранг определяется отношением затрат на самый дешевый канал к затратам на использование оцениваемого. Пример: предположим, что персонаж «миллиардер» получает информацию о внешнем мире только из двух источников – от своих референтов и через окно автомобиля. Тут 99 % информации идет по первому каналу, 1 % – по второму. Но референты берут 100 тысяч долларов за каждое переданное сообщение, а разместить по пути следования «миллиардера» рекламный плакатик стоит 100 долларов. Ранг удобства для референтов будет 0,001, а для плаката – 1.

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

2. Определение ограничений дискурса.

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

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

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

2.1.5. Определение цепочек добавленной стоимости персонажей

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

Основные факторы

1. Внутренняя логистика: закупка и хранение оборудования, сырья и комплектующих.

2. Производственный процесс: оказание услуг и производство товаров.

3. Внешняя логистика: доставка услуг или товаров потребителю.

4. Маркетинг и продажи: прием и оформление заказов, продвижение и реклама.

5. Послепродажное обслуживание: гарантийный ремонт, сервисное обслуживание товаров, сопровождение программных продуктов.

Вспомогательные факторы

1. Инфраструктура: юридическое оформление, помещение, оборудование. 2. Человеческие ресурсы: персонал, личные связи.

3. Технологии: используемые технологические процессы, включая ноу-хау и опыт персонала.

4. Снабжение: необходимые для повседневной деятельности расходные материалы и их поставщики.

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

В случае если персонаж является лицом, принимающим решение по корпоративным закупкам, внимание уделяется основным факторам его ЦДС как сотрудника соответствующей корпорации, ориентированного на используемые в ней KPI.

(23) Метод «Цепочки добавленной стоимости»

1. Определение цепочек добавленной стоимости.

Заполняется шаблон ЦДС М. Портера (см. выше) по основным и вспомогательным факторам. Для каждого персонажа составляется описание его образа жизни по факторам ЦДС (за счет каких факторов он зарабатывает деньги и на какие факторы тратит) с перечнем совершаемых в их рамках действий. Используется метод «Погружение в тему».

Пример заполнения (самый общий, реально записей в каждой клетке должно быть не меньше десяти).

2. Определение ожиданий персонажей и граничных условий.

Ожидание – это улучшение в каком-либо факторе ЦДС, позволяющее либо сократить затраты, либо получить больший результат. Для их определения анализируются действия персонажа в каждом факторе ЦДС, которые может улучшить или заменить продукт. Составляются конкретные описания ожиданий в терминах улучшаемых/замещаемых действий.

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

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

Результат. Описания ЦДС персонажей с ожиданиями, являющимися граничными условиями по отношению к продукту.

2.1.6. Оценка факторов ЦДС пользователей

Покупатель платит не за продукт и даже не за свои фантазии о продукте; в конечном счете покупатель платит за снижение затрат на какой-нибудь фактор своей ЦДС. Если приобретение продукта действительно ведет к снижению затрат, у покупателя появляются лишние деньги на следующие покупки. А если нет – первая волна покупок окажется и последней.

Поэтому, в соответствии с принципом объективности, в DaShe ранжирование возможных свойств продукта производится по стоимостной оценке факторов ЦДС, к которым они относятся.

(24) Метод «Оценка факторов ЦДС пользователя»

Для юридических лиц факторы ЦДС оцениваются в денежных единицах (себестоимость). Физические лица тратят на факторы ЦДС не только деньги, но и свое личное время; это время пересчитывается в денежные единицы, исходя из стоимости рабочего часа персонажа.

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

Затраты на факторы ЦДС и отдельные действия внутри них (которые и улучшают отдельные свойства продукта) оцениваются в денежных единицах. Источники информации: метод «Погружение в тему», результаты (платные и бесплатные) уже проведенных исследований потребителей (опросы, big data и т. п.). Оценки проверяются по балансу доходов и расходов: оценки денежных затрат на всю ЦДС должны соответствовать доходу персонажа, оценки затрат времени – количеству часов в выбранный период. Проверенные оценки факторов нормируются к рангам в диапазоне (0..1). Для этого используется метод «Взвешенное ранжирование» (см. ниже).

Результат. Для каждого персонажа – список оцененных факторов ЦДС и отдельных действий внутри фактора, имеющих отношение к продукту.

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

(25) Метод «Взвешенное ранжирование»

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

Например, про две группы целевой аудитории А и Б известно, что А в девять раз больше Б. Группы получают вес А (0,9) и Б (0,1). Если известно, что доход в группе А в четыре раза меньше, чем доход в группе Б, дополнительный вес получают А (0,2) и Б (0,8). Суммарный вес пересчитывается как А = 0,9 × 0,2 = 0,18; Б = 0,1 × 0,8 = 0,08, после чего нормируются по единице: А = 0,18: (0,18 + 0,08) = 0,69; Б = 0,08: (0,18 + 0,08) = 0,31. Таким образом, А уже не в девять, а только чуть больше чем в два раза лучше, чем Б.

Результат. Все ранги в рамках проекта выглядят одинаково и модифицируются при добавлении новых метрик одинаковым способом.

2.1.7. Оценка ограничений ЦДС со стороны стейкхолдеров

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

(26) Метод «Оценка ограничений ЦДС со стороны стейкхолдеров»

По каждому фактору ЦДС персонаж может быть зависим от шести групп сущностей:

1) прямого начальника;

2) административных ограничений (законов и инструкций);

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

4) силового воздействия (если «силовики» заинтересованы в определенных решениях);

5) экономического воздействия (взятка или премия);

6) референтной группы (своих друзей, которые, если что – «не поймут»).

Для каждого фактора ЦДС и действия внутри него нужно указать стейкхолдеров, влияющих на принятие решений пользователем, и направление этого влияния. Источники информации: метод «Погружение в тему».

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

Результат. Набор ограничений по факторам ЦДС (список для каждого персонажа).

2.2. Архитектура продукта и продуктовый дизайн

Только теперь, когда целевая аудитория продукта описана в терминах конкретных персонажей и их ожиданий, можно переходить к определению свойств создаваемого продукта. Для этого ожиданиям, которые являются целями персонажа в рамках конкретного фактора ЦДС, ставятся в соответствие функции будущего продукта, удовлетворяющие эти ожидания. Полученный набор функций уточняется, проверяется на безопасность и возможность совместной реализации, оценивается по SWOT: Strengths (сильные стороны), Weaknesses (слабые стороны), Opportunities (возможности), Threats (угрозы) – и после этого объединяется в концепт продукта.

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

2.2.1. Определение функций продукта и их оценка по ЦДС

Для каждого созданного в проекте персонажа известны:

1) количественно оцененные факторы цепочки добавленной стоимости;

2) ограничения, налагаемые на эти факторы внешними для персонажа обстоятельствами;

3) ожидания (цели внутри факторов) по отношению к потенциальному продукту.

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

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

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

2) продукты-субституты, обеспечивающие достижение тех же целей, но с другим качеством;

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

4) и только после этого – продукты-фантазии, «если б прилетели инопланетяне, то у них бы это делалось так».

Функции, явно или неявно выполняемые найденными продуктами, вносятся в перечень и ранжируются по важности для каждого из персонажей, исходя из оценок факторов их ЦДС. Обратите внимание, что результатом анализа и предметом оценки являются функции, а не сами продукты.

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

NB. Следует выделять не только основные, но и сопутствующие функции (такие как обеспечение безопасности = = велосипедный шлем), затрачивая на это достаточно времени.

(27) Метод «Перевод ожиданий в функции»

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

1. Извлечение функций.

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

• прямых аналогов, обеспечивающих достижение всех целей;

• субститутов, обеспечивающих достижение части целей;

• комплементарных продуктов, обеспечивающих достижение сопутствующих целей;

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

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

2. Ранжирование функций.

Ранг функции внутри фактора определяется как доля, в которой она обеспечивает реализацию всего фактора целиком. Например, «все включено» в гостиницах полностью закрывает потребности в жилье (50–80 % инфраструктуры) и питании (15–50 % снабжения), а доставка пиццы лишь частично закрывает потребность в питании (5 % снабжения). После простановки оценок этих долей ранги функций внутри факторов нормируются к диапазону (0..1). Общий ранг функций вычисляется как ранг фактора, умноженный на ранг функции внутри фактора. После вычисления ранги всех функций нормируются к диапазону (0..1) методом «Взвешенное ранжирование».

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

2.2.2. Аппроксимация функций

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

(28) Метод «Аппроксимация функций»

Аппроксимация функций производится в два этапа:

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

2. Отбрасываются формулировки, не подходящие под ограничения ЦДС.

Результат. Уточненный список функций. Критерий успешного завершения – не менее трети функций должны измениться.

2.2.3. Контроль экологии

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

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

(29) Метод «Интервью с экспертом»

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

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

1. Подбираются эксперты. Используются методы «Погружение в тему», «Углубление в социальную сеть».

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

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

Результат. Экспертное заключение в виде кратких выводов и полного транскрипта интервью.

NB. Хотя вокруг полно «экспертов» по всем областям жизни, найти реальных экспертов (годы личного опыта в использовании продуктов-аналогов) очень сложно, а часто и невозможно. Поэтому не следует тратить на поиск экспертов лишнее время: если они недоступны, сократить риски этим способом не получится, нужно двигаться дальше.

2.2.4. Оценка функций по SWOT

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

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

(30) Метод «Оценка по SWOT»

SWOT – способ структурирования разнородной информации по четырем типам характеристик.

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

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

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

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

2. После сбора характеристик производится численная оценка функции по SWOT. Для этого используется следующая метрика. Есть хотя бы одна угроза – общая оценка «−1». Нет ни одной возможности – общая оценка «−1». Слабые, средние и сильные преимущества, недостатки и возможности оцениваются как «1», «2» и «3». Если сумма преимуществ и возможностей меньше суммы недостатков – общая оценка «−1». Иначе общая оценка – сумма преимуществ и возможностей минус сумма недостатков.

Функции с оценкой «−1» отбрасываются как токсичные. Остальные функции нормируются к диапазону (0..1).

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

2.2.5. Создание концепта продукта

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

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

(31) Метод «Прототипирование по списку функций»

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

1. В зависимости от общего количества функций выбирается тип визуальной композиции (layout): если их пять или меньше, то F, если больше пяти, то Z.

2. Порядковое место функции в композиции определяется рангом по ЦДС, визуальный размер функции – рангом по SWOT.

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

Результат. Концепт продукта, представляющий собой его «рекламный листок», или Landing Page.

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

2.3. UX-дизайн и проектирование

Концепт описывает создаваемый продукт с точки зрения его функций: «что он умеет делать». Однако пользователь не знает и не может знать всех особенностей нового продукта. Он будет обращаться с ним, исходя из опыта использования других продуктов, ожидая такого же, привычного эффекта. Тут речь идет о пользовательском опыте (user experience, UX или UE). Если функции продукта не будут адаптированы к пользовательскому опыту, потребитель либо их вообще не заметит, либо будет «забивать гвозди микроскопом» и ругать микроскоп за неудобство. И то и другое означает крах продукта на рынке. Чтобы этого избежать, и приходится изучать и описывать пользовательский опыт как отдельный компонент будущего продукта.

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

Описание пользовательского опыта включает в себя следующие этапы и соответствующие им компоненты:

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

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

3) оценка уровня конкуренции по каждому из элементов (конкурентность);

4) пользовательские каналы получения информации и способы взаимодействия с аналогичными продуктами (customer journey map, CJM – карта путешествия пользователя).

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

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

Кроме UX-дизайна есть также UI-дизайн (user interface) – это то, как пользователь представляет продукт визуально (цвет, размер и прочие параметры). UX и UI настолько тесно связаны между собой, что часто говорят о UX/UI-дизайне.

2.3.1. Анализ ментальной модели по Куперу

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

(32) Метод «Анализ ментальной модели»

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

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

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

3. Проводится анализ ментальной модели.

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

Составляется список продуктов-конкурентов и продуктов-субститутов.

Результат. Ментальные модели и соответствующие им реальные продукты.

2.3.2. Анализ конкурентов и выявление элементов пользовательского опыта

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

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

(33) Метод «Анализ конкурентов»

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

2. Оценивается конкурентность элементов опыта по следующим метрикам:

1) эмоциональная вовлеченность (качественная оценка – есть/нет) посетителей веб-страниц;

2) интуитивность навигации (качественная оценка скорости поиска информации и расположения элемента);

3) избыток или недостаток информации на странице (качественная оценка);

4) адаптированность (или неадаптированность) элементов под ожидания ЦА продукта-конкурента (здесь на основе опыта построения ЦДС со своим персонажем можно приблизительно представить ЦДС персонажей конкурента и сопоставить ранг элементов в продукте конкурента с рангом факторов этой ЦДС);

5) соответствие дизайна и интерфейса мировым трендам (качественная – есть/нет);

6) наличие дополнительных ценностных предложений (по отношению к функциональному описанию проектируемого продукта);

7) критичность элемента для бизнес-процессов потребителя (если есть, то плюс);

8) участие предлагаемого конкурентом продукта в ЦДС потребителя разрабатываемого продукта (если есть, то плюс);

9) особый статус продукта, производителя или отрасли (элемент от Apple куда престижнее, чем элемент от Samsung).

3. Определяется ранг конкурентности элемента – по методу «Взвешенное ранжирование».

Результат. Таблица элементов опыта с их рангами конкурентности.

NB. Существуют и другие методы выявления элементов пользовательского опыта, например мозговой штурм и экспертный опрос. Однако анализ конкурентов обеспечивает значительно бóльшую объективность, полноту и качество выявления элементов и поэтому предпочтительнее (несмотря на большую трудоемкость).

2.3.3. Анализ продуктов-субститутов

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

(34) Метод «Анализ продуктов-субститутов»

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

Метод «Анализ конкурентов» применяется и к продуктам-субститутам.

Результат. Еще одна таблица элементов опыта с их рангами конкурентности.

2.3.4. Построение CJM

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

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

На каждом из этапов пользователь реагирует на элементы опыта (называемые в контексте CJM touchpoints – точками контакта). Эти реакции совершаются на нескольких уровнях:

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

2) интеллектуальном («а сколько эта красота стоит?»);

3) поведенческом («покупаю», «слишком долго грузится – удаляю приложение»).

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

(35) Метод «Построение CJM»

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

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

2. Составляется CJM в виде таблицы с этапами взаимодействия по горизонтали и типами реакций по вертикали.

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

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

Результат. Набор (отличающихся друг от друга!) таблиц CJM – по одной для каждого персонажа.

Теперь элементы опыта не только выявлены, но и соотнесены с конкретными персонажами и ранжированы по силе вызываемых реакций.

2.3.5. Создание матрицы ожиданий пользователя

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

(36) Метод «Построение матрицы ожиданий»

Матрица ожиданий представляет собой обобщенную CJM, в которой похожие этапы объединены, а с элементами сопоставлены метрики по разным персонажам.

1. Производится объединение этапов. Этапы разных CJM считаются похожими, если:

1) в них содержатся одни и те же элементы;

2) содержащиеся в них элементы выполняют одни и те же функции;

3) объединяемый этап пуст, а его описание в ментальной модели соответствует функциям, выполняемым элементами другого, непустого этапа. Этапы, которые не удалось объединить, остаются в матрице (они будут представлены единственным персонажем).

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

Результат. Матрица ожиданий, представляющая собой обобщенную CJM, содержащую элементы, отфильтрованные по негативным реакциям и проранжированные по силе реакций и важности персонажей.

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

Матрица ожиданий подробно отвечает на вопрос: «Чего пользователи ждут от продукта?» Теперь о продукте известно практически все – и что он умеет делать, и как эти умения воспринимают потенциальные потребители. Остается лишь объединить эти представления таким образом, чтобы свойства продукта наилучшим образом «легли» на ожидания потребителей.

2.4. UX/U – дизайн и проектирование

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

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

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

2) рассчитать интегральную оценку важности каждого элемента (с учетом всех уже созданных метрик);

3) оценить затраты на разработку каждого элемента;

4) отобрать для разработки только минимально необходимые элементы (выделить MVP – минимально жизнеспособный продукт) и сформировать на их основе бэклог.

2.4.1. Оценка эмоциональной значимости элементов

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

(37) Метод «Модель Кано»

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

1. Проводится опрос.

Каждому опрашиваемому предлагается оценить каждый из элементов матрицы ожиданий по двум осям:

положительной – насколько понравится наличие этого элемента в продукте;

отрицательной – насколько понравится отсутствие этого элемента.

Оценка выставляется по пяти уровням (1..5 = нравится, ожидаю, нейтрально, терпимо, не нравится).

2. На основе опроса ранжируются элементы.

Они делятся на пять групп:

1) линейные: + (нравится), − (не нравится);

2) обязательные: + (ожидаю, нейтрально, могу терпеть), − (не нравится);

3) восхищающие («вау»): + (нравится), − (ожидаю, нейтрально, могу терпеть);

4) нежелательные: + (не нравится) или – (нравится);

5) нейтральные – все остальные.

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

4. Проставляются ранги элементов. Ранги элементов в Кано-модели присваиваются условным образом: обязательным (исключение которых недопустимо при любых последующих преобразованиях рангов) – «неубывающая единица» (1+), восхищающим – 0,5, линейным – 0,1.

2.4.2. Расчет интегральной ценности элементов

Элементы, оставшиеся в описании продукта, ранжированы уже по нескольким осям:

1) ЦДС (для функции и для каждого из персонажей);

2) SWOT (для функции, соответствующей элементу);

3) конкурентность;

4) ранг Кано.

Для каждого персонажа также определен ранг его важности. Требуется сформировать единую оценку важности элемента в составе продукта.

(38) Метод «Взвешенное мультиплицирование»

Интегральная оценка элемента рассчитывается по следующей формуле:

Ценность (элемент) = max (k1 × ЦДС × персонаж) × k2 × SWOT × k3 × конкурентность × k4 × Кано.

Коэффициенты k1..k4 определяются экспертной оценкой следующих метрик: k1, k2, k4 – точности определения соответствующих показателей, k3 – важности (объема и перспективности) отрасли, в которой измерялась конкурентность.

Результат. Интегральная ценность – наиболее объективная оценка сравнительной важности элементов опыта.

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

1. Обязательные атрибуты.

2. Одномерные атрибуты (уровень функциональности продукта).

3. Привлекательные атрибуты.

4. Атрибуты, не имеющие большого значения для пользователя.

5. Нежелательные (избыточные) атрибуты.

2.4.3. Оценка затрат на реализацию элементов

Рассчитав ценность элементов для внешнего мира, следует оценить их себестоимость – затраты ресурсов (времени, денег и т. д.) на реализацию в ходе создания продукта. Затраты будут возникать не в среднем по мировой экономике, а в конкретных условиях: с оборудованием, разработчиками и стейкхолдерами проекта. Лучше всего оценить такие затраты могут те люди, которые непосредственно участвуют в проекте – то есть сами разработчики.

(39) Метод «Покер-планирование»

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

Перевод трудозатрат в денежные единицы производится по формуле:

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

Результат. Оценка затрат на разработку элементов своими силами.

Реализовать некоторые элементы опыта можно, и не создавая самостоятельно соответствующую функциональность продукта, а закупив ее на стороне или отдав разработку на аутсорс. Поэтому следует оценить и затраты на такое приобретение функций «на рынке».

(40) Метод «Оценка затрат по рынку»

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

2. Помимо оценок в трудозатратах и деньгах (необходимых для сопоставления с бюджетом проекта), элементы методом «Взвешенного ранжирования» ранжируются по рынку и в диапазоне (0..1).

Результат. Оценка затрат на приобретение элементов на рынке; «рыночный ранг» стоимости элементов.

2.4.4. Выделение MVP и формирование бэклога

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

Эта задача решается с помощью выделения MVP – минимально жизнеспособного продукта. Критерием жизнеспособности продукта является заполненность его элементами CJM хотя бы одного персонажа. Для отбрасывания лишних элементов и формирования действительно минимального продукта используется следующий метод.

(41) Метод «Выделение MVP из матрицы ожиданий»

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

2. CJM каждого персонажа, полученная из матрицы ожиданий, оценивается по минимальным затратам на реализацию. Для этого: 1) из каждой CJM отбрасываются все необязательные элементы; 2) оставляется хотя бы один «вау-элемент»; 3) суммируются затраты оставшихся элементов. Выбирается CJM с минимальными затратами.

3. Если суммарные затраты на CJM меньше, чем бюджет проекта, – не экономим! В CJM добавляются отброшенные ранее элементы и элементы из других CJM матрицы с максимальным соотношением «ценность/затраты» (начиная с «вау»), пока бюджет проекта не будет достигнут.

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

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

Бэклог можно (и нужно) оформить не только в виде списка элементов, но и в виде визуального макета продукта (Axure, Autocad Inventor).

3. Разработка

Ни один план не выдерживает встречи с противником.

Хельмут фон Мольтке

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

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

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

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

1. Содержание.

2. Процесс.

3. Персонал.

4. Стейкхолдеры.

5. Коммуникации.

6. Закупки.

7. Стоимость.

8. Качество.

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

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

3.1. Управление содержанием

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

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

3.1.1. Анализ зависимостей

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

(42) Метод «Анализ зависимостей»

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

2. Для исключения пропуска наиболее очевидных и потому чаще всего забывающихся зависимостей используется чек-лист.

• Деньги

• Помещение

• Логистика

• Коммуникационные системы (мессенджеры, хранилища файлов, пространство для совместной работы)

• Туалет

• Еда

• Вода

• Тепло

• Поддержка семьи

• Законность

• Качество воздуха

• Стулья, столы, интерьер

• Возможность спокойно работать (то есть отсутствие информационного шума и постоянных прерываний)

3. Особое внимание уделяется внутренней зависимости – когда разные элементы зависят друг от друга или предъявляют противоречивые требования. Эти конфликты разрешает ПМ с участием экспертов по каждому вовлеченному элементу.

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

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

3.1.2. Аллокация ресурсов

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

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

(43) Метод «Аллокация ресурсов»

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

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

3. Уточненный граф обсуждается со стейкхолдерами. Решаются две задачи:

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

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

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

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

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

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

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

3.1.3. Диаграмма Ганта

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

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

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

Таким образом, диаграмма Ганта позволяет контролировать не только состояние текущих задач, но и последствия их более раннего или более позднего исполнения.

(44) Метод «Диаграмма Ганта»

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

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

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

4. Исходя из сопоставленной стоимости каждой задачи заполняются показатели для метода освоенного объема. В первой итерации определяются плановые объемы: сумма плановых расходов на выполненные задачи к каждому майлстоуну (Planned Value, PV) и по всему проекту (Total Planned Value, TPV). После завершения каждой задачи фиксируются фактические затраты на все выполненные к данному моменту задачи – Actual Cost, AC. Далее рассчитывается плановая стоимость фактически выполненного объема работ за определенный период времени – Earned Value, EV (если проще, это освоенный объем).

Показатели освоенного объема предоставляют ПМ целую «приборную доску» для оценки хода проекта. Есть ли перерасход бюджета: EV – AC. Есть ли задержка по времени выполнения: EV – PV. На сколько процентов выполнен проект: EV/TPV. Какова текущая скорость выполнения по отношению к плановой: EV/PV.

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

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

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

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

3.1.4. Оценка инфраструктурных ресурсов

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

(45) Метод «Сравнительная оценка инфраструктурных ресурсов»

Оценить ресурс – значит сопоставить ему некую метрику его полезности по сравнению с альтернативами.

Например, если известно, что производительность программистов в open space на 40 % ниже, чем в отдельных кабинетах, ресурс open space получит индекс производительности 0,6, а ресурс «коридор + комнаты» – 1.

1. Составляется список «конкурентных позиций», для которых имеется два или более вариантов инфраструктурных ресурсов.

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

2. Выделяются сопоставляемые свойства ресурса.

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

• «+» доступность («−» риск дефицита);

• «+» понятность, быстрота результата («−» риск затягивания освоения);

• «+» производительность («−» риск затягивания работы);

• «+» гибкость, богатство возможностей («−» риск срыва работ из-за отсутствия ключевой функции);

• «+» надежность, отработанность («−» риск отказа в критический момент).

3. Экспертами (ответственными за элементы, под которые привлекаются ресурсы) производится оценка ресурсов.

Одинаковые свойства отбрасываются, остальным выставляются оценки в диапазоне от 0 до 1. Агрегация оценок не производится, так как в зависимости от задач при выборе ресурсов будут использоваться разные метрики.

Результат. Оценки инфраструктурных ресурсов. На основе оценок инфраструктурных ресурсов производится их выбор под конкретные задачи проекта.

(46) Метод «Выбор инфраструктурных ресурсов»

1. На диаграмме Ганта выделяются задачи, в которых задействованы альтернативные ресурсы. Исходя из расположения задач относительно критического пути определяется требование к надежности ресурса. Численно надежность может быть выражена в виде запаса времени, который наиболее ответственная задача имеет по отношению к критическому пути. Например, если первая из задач находится на критическом пути – запас равен нулю. Если первая из задач находится вне критического пути, то запас равен промежутку между ее окончанием и началом задачи, находящейся на критическом пути. Таким образом, каждому из наборов ресурсов соответствует требуемый уровень надежности, который рассчитывается по формуле:

Плановая продолжительность проекта – Запас

2. В зависимости от требуемой надежности используются разные метрики ресурсов.

Для надежности 0,8–1 – доступность, понятность, отработанность. Для надежности 0,4–0,8 – производительность. Для надежности 0–0,4 – богатство возможностей, потенциал роста.

Результат. Выбранные ресурсы под каждую задачу.

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

3.1.5. Оценка рисков и добавление буферов

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

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

(47) Метод «Добавление буферов»

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

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

1) инфраструктурные риски (вероятность «несрабатывания» конкретного ресурса);

2) персональные риски (вероятность, что конкретный разработчик «не потянет» или внезапно покинет проект);

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

После этого для каждой задачи рассчитывается агрегированный риск: как произведение (1 − риск) всех составляющих рисков.

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

4. По всем задачам пересчитывается плановая стоимость:

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

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

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

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

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

Результат. Диаграмма Ганта с временны´ ми буферами на критическом пути и пересчитанной плановой стоимостью каждой задачи.

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

3.1.6. Оценка влияния стейкхолдеров

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

(48) Метод «Влияние стейкхолдеров»

1. Из архива проекта извлекаются и помещаются на видное место перед глазами ПМ:

• карточки стейкхолдеров (с личными ценностями и предпочтениями);

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

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

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

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

5. Пункты 2–4 проделываются регулярно, а в идеале – ежедневно.

Результат. Измененная диаграмма Ганта, динамически подгоняемая под настроения стейкхолдеров.

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

3.2. Управление процессом

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

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

1) синхронизации действий (расписанию);

2) распределению действий между разработчиками (планированию);

3) мониторингу результатов;

4) координации совместной (групповой) работы;

5) найму и увольнениям разработчиков;

6) и самое главное – обеспечению высокой репутации как лично своей, так и проекта в целом.

Для каждого из этих объектов в DaShe предусмотрены соответствующие методы.

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

3.2.1. Управление расписанием

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

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

(49) Метод «Составление расписания»

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

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

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

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

5. В случае если суммарное время заданий укладывается в плановые сроки для задач, определяется последовательность выполнения заданий (назначается приоритет). Если не укладывается – производится возврат на этап 2, и декомпозиция задач проводится заново, с корректировкой требований, после чего пункты 3–5 повторяются.

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

В традиционном SCRUM этому этапу соответствует «подготовка к планированию спринта».

3.2.2. Планирование этапа проекта (спринта)

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

(50) Метод «Планирование этапа»

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

2. Входящая информация для планирования: бэклог (диаграмма Ганта) проекта; текущее состояние проекта (результат предыдущего этапа); статистика производительности команды; составленное предварительное расписание.

3. Каждому из участников совещания предлагается высказать замечания по входящей информации:

1) правильно ли отобраны задачи для этапа (может быть, слишком мало или слишком много?);

2) правильно ли они декомпозированы на задания;

3) правильно ли определена последовательность выполнения;

4) нет ли заниженных или завышенных требований;

5) правильно ли определена трудоемкость заданий;

6) правильно ли назначены исполнители заданий (в тех случаях, когда они уже назначены);

7) каких исполнителей лучше назначить на задания, где они еще не определены.

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

5. Формулируется общая цель этапа в терминах элементов продукта («Когда мы закончим этап, у нас будет работать А, Б и В!»).

6. Цель, задачи этапа и персонализированные задания выносятся на «доску проекта».

Результат. Перечень заданий, с конкретными исполнителями, плановым временем выполнения и точно сформулированными критериями выполнения – на «доске проекта».

3.2.3. Ежедневный мониторинг заданий (канбан)

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

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

(51) Метод «Канбан»

1. Задания с «доски проекта» переносятся в автоматизированную систему с сохранением приоритетов, планового времени и критериев завершения. Система должна обеспечивать единственность задания у одного исполнителя в один момент. Это принципиально важно, поскольку любое дополнительное задание, даже если оно не выполняется, рассеивает внимание и значительно снижает производительность. Значительно – это не на проценты, а в разы!

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

3. В любой момент ПМ обладает всей полнотой информации о выполненных, выполняющихся и запланированных заданиях этапа и использует эту информацию для управления репутацией (см. п. 3.2.6).

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

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

3.2.4. Групповая работа (Nexus)

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

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

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

(52) Метод «Групповая работа»

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

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

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

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

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

3.2.5. Наем и увольнение

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

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

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

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

(53) Метод «Увольнение токсичного разработчика»

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

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

3. Проверяется возможность представить увольнение как то, чего не может случиться с другими разработчиками (ХХХ нарушил правило, которое никому больше в голову не придет нарушать).

4. Если такая возможность есть и риски для проекта при сохранении разработчика выше, чем при увольнении, запускается процедура увольнения:

1) ПМ подыскивает варианты альтернативного трудоустройства разработчика (другие отделы той же компании, другие проекты и т. д.);

2) ПМ организует «коллективное мнение», что кандидат не вписался в проект, и когда тот придет на доверительную беседу, соглашается, что есть такая проблема и ее нужно решать;

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

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

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

(54) Метод «Наем нового разработчика»

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

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

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

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

3.2.6. Управление репутацией

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

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

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

Управление репутацией в DaShe ведется по трем направлениям:

1) репутация проекта у потенциальных потребителей продукта;

2) репутация самого ПМ у аффилянтов проекта;

3) репутация проекта в профессиональной среде разработчиков.

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

(55) Метод «Управление репутацией»

1. Любое хоть сколько-нибудь интересное событие в проекте оформляется как новость и доводится до потенциальных потребителей и профессионалов.

Информация оформляется по-разному для разных аффилянтов, аудиторий и информационных каналов. Используется нарративный анализ и подстройка тональности сообщений (tone of voice) под особенности аудитории.

2. В личном общении со всеми аффилянтами проекта ПМ строго придерживается следующих принципов поведения.

• Вежливость. Независимо от содержания контакта ПМ пользуется корректными интонациями и выражениями.

• Порядочность. ПМ соблюдает «библейские заповеди»: не врет, не подставляет, не занимается шантажом или вымогательством, выполняет свои обязательства и обещания.

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

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

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

3. Репутация проекта и команды проекта в профессиональной среде проверяется путем «прощупывания почвы» на профессиональных форумах и в социальных сетях: «Меня зовут в проект ХХХ, что посоветуете?» – и тому подобные вопросы от имени знакомых разработчиков (которых у ПМ, разумеется, должно быть много). Для формирования репутации в профессиональной среде ПМ создает информационный канал (блог какого-нибудь разработчика или даже официальный блог проекта; главное, чтобы его автором выступал кто-то другой). Через этот канал осуществляется пропаганда ценностей проекта теми же способами, что и в пункте 1.

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

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

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

3.3. Управление персоналом и субподрядчиками

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

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

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

Метафора управления персоналом – тот же «самолет в воздухе». ПМ «направляет» (мотивирует) и «ремонтирует» (устраняет проблемы) команду проекта.

3.3.1. Лидерство

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

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

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

(56) Метод «Лидерство»

1. Высовываться. Объясним смысл этого действия на примере известного анекдота. В проекте работает Вася, который не понравился стейкхолдеру. Тот звонит ПМ: «Давай-ка уволим Васю». – «Нет, – отвечает ПМ. – Вася очень важен для проекта, закрывает ключевой участок работы, без него мы не справимся, если хотите его уволить, начните с меня». – «А, ну если так, – говорит стейкхолдер, – тогда ладно». ПМ кладет трубку и спрашивает у команды: «Кстати, а Вася чем у нас занимается?»

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

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

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

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

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

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

3.3.2. Интеграция команды

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

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

(57) Метод «Интеграция команды»

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

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

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

3. Формирование субкультуры. Групповая субкультура складывается из стереотипов, определяющих «своих – чужих», норм поведения в отношении «своих», ощущения «мы вместе». Конечно, существуют и другие компоненты, но для управления достаточно и первых трех.

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

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

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

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

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

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

Результат. Команда с позитивной, настраивающей на работу субкультурой, лояльный ПМ, поскольку он лучший носитель этой субкультуры, а значит, «неформальный лидер».

3.3.3. Нацеливание на достижения

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

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

(58) Метод «Образ будущего»

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

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

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

Учитывается структура мотивации (см. п. 1.2.4) «безопасность – секс – доминирование», уже известная ПМ с этапа анализа аффилянтов. ПМ уточняет ожидания и мечты, связанные с мотивационным ядром разработчика, и переводит их в конкретные цели.

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

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

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

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

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

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

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

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

3.3.4. Защита исполнителя

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

Мотивация разрушается, когда исполнитель не получает положительной обратной связи по итогу хорошо сделанной работы. Наиболее распространенным случаем неправильной обратной связи является изменение заданий в ходе спринта: «Задача А, которую вы делали, пока не нужна, делайте сейчас Б». Казалось бы, ничего особенного – но ради задачи, которая не так уж и нужна, никто не захочет напрягаться. Даже единичный случай изменения заданий может подорвать доверие к проекту, а если такие изменения возникают регулярно – команда гарантированно перейдет в режим «не торопись выполнять указание, все равно отменят».

Поэтому поддержание мотивации в команде требует защиты исполнителей от несвоевременных требований.

(59) Метод «Защита исполнителя»

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

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

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

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

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

3.3.5. Работа с субподрядчиками

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

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

(60) Метод «Интеграция субподрядчика»

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

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

2. Формируется образ будущего. На основе карточки аффилянта ПМ формирует для исполнителя образ будущего, корректирует его в личных разговорах и обеспечивает личную заинтересованность исполнителя в успехе проекта в целом. Например: «Мы разместим у вас следующий заказ, отметив, что благодаря вам…»; или: «Мы упомянем лично вас в PR-кампании результатов проекта», и т. д. – в зависимости от ожиданий конкретного исполнителя.

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

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

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

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

3.4. Управление коммуникациями

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

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

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

3.4.1. Отслеживание коммуникаций

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

(61) Метод «Отслеживание коммуникаций»

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

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

Результат. Участие ПМ во всех значимых коммуникациях.

3.4.2. Переговоры и их результаты

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

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

(62) Метод «Фиксация результата»

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

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

Результат. Разосланное саммари обеспечивает лучшую запоминаемость результатов коммуникации.

3.4.3. Своевременное эскалирование

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

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

(63) Метод «Эскалирование»

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

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

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

3.4.4. Языки коммуникаций

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

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

Цель управления языками коммуникации заключается в обеспечении понятности коммуникаций. Достигается это учетом особенностей разных языков и целенаправленной организацией их использования. Применяется следующая типология языков:

1) по формату общения;

2) по нарративу общения;

3) по цели общения.

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

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

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

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

Чтобы взять под контроль основные случаи непонимания, используется следующий метод.

(64) Метод «Языки коммуникаций»

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

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

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

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

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

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

3.4.5. Трансфер компетенций

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

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

(65) Метод «Трансфер компетенций»

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

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

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

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

3.5. Управление стейкхолдерами

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

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

Управление стейкхолдерами имеет две задачи: 1) решение проблем, выходящих за пределы возможностей ПМ; 2) предотвращение негативных воздействий на проект со стороны стейкхолдеров.

3.5.1. Анализ политических раскладов

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

(66) Метод «Анализ политических раскладов»

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

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

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

3.5.2. Прямое или косвенное влияние

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

(67) Метод «Прямое или косвенное влияние»

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

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

3. Выбирается прямое или косвенное влияние.

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

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

1) Всем стейкхолдерам рассылается официальный документ с формальным описанием возникшей проблемы.

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

3) Один из дружественных стейкхолдеров инициирует обсуждение вопроса на совещании и, если он подготовлен (см. п. 2), добивается полезного для проекта решения.

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

Результат. ПМ выбирает наиболее эффективный способ воздействия на стейкхолдеров.

3.5.3. Поиск и замена стейкхолдеров

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

(68) Метод «Замена стейкхолдеров»

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

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

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

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

3.6. Управление стоимостью

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

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

3.6.1. Фиксация отгрузок

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

(69) Метод «Отгрузки»

1. ПМ фиксирует все производимые в рамках проекта расходы, разделяя их на оплату подрядчикам и собственные расходы на разработку.

2. После завершения очередного этапа рассчитывается стоимость выполнения каждого из активных в этот период заданий, она складывается:

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

долей в зарплатах разработчиков, работавших над заданием:

долей в произведенных собственных затратах:

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

4. Окончательная (появившаяся только после завершения платежного периода) стоимость завершенного задания включается в расписание проекта. С этого момента задание становится отгрузкой.

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

3.6.2. Контроль производительности (метод анализа освоенного объема)

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

(70) Метод «Анализ освоенного объема»

1. В ходе составления расписания была определена плановая стоимость каждой из запланированных задач (Planned Value, PV; см. п. 3.1.3). Плановые стоимости всех задач вместе с резервами и составляют полный бюджет проекта (Total Planned Value, TPV, как в п. 3.1.3, или бюджет по завершении – Вudget at completion, BAC).

2. После завершения первой задачи (а также каждой последующей) ПМ рассчитывает текущие характеристики. Во-первых, освоенный объем (Earned Value, EV), равный сумме плановых стоимостей всех завершенных задач. Во-вторых, фактическую добавленную стоимость (Аctual Cost, AC) – сумму фактических стоимостей отгрузок, входящих в завершенные задачи.

3. После этого рассчитывается индекс исполнения стоимости (Сost Performance Index, CPI) – отношение освоенного объема и фактической стоимости (CPI = = EV/AC). Если индекс меньше единицы (CPI < 1), текущая производительность недостаточна, имеется риск перерасхода бюджета (тем больший, чем ниже индекс исполнения стоимости).

4. Если индекс меньше единицы, производится оценка суммы возможного перерасхода бюджета. Для этого строится линейная регрессия по значениям CPI за всю историю проекта, вычисляется его прогнозное значение на момент завершения проекта, CPI’. Отсюда находится текущая оценка суммы перерасхода: Estimate Cost Variance, ECV = BAC × (1/CPI' – 1).

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

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

3.6.3. Коррекция расписания

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

(71) Метод «Коррекция расписания»

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

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

3. Если устранение причин требует эскалирования, ПМ незамедлительно к нему прибегает: составляет обстоятельную докладную записку и дает ей ход с учетом политических раскладов.

Результат. Если возникают риски перерасхода бюджета, ПМ своевременно корректирует расписание.

3.7. Управление качеством

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

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

Управление качеством в процессной деятельности (на производстве) – давно разработанный и стандартизированный процесс (см. кружки качества, шесть сигм, стандарт ISO 9000 и т. д.). Единственный недостаток этих стандартов – их высокая стоимость. Если соответствующие стандарты уже внедрены в среде, где реализуется проект, ими можно пользоваться; но если они отсутствуют, попытка управлять качеством по ISO 9000 приведет только к перерасходу средств. Поэтому в DaShe применяется сокращенная методика управления качеством, обеспечивающая 80 % результата за счет 20 % усилий.

Управление качеством в DaShe заключается в регулярном выполнении трех операций: 1) приемо-сдаточного контроля отгрузок на соответствие требованиям; 2) выборочного контроля текущей реализации на общее качество; 3) контроля критических мест текущей реализации продукта на соответствие ожиданиям аффилянтов. Во всех случаях выявленные ошибки или недоделки включаются в план следующего этапа.

3.7.1. Приемо-сдаточный контроль

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

(72) Метод «Контроль по чек-листу»

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

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

Результат. Зафиксированные отгрузки соответствуют формальным требованиям.

3.7.2. Выборочный контроль

Формальные тесты не способны гарантировать полную работоспособность компонента (например, multiply(a,b) return 4 проходит тест 2 × 2, но не является функцией умножения).

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

(73) Метод «Выборочный контроль»

1. ПМ случайным образом выбирает одну или несколько отгрузок завершившегося этапа.

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

3. Совместно с экспертом ПМ детально проверяет отгрузку (стресс-тестирование, анализ использованных технологий, сравнение с аналогами и т. д.). По итогам проверки выносится решение – достаточно ли качество для текущего проекта.

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

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

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

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

3.7.3. Критические места

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

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

(74) Метод «Критические места»

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

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

3. Выявленные задания, задачи и элементы являются критическими местами и подлежат дополнительному контролю, организованному по схеме из п. 3.7.2.

Результат. Дополнительная уверенность в отсутствии «подводных камней» в проекте.

3.8. Управление закупками

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

Для устранения риска закупки должны быть хорошо обоснованы. Для этого в DaShe предусмотрены три метода:

1) «импактов» для выявления особых интересов стейкхолдеров;

2) «разборчивая невеста» для анализа рынка (определения кандидатов и выявления критериев);

3) «проведение тендера» для окончательного выбора подрядчика.

Управление закупками требует временны´ х затрат и поэтому применяется не ко всем закупкам. Управления требуют: крупные закупки стоимостью выше некоторого порога чувствительности (например, 10 тысяч долларов; точную сумму определяют стейкхолдеры, задача ПМ – задать соответствующий вопрос), мелкие и средние закупки товаров/услуг, к которым у стейкхолдеров имеются особые интересы (классический пример из С. Н. Паркинсона – вопрос о зарплате уборщицы).

3.8.1. Учет импактов

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

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

(75) Метод «Учет импактов»

1. На основе карточек аффилянтов, с помощью поиска в интернете и опроса доверенных информаторов ПМ определяет возможное отношение каждого из стейкхолдеров к закупаемым товарам или услугам и к подрядчикам-кандидатам. В 90 % случаев отношение будет нейтральное – нет предпочтений, ни разу не работал; проверка проводится ради оставшихся 10 %. Анализ делается в два прохода:

1) при решении, запускать ли полную процедуру закупки; 2) при отборе подрядчиков (см. п. 3.8.2).

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

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

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

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

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

3.8.2. Определение критериев и отбор подрядчиков

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

Если особенности рынка заранее не известны, критерии для отбора подрядчиков необходимо формулировать одновременно с изучением имеющихся на рынке предложений. Для этого используется модифицированная «Задача о „разборчивой невесте“», приведенная на странице 80.

(76) Метод «„Разборчивая невеста“ на рынке»

1. ПМ определяет общее время, которое он может затратить на организацию закупки (N часов). Делением на 2,718 получается время, в течение которого ПМ изучает рынок – имеющихся поставщиков и их предложения. Оставшееся время используется на саму организацию тендера.

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

3. Руководствуясь списком критериев и средними значениями, ПМ отбирает кандидатов на участие в тендере – с показателями не ниже средних.

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

3.8.3. Проведение тендеров

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

(77) Метод «Проведение тендеров»

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

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

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

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

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

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

Заключение

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

«Швейцарский нож» в управлении проектами теперь в ваших руках!

Примечания

1

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

2

Генри Л. Гант (1861–1919) тесно работал с Фредериком Уинслоу Тейлором, отцом научной организации труда и науки управления – менеджмента. Первый формат диаграммы (их несколько) был разработан Гантом в 1910 году.

Content

Сергей Щеглов, Петр Давыденков
Фреймворк управления и анализа проектов DaShe

0. Почему DaShe?

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

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

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

1. Ресурсы

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

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

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

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

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

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

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

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

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

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

1.2.6. Привлечение дополнительных человеческих ресурсов

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

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

1.3.1. Конфликты между аффилянтами

1.3.2. Технические ограничения

1.3.3. Требования и ограничения PESTLE

1.3.4. Экономические требования и ограничения

1.3.5. Временны́е ограничения

1.3.6. Финансовые ограничения

1.3.7. Организационно-ресурсная схема с ограничениями

2. Продукт

2.1. Анализ ожиданий пользователя

2.1.1. Определение целевой аудитории

2.1.2. Кластеризация аудитории по осям нарратива

2.1.3. Формирование портретов персонажей

2.1.4. Определение каналов получения информации и ограничений дискурса

2.1.5. Определение цепочек добавленной стоимости персонажей

2.1.6. Оценка факторов ЦДС пользователей

2.1.7. Оценка ограничений ЦДС со стороны стейкхолдеров

2.2. Архитектура продукта и продуктовый дизайн

2.2.1. Определение функций продукта и их оценка по ЦДС

2.2.2. Аппроксимация функций

2.2.3. Контроль экологии

2.2.4. Оценка функций по SWOT

2.2.5. Создание концепта продукта

2.3. UX-дизайн и проектирование

2.3.1. Анализ ментальной модели по Куперу

2.3.2. Анализ конкурентов и выявление элементов пользовательского опыта

2.3.3. Анализ продуктов-субститутов

2.3.4. Построение CJM

2.3.5. Создание матрицы ожиданий пользователя

2.4. UX/U – дизайн и проектирование

2.4.1. Оценка эмоциональной значимости элементов

2.4.2. Расчет интегральной ценности элементов

2.4.3. Оценка затрат на реализацию элементов

2.4.4. Выделение MVP и формирование бэклога

3. Разработка

3.1. Управление содержанием

3.1.1. Анализ зависимостей

3.1.2. Аллокация ресурсов

3.1.3. Диаграмма Ганта

3.1.4. Оценка инфраструктурных ресурсов

3.1.5. Оценка рисков и добавление буферов

3.1.6. Оценка влияния стейкхолдеров

3.2. Управление процессом

3.2.1. Управление расписанием

3.2.2. Планирование этапа проекта (спринта)

3.2.3. Ежедневный мониторинг заданий (канбан)

3.2.4. Групповая работа (Nexus)

3.2.5. Наем и увольнение

3.2.6. Управление репутацией

3.3. Управление персоналом и субподрядчиками

3.3.1. Лидерство

3.3.2. Интеграция команды

3.3.3. Нацеливание на достижения

3.3.4. Защита исполнителя

3.3.5. Работа с субподрядчиками

3.4. Управление коммуникациями

3.4.1. Отслеживание коммуникаций

3.4.2. Переговоры и их результаты

3.4.3. Своевременное эскалирование

3.4.4. Языки коммуникаций

3.4.5. Трансфер компетенций

3.5. Управление стейкхолдерами

3.5.1. Анализ политических раскладов

3.5.2. Прямое или косвенное влияние

3.5.3. Поиск и замена стейкхолдеров

3.6. Управление стоимостью

3.6.1. Фиксация отгрузок

3.6.2. Контроль производительности (метод анализа освоенного объема)

3.6.3. Коррекция расписания

3.7. Управление качеством

3.7.1. Приемо-сдаточный контроль

3.7.2. Выборочный контроль

3.7.3. Критические места

3.8. Управление закупками

3.8.1. Учет импактов

3.8.2. Определение критериев и отбор подрядчиков

3.8.3. Проведение тендеров

Заключение

Примечания