Home

Автор: Вячеслав Панкратов

С чего начинать внедрение изменений в работу компаний или подразделений по разработке информационных систем: с выбора инструмента или адаптации методологии?

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

Точка входа в процесс внесения изменений

Вопрос, который я хочу рассмотреть, для многих может показаться чем-то сродни вопросы о курице и яйце, но на самом деле является достаточно интересной. Дело в том, что анализируя проекты по внедрению процессов и вопросы на которые периодически приходится отвечать и свой опыт движений в этом же направлении, я пришёл к одному простому выводу: в подавляющем большинстве случаев внедрение процессов начинают именно с выбора инструмента. Как показывает практика, зачастую такой подход не срабатывает и люди «справедливо» винят инструмент.

Определимся с порядком действий

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

Выбор автомобиля начинается с анализа предполагаемых условий его использования или как минимум с определения класса автомобиля: легковой, грузовой, автобус или промежуточные варианты. Определившись с классом, можно уточнять задачу — какой именно легковой автомобиль нужен: для семьи, представительский, спортивный и т.д. После чего идёт анализ предложений в полученном диапазоне условий и происходит выбор.

Или давайте нарисуем картинку, более приближенную к нашей теме.

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

Что такое, на этом примере, методология и инструменты?

Инструменты — это лифты, двери и лестницы, а фундамент, стены, планы коммуникаций это Методология.

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

После такой «артподготовки», надеюсь, дальнейшее пояснение будет воспринято более правильно.

Нерабочая схема

Как обычно происходит:

1. Выбираем несколько инструментальных решений
2. Сравниванием возможности
3. Выбираем инструмент
4. Пытаемся с его помощью решить наши задачи
5. Анализируем результаты
6. Виним во всём инструмент

В чём проблема такого подхода?

Выбор инструмента происходит зачастую по набору функциональных возможностей и цене. Что самое интересное — аналогичные проблемы наблюдаются не только в IT отрасли с решениями для автоматизации или сопровождения процессов разработки. Аналогичная ситуация встречается практически постоянно при внедрении популярных на сегодня CRM систем (я не буду говорить обо всех решениях автоматизации, потому что зачастую само по себе внедрение комплексного решения отдельная и нетривиальная задача). После внедрения оказывается, что часть модулей купленной и внедрённой системы не используется, а того самого функционала из-за которого всё затевалось в системе как раз и нет.

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

Разберёмся на примерах

Может ли система, которая предлагает настраиваемый процесс трекинга сущностей определить алгоритм самого трекинга? Для сомневающихся: попробуйте на основе багтрекера получить процедуру трекинга дефектов. Начините хотя бы с правил адресации сообщений об ошибках.

Хорошим примером может служить система безопасности, в которой происходит настройка прав пользователей и их прав по отношению к системе. Взяв на вооружение подобную систему, вы вряд ли сможете «обратным ходом» (я специально избегаю слов реверс инжиниринг) создать политику доступа к ресурсам исходя из потребностей конкретного предприятия или подразделения. То есть вместо того, чтобы на основе инструмента узнать правила работы, зачастую придётся эти самые правила в ней, для начала, настроить, адаптировав под процесс.

Часто встречающимся вариантом внедрения процессов «не с той стороны» является попытка внедрить алгоритм работы не от возможностей инструмента, а исходя из Шаблонов документов, которые могут генерировать инструменты или предлагают определённые методологии. С учётом рассмотренных выше случаев, становится очевидно, что если методология не может быть выстроена исходя из возможностей инструмента, то попытка отстроить процесс «от шаблона» (который может генерироваться согласно настраиваемым внутри инструмента правилам!) также похожа на попытку вытянуть себя за волосы из болота. Хотя эксперимент с вытаскиванием за волосы удавался одному сказочному герою, в повседневной жизни эта практика встречается редко.

Резюме

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