Caveat emptor, или Пусть покупатель будет осмотрителен

Фредерик Брукс однажды сказал: «Лучший способ повысить производительность труда программистов при разработке систем - это пойти в ближайший компьютерный магазин и купить уже готовым то, что они собираются разработать».

Фредерик Брукс однажды сказал: «Лучший способ повысить производительность труда программистов при разработке систем - это пойти в ближайший компьютерный магазин и купить уже готовым то, что они собираются разработать». Но готовую систему найти не всегда возможно. Приходится ее заказывать. И вот тут…

Слово «аутсорсинг» сегодня стало таким же привычным, как аббревиатуры ERP, CRM, ITIL и т. п. Возникает такое впечатление, будто аутсорсинг - это средство решения всех проблем, касающихся ИТ: дескать, придут на предприятие специалисты с богатым опытом и все сделают как надо. Те, кто об этом говорят, как правило, забывают, что внешним подрядчикам нужно более четко формулировать требования, чем собственным работникам, необходимо заранее выстроить все процессы и выработать строгие критерии оценки качества их работы. Древняя римская мудрость - caveat emptor («пусть покупатель будет осмотрителен») - оказалась подзабыта.

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

Аутсорсинг и разработка

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

С точки зрения разработки приложений есть три основных подхода:

полный аутсорсинг ИТ-службы;
передача внешнему подрядчику части функций;
полный отказ от услуг внешних подрядчиков.

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

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

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

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

Большую помощь в упорядочивании всех ИТ-проектов компании, а не только проектов заказной разработки, сыграл процесс инициации и осуществления проектов (Capital Value Process, CVP), привнесенный из BP. Этот метапроцесс позволил нам четко формализовать и разделить роль бизнеса, ИТ-службы ТНК-ВР и подрядчика в проекте. Внедрение данного процесса позволило нам повысить производительность менеджера проекта: вместо одного-двух одновременно выполняемых проектов он в настоящий момент выполняет три-пять.

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

Недостоверная оценка ожидаемой длительности и ресурсоемкости проекта

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

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

Уже определены рамки проекта по созданию Web-системы для одного из дочерних предприятий, на основании сформулированных требований проведен конкурс и выбран подрядчик. Заключен договор на фиксированную сумму. Подрядчик закончил разработку технического задания и выслал нам. В техническом задании нет указанной в требованиях единой авторизации данной системы с несколькими другими системами. На вопрос о причинах ее отсутствия получаем ответ: «Ну, мы пока не знаем, как это сделать, может, вообще не получится». Мы настаиваем: «А вы требования вообще читали?» Выясняется, что читали, но решили, что в требованиях это было написано на всякий случай, что называется, «до кучи», и заказчик об этом спрашивать не будет. Данный подход характерен для региональных компаний-разработчиков, которые привыкли не слишком формализовывать отношения с заказчиком и при сдаче работ договариваться по факту.

Интеграция новой системы электронного бизнеса с существующей системой, созданной на базе СУБД Microsoft Access и SQL Server. Вместо ожидавшегося одного месяца она заняла три. Причина - недостаточно подробный анализ разработчиком существующей базы: «Не будем терять время на полный анализ - что там может быть сложного, в ?акссесовской? базе-то?! Вот у нас Java, Oracle - это да!»

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

Проект разработки сайта с расширенной функциональностью. Все предложения, кроме одного, были на сумму 15-20 тыс. долл., но один из конкурсантов прислал предложение на 50 тыс. долл.

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

Неумение организовать работу проектной команды

В той или иной степени эта проблема свойственна практически всем разработчикам. Зачастую даже продвинутые разработчики используют RUP, UML, Quality Assurance, Change Management и другие «страшные» термины-методики только на словах. С теорией их применения многие знакомы и даже готовы читать лекции, но на практике предпочитают не использовать из-за их сложности и трудоемкости. Проблема, к величайшему сожалению, имеет множество следствий: невыполнение рабочих сроков, сложности при передаче задач другим исполнителям и др. и пр.

Мы говорим разработчику, что нам нужен результат к 12 часам. Это действительно так, результат планируется продемонстрировать довольно высокому лицу (естественно, после краткой предварительной проверки). К обозначенному сроку ничего нет. Ждем - возможно, медленно работает почта. Вирусы шалят, каналы перегружены - всякое бывает. Проходит час, снова ничего. Звоним, выясняем. Говорят, что работают, вот-вот сделают и через полчаса пришлют. Ждем - нет. Наконец, результат получаем через четыре часа. Если бы нам заранее сообщили, что результата мы не получим ни к полудню, ни к часу, ни к двум часам, то мы смогли бы придумать, как не потерять лицо перед бизнес-заказчиком. А так недовольными остались все: и заказчик, который не увидел то, что хотел увидеть, и мы - понятно, по какой причине, и подрядчик, которому теперь не доверяем.

Разработка нового модуля для встраивания в существующую Web-систему. После установки на нашей площадке версии, заявленной как финальная, найдено 17 ошибок и недоработок. В ответ на письмо со списком приходит ответ: «Да, мы все ошибки нашли и десять уже исправили». Возникает вопрос: зачем представители подрядчика везли непротестированную версию? Мало того, что мы выполнили их работу - провели тестирование, так еще и сделали это совершенно напрасно. Разработчики одного из наших сайтов заявляют: «Мы не мжем показать вам последний вариант, поскольку у нас полетел сервер и мы потеряли все результаты работы за последнюю неделю».

