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