Автор материала: Александр Крючков, Head of Presale в CoreValue

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

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

Александр Крючков, Head of Presale в CoreValue

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

О каком сервисе идет речь?

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

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

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

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

Поэтому важно смотреть не на цену и оценку проекта а на то, как вендор будет подходить к реализации проекта.

Об этом подробнее ниже.

На что смотреть при выборе вендора?

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

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

Так что кроме оценки смотреть важно и на другие критерии. 

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

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

Предположения, из которых исходил вендор при оценке. Любой качественный вендор включит в своё предложение раздел под названием Assumptions. Поскольку ни одна проектная спецификация не может быть абсолютно полной, у вендора всегда остаются белые пятна в понимании требований к разрабатываемому продукту. Чтобы сделать оценку проекта он должен заполнить эти белые пятна предположениями (assumptions) о том, как нужно понимать ту или иную неуточненную деталь. Если такого раздела нет, он слишком короткий либо явно не соответствует вашим представлениям о проекте - это может свидетельствовать о низком качестве выполненной оценки.

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

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

Оговорены ли границы качества. Уже наверное все знают, что кода без дефектов не существует. Тем не менее, клиент, ранее не имевший опыта аутсорсинга, вполне может ожидать, что поставленный ему продукт будет “просто работать”. В реальной жизни всё несколько сложнее. Дефекты будут, и на разных стадиях работы над проектом допустимо разное количество дефектов разной степени. Во время разработки их будет довольно много - это просто неотъемлемая часть процесса. К началу UAT (User Acceptance Testing, приемочное тестирование) их должно быть уже значительно меньше, а к его окончанию и публичному запуску продукта - еще меньше. “Правильный” вендор в своём предложении обязательно оговорит и согласует с клиентом допустимые рамки качества продукта - количество и степень дефектов на разных стадиях. Еще более важный момент - оговорить то, как и в какие сроки дефекты, обнаруженные на продакшене либо в ходе UAT будут устраняться, кто платит за эту работу и т.д.

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

Степень участия клиента в процессе разработки. Этот пункт имеет прямое отношение к зонам ответственности, описанным выше. Вендор должен явным образом указать какое участие будет требоваться от клиента и в каком объеме. Например, если предполагается участие клиента в UAT, то его сроки имеет смысл оговорить заранее. То же касается и работ по подготовке требований или участия во встречах с командой для их разъяснения. Для клиента не должно быть сюрпризом, например, что на начальной стадии проекта он будет нужен на митингах 3 дня в неделю.

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

Риски. В самом грубом приближении список рисков отвечает на вопрос: “Что может пойти не так в ходе проекта”. Здесь могут быть и технические факторы - например, разрабатываемый продукт зависит от сторонних сервисов, на которые вендор не может повлиять; и организационные - к примеру, возникновение какой-то новой регуляции, которая будет “мешать” функционированию продукта. 

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

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

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

1. Скоуп (что входит и не входит в рамки проекта)
2. Предлагаемая архитектура
3. Предположения (assumptions)
4. Риски
5. Предлагаемый процесс разработки и степень вовлечения в него клиента
6. Оценка трудоемкости (в идеале в разрезе бэклога проекта)
7. Предлагаемая команда проекта (роли и количество людей в них)

Только внимательно анализируя коммерческое предложение в комплексе, клиент может понять почему один вендор “дороже”, а второй “дешевле”.

О чем нужно помнить при работе с ИТ-аутсорсерами?

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

1. разработка ПО похожа на ремонт квартиры - в том смысле, что вовлечение клиента будет необходимо на каждом этапе проекта. С хорошими вендорами клиент потратит меньше времени и сил, и даже при более высоком часовом рейте в итоге заплатит меньше. С дешевым вендором будет платить за переделки и устранение последствий недопонимания. 
2. бюджет проекта скорее всего вырастет - тому есть масса причин, но основная состоит в том, что ни клиенту ни вендору не могут быть известны все детали продукта до начала его разработки. Много уточняется походу, особенно после первых демо - клиент начинает думать о вещах, которые раньше (пока проект был “на бумаге”) даже не приходили в голову.
3. абсолютно точных оценок не бывает - по указанным выше причинам. Но хороший вендор (и часто более “дорогой”) построит процесс разработки так, чтобы как можно быстрее уведомлять клиента об изменениях в оценке и чтобы он мог в любой (или почти любой) момент остановить разработку или поменять приоритеты.
4. контракты с фиксированной ценой - большая редкость - в большинстве случаев (особенно на больших проектах) неизвестных моментов в начале проекта так много, что вендор не будет брать на себя ответственность за выполнение работ по фиксированной цене. И дело здесь не в низкой квалификации, а как раз наоборот - в понимании и принятии того, что нельзя обещать то, что тебе не до конца понятно, ведь таким образом ты формируешь у клиента ложные ожидания. Гораздо лучше разбить проект на более управляемые фазы и выполнять его итеративно, что в целом уже стало стандартом в мире разработки ПО.