Black box - управление проектом

Статья для проектных менеджеров.

Могу предположить, что каждый проектный менеджер сталкивался с эффектом “Черного ящика” в проекте.

Чёрный ящик — термин, используемый для обозначения системы, механизм работы которой неизвестен или принимается неизвестным (Wikipedia).

Иными словами, это область проекта, которая скрыта от Руководителя. Например, разрабатываем устройство, один из менеджеров отвечает за драйверы управления процессором. Руководитель получает регулярную обратную связь от менеджера о том, что разработка идет по плану. Тем не менее проверить код на соответствие требованиям нет возможности. Можно ли доверять менеджеру, что результат будет в назначенные сроки в соответствии с требованиями?

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

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

https://lifehacker.ru/metod-pervogo-principa/

Блоки проекта, которые находятся на критическом пути требуют детального разбора. Для этого имеет смысл воспользоваться “Первым принципом”. Исторически сложилось так, что в философии, а теперь и в науке, первый принцип — это основное положение или предположение, которое нельзя вывести из какого-либо другого положения или предположения (Wikipedia). Другими словами, необходимо определить, что известно и доказано. Это должно стать отправной точкой для развития логической цепочки разработки. При этом чтобы определить базовые предпосылки необходимо найти ответы на следующие вопросы:

Здесь важно четко понимать и быть честным с собой: в каких областях вы разбираетесь, а какие для вас не очевидны?

Всё, что входит в пункт “1”, является базовой основой проекта. То, что входит в пункт “2”, обозначается понятием “Черный ящик” и далее требует основательной, детальной проработки.

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

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

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

Из практики

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

Обеспечение “прозрачности” разных подразделений по отношению друг другу позволит избежать слепых зон, особенно на этапе создания чего-то нового.

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

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

1. Что ему/ей известно на 100%, доказуемо и подтверждено? Другими словами, почему что-то может быть достигнуто? Нужны неопровержимые доказательства.

2. Что ей/ему неизвестно либо вызывает сомнения/опасения? Или что не дает спать по ночам, его страшный сон? (относительно проекта, конечно)

На основе данного разговора Вы получите своеобразную матрицу или карту рисков. Далее важно обсудить, как менеджер и/или вы вместе планируете работать с каждым из рисков. Идеально, если к каждому потенциальному решению будет привязан срок, некая контрольная точка. Это даст Вам в дальнейшем опору для того, чтобы понимать, в какой момент ситуация вышла из под контроля.

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

Целью дальнейших встреч является оценка процесса реализации идеи, то есть того, как планы переходят в конкретные действия и решения.

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

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

Открытые вопросы - это те, которые не подразумевают ответ “Да или Нет”.

Лучше всего избегать формулировок “Почему не получилось?” и заменить их на “Что может быть сделано, чтобы это получилось?” Это позволит перевести фокус на решения (solving state of mind) вместо поиска виновных.

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

Поскольку устройство не работало, как было запланировано. Мы нашли компанию, которая специализировалась на проектировании электронных плат. По нашей просьбе они сделали аудит изделия. Вердикт был однозначен - наша архитектура ошибочна. Мы не поверили в их оценку. Чтобы докопаться до правды было решено сравнить наше решение с платами Roku TV и Amazon Fire TV. Все тесты подтвердили результаты произведенной оценки. Стало очевидно, что мы облажались с конструированием платы. Кроме того по независящим от нас обстоятельствам мы лишились потенциального заказчика на продукт. Наш инвестор настоял на демонстрации прототипа. Чтобы решить проблему перегрева процессора нам пришлось усилить охлаждение. Таким образом маленький и аккуратный стик, который должен был подключаться к разъему HDMI, превратился в стимпанк устройство с торчащими во все стороны трубками для охлаждения.

При этом софт работал потрясающе мягко. Логика работы интерфейса производила отличное впечатление. Сегодняшний Google TV стал отчасти напоминать, то что мы делали тогда. Тем не менее инвестор остался не доволен тем, как выглядит стик. Было очевидно то, что изменение дизайна платы потребует минимум 12 месяцев. Мы не смогли найти деньги на разработку и проект был закрыт.

Управляя проектом мы часто теряем связь с реальностью. Поскольку мы становимся слишком погружены в детали, не замечаем или не хотим верить в реальность. Будьте честны с собой. Проверяйте ключевые части разработки через привлечение внешних партнеров. Возвращайтесь к вопросу - Что я знаю наверняка или что доказано на 100%?

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

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

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

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

5. Используйте “первый принцип” для определения базовых основ. Не позволяйте ввести вас в заблуждение. Помните, что основой, на которую можно опереться является, то в чем можно быть уверенным на 100%.