Я считаю, что с заказными разработками связываться не стоит. Лучший способ разработать систему — пойти и купить ее. Но с другой стороны, без заказных разработок, как бы ни старались ИТ-директора, не обойтись. Однако надо понимать, что любая разработка несет гораздо больший риск, чем любое внедрение.

Выбор подрядчика

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

Первый очевидный критерий — наличие у компании-разработчика методологии разработки систем, желательно подтвержденной сертификатом CMM как минимум третьего уровня (defined level, который характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован), а ещё лучше — четвёртого (managed level: в организации устанавливаются количественные показатели качества как на программные продукты, так и на процесс в целом). И тут мы сразу сталкиваемся с тем, что методологии сейчас имеют все компании, — другое дело, что далеко не все их выполняют. Даже наличие сертификата CMM совершенно не гарантирует выполнения требований стандарта разработки. И примеров тому масса. Скажем, такая ситуация: нужно было к довольно большой уже существующей системе доработать модуль. Модуль делали два месяца, наконец прислали — полдня мы его ставим и приходим в шок: в нем 17 ошибок. Заносим их в список, отсылаем обратно… и получаем издевательский ответ: «Ах да, спасибо, наши специалисты уже нашли эти ошибки, сейчас всё поправим и пришлем новую версию». О каком соблюдении стандартов разработки тут может идти речь? Тем более, что мы платим деньги не только за кодирование, но и за тестирование программного продукта.

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

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

Проблемы при утверждении проекта

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

Другой пример: в одном большом и довольно сложном проекте, где необходимо было интегрировать создаваемую систему на базе Java и СУБД Oracle с существующей учетной системой на Microsoft SQL и при этом учесть все особенности имеющейся структуры, мы впустую потратили три месяца и заполучили огромное количество проблем — и всё это только потому, что исполнитель недостаточно внимательно отнесся к работавшей у заказчика системе.

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

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

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

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

Проблемы в ходе проекта

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

Родовая проблема подавляющего большинства разработчиков ПО — постоянное несоблюдение текущих сроков. Например, мы говорим разработчику, что нам нужен результат к 10 часам утра. К обозначенному времени ничего нет. Хорошо, возможно, медленно работает почта, ждем. Проходит час — снова ничего. Звоним, выясняем. Говорят, что работают, вот-вот сделают и через полчаса пришлют. Ждем опять, нет как не было. Наконец получаем результат к концу дня. Очевидно, это проблема внутренней организации работы подрядчика. Ну зачем строить из себя суперразработчика, если у тебя возникла проблема? Скажите прямо, что вам потребуется какое-то время на ее решение. Тогда я по крайней мере не буду чувствовать себя идиотом перед бизнес-заказчиком, которого тоже кормлю этими «получасами». И чтобы вы не думали, что это плохой подрядчик, открою секрет: такое случается и в компаниях, сертифицированных по CMM.

Но раза три-четыре я сталкивался с откровенными «отмазками». Когда поджимают сроки, подрядчик вроде бы начинает работать активнее, обещает прислать версию в течение какого-то определенного времени. Не прислав вовремя, ссылается на то, что у него «упал» сервер. Это просто великолепно для ИТ-фирмы — не уметь делать резервное копирование! Компания, которая дорожит своей репутацией, даже произносить такое не должна. Но ведь произносят…

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

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

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

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

Какие документы должны быть в ИТ-проекте по заказной разработке ПО? По сути — такие же, как и в обычном ИТ-проекте. Любой проект создания заказного ПО разбит на пять этапов. Первый этап — оценка, определяющая, нужно ли вообще делать проект. Второй этап — выбор технологии и подрядчика. Здесь мы разрабатываем запрос на проект (внутренний документ компании). На его основании составляются технические требования, которые выносятся на тендерную комиссию. В ходе тендера мы выбираем подрядчика, и после того как он выбран, готовится довольно большой устав проекта (10—15 страниц), где описывается проектная команда, области её ответственности, основные риски и план.

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

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

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

В критической ситуации

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

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