реклама
Бургер менюБургер меню

Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 3)

18px

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

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

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

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