Proof of concept services

История понятия

Первое публичное упоминание понятия произошло в феврале 1967 года на слушаниях в Сенате США, посвящённых вопросам политики авиационных исследований и разработок. В 1969 году Подкомитет по передовым исследованиям и технологиям Комитета по науке и космонавтике США определил «проверку концепции» как «фазу разработки, на которой создаётся экспериментальное оборудование для демонстрации осуществимости новой технологии».

Позднее английский термин PoC стали соотносить не только с процессом (собственно проверкой), но и с его результатом (моделью, опытным образцом), так Брюс Карстен в 1984 году определил проверку концепции как «нечто, созданное в качестве инженерного прототипа с исключительной целью подтверждения его работоспособности»..

Why is having a proof of concept important for small businesses?

POCs are critical in helping businesses, especially small ones, launch their new or refined product ideas and begin their project management process. Here are three specific reasons why:

1. Project managers can pinpoint potential risks and obstacles

Developing a POC helps project managers pinpoint risks and obstacles they may face in implementing the proposed product.

Rather than uncovering those obstacles during or after the product launch, managers can foresee them and plan their projects accordingly while still in the development phase. Examples of these risks and obstacles are contracted parties’ failure to fulfill their deliverables, disputes during project implementation, and many more.

It’s worth noting that while the POC doesn’t guarantee smooth implementation of project management basics, it can increase the likelihood of the product’s success.

For instance, once POCs unveil the potential obstacles, project leaders can then record them in the risk register, also considered one of the best project management practices, for appropriate planning, budget coverage, and other actions.

Project leaders can also find ways to eliminate, mitigate, and address the risks and assure their investors about the project’s success.

2. Project leaders can determine the chances for scalability

When project managers propose creating a product, they and their stakeholders likely expect it to be scaled.

That’s why, through POCs, project leaders can verify not only the feasibility of the idea but also its scalability, whether immediately or over time.

POCs can help managers and stakeholders see how to go about growing and mass-producing the product in terms of systems architecture, human resources, and workflow standardization, among others.

In this way, companies can determine their capacity for working with additional production. POCs can even help project managers address scope creep while they’re still in the proposal phase.

Scope creep refers to how a product’s requirement realistically tends to multiply or escalate over the project life cycle.

For instance, a proposed product that begins with five essential components can then have 10 as the company scales it. Another is when managers need to spend on sudden product changes that can go beyond the project budget.

If project managers can prove the company’s ability to handle scope creep during scalability, they can note it in their project management tools, as well as present their proposal to stakeholders more convincingly.

3. Stakeholders need proof before investing

Before project managers can request resources for their proposal, they should show their stakeholders that the investment will be worth it.

POCs give project managers that opportunity. Through POCs, they can illustrate the usability and profitability of the idea. They can show the product idea in detail with illustrations and visuals to provide the presentation with sufficient data.

They can thoroughly explain the advantages of the proposed product to the company’s operations, brand image, customer relations, and more.

By doing so, project leaders can better convince the enterprise to commit the needed resources to develop the idea. POCs also allow stakeholders to assess the idea giving them a varied form of win-loss or cost-benefit analysis.

If the concept doesn’t prove to become as practicable or profitable as formerly assumed, and the losses outweigh the potential returns, stakeholders can decide not to invest. Building a new product, after all, isn’t cheap. If the proposed venture fails, tons of resources could go to waste that could have been invested in more productive initiatives.

If project managers can prove that they have an airtight idea and the right measures to mitigate possible losses, they can better compel stakeholders to accept their proposal.

What Is a Proof of Concept?

An effective proof of concept proves the goal of a proposed project is viable, and will be successful. The value of a POC is it can help a project manager identify gaps in processes that might interfere with success.

That’s not all a proof of concept does. A POC elicits feedback from everyone involved in a project, including those who might not have otherwise contributed, thereby mitigating unforeseen risk.

The proof of concept is so valuable because it’s a test project to evaluate before work begins on an actual project. A POC verifies that concepts and theories applied to a project will have a real-world application. POCs do not produce deliverables, as the core issue being considered is the feasibility of the project.

POC by Industry

Depending on the industry, proof of concept may be different. For example, in software development it speaks to processes with different objects and participant roles. In this context, it is about finding solutions to technical problems. In business, startups are using a POC to determine if a product is financially viable. There’s a lot of research and review that takes place.