А как же резервное копирование? Оно что, вообще не проводилось? Для ИТ-компании давать такой ответ - верх неприличия.

Разработка очередной Web-системы. Подрядчик говорит: «Согласно принятым в нашей компании политикам ISO 9000 мы не можем начинать работу, если не подписан договор». Мы отвечаем: «Но мы же работаем без договора уже две недели, техническое задание почти готово». Представитель подрядчика парирует: «А мне сегодня сказали, что так нельзя». В этой ситуации удивляют две вещи. Во-первых, то, что специалист компании-подрядчика неожиданно для себя узнал о наличии в компании процесса ISO и его требованиях. Во-вторых, еще не было случая, чтобы ТНК-ВР не выполнила свои обязательства вне зависимости от наличия или отсутствия договора. И на рынке об этом прекрасно известно. Мы считаем, что будущее - за гибкими компаниями, которые имеют достаточный ресурс, чтобы рискнуть и начать проект в интересах заказчика.

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

Проблемы бизнес-анализа

Главная проблема бизнес-анализа (анализа предметной области) состоит в том, что аналитик зачастую не ставит своей целью подготовить понятный конечному пользователю документ. Например, аналитик хочет разработать документ, соответствующий стандарту ГОСТ 34.602-89, потому что он много раз делал данный документ именно по такому ГОСТу. Возникает конфликт интересов: у бизнес-пользователя нет никакого желания (да и возможности) прочитать описание своей, в общем-то, небольшой проблемы, изложенной канцелярским языком двадцатилетней давности на 150 листах. Другая крайность - некий ?ИТ-комбайн? - специалист, совмещающий функции аналитика, менеджера, а в последствии также программиста и тестировщика. Как правило, ни одной из этих специальностей он в совершенстве не владеет, поэтому и выдает сложные для понимания косноязычные документы.

Другая проблема (мы о ней уже упоминали) - желание подрядчика минимизировать свои мозговые усилия и свое вовлечение в процесс анализа и формализации бизнес-процесса. «Вы скажите, что надо сделать, и мы сделаем», - говорит подрядчик. «Да мы точно не знаем, что нужно сделать, вот тут у нас работает так-то и так-то, а вот здесь - так и эдак. Даже и не знаем, как это заставить работать вместе», - пытается объяснить клиент. «Ну вы подумайте и скажите, как сделать, и мы сделаем!» - не унимается подрядчик.

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

Стандартизация взаимодействия между подрядчиком и заказчиком

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

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

Неготовность идти на компромиссы

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

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

Нам кажется, что хорошо выстроенные отношения между заказчиком и подрядчиком стоят намного дороже, чем один-два выпадающих списка.

Плохая отчетность и частое несоответствие отчета делам

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

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

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

Увы, не всегда удается объяснить подрядчику (или он не хочет этого понимать?), что наша совместная задача - сделать проект успешным. И в этом смысле мы с подрядчиком находимся по одну сторону баррикады. Скрывая свои проблемы, подрядчик не дает нам возможности помочь ему справиться с ситуацией. Возможно, по привычке подрядчик считает нас, так скажем, «неспециалистами» и не понимает, что ИТ-служба ТНК-ВР - это группа высокопрофессиональных людей, компетентных не только в области управления проектами. Мы владеем знаниями и опытом в очень многих областях, способны помочь и словом, и делом. В крайнем случае, мы можем найти способы смягчить последствия, но только при условии, что будем знать о проблемах сразу, как только они возникнут.

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

Соотношение цены и качества

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

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

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

С нашей точки зрения, ключевым фактором здесь является неумение и, самое главное, нежелание совершенствовать внутренние процессы - а именно этого требуют и ISO 9000, и CММ. И если для сертификации по ISO данный факт можно скрыть, то для CMM это сделать значительно сложнее. Этим и обусловлена его значительно меньшая распространенность по сравнению с ISO. У нас есть примеры подрядчиков, которые пытаются сертифицироваться на один из высоких уровней CMM, при этом уровень планирования ресурсов в проектах данной компании очень и очень невысок, не говоря уже об уровне зрелости внутренних процессов и документации. Мы с интересом ожидаем результата…

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

Проблема отсутствия информации

Совершенно отдельно стоит весьма серьезная проблема, не связанная напрямую с разработчиками. Речь идет об отсутствии следующей в достаточной мере объективной и общедоступной информации:

О компаниях.

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

О выполненных на рынке проектах.

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

О проблемных системах и проектах.

Согласно некоторым исследованиям западных компаний, до 60% ИТ-проектов не достигают успеха. Если попытаться, используя открытые источники, найти такую информацию для России, то окажется, что у нас неуспешных проектов нет вообще. Что вызывает серьезные сомнения… Разумеется, мы понимаем, что пожелание о том, чтобы информация о проваленных проектах все же появлялась в открытых источниках, можно отнести к области ненаучной фантастики.

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

Теймур Штернлиб - директор по ИТ консорциума «Альфа-Групп»

Павел Алферов - начальник отдела Web-систем компании ТНК-ВР и заместитель руководителя экспертного центра по CVP и управлению проектами