По мере того как плоские организации становятся более популярными, также набирают популярность методы и процессы, сопутствующие им. В этом блоге обсуждается не сама плоская организационная структура, а то, как плоская организация функционирует в сфере управления проектами. Принципы управления проектами, извлеченные из плоской организации, могут быть приняты как в самых плоских компаниях, так и в организациях с наиболее иерархической структурой.
Вы можете задать вопрос: «почему мне интересно плоское управление проектами?» Для менеджера проекта ответ прост: меньше делегирования, меньше запросов о статусе и меньше контроля. Это означает больше времени для вас, чтобы сосредоточиться на том, что вам нравится... если только вы действительно не любите быть надсмотрщиком (и если это так, вам следует прекратить чтение здесь). Для того, кто управляется, это тоже довольно очевидно: зачем вам нужен повелитель, который постоянно донимает вас запросами о статусе и «советует», как правильно делать вашу работу? Опять же, если вам это действительно нравится, то этот стиль может быть не для вас. Идея здесь в том, что менеджерам требуется меньше управления, а все остальные имеют автономию и свободу выполнять свою работу так, как они хотят, без надоедливых напоминаний.
Перед началом самого процесса существуют три основных предпосылки, которые действительно заставляют это работать: Доверие, Прозрачность и Общение.
ЗДЕСЬ
Рисунок 1. Доверие, Прозрачность, Общение
Доверие: Взаимное доверие является ключом к успешной плоской структуре проекта
Прозрачность: Необходимость для каждого быть полностью открытым в том, что он делает. Это можно сделать, общаясь о своей работе через некоторые из следующих средств:
Общение: Каждому нужно иметь возможность общаться друг с другом, и это должно поощряться.
Когда есть доверие, появляется прозрачность. Когда есть прозрачность, люди начинают чувствовать себя в безопасности. Когда люди чувствуют себя в безопасности и их поощряют быть открытыми в своей работе, общение происходит естественно.
Теперь, когда мы рассмотрели предпосылки, мы можем обсудить реализацию плоского управления проектом.
Руководитель проекта: "Но я думал, что в горизонтальной структуре нет начальников?" Хотя действительно никому не нужно заниматься "командованием и контролем", важно иметь фасилитатора. Подумайте о руководителе проекта как о дирижере, который гарантирует, что каждый находится в нужном ритме и играет в унисон.
Четкие цели и задачи: Цели проекта должны быть четко сформулированы с самого начала проекта. Вопросы вроде "Какова наша цель? Чего мы пытаемся достичь? Кому вообще нужен этот виджет?" должны быть определены, и вики-пространство идеально подходит для этого.
Требования и ответственность: Будь то руководитель проекта или маркетинг, требования необходимо документировать, иначе в условиях плоского стиля управления проектом может возникнуть хаос. Без четкого направления "босс" легко может вмешаться и собрать все воедино в обычной среде. В плоской среде люди могут легко потеряться без четко определенных требований. В системе отслеживания проблем, такой как Jira, эти требования могут быть зафиксированы как Задачи или Истории. Стандартной практикой было бы, чтобы руководитель проекта назначал задачи отдельным лицам. В более плоской рабочей среде список неназначенных задач представлялся бы команде, где они могли бы самостоятельно назначить эти задачи себе (или другим). Эта система (т.е. где представлены все задачи) может быть такой же простой, как общий лист Excel, или такой модной, как доска Kanban. Как только это установлено, каждый может просматривать и отслеживать статус всего проекта, не будучи боссом.
Централизованное хранилище проектов: Централизованное хранилище проектов является ключом к созданию и поддержанию такого стиля управления проектами. Не происходит сведения или постоянного отчета о работе каждого члена команды перед "начальством". Если люди не могут видеть работу друг друга, то отсутствуют проверки и балансы. Каждый член команды является проверяющим для другого. В мире программного обеспечения это формально делается путем создания Запроса на Изменение (Pull Request) и проверки вашей работы коллегами через код-ревью (вместо того, чтобы начальник выступал в роли контролера). В проектировании схем или разметке это также может быть достигнуто похожим процессом. В этом блоге обсуждается добавление вашего проекта в репозиторий Git (т.е. новый "SVN" или "CVS"). В этом случае следует следовать той же практике инженерии программного обеспечения, что и при добавлении в ветку разработки, а затем создании Запроса на Изменение. Для получения дополнительной информации по этой теме вы можете обратиться к учебному пособию по Git от Atlassian о создании запросов на изменение.
В этом примере вы можете видеть, что мы настроили небольшой проект, содержащий различные требования, составляющие встроенный системный виджет. В данном случае проект представляет собой Эпик, содержащий требования для создания платы "Мигающий светодиод".
Рисунок 2. Эпик, содержащий требования к проектированию платы "Фантазийный мигающий светодиодный PCB"
В этом пространстве проекта у нас есть механические, электрические и программные "компоненты", каждый из которых назначен ведущему компонента.
Рисунок 3. Обзор всех компонентов и ведущих компонентов проекта
Рисунок 4. Пример задачи, содержащей несколько компонентов
Электрик использует Altium и отправляет свой код на сервер Git (в данном случае Bitbucket).
Рисунок 5. Коммиты Git схематического дизайна
Инженеры-программисты и механики делают то же самое. В этом конкретном проекте всего три участника команды, но их может быть бесчисленное множество, при условии, что есть ведущий компонента (т.е. кто-то, кто несет ответственность за эту часть проекта).
Это вики-пространство позволяет вести диалог между всеми пользователями, участвующими в фазах концепции продукта, его реализации или верификации.
Рисунок 6. Вики-страница, содержащая информацию о продукте (включая задачи)
Будь то таблица, список задач, вики-страница или поток электронных писем, важно, чтобы у фасилитатора проекта и остальной команды была возможность видеть все, что происходит в рамках проекта. Это позволяет каждому члену команды быть ответственным перед другими, а не только перед одним менеджером. В нашей компании мы обнаружили, что доска Канбан является лучшим способом визуализации всей активности проекта.
Рисунок 7. Доска Канбан, содержащая задачи примера проекта
Наконец, если член команды обнаруживает проблему, он должен чувствовать себя уполномоченным создавать задачи и назначать их другим членам команды без колебаний. Возможно, они нашли ошибку или им просто нужен дополнительный компонент аппаратуры для поддержки их реализации программного обеспечения - независимо от этого, они должны чувствовать себя комфортно, беря на себя инициативу и делая этот запрос горизонтально, а не сверху вниз.
Микроменеджмент стал таким устаревшим. Управление проектом в горизонтальном стиле, в отличие от вертикального, не только стало модным, но и снижает давление на всех участников. Менеджер проекта меньше сосредотачивается на отслеживании статусов, а дизайнеры тратят меньше времени на создание этих отчетов. В этой статье изложены принципы горизонтального подхода к управлению проектами и то, как выглядит его реализация. Не обязательно полностью изменять корпоративную структуру, чтобы принять горизонтальный подход к управлению проектами - достаточно принять упомянутые выше принципы и смело внедрять их.
Хотите узнать больше о том, как Altium может помочь вам с вашим следующим проектом печатной платы? Обратитесь к эксперту Altium или продолжайте читать о том, как обширная библиотека компонентов Altium Designer напрямую взаимодействует с вашими инструментами проектирования и симуляции, позволяя легко разрабатывать встроенные системы с необходимым функционалом.
ПолучитеСпециальную Скидку При Добавлении Нового Места Altium Designer®