Наш вымышленный проект

В колл-центре работает 100 операторов. Они работают по плавающему расписанию, выходя на работу сменами по 8 или 12 часов. Смены начинаются в разное время и расставлены так, чтобы обеспечивать дежурство множества людей в часы пик и малого количества людей в холодные часы по ночам и выходным. Расписание планирует дежурный супервайзер колл-центра темными пятничными вечерами, на глазок планируя нагрузку на следующую неделю.

Один 8-часовой день работы оператора колл-центра стоит компании 2.000 руб. Если считать, что в году 250 рабочих дней, то колл-центр обходится компании в в год. Если мы автоматизируем составление расписания, мы сможем прогнозировать почасовую нагрузку и расставлять смены так, чтобы варьировать число дежурных операторов в зависимости от прогнозной нагрузки. Если наш прогноз и расстановка смен окажется хотя бы на 10% лучше, чем прогноз и расстановка супервайзера, получится экономия аж 5 млн руб. в год. Если нам действительно удастся выжать 10% улучшения, проект однозначно окупится. Или нет?.. Давайте подумаем, как вообще принимать такие решения.

PoC vs MVP vs прототип

Чтобы наглядно продемонстрировать, для каких целей подходит тот или иной метод проверки новых идей, мы составили сравнительную таблицу:

	Proof of Concept	MVP
Что проверяем?	Техническая возможность реализации функции	Востребованность продукта у пользователей
Какую часть функциональности охватываем?	Одна ключевая функция будущего продукта/один из сценариев использования	Ключевые функции продукта, достаточные для решения главной проблемы пользователя
Для кого предназначается?	Стейкхолдеры, инвесторы	Стейкхолдеры, пользователи, инвесторы
Какой результат?	Наработки с заключением экспертов	Работающий продукт

Подробнее о бизнес-задачах, которые решаются при помощи MVP, читайте в статье “4 причины, почему вашему проекту нужен MVP”.

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

Оценка 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%

Когда проекту нужен Proof of Concept?

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

Проверка концепции – необязательный этап проекта, и в большинстве случаев он не требуется. Если вы хотите создать приложение с механикой Uber – неопределенность на проекте будет минимальна: идея проверена, каждый этап разработки детально описан, доступно много готовых решений. А, например, использование VR/AR-технологий, алгоритмов машинного обучения (ML-алгоритмов) или анализа больших данных кратно увеличивает неопределенность на проекте. Так, по данным Microsoft около трети проектов IoT не проходят этап Proof of Concept.

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

Даже когда технологический стек привычен, Proof of Concept помогает сравнить результативность нескольких решений и выбрать оптимальное.

Подход Proof of Concept помог нам выбрать сервис по построению маршрутов для коммерческих грузоперевозок на проекте SmartSeeds

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

Наша команда разработала тестовый стенд для проверки нескольких картографических сервисов. Это позволило наглядно сравнить маршруты, которые построили Google Maps, HERE.maps и Яндекс.Карт с учетом соответствующих ограничений для грузового транспорта. Результаты ранжировали по количеству нарушений ПДД в построенном маршруте. Подготовив заключение о стоимости каждого решения, мы рекомендовали сервис, который лучше всего решает поставленную задачу.

PoC помогает проверить идею на наличие “узких мест”. К примеру, в последние годы маркетологи возлагали большие надежды на технологии персонализации рекламы. Однако ажиотаж и поспешное внедрение инноваций привели к сложностям со сбором, интеграцией и защитой данных. В конце 2019 года Gartner заключил: потребительское доверие снизилось, персонализированные предложения стали менее эффективными, что привело к снижению ROI

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

На данный момент прогнозы неутешительны: к 2025 году 80% маркетологов откажутся от персонализации. Тем, кто все еще планирует инвестировать в эти технологии, аналитики Gartner рекомендуют принимать решение только после демонстрации Proof of Concept.

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

Когда проверка концепции инновационных идей становится обычной практикой в компании, скорость развития бизнеса возрастает в 2-3 раза.

Хотите запустить новый продукт и снизить риски? Напишите нам, и мы подберем решение, которое подойдет именно вам

Сообщение успешно отправлено
Заполнить заново

V. Hikvision HDTVI РОС решения системы электропитания, как?

