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

Руководителю, который задумался о внедрении нового процесса разработки программного обеспечения, в первую очередь нужно задать себе вопрос «зачем». Существуют по крайней мере два повода — и, соответственно, два сценария — для внедрения такого процесса: намерение получить соответствующий статус и повысить «натуральные» показатели процесса разработки.

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

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

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

Что такое внедренный процесс

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

Первые вопросы, которые надо задать себе и потенциальному консультанту, примерно таковы: «Что я получу в результате внедрения? И что такое — внедренный процесс? Все ли смогут его разглядеть и оценить? А главное, будут ли разработчики его использовать?» Если в ответ консультант предложит лишь набор нормативной документации, регламенты, шаблоны и другие документы — гоните его!

Вы наверняка читали описание уровней зрелости в CMM. Сначала, пока устоявшегося процесса нет, все выполняется как в первый раз. Никто не знает заранее, что и как будет делаться дальше, никто не использует опыт прошлых проектов. Потом появляется процесс — это прежде всего знания, навыки и устоявшиеся привычки участников разработки. Проект начинается с разработки ТЗ, а к кодированию приступают только после одобрения архитектором диаграмм классов. Подобные базовые принципы становятся общепринятыми, и только затем, на третьем уровне CMM, речь заходит о документировании процесса.

Документы всегда вторичны. Начинать внедрение процесса с разработки детальных документов вряд ли разумно. Практически в любом случае окажется, что «гладко было на бумаге...», что в реальной жизни что-то нужно делать иначе, а что-то — вообще не нужно. То есть в лучшем случае большая часть выполненной консультантом работы по документированию процесса окажется бесполезной, а в худшем — документацией все и закончится.

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

Вернемся к документации. Разумеется, нельзя вводить совсем не описанный процесс, но на начальных этапах внедрения достаточно минимума документации. Например, автор статьи начинал внедрять процесс оценки трудоемкости проекта по новой методике с небольшой презентации и памятки на полстраницы. Но после обсуждения этой памятки с руководителями проектов и аналитиками в нее было добавлено немало весьма полезных усовершенствований, учитывающих особенности выполняемых проектов. Значительно важнее при внедрении процесса использовать какой-либо инструмент управления (скажем, Microsoft Project); такой инструмент подсказывает каждому участнику проекта, что он должен делать дальше, и не позволяет сбиваться на старый процесс.

Какой процесс внедрять

Да, RUP — универсальный процесс разработки. Да, стандарты серии ISO 9000 описывают идеальный процесс управления качеством. Да, в книжке Бека описан типовой процесс XP (Кент Бек, «Экстремальное программирование». СПб.: Питер, 2002. — Прим. ред.). Но представляете ли вы, сколько времени продлится и чего будет стоить вашей команде внедрение RUP в полном объеме? И готовы ли ваши программисты программировать в парах, если речь идет об XP? Если консультант предлагает, не глядя, внедрить типовой процесс в полном объеме, ищите другого консультанта!

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

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

Еще один случай из практики. В одном из подразделений компании, занятой заказными разработками, вообще не оформлялись ТЗ на новые проекты. Над головой руководителей проектов начали сгущаться тучи, но все оказалось очень просто. Сотрудники этого подразделения выполняли проекты с использованием «скорой» (agile) методологии и оплаты по реальным затратам, поэтому в начале работы точно описать границы проекта никто не мог. Проблем с заказчиком по данному поводу не возникало: если он просил обеспечить дополнительную функциональность, то, значит, был готов оплатить ее разработку. Кстати, сам заказчик возражал против оформления ТЗ: в таком случае ему пришлось бы платить и за разработку ненужного ему документа.

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

Как проводить обследование

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

Кроме того, обследование — это моральная подготовка сотрудников к тяжелому периоду внедрения нового процесса. Если человека просят указать, что именно «вокруг» плохо, он потом легче соглашается с необходимостью это изменить.

Как внедрить процесс

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

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

Внедрять процесс лучше всего в ходе выполнения реального проекта. Если консультант предложит вам предпринять учебный проект, чтобы не рисковать успехом в реальных проектах, вам стоит серьезно задуматься. Действительно ли ваши проекты настолько критичны? Или консультант не слишком уверен в себе? Либо он не понимает, что в рамках учебного проекта взрослые люди не будут напрягаться так же, как при выполнении реального проекта, и что руководство выделит на него не лучших разработчиков, а при необходимости заберет и их?

Почему падает производительность

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

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

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

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

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

Чтобы все же привести какие-то цифры, воспользуемся методологией оценки проекта COCOMO II. В соответствии с ней использование инструментальных средств для автоматизации наиболее трудоемких процедур может дать до 30% роста производительности. Еще примерно столько же обеспечат (в совокупности) использование моделей для проектирования, внедрение управления конфигурациями и управления границами проекта. Скорее всего, это и есть тот джентльменский набор, который будет внедряться.

Долговременный проект или несколько коротких

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

Изменение производительности при внедрении нового процесса

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

Что еще нужно сделать

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

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

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

Во-вторых, прежде чем начинать внедрение, нужно выявить наиболее инициативных сотрудников, чаще всего — «поклонников» внедряемого процесса. Из их числа должны по возможности формироваться группы разработчиков для пилотных проектов. Это особенно важно для менеджеров пилотных проектов, поскольку консультант не подменяет их, а только помогает по-новому планировать проект и оценивать выполнение планов. В конце концов, менеджер проекта отвечает за его своевременное и качественное выполнение.

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

Алексей Закис (AZakis@luxoft.com) — специалист отдела развития инженерных процессов компании Luxoft (Москва).