Управление быстрыми изменениями. Колонка новосибирского IT-эксперта

Партнер компании BGGroup Сергей Голубицкий

Само понятие «управление быстрыми изменениями» неконкретно, так как не понятно, что подвергается изменениям. А еще приходится этим непонятно чем управлять. Чтобы не уходить в философию, мы примем, что в компании присутствуют какие-то направления работ (например, автоматизация, изменение процессов, производство продукции), которые и требуют быстрых изменений. В статье мы будем исходить из того, что в процессе автоматизации нам необходимо изменять программное обеспечение, процессы, работу людей и т. д. Основная мысль, которую я рекомендую держать в голове, —  быстрое получение результата. Пусть результат будет маленький, но это результат! Быстрыми изменениями нужно не только управлять, их нужно быстро создавать и внедрять. Понятие «быстро» вы сами для себя определите. Для кого-то это будет один день, для кого-то месяц, а для кого-то несколько лет.

В качестве пролога, или определяемся с понятиями

Для начала нужно решить, что нам придется менять? Определить характеристики объекта изменений. Материален или не материален он? Что случится с ним в процессе изменений? Какие сроки для нас приемлемы и критичны? С помощью чего и как мы будем воздействовать на объект? Кто заказчик изменений и кто исполнитель? В общем, определяем все, что связано с объектом изменений. А мы условились, что рассматриваем процесс автоматизации. То есть объектом (что будем менять) является некий процесс или процессы, инструментом (с помощью чего) — программное обеспечение, заказчиком (кто заказывает музыку) — представители бизнеса, исполнителями (руками) — программисты. Погружаться дальше в терминологию не будем.

Итак, поехали. Все начинается с головы...

Вы как руководитель должны хотеть...

Чего? Да всего! Конечно, прежде всего — того, что вы будете менять. Без вашей заинтересованности работу можно даже не начинать, потому что никакого результата в долгосрочной перспективе не получится. Так что готовьтесь участвовать на самом деле, а не формально.

Назначить крайнего... или «буйного»

Буйного, конечно, лучше, поскольку он, скорее всего, заинтересован курировать данный проект. Шучу, — руководителя проекта (РП), ответственного за данную работу. Да все равно, как вы его назовете, главное — чтобы он был! Без него ничего не поедет и не поплывет. Вернее, поедет и поплывет, но недолго. Если это сотрудник компании, выполняющий определенные функции, лучше на время проекта освободить его от выполняемых функций полностью или частично. Руководить проектом по остаточному принципу или как дополнительной нагрузкой не получится. При этом руководство должно наделить РП полномочиями, ведь ему придется взаимодействовать с сотрудниками и руководителями подразделений компании. Соответственно, все должны знать, что РП по данному проекту главный, как директор в компании.

Изложите свой великий замысел на бумаге

Очень мало людей (цифра стремится к «минус бесконечности»), которые с первого раза могут объяснить свои «хотелки» программистам. Поэтому заставьте заказчиков (те, кто запрашивает изменения) во главе с РП описать то, что они хотят автоматизировать. Вот только не нужно давать им волю и время на написание нескольких сотен листов (еще и дорогущих консультантов притащат), которые после написания можно смело выкинуть в мусорную корзину, так как бизнес не стоит на месте, и требования уже устарели. Пусть сотрудники изложат свои общие пожелания на минимально возможном количестве листов (в идеале — один-два) за ограниченное время (один-два дня) и предоставят вам для согласования. Далее вы примите решение, а стоит ли автоматизировать этот блок или лучше заняться чем-то другим. Если решение принято в пользу автоматизации, попросите РП детализировать этот блок. Требования — описательный объем и время — те же.

Лучше меньше, да работающее

Главное условие — блок должен быть работоспособен, то есть приносить пользу компании. Требуйте работающий функционал! Долгие внедрения (от одного года и более; лично для меня полгода —  вечность) без получения результата выматывают сотрудников, участвующих в проекте. Энтузиазм прекращается, все устают, включая руководителя, на которого еще давит ответственность финансовых расходов. Так что в автоматизации лучше быть спринтером, чем марафонцем. А если не можете уложиться в минимально разумный срок — дробите задачу. И, опять же, раздробленный блок должен работать!

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

Внедрение. Все довольны? Ничего не работает!

Как правило, при любой автоматизации будут сотрудники, которые получат не только блага (дополнительные возможности, уменьшение ручного труда и т. д.), но и дополнительные функции, чтобы эти блага потом появились. Как правило, такие сотрудники не особо хотят эти дополнительные функции выполнять. Несмотря на то, что при обсуждении задачи эти сотрудники особо не противились, при внедрении они почему-то начинают упираться и возмущаться, что неудобно делать это или то. Конечно, целесообразно доработать систему для удобства этих самых недовольных, но, опять же, разумно. Если вы и ваш РП считаете, что функционал рабочий, и сотрудники начинают откровенно саботировать процесс, принимайте жесткие решения по отношению к данным сотрудникам. Или останавливайте автоматизацию и сворачивайте проект. Значит, вы как управленец не состоялись, если не можете заставить сотрудников работать.

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

Документируем. Или все забудут, как это работает

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

Выбираем следующую ступеньку

Если «кусочек» автоматизации заработал, все довольны и счастливы (возможно, за исключением саботажников), можно приступать к следующему процессу или блоку. Действуем по той же схеме, сначала.

В качестве эпилога

Возможно, кто-то заметил в моих рекомендациях (ступеньках, блоках, кусочках) элементы японской философии кайзден. Да, я тоже считаю, что нужно фокусироваться на непрерывном процессе совершенствования. Но я также настаиваю, чтобы «кусочек» совершенствования укладывался в минимально возможное время, и результат был работоспособен, то есть приносил пользу. В наше время гиперскоростей компании не могут ждать; результат нужен не просто завтра, он нужен вчера. Соответственно, или вы будете все делать быстро, или вашей компании не будет. Но быстрыми изменениями нужно управлять. Не забывайте про это! Работайте с профессионалами, и — процветания вашему бизнесу.