О чем нужно знать, отдавая

проект на аутсорсинг
…или свой продукт чужими руками

Тема доклада




Почему я задался этим вопросом?
Успехи и провалы
Кто заказывал?
Мы говорим только о мобильных продуктах
Вроде все очевидные вещи

In House VS Outsourcing
Никто не знает кроме нас
Украдут идею
Domain Expertise
Дешевле
Лучше как-то сами
Не уверены в результате

In House VS Outsourcing
Нет опыта / нет команды
Сэкономить
Быстрее / Time to Market
Не технический заказчик
Не хватает ресурсов

Чем отличается от фриланса
• Имеете дело с компанией
• Более защищены т.к. есть контракт
• Требует более формального оформления
взаимоотношений
• Часто дороже за час работы
• Процессы и прозрачность?
• Результат вероятнее

Кто обычно заказывает
• Есть продукт под другую платформу: игры,
веб-сервисы, desktop продукты
• Стартапы
• Independent software vendor
• Инвесторы
• Люди не из IT мира

Где искать





Рекомендации знакомых
Google Search
Рейтинги
Конференции
Сами постучались
Продукт – вендор - разработчик

Бизнес Модели: Фиксированная
стоимость
• Требования к продукту четко определены
• Подрядчик определяет стоимость проекта,
которая не изменяется в рамках
требований
• Фиксированные сроки
• Состав команды не имеет значения
• Риски заложены в стоимость

Бизнес Модели: Time & Materials
• Требования к продукту четко не
определены и могут изменяться в процессе
• Hourly Rate Table
• Вы оплачиваете каждый час, затраченный
командой
• Единственно возможная бизнес модель для
работы по Agile методологии
• Дает гибкость

Определите для себя модель
• Есть ли видение всего продукта? Нет –
нужен бизнес аналитик
• Есть ли у вас Техническое Задание?
• Достаточно ли оно полно описывает
продукт?
• Какие услуги вам нужны? Все под ключ,
только разработка?

Выбор подрядчика: На что смотреть





Рекомендация
Портфолио
Коммерческое предложение
Клиенты и их отзывы
Отношение к вам
Оценка вашего проекта в денежном
выражении и сроках
• Язык общения

Request for Proposal Document
• Больше информация для принятия верного
бизнес решения
• Проведение благоприятной сделки
• Возможность рассмотреть более широкий и
творческий диапазон решений.
• Более структурированный подход

RFP Document : Плюсы



Ускоряет процесс обработки ответа
Формализует требования к продукту
Формализует требования к поставщику
Описывает ограничения и условия: бюджет,
гарантия, сроки, дедлайны, etc.
• Позволяет охватить более широкий диапазон
предложений
• Демонстрация беспристрастности
выбора

RFP Document : Минусы
• Работает только в случае, если требования
четко определены
• Требует времени и ресурсов на подготовку
• Выборку компаний делают вручную
• Имеет смысл в случае публичного тендера
• Не всегда хорошая реакция подрядчиков

Первый контакт



E-mail проще, но попробуйте позвонить
Звонок позволит сэкономить время
Обратите внимание на время реакции на мейл
Если у вас нет RFP документа и шаблона
письма, не пишите много. Завяжите общение.
• Определите наличие всех сервисов, которые
вам необходимы (дизайн, тестирование,
разработка, BA, etc.)

Коммерческое предложение





Стоимость
Понятное ценообразование
Сроки
Этапы работ, WBS, Gantt Chart
Методология разработки. Почему такая?
Тестирование, документы, платформы,
версии
• Гарантийные обязательства

Стоимость: вопросы





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

Контракт
• Если нет своего контракта – возьмите за
основу контракт подрядчика и добавьте
туда ваши пожелания
• Контракт – это последний инструмент,
которым вы сможете воспользоваться в
суде. Но он должен защищать ваши
интересы.
• NDA

Исходный код
• Постарайтесь договориться и использовать
вашу систему контроля версий кода.
• Регулярные code review. Это может быть
причиной для принятия пункта выше
• Документированный код – ваше
требование. Вероятно продукт нужно будет
поддерживать дальше вам.

Рабочий процесс




