Управлять, страдать, улыбаться…

by Shnobell

Ракетостроение, строительство дома, производство автомобилей, разработка ИТ продуктов – любое создание уникального продукта или услуги нуждается в управлении.

Классические методики управления проектами описаны уже более 40(50) лет назад. Хорошим примером является книга «Основы менеджмента» М.Х.Мескона. С 1992 она уже пережила 3 или 4 переиздания. Последнее время активно продвигаются методики Waterfall, Agile, Scrum, Canban, теория бирюзовой организации и многое другое. К сожалению, в российских реалиях менеджмент проектов является «болевой точкой» для организаций.

Владельцы бизнеса прилагают массу усилий для увеличения маржинальность, увеличению объемом продаж, вывод на рынок новых продуктов, оптимизации расходов. Расходы все равно растут, штат сотрудников увеличивается. ТОП-менеджмент, не понимая, почему это происходит старается «выжать» из своих сотрудников по максимуму… Хотя можно посмотреть на весь этот процесс под другим углом. Как на счет увеличения KPI собственных сотрудников за счет эффективности их совместной работы? Совершенствование процедуры коммуникаций между различными подразделениями? Обучение сотрудников?

Слова и дело

Любая задача хорошо ложится на словах в учебнике. Как на счет практического применения? Чтобы проводить какие-то изменения внутри компании необходимо:

• Знать о существующей проблеме

Все равно, что пройти текст на детекторе лжи. Как прибор зафиксирует лож, если испытуемый не знает, что он врёт? Так и с проблемой, если не знать, что она есть, вроде как её и нет.

• Отдавать себе отчет в причинах возникновения проблемы

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

• Желание меняться

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

«Идеальная модель управления проектами – как утопия»

Позволю себе небольшое отступление…

Все специалисты, работающие по направлению PM (project management) знают слова Agile, Scrum и т.д. Да, это рабочие модели. Но практика их применения возможна:

а) В крупных организациях. Для России это банки, сотовые операторы, гос.корпорации

б) Внедрение требует колоссальных инвестиций

в) На выходе получается что-то своё… Например, у Сбербанка получился не Agile, а Sbergile. Т.е. в той или иной степени все эти модели искажены и адаптированы под текущие реалии. В отрыве от реальность вообще ничего не получится. Поэтому данная статья посвящена описанию процедуры управления проектами в малых и средних компаниях, которые вынуждены в 2020 году делать упор на ИТ сферу, т.к. это диктует рынок.

Старая парадигма по работе с проектами

Классическая схема организации работы:

ТОП менеджмент -> Линейное руководство -> Отделы (Сектора) -> Сотрудники.

Организация развивалась, роста. Появлялись новые отделы. Отделы выросли в департаменты. Количество людей росло. Количество направлений бизнеса увеличивалось. Знакомая же картина? См. Рис. (1).

Эффективно работает вертикальная модель управления, как компанией, так и проектами. См. Рис. (2). Горизонтальные связи на линейном уровне не налажены.

Что происходит дальше?

Сложность бизнеса растёт. Теперь для решения вопроса не достаточно только вертикальных связей от ТОП-менеджмента до отдела решающего конкретную задачу. Возникают CROSS – коммуникации между отделами на уровне руководителей. Далее каждый руководитель спускает задачу на своего подчинённого. Чем сложнее задача, тем больше отделов задействовано в работе над общим проектом. См. Рис.(3)

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

Use case  

Основной поток событий. См. рис. 4.

Результатом конкретного User case стало 7 коммуникаций для прояснения 1 вопроса!

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

Почему не решить вопрос между Сотрудник отдела (1) — Сотрудник отдела (2) спросите Вы? Ну, потому что система устроена по другому.

P.S. Обращаю внимание, что здесь рассматривается модель. А именно модель работы по проектной деятельности, а не по всем процессам внутри компании. Понятно, что существуют процессы, которые отработаны и работают по другой схеме. Например, бизнес процесс ИТ поддержки рабочих мест. Скорее всего, пользователи пишут в тех. поддержку и вопрос решается.

Часть 2 — Проблемы управления проектами. Какие проблемы несёт «вертикальная система» управления проектами в компании?