Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно.

Нет, я не помешан на метриках и отчётах. Знаю много случаев, когда управленческие решения принимаются вовсе без данных, и оно срабатывает. Что уж там говорить, с 2009 года, когда появилась компания, мы в нашей компании принимаем сотни решений каждый год, и только часть из них основана на каких-либо измеримых показателях.

С другой стороны, всегда, когда речь идёт про часто повторяющийся процесс, опирающийся на труд персонала, я агитирую за наличие разумного набора метрик. Так можно убрать разрыв между «я думаю» и «на самом деле», так можно увидеть где теряются деньги и другие ресурсы, так можно проще запустить процесс и сделать его лучше. Вот почему в первых же консалтинговых проектах в 2005-м мы с клиентами проектировали для каждого процесса метрики его эффективности, производительности и прочего. Вот почему сейчас для каждой новой команды разработки ПО вопрос измерения я с клиентами начинаю обсуждать как только речь заходит об организации работы. Без фанатизма, а как один из инструментов наладки.

Кроме метрик, вторая моя любимая тема — поток создания ценности. Этой идеей я увлёкся намного позже, когда до меня, наконец-то, дошло, как можно построить работающий (а не декларируемый) поток в интеллектуальной работе по разработке программного обеспечения. Спасибо ребятам из IT Revolution, они (в числе прочих) помогли мне сложить для себя новую, понятную, непротиворечивую и весьма прикладную картину мира. Многое встало на свои места. Несколько десятков команд мы помогли организовать по принципам потока создания ценности и я вижу, насколько мощный это инструмент.

Люди знакомые с ITSM/ITIL знают о том, что, описывая любую услугу, мы можем выделить характеристики «полезности» (utility) и «гарантии» (warranty). Также нередко обсуждаются характеристики, описывающие опыт (experience: user experience, UX и customer experience, CX).
Как соотносятся эти понятия? Можем ли мы говорить о том, что experience — это ещё одна, третья группа характеристик? Что вообще даёт это понятие, и почему utility и warranty может быть недостаточно?

Менеджеры обладают всеми возможностями, чтобы заставить команду страдать

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

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

Три секретных антипаттерна

1. «Белка в колесе»

2. «Миллион Agile-встреч»

3. «Гантаголик»

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

Однако многие, кто заменяет (у себя или у клиента) проектный менеджмент на продуктовый, не утруждают себя анализом границ применимости, а «приклеивают» управление продуктами и к месту, и не к месту.

Приведу примеры, связанный с информационными технологиями: предположим, у нас есть идея какой-то ИТ-системы, закрывающей очень существенную потребность определённой аудитории или устраняющей очень неприятную «боль», при этом аудитория является внешней по отношению к нашей организации и, как нам кажется, готовой платить за закрытие потребности и устранение боли. Мы до конца не понимаем, что за ИТ-система получится, как именно она будет закрывать и устранять, куда она будет развиваться, как её позиционировать, как монетизировать. На верхнем уровне идея нам ясна, а в реализации, понятное дело, будет миллион вопросов и миллиард вариантов. Пригодился бы в таком случае продуктовый подход, применённый к разработке ИТ-системы? Очень вероятно.

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

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

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

Любое серьёзное преобразование в компании, от «внедрения» какого-либо нового ИТ-процесса до пресловутой цифровой трансформации, является организационным изменением: требуется изменить уже имеющиеся системы управления, чтобы они стали работать по-новому, или обрели новые свойства и способности. Приходится работать с формальной стороной (регламенты), культурной стороной (как у нас принято делать дела), технической составляющей, политической и так далее. Это — очень интересная работа, проводить организационные изменения в средних и крупных компаниях.

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

В частности, некоторые эксперты выделяют три явно отличные друг от друга фазы крупного организационного изменения. На первой фазе требуется понять цели и задачи, провести проектирование первых новых систем и структур, составить коалицию влияющих и неравнодушных, приобрести новые необходимые компетенции — много всего. Главное — «сдвинуть махину», «придать ей ускорение», «дать импульс».

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