Proof of concept что это такое
Proof of concept что это такое
Перед началом реализации идеи, многие люди по-разному называют предполагаемый результат. Наиболее часто встречающиеся термины в этом случае: MVP ( minimum viable product ), POC ( proof-of-concept ), Prototype.
Давайте попробуем разобраться, в каких случаях наиболее уместно использовать каждое из вышеперечисленных определений, чтобы избежать недопонимания
MVP
Minimum viable product — версия продукта, которая имеет минимальный набор функций исключительно для реализации бизнес-цели, сохраняя при этом жизнеспособность. Другими словами, она не содержит кучи интересных “фич” и красивого интерфейса. Такое решение имеет смысл использовать при работе со стартапами для того, чтобы вывести продукт на рынок и выяснить, будет ли он вообще пользоваться спросом. Таким образом, если спрос появился, то смысл дальнейшей работы есть и можно пробовать получить деньги с первых инвесторов на развитие продукта в будущем. Естественно, в свете того, что MVP отправляется прямиком на рынок, это должна быть стабильно работающая без ошибок версия ПО.
POC
Так называемое подтверждение концепта ( proof of concept ). В отличие от MVP, это маленький проект, созданный для проверки критически важных гипотез перед началом полноценной разработки. Например, POC создается для того, чтобы проверить, можно ли вообще реализовать какую-либо функцию или, если нет уверенности, что идея сработает. Подтверждение концепции охватывает не всю систему, а лишь небольшую её часть, которую пользователи могут и вообще не увидеть, потому что чаще всего POC используются внутри компании для уточнения пути развития продукта. Грубо говоря, POC — это небольшое исследование, которое дает зеленый (или красный) свет для дальнейшей работы, будь то начало нового проекта или развитие существующего. Бывают и случаи, когда POC используется вместо MVP для получения финансирования.
Prototype
И последнее, но не менее важное определение в нашем обзоре — прототип (Prototype). Основная цель создания прототипа — помочь принять решение о разработке продукта и уменьшить количество ошибок в нем. Прототип — это рабочая модель нескольких аспектов продукта (в отличие от POC, где чаще реализовывается одна функция). Чаще всего прототипирование используется для демонстрации какой-либо части системы, обнаружения ошибок в ней, опроса пользователей. С помощью прототипа, команда проверяет дизайн продукта, удобство использования, а зачастую и функциональность, чего никак не сделаешь, используя POC. Если говорить проще, прототип больше похож на драфт — т.е. своего рода черновой набросок, который еще требует много доработок, но при этом показывается конечным пользователям для того, чтобы услышать их мнение в целом о полученном результате. Важно отметить, что прототипы часто используются для реализации каких-то свежих идей и впоследствии вполне могут перерасти в MVP.
Подводя итоги к вышесказанному, предлагаю для наглядности сравнить описанные термины в небольшой таблице:
| POC | Prototype | MVP | |
| Цель создания | Проверка осуществимости идеи или одной функции | Проверка реализации и юзабилити нескольких функций | Создать жизнеспособный продукт, приложив минимум усилий |
| Функции | Может быть одна функция | Несколько функций, которые не вошли в MVP | Основные функции для того, чтобы оставаться жизнеспособным |
| Аудитория | Внутри команды | Потенциальные инвесторы | Группы клиентов |
| Дальнейшее использование | Реализация функции может быть использована в дальнейшей разработке | Дизайн может быть использован в последующей разработке | Первая версия продукта |
| Ценность | Задел на будущее | Потенциал для возможных инвесторов | Готовый продукт |
| Когда разрабатывается | Когда неизвестно, можно ли реализовать идею или отдельную функцию | Когда экономическое обоснование не доказано, риски неизвестны | Когда есть финансирование и риски минимальны |
| Необходимые ресурсы | Необходима техническая экспертиза для реализации идеи | Технические ресурсы почти не требуются, разработки может не быть | Нужна техническая экспертиза и ресурсы для создания продукта |
В итоге хочется отметить, что хотя MVP, POC и Prototype имеют много общего, но все же у них разные цели. А также то, что в ходе работы POC может перерасти в прототип или MVP или наоборот. В итоге только вам решать, каким именно путем идти.
В своей работе со стартапами мы чаще всего имели дело с MVP, которому могли предшествовать POC и/или Prototype.
Почему никогда не стоит использовать Proof of Concept в продакшене
Никогда не встречал разработчика, не любящего создавать всевозможные proof of concept (POC). Возможность построить что-то новое с нуля, чтобы протестировать теорию/процесс/технологию… Сама мысль об этом вдохновляет меня.
Есть в них что-то, что стимулирует наше творческое мышление. Вероятно, это отсутствие всяческих ограничений. Может, быть, это просто восторг от разработки «с чистого листа». Как бы то ни было, разработчикам это нравится.
Частично привлекательность создания proof of concept заключается в широте способов их применения. Можно создать POC для чего угодно! Хотите ли вы создать что-то забавное, научить кого-то незнакомой концепции, придумать идею для бизнеса или научиться использовать новую технологию для решения проблемы — варианты просто бесчисленны.
Но стоит быть аккуратными со своими ожиданиями. Я постоянно вижу, как разработчиков просят просто брать в продакшен их POC. Не делайте этого!
Proof of concept — это именно концепция. Это не «рабочая лошадка» для продакшена, соответствующая всем рекомендациям, общепринятым шаблонам и процессам разработки. Это инструмент для демонстрации идеи за короткий промежуток времени.
Сегодня мы поговорим о четырёх причинах, по которым POC ни за что не должно попадать в продакшен.
Продакшен изменяет способ разработки
Один из удобных аспектов создания POC заключается в том, что вы не скованы привычными ограничениями разработки. Вы можете писать на любом языке, использовать «быстрые и грязные» решения, а также хардкодить.
Не важно, как вы реализуете результат, если в результате сможете доказать свою правоту.
Если бы вы предполагали, что POC будет использоваться в продакшене, то подходили бы к кодингу немного иначе. Вы бы выбирали другие архитектурные решения, намеренно использовали другие шаблоны и придирчивее обрабатывали бы ошибки. Иными словами, вы бы двигались медленнее.
БОльшую часть времени нужно тратить на реальный продукт, а не на POC, которое продаёт вашу идею владельцу продукта.
Proof of concept должно передать вашу идею за как можно более короткий промежуток времени.
ПО пишется не одним человеком. Оно производится командой разнообразно мыслящих людей, что стимулирует творчество и продвигает инновации. POC чаще всего создаются одним человеком. Когда вы хотите реализовать настоящий продукт, то вам нужна команда, способная выложиться по максимуму и повысить его потенциал.
Оно не предназначено для этого
Ваше POC создавалось, чтобы проиллюстрировать суть. Это идея. Она не создавалась с расчётом на нагрузки продакшена.
Перед ремонтом дома вы набрасываете свои идеи на листе бумаги, чтобы показать их друзьям, семье и рабочим. Все понимают, чего вы хотите, но этот черновик с каракулями явно не стоит отдавать строителям.
Нет, вы попросите составить чертёж в CAD, всё просчитать, найти несущие нагрузку конструкции и формализовать проект, прежде чем к нему приступать.
Ваше proof of concept — это набросок на листе. Он выполнил свою цель и продемонстрировал чёткое направление, но в продакшене вы использовать его точно не будете. Его нужно проработать, правильно спроектировать, разбить на истории и задокументировать.
Если команда разработки использует методологии agile, то этот процесс будет выглядеть примерно так:
Proof of Concept хрупки
Вы отлично справились. Вы создали POC, единственное назначение которого — демонстрация работающего примера новой концепции. Его создание почти не заняло времени, и вашему руководству оно понравилось. Отлично!
Как и можно было ожидать, владелец продукта просит вас просто вывести его в продакшен, потому что, по его мнению, у вас уже есть работающий продукт.
Но вы-то знаете правду.
В нём нет обработки ошибок. Вы создали ПО, которое будет работать в идеальных условиях. Как только вы отклонитесь от реализованного в коде процесса, он сломается.
На обзоре спринта вы не отклоняетесь от сценария демонстрации, и на то есть причины. Если вы нажмёте кнопку X вместо кнопки Y, всё развалится. Но это нормально! Вы создали именно то, что и должны были создать. Proof of concept продемонстрировало именно то, что и должно было показать.
Хотя подобные ситуации в продакшене считаются багами, в proof of concept они багами не являются. Помните, это просто черновик, а не готовый чертёж.
Стоит ожидать, что вы столкнётесь с нехваткой фич, забавными багами, ошибками путей выполнения, дырами в безопасности и отсутствием наблюдаемостью системы. Всё, чего не хватает, появится позже, в реальной сборке. Но пока считайте, что в вашем POC больше дыр, чем в швейцарском сыре.
Во второй раз всегда получается лучше
Век живи — век учись. Практикуйся. В следующий раз повезёт.
Что общего у всех этих фраз?
Они подразумевают, что чем больше вы чем-то занимаетесь, тем лучше будут результаты.
Вы же не думаете, что спортсмены не тренируются перед соревнованиями? Конечно же, они тренируются, ожидая, что чем больше практикуешься, тем лучше проявишь себя.
Тот же принцип применим и к созданию ПО. Когда ты в первый раз что-то пишешь (например, POC), то находишься в фазе исследования. Изучаешь все аспекты, пытаясь собрать что-нибудь.
Во второй раз ты движешься быстрее, потому что узнал часть нюансов. Ты пишешь более производительный код, который проще поддерживать. Ты пишешь лучше.
Воспринимайте POC как поучительный урок. Проиллюстрируйте идею и научитесь кодировать концепцию. Найдите все подводные камни. Будьте готовы, что потом найдёте новые. Приготовьтесь к созданию более качественного ПО.
Заключение
Proof of concept всегда стоит потраченного на него времени. Даже если результат докажет, что вам не стоит использовать проверяемую концепцию, по крайней мере, вы не потратили на выяснение этого много времени.
POC дают нам шанс поэкспериментировать с чем-то новым и взвесить свои решения перед тем, как приступать к реализации. Но они не являются реализацией. Хотя иногда может возникать искушение встроить этот код в приложение в продакшене, не стоит этого делать.
Используйте proof of concept как отправную точку. Пользуйтесь его уроками как руководством, чтобы создать нечто лучшее. Ужесточите требования к тому, что вы сделали. А потом начинайте новую итерацию.
Не распыляйтесь при создании сборок POC. Создавайте их как можно быстрее. Тратьте максимально возможное время на работу над реальным ПО, обладающим безопасностью, устойчивостью к сбоям и надлежащей обработкой ошибок.
На правах рекламы
Серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и хранилища на основе NVMe дисков от Intel для размещения проектов любой сложности, создавайте собственную конфигурацию сервера в пару кликов!
Как бизнесу проверять новую идею при помощи Proof of Concept
Инновационному проекту на старте сопутствует неопределенность. Прежде чем как вкладываться в новую технологию, идею или метод, хочется получить доказательство, что они действительно будут работать – и при этом не потратить все имеющиеся ресурсы. Это справедливо для любой сферы. Например, дорогостоящие клинические исследования лекарственных препаратов стартуют не раньше, чем будут получены результаты ранних, менее строгих проверок, когда лекарство принимается однократно или в течение короткого срока. Хотя полученные результаты не заменяют масштабного исследования, принимать решение на их основе надежнее, чем руководствуясь только предположениями.
IT-проекты – не исключение. Любая новаторская идея сопряжена с рисками, и потому требует проверки не в процессе разработки, а еще на этапе предевелопмента и привлечения инвестиций.
В предыдущих статьях мы уже рассказывали, как Discovery-фаза помогает подсветить “узкие места” будущего продукта, которые нуждаются в проверке. Таким местом может стать самая сложная или инновационная функция IT-продукта. Если на этапе планирования возникают такие вопросы: реализуемо ли решение, которое мы предлагаем? каких затрат потребует разработка? какие есть ограничения и можно ли их обойти? – то худшее, что можно сделать, это положиться на интуицию и отложить проверку на потом. Ведь когда в проект уже вложено много усилий, времени и денег, внести изменения в концепцию гораздо сложнее, чем на этапе предевелопмента.
Разбираемся, как снизить риски на старте инновационного IT-проекта при помощи Proof of Concept.
1. Что такое Proof of concept?
Проверка концепции (англ. Proof of concept, PoC) – это демонстрация практической осуществимости какого-либо метода, идеи, технологии, с целью доказательства факта, что метод, идея или технология работает.
Существуют разные подходы к определению Proof of Concept. Часто в него включают и разработку прототипов, и создание MVP – работающего продукта с минимальной функциональностью. Однако мы в Umbrella IT разграничиваем эти методы проверки идеи, так как они преследуют разные цели и на выходе дают разный результат. Также ошибочно принимать PoC за некий “черновик” проекта, который в дальнейшем необходимо лишь немного доработать. Сам формат Proof of Concept гораздо ближе к исследованию, чем к разработке работающего продукта. Тестируется лишь небольшая часть системы – критически важные функции, а полученный результат может не использоваться в дальнейшей разработке. Так как цель PoC – в сжатые сроки убедиться в том, что концепция работает, могут быть опущены второстепенные аспекты, важные для продакшн версии продукта. В таких случаях, получив зеленый свет на этапе PoC, команда может начать писать проект с нуля.
2. PoC vs MVP vs прототип
Чтобы наглядно продемонстрировать, для каких целей подходит тот или иной метод проверки новых идей, мы составили сравнительную таблицу:
Подробнее о бизнес-задачах, которые решаются при помощи MVP, читайте в статье “4 причины, почему вашему проекту нужен MVP”.
Proof of Concept подразумевает под собой одну ключевую функцию, которая не обязательно будет доведена до совершенства. В отличие от PoC, прототип лишь визуально воспроизводит будущее приложение, которое содержит в себе вышеуказанную функцию. Например, если на этапе PoC нам нужно проверить техническую возможность вычисления производных первого порядка, то при создании прототипа мы продемонстрируем, где будут располагаться поле ввода, куда пользователь может ввести функцию, а также кнопка “Вычислить“.
3. Когда проекту нужен Proof of Concept?
Из-за разнообразия опций проверки идей бывает сложно понять, на какой из них стоит выделить ресурсы сейчас, чтобы сэкономить месяцы разработки в перспективе. Предлагаем разобраться, когда проект по разработке ПО нуждается в Proof of Concept.
Проверка концепции – необязательный этап проекта, и в большинстве случаев он не требуется. Если вы хотите создать приложение с механикой Uber – неопределенность на проекте будет минимальна: идея проверена, каждый этап разработки детально описан, доступно много готовых решений. А, например, использование VR/AR-технологий, алгоритмов машинного обучения (ML-алгоритмов) или анализа больших данных кратно увеличивает неопределенность на проекте. Так, по данным Microsoft около трети проектов IoT не проходят этап Proof of Concept.
Новые возможности сопряжены с определенными рисками, среди которых угроза безопасности, высокая сложность проектов, дефицит квалифицированных кадров. Значит перед запуском проекта необходимо убедиться не только в работоспособности решения, но и в соразмерности затрат и рисков бизнес-результату.
Даже когда технологический стек привычен, Proof of Concept помогает сравнить результативность нескольких решений и выбрать оптимальное.
Наша команда разработала тестовый стенд для проверки нескольких картографических сервисов. Это позволило наглядно сравнить маршруты, которые построили Google Maps, HERE.maps и Яндекс.Карт с учетом соответствующих ограничений для грузового транспорта. Результаты ранжировали по количеству нарушений ПДД в построенном маршруте. Подготовив заключение о стоимости каждого решения, мы рекомендовали сервис, который лучше всего решает поставленную задачу.
PoC помогает проверить идею на наличие “узких мест”. К примеру, в последние годы маркетологи возлагали большие надежды на технологии персонализации рекламы. Однако ажиотаж и поспешное внедрение инноваций привели к сложностям со сбором, интеграцией и защитой данных. В конце 2019 года Gartner заключил: потребительское доверие снизилось, персонализированные предложения стали менее эффективными, что привело к снижению ROI. Кроме того, неаккуратное обращение с персональными данными привлекло внимание регулирующих органов. Всего этого можно было бы избежать, если бы проблемы были выявлены на этапе проверки гипотезы. На данный момент прогнозы неутешительны: к 2025 году 80% маркетологов откажутся от персонализации. Тем, кто все еще планирует инвестировать в эти технологии, аналитики Gartner рекомендуют принимать решение только после демонстрации Proof of Concept.
Опыт Umbrella IT показывает, что использование подхода Proof of Concept дает бизнесу ряд преимуществ. Нежизнеспособные и нецелесообразные идеи отсеиваются на раннем этапе, а сэкономленные время и ресурсы задействуются для реализации проверенных идей. Процент успешных и эффективных проектов увеличивается, появляются прорывные продукты, позволяющие обогнать конкурентов.
Когда проверка концепции инновационных идей становится обычной практикой в компании, скорость развития бизнеса возрастает в 2-3 раза.
Хотите запустить новый продукт и снизить риски? Напишите нам, и мы подберем решение, которое подойдет именно вам
Proof of Concept: Как проверить, что внедрение ML стоит свеч
Недавно в уютном чатике дата сатанистов подняли вопрос, как правильно «продавать» внутренние проекты по машинному обучению. Оказалось, что многие из нас весьма брезгливо относятся к экономическому обоснованию своей деятельности. Меж тем, чтобы провести минимальную оценку рентабельности проекта, никакого MBA не нужно — в небольшой статье (10 страниц текста, ке-ке-ке) я расскажу вам, что такое рентабельность инвестиций, как оценить её для внутреннего проекта, какую роль в этом играет Proof of Concept, и почему в реальной жизни всё может пойти не так. Делать мы всё это будем вокруг вымышленного проекта по автоматизации составления расписаний для колл-центра. Добро пожаловать под кат!
Наш вымышленный проект
В колл-центре работает 100 операторов. Они работают по плавающему расписанию, выходя на работу сменами по 8 или 12 часов. Смены начинаются в разное время и расставлены так, чтобы обеспечивать дежурство множества людей в часы пик и малого количества людей в холодные часы по ночам и выходным. Расписание планирует дежурный супервайзер колл-центра темными пятничными вечерами, на глазок планируя нагрузку на следующую неделю.
Один 8-часовой день работы оператора колл-центра стоит компании 2.000 руб. Если считать, что в году 250 рабочих дней, то колл-центр обходится компании в 100 х 2.000 х 250 = 50 млн руб в год. Если мы автоматизируем составление расписания, мы сможем прогнозировать почасовую нагрузку и расставлять смены так, чтобы варьировать число дежурных операторов в зависимости от прогнозной нагрузки. Если наш прогноз и расстановка смен окажется хотя бы на 10% лучше, чем прогноз и расстановка супервайзера, получится экономия аж 5 млн руб. в год. Если нам действительно удастся выжать 10% улучшения, проект однозначно окупится. Или нет. Давайте подумаем, как вообще принимать такие решения.
Как считают ROI
Прежде, чем начинать большой проект, неплохо бы оценить его экономическую целесообразность. Хрестоматийный способ сделать это — посчитать возврат на инвестиции, ROI.
ROI (Return on Investment) — это показатель доходности проекта, равный отношению доходов к затраченным инвестициям. ROI ¯\_(ツ)_/¯ ). Картинка оттуда же — на ней пример прогноза нагрузки.
Для начала, нам удалось предсказывать почасовую нагрузку с WAPE = 14%. Удалось достичь ошибки меньше 10% на 43% часов, меньше 20% на 70% часов.
Вообще, это очень неплохо — мы достаточно точно ловим и суточные колебания, и недельные циклы, и среднесрочные тренды. Обжигаемся только на случайных флуктуациях, и, скорее всего, избежать их не удастся.
По нагрузке мы сможем легко вычислить число операторов, которые должны быть в смене в данный час. Мы написали жадный неоптимальный алгоритм планировщика смен и вычислили, что что нам удается сэкономить 10% смен на прогнозной нагрузке. При этом оказалось, что если мы в дополнение к 12-часовым сменам введем 8-часовые и умно расставим их по суткам, можем сэкономить еще 5%.
Переводим показатели в деньги. Текущая стоимость годового содержания колл-центра — 50 млн руб в год. Наш эксперимент показал, что мы можем уменьшить эту сумму на 15%, что приведет к экономии до 7,5 млн руб в год, а за весь срок жизни — до 22,5 млн руб.
Это очень хороший эффект, и так и хочется признать PoC успешным. Давайте, однако, задержимся и проанализируем, что может пойти не так.
Риски, влияющие на экономический эффект
Мы получили положительный эффект за счет сокращения числа сотрудников. Число сотрудников мы смогли сократить за счет сокращения числа смен. Число смен мы смогли сократить за счет перераспределения их по предсказанной нагрузке. Нагрузку мы смогли предсказывать с помощью моделирования на основе исторических данных.
Во-первых, если паттерны пользования продуктами, которые обслуживает наш колл-центр, изменятся, исторические данные потеряют актуальность. Шанс того, что паттерны не изменятся в течение ближайших трех лет, достаточно мал. Нужно заложить расходы на дообучение и коррекцию модели по ходу ее жизни.
Во-вторых, мы предсказали нагрузку достаточно точно, но, тем не менее, в 30% случаев ошибаемся больше, чем на 20%. Может оказаться, что такая ошибка в час пик приводит к недопустимому росту длительности ожидания. Супервайзеры примут решение закладывать резервные смены для покрытия рисков.
В-третьих, при проведении PoC’а мы оперировали только сменами, а в реальности окажется, что на сменах работают вполне конкретные люди. Почему-то людей нельзя просто так увольнять и моментально набирать, а смены для сотрудника нужно ставить с учетом рабочего графика, Трудового Кодекса и личных пожеланий сотрудника. Из-за этих факторов придется держать штат чуть больше, чем того хочет машина.
Итого, нам нужно заложить резервные смены в часы пик и поддерживать немного «балласта» в тихие недели. А кроме того, нам нужно будет заложить расходы на поддержание модели.
Настало время поговорить о расходах и рисках, с ними связанных.
Разработка и сопровождение, их стоимость и риски
По ходу проведения PoC нам стало понятно, что нужно делать для промышленной реализации решения.
Во-первых, нужно выстроить стабильно работающий процесс сбора данных. Оказалось, что мы достаточно легко можем получать данные из CRM. Однако, данные о расписании операторов мы были вынуждены собирать по крупицам. Значит, нам придется сначала сделать автоматизированную систему контроля расписаний операторов. Удачное совпадение, что результаты планирования мы тоже будем выгружать в эту систему. Мы оценили, что на разработку выгрузки из CRM у нас уйдет неделя-две. Разработка системы для управления расписанием потребует месяца два, и есть риск, что мы ошиблись в оценке в разы.
Во-вторых, нам нужно закодить сервис, применяющий модель для прогноза нагрузки, а потом закодить алгоритм, составляющий расписание под эту нагрузку. Саму модель мы уже обучили, как ее применять, примерно понятно — мы сможем упаковать ее в сервис примерно за неделю, максимум две. С алгоритмом составления расписаний сложнее, к тому же, мы можем погрязнуть в реализации ограничений или не смочь обойти комбинаторную сложность. Разработка алгоритма займет у нас от пары недель до двух-трех месяцев — неопределенность высока.
В-третьих, для работы всего этого потребуется инфраструктура — сервера приложений, базы, балансировщики и мониторинг. Как хорошо, что мы делаем это не в первый раз и знаем, что это займет где-то неделю. Если накосячим с оборудованием, то две. Сопровождение инфраструктуры будет занимать у нас от силы один-два человеко-дня в месяц, пфффф. Но за три года набежит до пары полных месяцев, ой. Кроме того, надо заложить дообучение и перевыкладку модели раз в полгода — итого 2-5 раз, каждый раз по 3-5 дней.
Просуммируем расходы в оптимистичном, реалистичном и пессимистичном вариантах.
Пусть средний разработчик обходится компании в 20 тыс. руб. в день.
Оптимистичный — 5 дней на CRM, 40 дней на систему управления расписанием, 5 дней на прогнозирование, 10 дней на составление расписаний, 5 дней на инфраструктуру, 3х12х0,5 дней на ее поддержку, и 2х3 дней на редкие дообучения модели. Итого 65 рабочих дня на разработку, 24 дня на поддержку. Итоговая стоимость решения — 1,3 млн руб на разработку + 0,48 млн руб на поддержку за 3 года.
Реалистичный — 10 + 60 + 10 + 20 + 10 + 3х12х1 + 5х3 = 110 разработки и 51 поддержки, 2,2 + 1,02 млн руб.
Пессимистичный — это когда все пошло не так. 20 + 80 + 20 + 40 + 10 + 3х12х2 + 5х5 = 170 разработки и 97 поддержки, 3,4 + 1,94 млн руб.
Отметим, что около 40% стоимости уходит на поддержку, как ни крути.
Оценка ROI и целесообразности проекта
При оптимистичной оценке мы получали 15% экономию на рабочей силе, что приводило нас к экономии 22,5 млн руб за срок жизни проекта, из которых 7,5 млн руб сваливалось на нас в первый год. Оптимистичная оценка расходов показывала всего 1,3 + 0,48 млн руб, что дает +6,2 млн (+377% ROI) в первый год и +21 млн руб (+1160% ROI) за время жизни. Божественно.
Однако, если реализуется хотя бы часть рисков, ситуация изменится. Если окажется, что на часы пик выпадает 50% смен, и мы захотим поддерживать 10%-ный резерв, мы тут же потеряем 5% эффекта. Еще 2,5% расходов на неэластичность штата — и вот мы потеряли в сумме 7,5% из 15% эффекта. Получаем всего 3,75 млн руб доходов в год, 11,25 млн за срок жизни. Это реалистичная оценка доходов.
Вычтем из этого расходы по реалистичной оценке — 2,2 млн на разработку и 1,02 на поддержку. Получим +55% ROI в первый год, +252% за срок жизни. Результат все равно достойный, но вывод о внедрении выглядит уже не таким однозначным.
Теперь давайте перестрахуемся и добавим 20%-ный резерв в часы пик. Мы потеряли еще 5% эффекта, осталось всего 2,5% сокращения расходов, или 1,25 млн в год, 3,75 млн за срок жизни. Это пессимистичная оценка эффекта, но эффект всё ещё хотя бы есть. Теперь при реалистичной оценке расходов проект не окупается в первый год, и только на горизонте в 3 года немного выходит в +17% ROI. Кажется, положить деньги на депозит выглядит надёжнее. Таким образом, при реалистичной оценке доходов и расходов мы уже не можем себе позволить 20%-ную перестраховку.
При реализации пессимистичного сценария разработки расходы составят 3,4 млн руб в первый год. Приемлемый ROI +121% мы получим только в самом радужном случае. На горизонте 3х лет также окупится с +108% ROI «средний» по доходам сценарий.
Таким образом, видно, что реалистично ждать от проекта ROI +55% в первый год и +252% за все время жизни, однако, мы будем вынуждены сильно ограничивать себя в резервах. И если мы не уверены в компетенциях собственной разработки, то проект лучше вообще не начинать.
| Сценарий дохода | Сценарий расхода | Income | Dev | Support | ROI 1г | ROI 3г |
|---|---|---|---|---|---|---|
| Optim | Optim | 7,5 | 1,3 | 0,5 | +4x | +11x |
| Optim | Real | 7,5 | 2,2 | 1,0 | +2x | +6x |
| Optim | Pessim | 7,5 | 3,4 | 1,9 | +85% | +3x |
| Real | Optim | 3,75 | 1,3 | 0,5 | +155% | +5х |
| Real | Real | 3,75 | 2,2 | 1,0 | +48% | +2,5х |
| Real | Pessim | 3,75 | 3,4 | 1,9 | -7% | +112% |
| Pessim | Optim | 1,25 | 1,3 | 0,5 | -14% | +108% |
| Pessim | Real | 1,25 | 2,2 | 1,0 | -50% | +17% |
| Pessim | Pessim | 1,25 | 3,4 | 1,9 | -69% | -29% |
P.S. Делать свое или купить готовое
Живой менеджер изучил бы альтернативные решения еще до внедрения PoC, но у нас же умозрительный проект, да? К тому же, про сторонние закрытые решения статью не напишешь.
Для начала, есть очень важный стоп фактор — каким будет исход разработки, сильно зависит от компетенций компании. Если компания не уверена в своих разработчиках и DS’ах, вероятность пессимистичного исхода слишком велика. В этом случае нужно однозначно использовать решение от вендора. Просто исходя из этого соображения, просто по этому пути идут все нетехнологические компании. Технологические компании отличаются тем, что сила их команды даёт шансы на оптимистичный исход. Вот тут начинается математика.
Решения от вендоров биллятся, исходя из стоимости аренды рабочего места. По нашей «реалистичной» оценке дохода в 7,5%, мы экономим на одном рабочем месте 37,5 тыс. руб в год. Это и есть максимальная стоимость решения. Если решение стоит дешевле — оно принесет положительный ROI. С собственной разработкой все сложнее — окупаемость зависит от числа операторов. За первый год положительный ROI возможен при расходах на операторов в 26,66 млн в год, что достигается при 53 операторах. За три года положительный ROI начинается от 27 операторов.
При выборе стороннего решения кроме простой математики стоит учесть еще два фактора.
Во-первых, это риски. При покупке решения вы получите что-то более-менее работающее. При реализации решения своими силами у вас остается существенный шанс провала.
Во-вторых, это активы. По окончании разработки вы получаете актив, который можете развивать и дорабатывать. При аренде или покупке лицензии собственного актива вы не получаете.