Originally published at Авторский сайт Новичкова Александра Николаевича. Please leave any comments there.
Человеческий фактор во внедрении процессов и инструментов или где лучше приживаются инструменты?
Автор Новичков Александр Николаевич
Где лучше приживаются инструменты? Странный вопрос – конечно там, где есть схожие инструменты и технологии! Может сказать читатель и будет прав лишь отчасти. Если у заказчика есть похожие технологии и инструменты, то зачастую это только мешает, так как психологически, каждый из нас отвергает все новое.
Существует несколько факторов, оказывающих негатив на процесс внедрения, отметим лишь самые важные:
- Длительность работы с инструментом – наиболее очевидный фактор – чем дольше – тем больше привыкли, тем сложнее перейти на новое.
- Возраст специалиста – это наиболее интересный фактор, который сам по себе абсолютно ни о чем не говорит. То есть при внедрении можно делать небольшую корректировку на возраст, но только вместе с первым фактором можно говорить о существенном влиянии на конечный результат.
- Удовлетворенность текущим инструментарием – фактор “а мне и так все подходит” можно назвать блокирующим – он существенно влияет на результат.
Это были объективные критерии, рассмотрение которых было бы неполным без таких мощных субъективных как:
- Нежелание переходить на новую технологию, так как она осуществляет более глубокий контроль над деятельностью исполнителя
- Элементарное саботирование…
При внедрении следует учитывать все факторы и готовить мероприятия по снижению их влияния на финальный результат.
А пример?
Хочется привести пример из реальной жизни на данную тему.
Итак, имеем компанию, которая пережила череду поглощений. Персонал состоит из специалистов разных компаний. Возраст – абсолютно разношерстный, но превалирует середняк.
Никаких процессов у организации нет. Правда, руководство пребывало в уверенности их присутствия. В какой-то момент времени всем внутри стало понятно, что без процессов и инструментов автоматизации нельзя – компания на себе ощутила все проблемы хаотичного подхода:
- Не те сборки отдаются не тем заказчикам;
- Документирование ошибок ведется вручную;
- Журнал ошибок в word;
- метрики не собираются;
- Планирования нет (вернее есть планы, которых никто не придерживается);
- Задачи на разработчика вешаются устно;
- И так далее…
Все усугубляется тем, что сегмент рынка показывает бурный рост – сама компания сверхуспешна, что позволяет бизнесу смотреть сквозь пальцы на чрезмерные издержки отдела ИТ.
Наверное просто необходимо отметить разобщенность отделов ИТ и полную несплоченность команды. А всем известно, что сплоченность команды имеет очень важное значение успешности проекта.
Хаос в чистом виде!
Часть команды решает, что так жить нельзя и решает навести порядок.
Первое и последнее, что сделано – создана самописная система управления изменениями. Сама система являет собой классику кустарной системы – только учет и только запросов одного типа. Управлять из нее реально можно только задачами, причем не маленькими задачками с одним ответственным, а глобальными задачинами, разбитыми по этапам, за каждым этапом закреплен один ответственный и куча соисполнителей, то есть масса владельцев на одну задачу.
Любой перенос сроков любого этапа приводил к ручному переделыванию всеми ответственными сроков собственных этапов.
Отдельно об этапах. Этапы выстраиваются в некий водопад, где предусматривается возврат не только на предыдущий, но и на любой вышестоящий – как сочтет правильным руководитель этапа. Ясно, что он не всегда прозорливо угадывает, куда именно вернуть (особенно, когда не определены четкие критерии возврата). Ненужно говорить, что после подобной “итерации” ничего не подозревавший владелец другого этапа крайне удивлен тому, что согласованная задачи через три головы вернулась назад.
Такой подход можно считать правильным только в том случае, когда компания работает на динамично меняющемся рынке – только тогда работы могут быть пересмотрены и возвращены в самое начало – на анализ. В любом другом случае понятно, что в организации нет анализа и управления требованиями.
Вернемся к системе управления изменениями – при все порочности система прижилась, так как лучше хоть какой учет вместо никакого… Система жила и росла полтора года.
Настал час внедрения IBM Rational. Заказчик мягко намекнул, что процессы ему выстраивать не надо. Нужно только автоматизировать существующие. Апелляция к логике, осведомленным источникам и высшим силам не возымела действия! Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать. Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”. Пришлось взять расписку об ответственности за неуспех и приступить.
Автоматизация УК и УИ (управление конфигурациями и управление изменениями) пошла в жизнь. Внедрение ClearCase прошло без сбоев. Проблем не возникло – так как ничего похожего у заказчика не было, то решение прижилось. Чистое версионное хранилище может вызвать отторжение только неправильной настройкой. В данном случае все было «ок».
ClearQuest же не внедрился… Это, возможно, первый прецедент в нашей практике когда не внедрилась система УИ даже в беспорядочном процессе.
Устроим разбор полетов: итак, заказчик привязан к существующей системе и не готов не только менять процессы, но не готов видеть иные экранные формы в системе автоматизации. Получилось так, чтобы выполнить проект необходимо на ClearQuest повторить функционал системы заказчика. То есть выполнить весь некорректный процесс но в другой системе – одна мегасущность и куча соисполнителей.
Естественно, что функциональные возможности ClearQuest позволяет сделать все. Мы повторили функционал, как нас и просили. Только в итоге системой пользоваться никто не стал. Получалось, что все огрехи стали еще более очевидны. Заказчик, в свою очередь, принял решение о том, что данная технология ему не нужна.
Скрытые (подводные) камни:
Давайте вспомним, что система самописная и развивающаяся… Отдел, разрабатывавший ее сделал максимум возможного, чтобы ее сохранить. Новое здесь никому не нужно… Пусть даже это новое лучше – здесь свои меркантильные интересы.
Отсутствие явно заинтересованного лица. Казалось бы, руководитель кровно заинтересован в результатах выстраивания прозрачной структуры… Но не в этот раз. Здесь руководитель сидел и ждал чуда, ничего для его получения не делая.
Итог:
Система развернута и сдана. Заказчиком мило похоронена…
Потрачена куча времени и ресурсов практически впустую.
Грустно? – да!
Неудачное внедрение? – еще как неудачное!
Консультантов на мыло?! – возможно, да, но рамки проекта не позволяли нам действовать.
Чем сердце успокоилось…
Самое интересное! История имела продолжение!
Как известно, история идет по спирали, и на более высоком витке мы обычно сталкиваемся с теми же проблемами, но на более высоком уровне. Так и случилось – заказчик взял еще несколько проектов, нанял дополнительных людей и сложилось так, что персонал сам устал от свой системы, которая при выросших объемах была неспособна эффективно работать (процесса нет а идеология у системы – порочная). очевидно случилась та революция о которой так долго говорили большевики. Да! Еще сменилось руководство. Новый руководитель как раз желал видеть не учет, а эффективность и прозрачность процесса.
Заказчик снова позвал нас и попросил сделать все так, как мы считаем правильным. И случилось чудо – работа пошла.
Здесь теперь живет порядок.
Анализ разбора полетов
Далее мы попытаемся проанализировать проблемы и дадим рекомендации по их устранению, но с учетом того, что у вас есть возможности по продвижению решений:
Незаинтересованное руководство – отсутствие политической воли практически всегда – провал проекта. Руководство нужно убеждать и доказывать. Если не получается – проблему надо эскалировать. Если это не помогает – пытаться пойти снизу и убедить специалистов. Потом общей массой доказать правоту руководству.
Почему ничего не вышло у нас?
Выше нашего руководителя только совет директоров компании – нет возможности эскалировать. Ниже специалисты, которым и так хорошо, а вторая часть разработала схожее решение. Фактор “от добра добра не ищут” сыграл на 100%
Возраст специалистов – в чистом виде у него есть влияние, но не пагубное. То есть человеку можно объяснить и несколько раз показать. Но в совокупности с отсутствием политической воли получаем крах.
У нас был ряд проектов, в которых процессы ставились и автоматизировались персоналом, чей средний возраст далеко за 56 лет… И ничего – порядок
Наличие аналогичной системы – в чистом виде тоже не помеха. Очевидная эффективность ClearQuest перед самоделкой позволит продемонстрировать руководству получение ощутимых результатов. Здесь руководство должно было проявить прозорливость и объяснить своим, что их система помогла в трудное время, но надо идти вперед. Самое главное – продемонстрировать, что разработчики старой не будут сокращены.
В данном случае все этого и боялись…
Внедрение от инструмента – путь в могилу. Нельзя автоматизировать хаос. Любое внедрение должно начинаться с осмысления процессов (с последующим переосмыслением).
В нашем случае заказчик настаивал только на внедрении инструментов.
Зрелость организации – даже если девять беременных женщин собрать вместе – ребенок родится через девять месяцев. Зрелость и сплоченность коллектива идут рядом. Если организация не сплоченная и незрелая то трудно будет внедрить инструмент. Здесь нужна воля руководства + процессы + время на их реализацию. Время дозревания.
В нашем случае заказчик дозрел в течении 4-5 месяцев, после того как мы “плешь проели” на всех уровнях, что так нельзя…