Отдал и забыл – не работает.
Будьте участливы, будьте в процессе
Требуйте Roadmap и план поставок
Требуйте регулярные Demo
У вас должен быть хотя бы один инструмент
– индикатор прогресса проекта: Burndown
Chart, Отчеты, Weekly Estimates, etc.

Отчетность
• Перед началом работ получите информацию
какие отчеты и документы предоставляет
компания подрядчик (на этапе UX/UI дизайна,
разработки и тестирования).
• Спросите как вы будете понимать, что все идет
по плану и нет задержек по срокам.
• Если речь идет о T&M модели, то спросите как
вы будете понимать соответствие
затраченным часам (и деньгам) задачам.

Тестирование продукта




Получите доступ к системе баг-трекинга
Потребуйте тест-план
Тест-кейсы
Версии ОС
Перечень устройств для тестирования

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

Публикация продукта в магазины
• Позаботьтесь о наличии аккаунтов в AppStore и
Google Play до завершения разработки продукта.
Иногда их регистрация занимает немало времени.
• Если сами никогда этого не делали, попросите
разработчика помочь за загрузкой продукта.
• Разработчик должен давать гарантию на то, что
продукт пройдет Approval процесс. Кроме случаев,
когда это происходит из-за предоставляемого
контента.
• Производите оплату финальной части за продукт
только после публикации продукта в магазины.

Гарантийный период
• Позаботьтесь о том, чтобы гарантийный период
стартовал с момента публикации продукта в магазины.
А не с момента приемки.
• В контракте должен быть прописан срок исправления
ошибок в гарантийный период. Срок может различаться
в зависимости от критичности ошибки.
• Учтите, что после апдейта продукта в AppStore Apple
также проводит процедуру верификации. Поэтому
иногда не имеет смысла делать апдейты с 1-м фиксом.
• В контракте имеет смысл прописать условия поддержки
продукта после гарантийного периода

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

Советы
• Перед тем, как искать подрядчика
подготовьте требования к продукту и
подрядчику, определите модель
• Не рассматривайте подрядчика, как объект
по другу сторону баррикад. У вас общая
цель – сделать качественный продукт.

Советы
• Первое письмо/звонок скажет многое об
отношении к вам потенциального партнера.
• Если вам подрядчик говорит, что большая
часть работ под NDA, то часто так оно и есть.
• Не становитесь таким клиентом, который
запрещает говорить о продукте подрядчику
без весомых причин на это.
• Обязательно попросите предоставить 2-3
контактных лица, у которых можно спросить
мнение о вашей компании.

Советы
• Бывает полезно посмотреть примеры кода.
• Не будьте занудой, но стоит максимально
возможно проговорить «на берегу», чтобы на
время проекта оставить как можно меньше
открытых вопросов.
• Не всегда стоит гнаться за низкой стоимостью.
• Оценки на T&M и Fixed Price одного проекта
будут различаться.

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

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

Советы
• Поддержка iPhone не означает нормальной
поддержки iPad. Когда приложение для
Android должно адекватно функционировать
как на телефонах, так и на планшетах.
• Гарантия с момента публикации в магазинах, и
финальная оплата тоже.
• Контракт – важная часть процесса. Но не
зацикливайтесь на нем.

Советы
• Повышает шансы на успех личное знакомство с
командой при старте проекта. Конечно, там, где это
оправдано экономически.
• Держите код проекта и ресурсы «при себе».
• Никогда не выпадайте из процесса, пока
разрабатывается ваш продукт. В противном случае
результат в конце вас сильно удивит.
• Если product owner и вы – это один человек, то
будьте готовы к тому, что это потребует много
вашего времени. По крайней мере, пока
требования к продукту для команды не 100% ясны.

Советы
• У вас ВСЕГДА должен быть инструмент, который
дает вам возможность понять текущий прогресс
проекта.
• НИКОГДА не стесняйтесь просить подрядчика о
большей прозрачности чего бы то ни было.
• Если вы будете следить за процессом тестирования,
то это позволит сэкономить ресурсы на приемке.
• Подготовьтесь к публикации продукта. Аккаунты
регистрируются не за один день.

Артем Петров
GM Mobile & Consumer products
artem.petrov@provectus-it.com
maphan1