16.04.2004/118

Алексей Закис

Внедрение RUP

Диалоги с заказчиком в 7 частях с эпилогом

Действующие лица:

• Вопрошающий (В) - руководитель софтверной фирмы. Человек, не желающий отдавать деньги, как он говорит, "за эту макулатуру".
• Отвечающий (О) - некто, пытающийся продать этому человеку внедрение  RUP.

Зачем внедрять RUP?

В. Зачем мне нужно внедрять RUP?

О. Разумеется, чтобы получать большую прибыль от проектов.

В. И как вы это себе представляете? 

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

В. И за счет чего вы предполагаете этого добиться? Мои программисты и так уже 10 часов в день программируют. Если они будут работать больше, то ни о каком качестве уже нельзя будут говорить.

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

В. Как можно убедиться, что внедрение RUP принесло положительный эффект?

О. Достаточно сравнить затраты на разработку продукта и его последующее сопровождение до и после внедрения RUP.

В. И каков же может быть эффект?

О. По оценкам экспертов снижение трудоемкости может достигать 30%. Например, "В прошедшем году фирма "Кворум" завершила начавшееся в 2000 г. внедрение технологии Rational Unified Process (RUP), разработанной фирмой Rational Software. Внедрение технологии RUP позволило уменьшить в среднем на 30% сроки постановки задач на разработку ПО." (http://www.bizcom.ru/news/2002-02/02.html)

Что значит "Внедрить RUP"?

В. Ну и что же это конкретно значит - "Внедрить RUP"?

О. Это значит, что в вашей фирме будут качественные процессы разработки. Каждый исполнитель будет понимать свою роль и свои задачи. Обладать необходимыми навыками для их выполнения. Сократятся до минимума непроизводительные затраты труда на работы, выполняемые не вовремя (и которые все равно придется потом переделывать) или на вовсе ненужные работы.

В. То есть вы принесете мне кучу бумаги, где все эти процессы будут описаны в регламентах? Я и сам могу купить RUP, даже лицензионный. Он всего-то стоит: И распечатать. Программисты у меня по-английски читают без проблем.

О. Описание процессов мы тоже выполним, но только после того, как эти процессы будут  реально внедрены и отлажены. Вам нужны рекомендации вообще? Нет, вам нужны рекомендации, настроенные на ваши проекты и даже для ваших конкретных сотрудников.

В. То есть вы перепишете все сколько-то там тысяч страниц RUP применительно к нашей организации? И кто это прочтет?

О. Вовсе не обязательно переписывать весь RUP. В нем есть много рекомендаций, относящихся к проектам, которые вам в обозримом будущем не придется выполнять, и к инструментам, которым вам не придется пользоваться. Вы хотите платить за перевод этих рекомендаций?

А мы выберем то, что реально нужно вашим сотрудникам, и оформим это как очень короткие и очень конкретные правила, как поступать в реальных ситуациях.

В. Я не уверен, что мои программисты и короткие-то инструкции прочтут. Думаете, я не пробовал?

О. А мы ведь и говорили, что сначала мы наладим реальный процесс, объясним каждому, что он должен делать, а потом уже запишем. Мало ли, вдруг кто-то забудет или если нового сотрудника наймете:

В. И что же это значит - наладить реальный процесс?

О. Это значит, что наши сотрудники будут реально участвовать в ваших проектах и подсказывать, что и как лучше делать.

В. Еще раз и помедленнее, пожалуйста. Что вы хотите сказать? Ваши инструкторы будут принимать участие в наших проектах?

О. Именно так. Наши инструкторы - не теоретики, начитавшиеся книг "про RUP". Это специалисты, являющиеся не только высококлассными профессионалами в таких конкретных дисциплинах, как управление требованиями или управление изменениями, это грамотные менеджеры, умеющие организовывать процесс. Они определяют, какой именно процесс имеет смысл внедрять, и по ходу работ обучают ваших сотрудников. Как известно, чем меньше разрыв между обучением и использованием полученных навыков и знаний - тем более эффективно обучение. К тому же многие люди предпочитают курсам и тренингам обучение "из-за плеча". Им просто надо показать на собственном примере, что и как надо делать.

И самое главное, наши специалисты понимают, какие трудности обычно возникают у людей, осваивающих RUP.

Внедрение изменений - это сложно

В. Вы говорите, трудности?

О. Да, внедрение изменений - это сложно. Практически всегда внедрение изменений приводит в первый момент к снижению производительности вместо обещанного роста. Рост начинается позже. В общем-то, почти все про это знают или догадываются. Поэтому те, кому предстоит менять привычный порядок действий, обычно говорят "Да-да, конечно. Но лучше в следующем квартале, когда будет проект попроще:".

В. То есть внедрение RUP может привести к снижению производительности?

О. И еще к какому! Без поддержки грамотных инструкторов обычно этим дело и заканчивается. Ведь первая реакция человека на изменения обычно состоит в его полном отторжении. "Не хочу ничего менять!". А затем наступает фаза полного замешательства. "Да, придется все делать по-новому, но я же не понимаю, как!". Разумеется, в этих фазах производительность разработчика падает и весьма значительно. И только после этого появляется состояние удовлетворения. "А мы с эти справились. Теперь нам любая задача по зубам!". Обычно, это значит, что разработчики освоили новый процесс, и их производительность не только достигла прежнего уровня, но значительно его превзошла.

В. Сколько же времени нужно, чтобы дойти до этого состояния?

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

В. Цикл? И сколько же таких циклов будет?

О. Как говорят, "It depends:". Во-первых, это зависит от текущего состояния вашей организации. Может быть, у вас уже замечательные процессы, и вам нужны только небольшие изменения:

В. Но ведь эти процессы не соответствуют RUP!

О. А вам, как в старом анекдоте, шашечки нужны или ехать? Если ехать, то есть снижать затраты, повышать производительность и качество, то лучше не ломать то, что и так хорошо работает. Замена хорошо работающих процессов на RUP не принесет большого эффекта, а сил и времени потребует. Наши инструкторы помогут вам соединить ваши процессы с теми, которые лучше взять из RUP.

В. Так. А отчего еще зависит длительность внедрения RUP?

О. Еще от готовности вашей организации к изменениям. Есть организации, где регулярно осваивается какой-то новый опыт, языки программирования, инструментальные средства. Где сотрудники привыкли учиться и осваивать новые технологии. Конечно, там можно внедрять RUP более крупными порциями и завершить весь процесс быстрее. Если же у вас консервативная организация, уже двадцать лет не использующая ничего, кроме Кобола, начинать следует с небольших изменений.

В. Ну и сколько же времени все это может занять?

О. Улучшать, как известно, можно до бесконечности. Вряд ли вы сами захотите внедрять RUP более пары лет. Даже если у вас останутся недостаточно качественные процессы, скорее всего вы предпочтете назвать их усовершенствование как-нибудь по-другому. Кстати, это вполне оправдано с психологической точки зрения. 

План

В. Пожалуй, кое-какой смысл в ваших предложениях есть. Так что расскажите подробнее, как будет происходить внедрение.

О. Пожалуйста. Основные шаги представлены на этой диаграмме:

Как вы видите, здесь есть предварительные шаги, которые выполняются до того, как мы приступим непосредственно к внедрению RUP, есть само внедрение и есть шаги, выполняемые после внедрения.

В. Так. Ознакомить с RUP. Это понятно. Лапша к обеду. А что значит "Оценить текущую ситуацию"?

О. Перед началом работ мы, во-первых, постараемся познакомить всех с предстоящими переменами. Что такое RUP, зачем нужно его внедрять, как будет проходить его внедрение и т.п. Чтобы люди знали, чего им следует ждать. А после этого мы займемся обследованием вашей организации. Нам ведь надо выяснить, какие процессы у вас используются в настоящее время, насколько они эффективны и т.д.

В. А зачем обследование? Я скажу заместителю, он вам за пару часов все расскажет. И людей от работы отвлекать не потребуется.

О. Конечно, ваш заместитель знает состояние дел в организации. Но это его субъективный взгляд, а нам нужна объективная картина. Для этого нужно опросить 20-30% процентов ваших сотрудников. Ознакомиться с имеющейся документацией, регламентирующей процессы. И даже просто посмотреть и послушать со стороны, как эти процессы выполняются: Кстати, по результатам этого обследования мы подготовим для вас отчет. Я думаю, вам будет небезынтересно узнать, что думают ваши сотрудники о вашей организации и вашем процессе разработки. Но предупреждаю заранее, никаких фамилий! Иначе люди не будут нам доверять. 

В. Ладно. Это действительно любопытно. Что там дальше?

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

Кстати, заодно будут определены опережающие индикаторы, по которым и вы и мы сможем контролировать успешность внедрения.

В. А что это такое?

О. Ну, например, мы с вами можем решить, что за счет внедрения качественного управления требованиями мы хотим снизить стоимость строки кода на 25%. Как это контролировать, пока проект еще не завершен? Очень просто. Мы определяем конкретные действия, которые должны привести к этому результату. Например, согласование всех требований к проекту с заказчиком и другими заинтересованными лицами. И вводим идентификатор: число требований, которые пришлось существенно уточнить из-за того, что первоначальная формулировка была ошибочной или недостаточно точной. Если этот показатель снижается, значит, требования выявляются точнее и, в итоге, стоимость строки кода действительно снизится.

Кстати, вы можете заключить первый договор именно на этот объем работ. А далее решать, хотите ли вы что-то внедрять, исходя из нашего экономического обоснования. Именно здесь мы с вами будет решать, в частности, какие инструментальные средства Rational и в каком количестве вам понадобятся. И не просто так, а с цифрами в руках.

В. Ну уж и с цифрами! Разве таким цифрам можно верить?

О. Есть разные методики, хорошо зарекомендовавшие себя во множестве проектов. Например, мы часто пользуемся COCOMO II. Этот подход позволяет достаточно точно оценить последствия изменения процесса разработки. Кстати, опережающие индикаторы - это из Системы сбалансированных показателей для ИТ индустрии Balanced IT ScoreCard. А еще мы используем CMM, SPICE, отечественные ГОСТы:

В. И что там еще осталось до начала внедрения?

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

В. Ну хорошо, предположим, я поверил вашим цифрам. И мы выбрали проекты.

О. Вот тут-то и начинается самое интересное. Во-первых, мы вместе с вами составляем план внедрения RUP. Точнее, очередной итерации процесса внедрения. А дальше уже и не поймешь, что сначала, а что потом. Короче, с помощью наших инструкторов вы определяетесь с тем, что именно из RUP будет внедряться в конкретных проектах. Учитесь это делать в соответствие с RUP. Документируете выработанный процесс. И, как во всяком проекте, боретесь с плохими неожиданностями и стараетесь в полной мере использовать приятные.

Внедрение включает и все формы обучения, которые будут выбраны: курсы "с отрывом от производства", лекции и тренинги на рабочем месте, индивидуальные консультации:

Сюда же входит доработка стандартного сайта RUP, его настройка для сотрудников, выполняющих определенные роли или разработка дополнительных плагинов.

А в документацию входят и методические рекомендации по выполнению отдельных операций, и шаблоны документов, соответствующие отечественным ГОСТам или образцам RUP. Смотря с какими заказчиками вы работаете.

Ну а самое главное, на наш взгляд, это не все эти бумаги или сайт, это хорошо налаженный процесс, и это сотрудники с необходимой квалификацией. В том числе, и с навыками использования инструментов Rational не на модельных примерах, а в реальных "боевых" условиях.

И по ходу всего этого наши инструкторы не забывают следить за, так сказать, самочувствием разработчиков. Всем ли понятно, что от них ждут? Все ли в достаточной мере освоили нужные навыки? Не нужно ли просто немного помочь кому-то в выполнении очередных задач, чтобы выкроить еще немного времени на дополнительные занятия? Кстати, примерно половину своего времени инструкторы тратят просто на работу в проекте, обучая остальных своим примером. И разрабатывая эталонные модели, документы и т.д.

Итерации

В. И на этом внедрение завершается?

О. Во-первых, после этого проводится оценка достигнутого состояния. А, во-вторых, принимается решение о продолжении или завершении работ. Нужно ли продолжать внедрение RUP? Какие цели следует поставить на следующую итерацию? Какие именно процессы из состава RUP следует внедрять в очередной итерации?

В. А почему нельзя все внедрить сразу?

О. Иногда бывает и так. Но это обычно происходит в тех ситуациях, когда существующий процесс безнадежно плох. Когда что ни делай, все равно хуже не будет. В остальных случаях, как мы уже говорили, внедрение слишком больших изменений за одну итерацию может просто привести к полному параличу, когда инструкторы не будут успевать объяснять каждому что и как он должен делать. В результате производительность снизится сильно и надолго. Появится риск просто провалить проекты, выбранные в качестве пилотных для внедрения RUP. А, в лучшем случае, существенно снизится экономическая эффективность внедрения.

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

В. А что это еще после внедрения?

О. А это то, чему мы вас тоже научим по ходу внедрения, и что позволит вам самим поддерживать процесс на должном уровне. Это совершенствование существующего процесса. Коротко говоря, после завершения каждого проекта в организации стоит проводить обсуждение его итогов. Что было хорошо и какой опыт следует распространить, какие проблемы возникали и как с ними лучше бороться. А потом внедрять соответствующие усовершенствования процесса.

А сколько это стоит?

В. Ну замечательно! Сколько же стоит это удовольствие?

О. Ну давайте считать.

А это уже комментарий от автора

Проведение обследования и подготовка для организации с 20 разработчиками ЭО - 2 человека х 3 недели. Для организации со 100 сотрудниками - 4 человека х 4 недели.

Далее один-два инструктора на проект. По хорошему, лучше пару. Но можно на неполный рабочий день.

Плюс отдельно за курсы.

Плюс инструментарий

И еще надо учесть снижение производительности в пилотном проекте:

И это все должно компенсироваться будущими 30% прироста производительности:

Кто сосчитает, сколько должен стоить разработчик, чтобы это оправдывалось за год?

А кто это сделает?

В. А можно познакомиться с вашими инструкторами? Пришлите нам для начала из резюме. Мы посмотрим их опыт до того, как они стали инструкторами. И success story после того, как они стали инструкторами.

О. :-(

Эпилог

Не знаю, удалось ли мне, но хотел сказать я примерно следующее.

Внедрение RUP не начинается, а заканчивается оформлением НМО или сайта с описанием процесса для конкретной организации.

Работа начинается с серьезного обследования компании с анкетированием, интервьюированием и т.д. Выясняются особенности проектов, команды и используемого процесса. Выявляются "дыры" в процессе, которые наиболее легко "заштопать", и эффект от штопки которых будет наиболее высок. Работа требует определенного опыта если не в руководстве проектами, то хотя бы в организации отдельных процессов в реальных командах и в разных проектах.

Далее следует оформление рекомендаций и, самое главное, разработка экономического обоснования для последующего внедрения RUP. Здесь действительно нужно владеть различными методиками оценки процесса разработки и оценки длительности выполнения проекта в зависимости от используемого процесса. И плюс к тому, хорошим опытом оценки длительности проектов. Чтобы знать, к какой цифре подгонять методики.

Теперь собственно внедрение.

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

• Объяснить теоретически, как ЭТО нужно делать
• Показать практически, как ЭТО делается
• Сделать ЭТО целиком на таком уровне, чтобы артефакт можно было использовать в качестве образца
• И более того, в свободное от консультаций время именно ЭТО и делают.

Увы, ЭТО - это практически все, чем занимаются разработчики. Это и план управления тем-то и тем-то, и сценарии использования, и список нефункциональных требований, и диаграммы классов, и даже тщательно написанный и хорошо оформленный код программы. Ну, и тестовый скрипт, и что еще я забыл перечислить... Короче любой из сотни RUPовских артефактов.

При этом внедрение RUP - достаточно дорогое удовольствие именно в плане оплаты специалистов. Человек, проводящий 2-3 дня в неделю у заказчика, вряд ли потянет еще один проект параллельно. Ему в  два оставшихся от посещения заказчика дня разобраться бы с вопросами, которые нужно решить к следующему визиту... А с другой стороны, это же высококвалифицированный менеджер проекта, и зарплату он требует по своей квалификации.

Для справки. В импортной книжке про внедрение RUP приводятся такие (видимо, типичные) цифры:

• Внутренняя стоимость одного специалиста, участвующего в проекте - 100$ в час.
• Оплата инструктора (наставника) - 2000$ в день (день, то есть 250$  в час).
• Наставник используется 2 дня в неделю в течение 5 месяцев. ( По моему мнению, для 10 участников проекта одного инструктора, может быть, и достаточно (см. ниже описание типичного проекта). Но 5 месяцев при 6-месячной разработке проекта - явный оптимизм.)
• Средняя стоимость проекта исходя из трудоемкости 10 человек на 6 месяцев порядка 1 млн $.
• Падение производительности в первом проекте - 20%.
• Прирост производительности (относительно исходного уровня) во втором проекте - 30%.

При таком соотношении стоимости наставника и разработчика использование наставника окупается уже во втором проекте (который выполняется без наставника). При этом о затратах на покупку инструментария говорится как о мелочи, которую и учитывать-то не стоит, чтобы с этими копейками не возиться.

Хороший наставник может при удачном раскладе обеспечить прирост уже во второй половине первого проекта, который компенсирует провал в первой половине.

Алексей Закис