Инструменты, изменяющие процесс
Опыт, зафиксированный в инструментальных решениях
Прочный фундамент для процессных изменений
Введение
Работая в проектах по внедрению новых инструментов в промышленной разработке программного обеспечения, консультанты по методологиям и специалисты по инструментальным решениям часто опасаются возникновения эффекта «затяжного прыжка». Он характерен для проектов, которые растягиваются на годы и зачастую потенциально опасны для компании именно тем, что в процессе сложных изменений «не видно земли»: ожидаемые результаты внедрения размыты, задачи компании или подразделения постоянно меняются, а объем работ по внедрению методологий и инструментов кажется неподъемным.
С другой распространенной проблемой сталкиваются менеджеры консалтинговых проектов на первых этапах внедрения. Руководство готово тратить время на серьезные изменения и развитие ИТ-подразделений, но люди «на передовой» — менеджеры проектов, ведущие специалисты по разработке и тестированию ПО — как правило, не вполне осознают необходимость крупномасштабных исследований и внедрений. Стоит отметить, что они не всегда ошибаются. Будучи глубоко погруженными в производственные задачи и проблемы разработки и сопровождения ПО, специалисты ИТ-департаментов понимают необходимость внедрения инструментальных решений, но при этом нередко настаивают на сохранении существующих процедур и методов ведения работ, у которых есть одно неоспоримое преимущество: они уже работают.
Проблемы «затяжного прыжка»
Для большинства ИТ-компаний длительные сроки «классических» консалтинговых проектов являются сдерживающим фактором в процессе внесения качественных процессных изменений. ИТ-подразделение и так вынуждено постоянно реагировать на появление новых технологий, на меняющиеся условия ведения бизнеса, изменения в законодательной базе и возрастающие требования к качеству разрабатываемых и внедряемых информационных систем.
Проблемными с точки зрения ИТ-консалтинга являются также компании и подразделения, которые имеют негативный опыт работы с консалтинговыми фирмами. Повторный «поход за улучшениями» трудно не только инициировать, но также организовать и завершить, особенно в ситуации, когда по окончании предыдущего неудачного проекта не проводился подробный «разбор полетов» и не были выявлены причины неудач. Так или иначе, но все изменения касаются непосредственно людей на местах, которые, имея за плечами негативный опыт участия в масштабных проектах, уже не верят в результат. Однако без поддержки этих людей, равно как и без проявления политической воли руководства, ни один консалтинговый проект не может закончиться успешно.
Единственно верным путем, который позволит изменить ситуацию, является итеративность проекта и получение осязаемых результатов в максимально сжатые сроки. Практический результат сегодня — вот какая цель ставится для большинства современных консалтинговых проектов. Таким осязаемым практическим результатом в случае автоматизации процесса разработки информационной системы являются внедренные и работающие программные средства автоматизации.
Скептики наверняка выразят сомнение в том, что что-то можно сделать более быстро, дешево и в то же время качественно. И они отчасти правы: внедрение всякого инструментария, тем более обеспечивающего процесс создания ПО, требует предварительной проработки.
Однако процессная оптимизация затрагивает не только компании, в которых работают консультанты, но и сам консалтинговый бизнес: если есть задача, ее всегда можно попытаться решить. Многие наши заказчики считают, что консалтинговым компаниям следует не только знать инструменты и владеть процессными областями, но и ориентироваться в специфике различных отраслей: банковской, нефтяной и т.д. Однако в реальности такого сочетания компетенций очень трудно достичь.
А если попытаться вынести процесс предварительной подготовки инструментальных решений за рамки проекта по внедрению системы автоматизации разработки информационных систем? Приняв во внимание эту достаточно очевидную мысль и учитывая накопленный опыт, мы попытались обобщить и структурировать имеющиеся конфигурации и базовые настройки инструментария IBM Rational и пришли к следующему выводу: в большинстве случаев разработчики и руководители проектов осознанно или неосознанно используют существующие методологии и лучшие практики в своих проектах и подразделениях.
Таким образом, на основании общих подходов компаний к разработке в большинстве случаев можно предложить один или несколько типовых вариантов настроек систем и схем интеграции, которые сработают и позволят в достаточно сжатые сроки (порядка нескольких недель) получить вполне функциональную систему, с которой можно работать и постепенно доводить ее до ума за счет тонкой настройки процессов.
Опыт, зафиксированный в инструментальных решениях
Цель внесения изменений практически одна и та же во всех проектах — это обеспечение соответствия процессов и процедур определенному уровню качества согласно стандарту CMMI или адаптированным легким методологиям. Неизменной остается и суть внедрения — улучшение текущего состояния дел в проектах или достижение более высокого уровня зрелости процессов разработки в компании.
Консалтинговые проекты в части разработки ПО часто ведутся по одному и тому же алгоритму, при этом повторяется и сама процедура внесения изменений в процесс, что дает возможность на том или ином этапе проекта довольно точно спрогнозировать потребности в конкретных инструментальных решениях, их конфигурациях и правилах интеграции. Изучая успешные и неуспешные проекты, компания, выполняющая анализ и внесение изменений в процесс вместе с инструментальной поддержкой, может применять накопленные данные для действий на опережение — то есть устанавливать у клиентов предварительно апробированные конфигурации ПО для автоматизации процессов разработки.
Это позволяет с минимальными доработками и в сжатые сроки получить работающую инфраструктуру, пригодную для использования и миграции с существующих систем сопровождения процессов разработки и наследующую их процессную логику.
Правила быстрого внедрения
Использование практик быстрого внедрения и адаптации инструментов автоматизации разработки ПО к существующим у заказчика процессам и методологиям не только позволяет сократить сроки внедрения обновленных процессов и средств автоматизации, но и способствует более полному вовлечению специалистов заказчика в решение задачи внесения изменений в процессы — специалисты легче осваивают инструменты разработки, если им надо только понять, что и где расположено в новой системе, не вникая в новый порядок вещей в ходе разработки.
Выделим следующие правила быстрого внедрения инструментов автоматизации разработки ПО:
- классический консалтинговый проект зачастую подразумевает первоначальный и достаточно долгосрочный аудит, который для широкого круга клиентов из числа софтверных компаний может стать серьезным аргументом «против» в процессе принятия решения о внедрении инструментария;
- внедрение инструментов автоматизации процессов разработки ПО в классической модели проектов по внесению организационных изменений происходит на заключительном этапе;
- недостаточная очевидность практических результатов на первых этапах проекта по внедрению снижает мотивацию участников проекта со стороны заказчика;
- имея достаточный опыт, консалтинговая компания может на ранних этапах внедрения предложить заранее определенные конфигурации и планы по интеграции решений, которые, с одной стороны, дадут возможность провести быстрое внедрение, а с другой — позволят вносить изменения на уровне процессов уже на базе предварительно внедренных инструментальных решений;
- упор на тренинги. В быстрых проектах тренинги приобретают особое свойство. Если в длинных проектах можно позволить себе проводить большие и пространно-теоретические тренинги, то в быстрых возможны только сжатые по времени и исключительно практические тренинги. Все это обязательно подкрепляется практикой использования полученных знаний сразу же после лекций. Хорошо себя показала схема «утром лекция — днем работа». Причем на самом тренинге все рассматриваемые сценарии берутся из проектов данной организации, а не из учебных примеров.
Стоит отметить, что современный потребитель консалтинговых услуг все чаще задает правильные вопросы об опыте консалтинговой компании — о количестве, сложности и разнообразии успешных проектов и внедренных конфигураций. Это свидетельство того, что заказчик интуитивно нащупывает для себя пути реализации проекта по внедрению программного обеспечения с целью автоматизации процессов разработки.
Риски быстрого внедрения
Практика показала, что даже при краткосрочном проекте могут возникнуть проблемы. Особую роль при быстром внедрении играют человеческий фактор и напряженная работа двух сторон (заказчика и подрядчика). В долгосрочных проектах человеческий фактор тоже очень важен, но не является критичным, поскольку может быть скорректирован за счет длительности проекта. Приведем простой пример одного из проектов быстрого внедрения.
Исходные данные:
- крупная компания. Проект быстрого внедрения;
- плановая длительность проекта — месяц.
Основной упор при быстром внедрении:
- развертывание средств;
- тренинги специалистов на практических примерах;
- специальные тренинги для администраторов.
Проблемы, возникшие в процессе выполнения проекта:
- к обучению все подошли серьезно. Специалистов мотивировали на максимальную отдачу на лекциях. Правда, из всех способов мотивирования был выбран не самый удачный, а именно: сотрудникам обещали отпуск после успешного обучения. Соответственно после плотного обучения вместо активной работы наступил трехнедельный перерыв;
- указанный риск можно было бы спрогнозировать и снизить, предварительно проведя переговоры с руководством заказчика;
- в данном проекте возник и непрогнозируемый риск (форс-мажорное обстоятельство): администратор после месячного тренинга был призван на армейские сборы.
В итоге быстрое внедрение растянулось во времени.
Еще один показательный пример — успешное внедрение, результаты которого не используются.
Исходные данные:
- крупная компания. Проект быстрого внедрения;
- плановая длительность проекта — два месяца.
Основной упор при быстром внедрении:
- развертывание средств на реальном проекте;
- тренинги специалистов на практических примерах;
- оценка результатов на основании метрик.
Проблемы, возникшие в процессе выполнения проекта:
- развертывание средств и запуск автоматизированных процессов прошли успешно. Обучение участников проекта позволило всем активно включиться в работу. Но систему, которая применялась в пилотном проекте, решили снять с эксплуатации вскоре после завершения развертывания. В результате оценить результаты внедрения на основании метрик стало практически невозможно, а принимать решение по дальнейшему внедрению технологии пришлось при отсутствии важных данных по ее использованию в пилотном проекте.
В итоге быстрое внедрение фактически пришлось выполнять повторно, хотя и с меньшими затратами.
Быстрое внедрение требует особого отношения как в реализации, так и в планировании. Необходимо фундаментальное планирование проекта с учетом всех возможных рисков (как видимых, так и непредсказуемых).
Один из успешных примеров применения быстрого внедрения несколько лет назад в России дает богатую пищу для размышлений.
Исходные данные:
- крупная компания — разработчик ПО. Одновременно несколько проектов быстрого внедрения;
- плановая длительность проекта — полтора месяца. Обусловлена невозможностью существенного отвлечения ресурсов от ключевой деятельности.
Основной упор при быстром внедрении:
- развертывание средств на реальном проекте. Независимое внедрение процессов управления конфигурациями, управления изменениями, управления требованиями и функционального тестирования;
- тренинги специалистов на рабочих местах и на основе реальных примеров;
- ответственность отдельной команды за независимое быстрое внедрение одного из процессов.
Проблемы, возникшие в ходе выполнения проекта:
- развертывание средств не вызвало затруднений. Обучение участников проекта позволило всем активно включиться в работу. Заинтересованность участников в результате напрямую влияла на успешность выполнения каждого мини-проекта, все проекты поддерживались и жестко контролировались руководством. Единственной неудачно решенной задачей было внедрение управления требованиями, что объясняется незаинтересованностью ответственного за это внедрение сотрудника компании (в скором времени сменившего место работы). Всю работу в данном направлении вынуждены были выполнять консультанты, поэтому после их ухода никто не смог продолжить процесс. Через несколько месяцев управление требованиями пришлось внедрять повторно;
- остальные команды были заинтересованы в успехе и обучении. Возникающие технические проблемы быстро решались совместными усилиями. В каждом мини-проекте отсутствовал риск перекладывания ответственности на другое подразделение и риски по взаимодействию с другими подразделениями при внедрении нового процесса. Также отсутствовали риски по интеграции процессов и инструментов между собой.
После успешного завершения мини-проектов в течение нескольких месяцев процессы были дополнительно адаптированы, распространены на другие проекты и подразделения и интегрированы между собой по мере необходимости.
Еще один очень интересный и необычный проект — быстрое внедрение офшорного процесса тестирования.
Исходные данные:
- американская компания — разработчик ПО. Необходимо внедрить процесс функционального тестирования;
- плановая длительность проекта — месяц. Разделение обязанностей в процессе после его внедрения: компания-заказчик предоставляет ПО и планы тестирования, а специалисты компании-консультанта осуществляют тестирование и предоставляют его результаты.
Основной упор при быстром внедрении:
- четкое разделение работ в процессе тестирования. Определение форматов обмена данными и сроков реализации. Четкое планирование;
- минимизация тренингов, так как внедрение большей частью выполнялось из России с минимальным количеством командировок.
Разница во времени требовала высокой четкости при взаимодействии и точного определения процесса и регламентов. Компания-заказчик начала быстро получать эффект за счет использования на большинстве работ процесса внешних специалистов, имеющих необходимые навыки. Первоначальная стоимость проекта была снижена, поскольку не было необходимости закупать все средства автоматизации на начальном этапе.
После подтверждения эффективности тестирования на основе быстро внедренного процесса с использованием внешних специалистов американская компания постепенно подключила к процессу тестирования собственных специалистов и получила большую независимость от внешних тестировщиков и возможность развития процесса тестирования.
Залогом успеха в проектах быстрого внедрения являются опыт консультанта, предоставляющего готовые решения на основе накопленного мирового и своего собственного опыта, и готовность заказчика следовать советам консультанта, доверять его опыту и квалификации. В случаях, когда заказчик оговаривает для себя особое положение, с самого начала выдвигает требования к глубокой переработке предлагаемых процессов на основе своих пожеланий, зачастую не подтвержденных практикой, — о быстром внедрении можно забыть. Процесс внедрения, с большой вероятностью, погрязнет в бесконечных согласованиях деталей, без которых можно обойтись, и вряд ли закончится успешно. Кстати, большое количество согласований обычно указывает на неверие в успех проекта (или незаинтересованность в успехе) и желание заранее подстелить себе соломку вместо того, чтобы принимать решения и брать на себя ответственность за их реализацию.
Прочный фундамент для процессных изменений
Предлагаемый подход позволяет достичь сжатых сроков внедрения за счет применения библиотек наиболее распространенных конфигураций инструментария автоматизации процессов разработки, а также за счет поэтапной адаптации существующих процессов к модели, которая является целью внедрения.
При таком подходе первым шагом на пути внедрения средств поддержки процесса разработки программного обеспечения является создание инфраструктуры, дублирующей существующую логику и процессы разработки. Для разработки программного обеспечения такая процедура не кажется чем-то из ряда вон выходящим — разработчики в ходе проекта часто мигрируют на новые версии инструментальных систем и переносят код и документацию в новые системы хранения, не изменяя при этом порядка кода или построения версии.
Специалисты легче осваивают инструменты, если от них требуется только понимание того, что и где расположено в новой системе, без необходимости вникать в новый порядок вещей в процессе разработки. Овладев новым инструментом, персонал компании-заказчика зачастую сам идет навстречу консультантам, предлагая возможные варианты использования функциональности инструментария.
Пройдя этот первоначальный этап внедрения, специалисты более активно включаются в проект по внесению процессных изменений, работая уже в принципиально новой среде, которая позволяет производить требуемые изменения конфигурации, влияющие на уровень процесса.
Идеальных инструментов для организации разработки программного обеспечения не существует (см. таблицу). Большинство производителей подобных коммерческих инструментов не имеют набора, обеспечивающего полный охват всех процессов, а некоммерческие инструменты не лишены недостатков, также не позволяющих называть их идеальными. Поэтому при выборе инструментов реализации часто приходится идти на компромисс, соглашаясь на незначительные неудобства для получения основных преимуществ, ради которых и затевался весь проект.
Говоря о решениях, охватывающих все процессы разработки, отметим следующее. В качестве особенностей инструментария IBM Rational можно отметить излишний академизм средств. Они отпугивают многих именно своей фундаментальностью, которая идеальна для крупных компаний, но часто является излишней для малых. Бесплатные системы хороши всем, за исключением того, что они состоят из разрозненных инструментов, которые нужно интегрировать между собой для получения целостного результата. А это, как правило, уже программирование, и, как следствие, дополнительные затраты.
Заключение
Кратко резюмируя основные идеи данного подхода, хотелось бы отметить как положительные, так и отрицательные его стороны.
Преимущества:
- классический консалтинговый проект зачастую подразумевает первоначальный и достаточно долгосрочный аудит, который может оказаться для широкого круга клиентов из числа софтверных компаний серьезным аргументом «против» в процессе принятия решения о внедрении инструментария;
- внедрение инструментов автоматизации процессов разработки ПО в классической модели проектов по внесению организационных изменений является заключительным этапом;
- недостаточная видимость практических результатов на первых этапах проекта по внедрению служит демотивирующим фактором для участников проекта по внедрению со стороны компании-клиента;
- имея достаточный опыт внедрения, консалтинговая компания может на ранних этапах внедрения предложить заранее определенные конфигурации и планы по интеграции решений, которые, с одной стороны, дают возможность провести достаточно быстрое внедрение, а с другой — позволяют вносить изменения на уровне процесса уже на базе работающих решений.
Недостатки:
- при всей кажущейся простоте подхода необходимо внимательно относиться к планированию и управлению рисками проекта, так как любое промедление в мелочах отрицательно сказывается на длительности проекта. При этом быстрый проект стремится превратиться в классический — длительный;
- использование практик быстрого внедрения и адаптации инструментов автоматизации процессов разработки ПО к существующим внутри компании-клиента процессам и методологиям позволяет не только сократить проект по внедрению специализированного ПО, но и приводит к более глубокому вовлечению специалистов заказчика в процесс внесения изменений на стадии разработки.
 |
|