HDTVI POC особенность системы питания решения является то, что использование источников питания постоянного тока и аналоговые HD различия видеосигнала в пределах спектра для достижения коаксиального кабеля можно передать: источник питания, аналоговых видеосигналов высокой четкости и другие сигналы, которые могут не только сэкономить значительные затраты на строительство, это может привести к сокращению сроков строительства.

Система состоит из переднего конца камеры ОНК, блоки питания POC HDTVI DVR и серверными компонентами.

Совет POC камера DS-2CC12D9T-E имеет 2-Мп и 120dB широкий динамический настраиваемый соответствующий камеру для удовлетворения потребностей различных сценариев.

СПЭ питанием устройство имеет 4-Way, 8-контактный две модели, а именно DS-1TP04 и DS-1TP08 через коаксиальный кабель 4 или 8 POC источник питания камеры, холостая выходная мощность 800 Вт. Поддерживая доступ к 4 или 8 HDTVI DVR, с помощью коаксиального кабеля для передачи видеосигналов, реальная власть, передача, управление тремя линиями один. Все Фоновые модели HDTVI DVR поддерживает устройства с питанием POC доступа легко стыковки.

POC система электропитания конструкция обеспечивает более удобный способ упростить проводку и снизить затраты. Коаксиальный кабель передачи расстояние до 400 метров (в том числе и от заднего конца переднего плана электропитания и передачи), передний конец оборудования может решить трудную задачу отдельного источника питания, централизованной власти. инновации Hikvision в силу власти, патентов аналоговой технологии наложения видео высокой четкости, хорошее решение проблемы прочности электрических помех, вызванных передачи с наложением. Также имеет схему защиты от перегрузки по току, цепь медленно два патентов на технологии, чтобы обеспечить стабильность и надежность системы.

How to write a proof of concept

The POC process has five basic steps that project teams can follow, from developing the idea to firming it up and presenting it to the investors.

These are the five steps in the POC process.

Step 1: Demonstrate the need for the product

When presenting their POC, project leaders must establish the need for the product by mentioning who the target market is and what their pain points are. In narrating the customers’ pain points, however, project managers must not merely assume what these are. They need to get actual and verified answers.

Project leaders can acquire these responses by interviewing a representative sample of customers. They should ask in-depth questions about the clients’ frustrations, what they want a product to do to alleviate their inconvenience, their desired user experience, and more.

Doing that allows project leaders to grasp their customers’ feelings and perspectives clearly, as well as acquire a list of specific needs and targets for their POC.

Pro tip: Interview a sample group of customers to understand and verify their pain points.

Step 2: Ideate the right solution

From the sample group’s answers, project managers can now start brainstorming with their team for the right solutions to the customers’ pain points, keeping in mind that they should also be feasible and within the company’s capacities.

The team should then assess each brainstormed solution according to the likely costs, timeline, technologies needed, required operational capacities, competition, resources, and other factors.

They can even narrow down the list of ideas to the most feasible ones and finalize their proposed product.

Additionally, to firm up the proposal, the team should discuss how their solution can support the fulfillment of the organization’s or stakeholders’ goals.

Pro tip: Welcome half-baked ideas. You don’t need to be a perfectionist when ideating, at least, in the initial stages. You’ll be surprised how half-baked ideas can lead you to the best solutions.

Step 3: Create a prototype and test it

Once the team has arrived at a feasible idea, they should create a prototype based on the decided requirements, features, and solutions.

The project team must let the individuals in their sample group try and test the completed prototype. This is so they can quickly determine whether the product truly addressed the pain points shared by the group.

Testing it with the same group enables the team to document their feedback more easily, which is essential to the next step.

Pro tip: Prototyping isn’t the end in and of itself, it is just the means. Don’t get so caught up at building the perfect prototype. While you need to exercise caution and vigilance, don’t be stuck in this phase longer than you should be.

Step 4: Gather and document feedback

During the prototype testing, the project team must gather and document the sample group’s feedback about their experience, their reactions, and any other valuable details, including what they think of the user interface.

The gathered feedback lets the project team initially verify the usability and feasibility of the solution. It also informs the team of any needed improvements to the proposed product and gives significant insight for other relevant actions moving forward.

For the team’s quick reference to the collected responses, they can record the feedback in their project management software.

Pro tip: Use a cloud-based platform to obtain feedback. In that way, it’s easier for your project team or even your sample group to participate and collaborate.

Step 5: Present POC for approval

