«Сложность»! = «эффективность»

Наверное, почти каждый менеджер хотя бы пару-тройку раз сталкивался с ощущением потери контроля над ситуацией. Собственно, еще в середине 1980-х Лоуренс Питер сформулировал полушутливый принцип, дав ему свое имя: “В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности” — так что правильнее было бы сказать “почти каждый — кроме тех, кто еще не сталкивался”. В том числе и по этой причине, например, управление проектами принято включать в число наиболее стрессовых профессий.​

Читать дальше 

Для нас же важно, что данная проблема рано или поздно касается менеджмента всех уровней: от тимлида в коллективе из 20 человек — до CEO транснациональной корпорации с десятками тысяч сотрудников. Вот только если у гигантской корпорации обычно есть запас времени на восстановление контроля и бюджет на привлечение матерых консультантов (тяготеющих в качестве решения предложить некий продукт или технологию, сложные настолько, что уровень реального контроля в результате их работы падает куда чаще, чем восстанавливается) — то в небольшой компании обычно нет ни времени, ни бюджетов, ни особых инструментов… ни прошлого опыта успешного решения таких проблем.

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

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

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

И если внимательно присмотреться к этим попыткам упорядочения хаоса, то чаще всего у них обнаруживаются две общих черты: сложность использования + отсутствие наглядности. Одна датская компания также столкнулась с этими проблемами — и так у нас в HQSoftware появилась возможность поработать над достаточно интересным в своей конечной простоте проектом. Что же придумали датчане (и реализовали минчане)? Эту методологию они назвали SCOR:
1. Strategy
2. Context
3. On budget
4. Realization of benefits

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

Итак, заказчику требовался инструмент, который позволял бы (на первом этапе — через вебсайт, далее — через мобильное приложение) Большому Боссу:

а) Сгруппировать цели, задачи, продукты, проекты, бизнес-процессы или проблемные точки компании​

​

б) Запросить у владельцев (в более сложных случаях также была необходима возможность привлекать к оценке объектов иных существенно влияющих на них сотрудников, по аналогии с HR-методом “360 градусов”) продуктов, процессов или иных сущностей нижнего уровня их оценку текущего состояния каждого из объектов по четырем критериям:

1. Strategy — вот мы что-то делаем, а ведут ли нас действия в этом направлении к достижению стратегических целей компании? Quo vadis, в общем
2. Context — есть ли у нас ресурсы и навыки, чтобы добиться успеха в данном проекте/процессе/решении?
3. On budget — укладываемся ли мы в запланированный бюджет (денег и времени)?
4. Realization of benefits — насколько ценен для нас результат в случае успеха? Сможем ли мы извлечь из этого пользу?

Все оценки должны были делаться в измеримом виде, т.е. состояние объекта оценивалось от возможного минимума (“шеф, усё пропало!”) до возможного идеала. Со стороны пользователя, это реализовывалось через single choice radio button, а полученный ответ всегда квантифицировался, чтобы получить возможность для сопоставлений.

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

Тут следует сделать ремарку: для многих из нас это пока не привычно, но в крупные города Европы люди каждый день ездят на работу, зачастую, за 100+ километров, используя не личный автомобиль, а развитую систему скоростного общественного транспорта. Разумеется, коварный капиталист предпочтет, чтобы в это, формально уже — или еще — нерабочее (а значит — неоплачиваемое!), время сотрудник вместо того, чтобы играть в какой-нибудь Clash of Clans или Hearthstone, поработал головой хотя бы.

А далее, в соответствии с полученным оценками, все объекты размещаются на уже упомянутой двумерном координатном поле со следующими шкалами: по оси абсцисс — вероятность успеха, по оси ординат — важность для компании.еще несколько минут на благо компании 4free.

И вот каждый объект оценен. Результат оценки представляется в виде вот такой разноцветной ромашки, где оттенок лепестка отображает оценку состояния по соответствующей шкале:

Значения по шкалам Strategy и Realization of benefits влияют на оценку важности конкретного объекта для компании, значения по шкалам Context и On budget — соответственно, на кумулятивную оценку шансов на успех.

Все просто, все наглядно, конкретные проблемные области подсвечены цветами — тут даже Большой Босс, и то разберется! ;)

Ну и далее, как обычно — набор готовых рецептов:
1. Объект справа вверху? Ничего не трогай, лучше пойди на радостях опрокинь рюмочку: в реальном мире такого обычно просто не встречается! Только не забывай продолжать держать его на контроле: как бы он не начал сползать влево.
2. Объект справа внизу? Вообще лафа: можно расслабиться и о нем забыть: мало того, что он вообще не особо на что-то влияет, так и дела у него идут хорошо.
3. Объект слева внизу, близко к нулевым значениям? Похоже, пора задуматься: так ли он на самом деле нужен вообще.
4. Объект слева вверху? Максимум внимания — именно таким объектам: ситуация трудная, но запускать ее нельзя.
Ну, и большинство объектов, конечно же, оказывается в реальности где-то ближе к центру диаграммы, требуя тех или иных точечных усилий.

Вот такая, если ее можно так назвать, методология. Да, адепты TOC в этот момент резонно заметят, что датчане совершенно проигнорировали вопрос “бутылочных горлышек” — и будут правы. Также не трудно заметить, что работа идет сугубо с вопросами результативности, всякого рода удельная эффективность, включая даже совершенно базовый показатель ROI, пока что остается за гранью внимания.

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

Что же касается технической части — в этот раз мы следовали пожеланиям заказчика: использовали стандартные технологии (чистый PHP, JS, для графиков — canvas), чтобы обеспечить наилучшие возможности для последующей интеграции с другими инструментами и кроссплатформенности.

На втором этапе, нами также был реализован API и сделано “под ключ” Ionic-приложение c авторизацией, ролями, разграничением доступа к проектам и уже знакомым по веб-версии функционалом заполнения опросников (для специалистов и линейного менеджмента) и просмотра сводных оценок (для менеджмента более высокого уровня).

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.