В отличии от бюрократических подходов план реализации не дается сверху как принято говорить.
Если и рассматривать иерархичность, а она должна быть в паре руководитель-исполнитель, то сверху спускается волевое решение о целях, или же определение проекта как направления дела, о котором сказано выше.
Цели это первый шаг к диалогу о результатах. Многие не понимают такой момент, что поставленную задачу не просто можно обсуждать, а нужно обсуждать, или как говорят “челенджить”, бросать ей вызов.
Именно всевозможные ответы на вопросы как раз должны уточнять и дополнять вышеописанные концептуальные документы. Только таким образом проект будет постоянно развивать свою устойчивую модель знаний.
На предоставленные цели план приходит снизу, и поэтому цели могут быть откорректированы или даже отменены, да именно так и работает целесообразность - она способна отменить любой идиотский приказ.
Управление разбивается по целям именно потому что нет возможности (и в том числе нет необходимости) уделять достаточно времени каждому результату, который должен быть получен в рамках целей.
Если цепочка результатов приведет к достижению цели (а именно за этим тянется исполнитель в рамках понимания Engagement Rate) - то за результатами можно не следить, а лишь обсуждать пожелания по их корректировке при их эксплуатации, когда они будут наблюдаемы и обсуждаемы.
Хороший руководитель тот, чье подразделение достигает поставленных целей выполняя необходимые работы вовремя и в выделенные бюджеты -- не это ли мечта.
Необходимо понимать что ничего из ничего не бывает. Любое новое начинание, инновация или изобретение это всегда комбинация на базе предыдущих достижений.
Как минимум мы берем уже существующий порядок вещей и стараемся его улучшить. Хороший пример в этом плане скафандр для жизнеобеспечения в космосе.
До того как в космосе кто-то оказался, уже были разного рода шлемы для полетов в воздухе. И скафандр технически оказался пусть и достаточно сложной, но все же итерацией развития способов защиты человека в не типичной среде существования.
Также и с любым новым проектом можно сформулировать первичный набор компонентов, крупными мазками, из которых будет состоять финальный результат.
Можно привести еще в пример автомобиль и его агрегатные узлы. Двигатель, колеса и прочие ключевые агрегаты. Все мы прекрасно понимаем что это самостоятельные “вещи” выполняющие определенные функциональные задачи (Дела) в рамках общего Дела автомобиля - Ехать.
Двигатель двигает, колеса крутятся, крыша закрывает и тд. Функциональное разбиение это декомпозиция по функциям, или действиям, которые будут использоваться в процессе употребления основного конечного результата.
Ключевая задача первого инженерного действия это получить такой перечень первичных компонентов, который вы можете поручить своим исполнителям в команде.
То есть в этом и заключается и управленческий трюк - в вашем результате будет столько функциональных компонентов, сколько у вас есть доступных сотрудников для этой работы.
Ваша задача сделать первичное разбиение таким образом, чтобы у каждого исполнителя был свой компонент, который и будет являться назначенной целью.
Возможно вы встречали такой подход к управлению как дерево целей, применяется обычно к организации в целом.
Так вот, это он и есть, и если посмотреть вверх и вниз по иерархической лестнице - в момент времени все сотрудники организации расположены на ветвях такого дерева Деятельных Целей.
Не стоит путать такие команды с фактической иерархией. Дело в том что проект, или Дело может быть абсолютно разными, и не связаны, а как правило не связаны с иерархическими структурами.
Можно привести в пример проекты по любым формам партнерских интеграций -- чего угодно с чем угодно.
Сразу вырисовывается “команда проекта двух компаний” - то есть сотрудники одной фирмы и сотрудники другой.
Вместо того, чтобы взаимодействовать через секретарей, юристов, иерархических руководителей -- необходимо работать напрямую, не нарушая оргструктуры и тем самым не мешая проектам.
В той или иной форме это существует уже давно и везде, имя таким командам легион - трайбы, когорты, группы, фичтимы и прочие развлечения.
Все это ни что иное как рабочие группы, целевые проектные команды со своими руководителями, так это и надо учитывать. А называть их можно как вам сегодня будет удобно, смысл не поменяется.
Есть цели, есть ответственные, есть результаты.
Поэтому, по такому же принципу мы декомпозируем решения настолько компонентов, сколько у нас есть доступных человеко-ресурсов под управлением на этот проект.
Важно тут одно - кто отвечает за распределение человеко-ресурсов по проекту, тот и является таким Целевым Руководителем.
Если представлять дерево целей и дерево ответственных по целям, то мы понимаем что это одни и те же деревья.
Можно ли проектировать и декомпозировать цели, если у меня нет подчиненных? Ну во первых вы уже не руководитель в таком случае, но прямо отвечу что да.
Вы имеете можете иметь виртуальную команду, о которой я говорю регулярно, это команда минимум из трех человек - это вы вчерашний, вы сегодняшний, и вы завтрашний.
Этого разбиения, по биологическим циклам уже достаточно, чтобы разделять работу на цели-компоненты.
Более того, так и нужно поступать, если вы действительно понимаете что вы соорудите, то процесс назначения руководителей все-таки идет от того что вы вы хотели бы построить, и в момент времени у вас даже может и не быть команды.
Именно в этой части вам будет понятно, почему пишутся такие документы как Whitepaper, и почему эта процедура может принципиальным образом изменить мнение потенциальных инвесторов о вашем проекте.
Именно потому, что вы можете наглядно продемонстрировать ваше мышление и видение именно продукта в его принципиальных деталях, во времени и пространстве.
Такая квалификация поднимает вас на уровень технологического предпринимателя и вызывает высокий уровень доверия.
Можно отдельно проектировать решения на долгий срок, но у большинства это сейчас не приветствуется, в мире быстрого забега здесь и сейчас, на пятилетку думать особо не хотят.
Но как говорится проблемы индейцев шерифа не тревожат
Прописыванием и проработкой таких длинных целей мы будем говорить в отдельном проекте под названием “Экзамен предпринимательского замысла или Whitepaper”.