With the concept tested and improved based on the feedback, the project team can now prepare their presentation to the stakeholders.

They must present, among other things, the pain points that the product solves, features that address those problems, and technologies integrated to demonstrate the value of the idea.

They should elaborate on the product development and project management components, which they should also note in their project tracker.

These include clearly defined success criteria or project management metrics, evaluation measures, timelines, next project management plans (should it be approved), resources needed, and other aspects discussed earlier.

Once the team successfully presents the idea and persuades the stakeholders to approve and invest, they can begin to implement it.

Pro tip: Put more emphasis on the benefits that your product brings, instead of its features.

Этап 4. Сгенерируем признаки и обучим модель

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

Эксперимент мы сформулировали как задачу регрессии — «для каждого часа в истории будем строить feature-вектор и прогнозировать по нему нагрузку в этот час». Давайте собирать обучающую выборку. Строкой в выборке будет календарный час. Каждому часу соответствует таргет — число обращений за этот час.

Теперь подумаем, какие признаки мы можем использовать.

1. Для начала, воспользуемся календарной природой наших данных. Добавим признаки дня недели, часа, дня месяца. Их можно замкнуть в кольца.
2. Добавим число обращений в час по таким дням и в такие часы. Можно брать число обращений в последнюю неделю, а также среднее за месяц и за год.
3. Добавим аналогично число обращений в точно такой же час и день недели.
4. Возьмем окно агрегации пошире — добавим среднее число обращений в такой день недели и в такое время суток.
5. Попробуем сразу отнормировать числа обращений на тренд нагрузки. Протестируем как на нормированных, так и на сырых значениях.
6. Добавим сезонность — число обращений в месяц в прошлом году, нормированное на тренд нагрузки.
7. На всякий случай, добавим также «сырые» данные о тренде нагрузки. Причем возьмем как значение в текущий момент, так и «смещенные» значения — неделю назад, месяц назад.

Попробуем не только «обычную» функцию ошибки RMSE, но и WAPE — она больше подходит по смыслу задачи. Для валидации мы не сможем использовать обычную K-fold кросс-валидацию — появится шанс заглянуть в будущее. Поэтоиу будем использовать Nested Folds разбиение, причем зафиксируем размер тестового фолда равным, скажем, 4-м неделям ровно. И границы фолдов будем устанавливать точно в полночь понедельника.

Для PoC’а попробуем две модели — линейную с L1 регуляризацией и самую любимую деревяшечку. Для линейной модели не забудем стандартизировать (и логарифмировать, где нужно) признаки, а для деревяшечки — выкрутить параметры регуляризации поагрессивнее.

Этапы 5 и 6. Оценим качество модели и экономический эффект

Итак, все приготовления завершены, и мы, наконец, можем перейти к самой интересной части PoC’а — анализу результатов и принятию решений.
К сожалению, весь пример был умозрительным, без реальных данных, так что и результаты будут высосаны из пальца. Чтобы не было так стыдно, я взял похожие по порядку цифры из книги «Call Center Optimization» за авторством Ger Koole (я нечаянно нашел ее, пока писал эту статью ). Картинка оттуда же — на ней пример прогноза нагрузки.

Для начала, нам удалось предсказывать почасовую нагрузку с WAPE = 14%. Удалось достичь ошибки меньше 10% на 43% часов, меньше 20% на 70% часов.
Вообще, это очень неплохо — мы достаточно точно ловим и суточные колебания, и недельные циклы, и среднесрочные тренды. Обжигаемся только на случайных флуктуациях, и, скорее всего, избежать их не удастся.

По нагрузке мы сможем легко вычислить число операторов, которые должны быть в смене в данный час. Мы написали жадный неоптимальный алгоритм планировщика смен и вычислили, что что нам удается сэкономить 10% смен на прогнозной нагрузке. При этом оказалось, что если мы в дополнение к 12-часовым сменам введем 8-часовые и умно расставим их по суткам, можем сэкономить еще 5%.

Переводим показатели в деньги. Текущая стоимость годового содержания колл-центра — 50 млн руб в год. Наш эксперимент показал, что мы можем уменьшить эту сумму на 15%, что приведет к экономии до 7,5 млн руб в год, а за весь срок жизни — до 22,5 млн руб.

Это очень хороший эффект, и так и хочется признать PoC успешным. Давайте, однако, задержимся и проанализируем, что может пойти не так.

Proof Of Concept Examples

Here are some real-life examples of validating hypotheses using proof of concepts.

Da Vinci’s Armoured Car

The oldest and the best example of a proof of concept is the Leonardo da Vinci’s armoured car which formed the basis for the armoured car used today in modern warfare. He proved his product hypothesis by designing a prototype of an armoured car which was capable of moving in any direction and was equipped with a large number of weapons.

Disney Pixar’s Piper

Alan Barillaro is a director working with Pixar since 1997. He has put his effort in almost all of the major Pixar creations like A Bug’s Life, Toy Story 2, Monsters, Inc., Finding Nemo, The Incredibles, WALL-E, and Brave.

After “Brave”, Barillaro started working with the Pixar’s software development team to help develop an animation tool to help provide additional creative flexibility to the studio’s filmmaking process.

As a proof of concept, the director developed a short animation clip about a small sandpiper bird on the beach. This animation soon grew into a full-fledged short film, “Piper”, which was theatrically released with “Finding Dory” in 2016 and won the Academy Award for Best Animated Short Film at the 89th Academy Awards.

Bitcoin Whitepaper

In 2008, Satoshi Nakamoto published the Bitcoin Whitepaper as the proof of concept of the problem of financial transactions that existed in the market then and how bitcoin was a perfect solution to solve that problem.

The whitepaper also explained in detail how the cryptocurrency would work and benefit society.

How To Build A Proof Of Concept?

The main objective of developing a proof of concept is to get answers for these two questions –

• Is it feasible to develop the offering?
• Does the market need what I have to offer?

And finding the answers to these questions doesn’t require you to develop the actual product. It just requires you to follow four proof of concept steps.

• Assume that there’s a problem,
• Develop a concept based on that assumption,
• Ideate a solution,
• Validate both the problem and the solution.

This is how it’s done –

Assume That There’s A Problem & Develop Hypotheses

A hypothesis is a specific, testable prediction; a prediction that a problem exists, and customers would like to have a solution.

Let’s say you were looking to develop a SAAS and found an opportunity in the remote work industry. You found out that there isn’t a one-stop solution for managers to handle and manage their remote workers.

Develop A Concept-Based On Those Hypotheses

Now the problem discussed above is your first hypothesis.

Develop it more.

Find out what all problems do they face while handling their remote employees. Some of them might be –

• Using different applications to fulfil different tasks – Zoom for video conferencing, Trello for project management, and Hubspot for meetings and CRM.
• Not being able to check the hours worked.
• No good platform to manage remote employees’ payroll according to hours worked.

Develop A Hypothesis For Your Perfect Solution

Once assumptions relating to problems are conceptualised, solution(s) hypothesis is formed which involves the intended solution, aka the offering.

This step converts the idea into a concept as you start thinking of a product which actually solves the intended problem. The concept includes –

• What problems will the solution solve?
• What gains will the customer get after solving the problem?

For the problem of remote employees’ management, you can conceptualise a SAAS offering which has the following features –

• Video conferencing tool
• Project management tool
• Payroll management

…aka a complete remote employee management solution.

Do The Feasibility Tests

The steps above only made you develop a concept. This is the step which actually helps you find the proof of that concept.

It involves you to ask questions, take feedback, and look for convincing evidence that –

• The problem you thought of actually exists: The customer actually faces the problem and would like to solve it, either manually or with some outside help.
• Your solution can be built: It is feasible to develop the offering you plan to solve the problem with.
• Your solution is either needed or will be appreciated by the customer: The customer believes that the solution you have to offer will solve his problem.

The evidence is found using these strategies –

Prototypes

Often, to prove the product-oriented hypotheses, prototypes are used. They vary from technical designs to 3d prints to normal algorithms without user interface.

Surveys

• Face-to-Face Surveys: This involves setting up meetings with the potential customers, asking them questions, taking suggestions, offering your solution and taking feedback.
• Online Surveys: Online surveys involve using survey tools like Google Forms, Typeform, Product Hunt Ship, etc. to take a survey about the assumed problem and feedback about the offered solution.
• Tele-surveys: Tele-surveys are just like face-to-face surveys, but the questions and cross-questions are asked over telephone calls.

Landing Pages

Landing pages involves developing a landing page for the offering and taking early invites, asking questions, and/or analysing user behaviour on the landing page.

Demo

A demo is a low budget implementation of your artistic work, technical design, or service. It involves offering a demo to your target audience, followed by questions to understand if this offering solves the market’s problem.

For the example of the remote employees’ management tool, you might want to conduct surveys and develop a landing page with a demo video.

Этапы PoC

Длительность PoC’а обычно варьируется от недели до пары месяцев. Над задачей будет работать один человек, ведущий дата сатанист. Проведение PoC’а требует также много внимания бизнес-заказчика — на разговоры в начале PoC’а и на осмысление результатов в конце. Итого, PoC будет стоить нам до двух месяцев работы ведущего DS и несколько дней работы бизнес-заказчиков. Вот и первый индикатор — если заказчик не нашел время на PoC, то и результат большого проекта не будет по-настоящему востребован.

Итак, этапы.

1. Перейти от «хотелок» и базз-вордов к конкретным бизнес-требованиям. Это традиционная задача бизнес-аналитика, но очень желательно, чтобы DS проводил её сам. Так он сможет точнее понять потребности заказчика и выполнить второй этап…
2. Сформулировать эксперимент. Правильная формулировка — залог успешности проекта. DS должен определить, в каком месте бизнес-процесса принимается автоматизированное решение, какая информация доступна на входе, что ожидается на выходе, к какой задаче машинного обучения это можно свести, какие данные потребуются при обучении и в продакшене, какие технические и бизнесовые метрики использовать для оценки успешности.
3. Разобраться с данными. DS должен понять, какие вообще данные нам доступны. Оценить их атрибутивный состав, полноту, глубину истории, непротиворечивость. Быстренько собрать вручную датасет, достаточный для построения модели и проверки гипотезы. Неплохо бы сразу осознать, будут ли данные в продакшене отличаться от того, что доступно в трейне, и что мы тут собрали.
4. Наинженерить фич и построить модель. Юные сатанисты с младых ногтей думают только о моделях (ЕВПОЧЯ), так что комментарии излишни.
5. Оценить качество модели. Правильно провести кросс-валидацию, посчитать технические и бизнесовые метрики, а также оценить пределы, в которых они могут колебаться в продакшене. Это все тоже должен делать DS.
6. Оценить полученный ROI — ради этого всё и затевается. Для оценки можно привлекать представителей заказчика и кого-то, кто умеет в фин. модели.

Проведем вымышленный PoC на основе нашего вымышленного проекта.

Tips for Making a Proof of Concept

As noted above, a proof of concept is a project, and like any project it must be clearly defined. That means breaking down the process into these four steps in order to better manage it.

1. Duration & Effort

When you’re working on a POC it’s a project, but it’s not the final project. Completing work will be on a limited timeline. Usually that timeline is no more than two weeks. Also, you’re going to want to have a team assembled to do the job, but it doesn’t have to be a massive use of resources. Usually, two people are fine.

A project management software, like ProjectManager.com, can help facilitate the POC process. When you’re talking about duration and effort, you mean a schedule and tasks. These things are more efficient with the use of our award-winning online Gantt charts. Gantt charts can collect proof of concept tasks and lay them out on a timeline, with dependencies linked and durations easily edited.

In ProjectManager.com, tasks can be viewed individually or collectively, so each person knows what they’re responsible for and can see what others are doing, so everyone is on the same page. If there are questions, they can be added as comments on the task level, and documents, whether files or images, can be also added to the task. This keeps all documentation together and easily accessible.

ProjectManager.com lets teams collaborate on the task level—Click here to try it free!

2. Scope of Project

Defining the project scope for your proof of concept is key to getting accurate results. Even if the POC is proved viable, that proof is worthless if the scope is not correct. Time and effort is wasted if the scope is off. Therefore, you’ll want to keep the scope of the POC to one focus. That is, finding a resolution to one problem. If scope expands to look at too many things, you won’t get any of them done.

3. Pick Your Resources

Who you choose to execute the proof of concept is as important as the process. You want to make sure they have the right skills to do a thorough job. Depending on the what the project is, you might want to have a mentor, or someone with prior experience to act as a manager and a resource for any questions.

4. Choose Your Criteria

To have accurate feasibility measurements, you first must have a set of project metrics that have been decided upon. Metrics that collect the project’s most pertinent information, and determine its success or failure. You can start this process by interviewing the client, as it is their satisfaction which will determine whether the project is a success. But keep these questions targeted. Project goals should inform what you ask the client.