Custdev in the development of video surveillance products
Almost all companies that develop video analysis modules do this based on the extrapolation of their own engineering thought. The company thinks: "We will be able to develop a function that, for example, will detect objects left behind, or detect fire, or count people at the box office of shops, etc.". And does it. The decision on which module to create is made in most cases based on the capabilities of the developers and the resources of the company. As a result, often the modules that are obtained become a kind of technical experiments. And when customers buy them, they embed them into existing video surveillance systems and begin to put them into practice, it turns out that they don’t carry any real benefits.
It turns out the development for the sake of development, and not for the sake of solving urgent problems. And this is wrong and unprofitable. The fact is that the development of a function does not end with its creation. The function is part of a software product that is constantly updated, respectively, and it must be constantly maintained, changed, lining up in new versions. And this requires the resources and time of developers. Each new function iteration should be checked at the product testing stage, and these are the resources and time of the quality group.
In addition to everything, the accumulation of unnecessary, unhealthy, unclaimed in practice functions in a product leads to its general cluttering and complication (see the article “Towards simplicity: how difficult it is for developers” ).
')
So, we should strive to develop only what is really useful and applicable in practice by a large number of people. But how to find such a function?
In addressing this issue, we have relied on customer development. By definition, custdev is testing an idea or prototype of a future product with potential consumers.
This method assumes that we can generate ideas and hypotheses on what the desired function should be (based on our capabilities or fantasy - it does not matter), but then they will need to be validated.
Practically all developments in the field of video analysis today are the result of the implementation of unvalidated, unverified hypotheses. The developers assume that the function invented by them will be needed by someone. It is supposed that it will bear the benefit if it is done this way and not otherwise. But custdev’s global experience shows that most hypotheses are wrong.
We started generating ideas. To do this, we stormed on our own, asked current and potential users of video systems, what they lack, remembered what we encountered and heard from participants in exhibitions, seminars, etc. As a result, we have 115 hypotheses. These are ideas of value that can be transferred to the user through the video analysis module.
This is how one of our worksheets with hypotheses for validation looked
Further hypotheses had to be validated. To do this, we went and traveled to real users at various real objects, which are using the video surveillance system right now, and conducted “problem” interviews with them. We asked them about the past user experience, found out what problem they had during the last month that could potentially be solved with the help of some kind of video analysis module. And are they ready to buy a function for solving the problem for a specific price when it is developed by us?
At this stage, we conducted 124 such interviews and were surprised to find that only 5 of our 115 hypotheses were tested. Only 4%! This has already become very significant for us.
After we selected applicants for development, it was necessary to understand how to do this. For each module, we have compiled implementation options, and again went to the same users with a question, or maybe they want to see.
And in most cases, our assumptions were again wrong. The convenience of working with the same function for the developer who creates it, and for the user who exploits it, looks completely different. Therefore, using the custdev method, we searched for not only “what”, but also “how”. Only a few assumptions about how the selected functions should work, confirmed by the words of users.
One of the 5 ideas we found was implemented in the fall of 2017. This is a module that allows you to monitor compliance with safety at work and construction sites - detector absence of a helmet on a person’s head.
Users were directly involved not only in the choice and form of the function, but also in its development. Using the deep learning approach, the developers in the process of creating the module trained the detector on real videos from real objects: construction sites, industrial enterprises, power plants. Users sent us something; we received something ourselves, going to the objects; something was shot when there were building or repair areas; something was taken from free sources of internet online broadcasts.
We are well aware that the function that users need, according to them, and the function that they buy and actually use is not always the same thing. For the first 1.5 months of sales of the absence of helmets detector, we purchased it in 5 countries, and we rate this result well. But in the future it is necessary to continue to assess the relevance and real usefulness of the module: to track the detector's repeated purchases from those who have already begun to use it; find out the specific results of the implementation of the function in the structure of the video system; track if there are any calls to technical support for the module, etc. And if in practice the need and actual use of the module is not confirmed, have the courage to say goodbye to it. As we once did with the interactive search module (see the article “Development in our own juice or how we understood that we are not doing what users need” ).
The way of development using customer development techniques is not the only correct one. But, in our opinion, it allows you to make video analysis modules not with engineering developments, but with functions that give real benefit to real people.
It turns out the development for the sake of development, and not for the sake of solving urgent problems. And this is wrong and unprofitable. The fact is that the development of a function does not end with its creation. The function is part of a software product that is constantly updated, respectively, and it must be constantly maintained, changed, lining up in new versions. And this requires the resources and time of developers. Each new function iteration should be checked at the product testing stage, and these are the resources and time of the quality group.
In addition to everything, the accumulation of unnecessary, unhealthy, unclaimed in practice functions in a product leads to its general cluttering and complication (see the article “Towards simplicity: how difficult it is for developers” ).
')
So, we should strive to develop only what is really useful and applicable in practice by a large number of people. But how to find such a function?
This is the scary word custdev
In addressing this issue, we have relied on customer development. By definition, custdev is testing an idea or prototype of a future product with potential consumers.
This method assumes that we can generate ideas and hypotheses on what the desired function should be (based on our capabilities or fantasy - it does not matter), but then they will need to be validated.
Practically all developments in the field of video analysis today are the result of the implementation of unvalidated, unverified hypotheses. The developers assume that the function invented by them will be needed by someone. It is supposed that it will bear the benefit if it is done this way and not otherwise. But custdev’s global experience shows that most hypotheses are wrong.
We started generating ideas. To do this, we stormed on our own, asked current and potential users of video systems, what they lack, remembered what we encountered and heard from participants in exhibitions, seminars, etc. As a result, we have 115 hypotheses. These are ideas of value that can be transferred to the user through the video analysis module.
This is how one of our worksheets with hypotheses for validation looked
Further hypotheses had to be validated. To do this, we went and traveled to real users at various real objects, which are using the video surveillance system right now, and conducted “problem” interviews with them. We asked them about the past user experience, found out what problem they had during the last month that could potentially be solved with the help of some kind of video analysis module. And are they ready to buy a function for solving the problem for a specific price when it is developed by us?
At this stage, we conducted 124 such interviews and were surprised to find that only 5 of our 115 hypotheses were tested. Only 4%! This has already become very significant for us.
After we selected applicants for development, it was necessary to understand how to do this. For each module, we have compiled implementation options, and again went to the same users with a question, or maybe they want to see.
And in most cases, our assumptions were again wrong. The convenience of working with the same function for the developer who creates it, and for the user who exploits it, looks completely different. Therefore, using the custdev method, we searched for not only “what”, but also “how”. Only a few assumptions about how the selected functions should work, confirmed by the words of users.
From words to development
One of the 5 ideas we found was implemented in the fall of 2017. This is a module that allows you to monitor compliance with safety at work and construction sites - detector absence of a helmet on a person’s head.
Users were directly involved not only in the choice and form of the function, but also in its development. Using the deep learning approach, the developers in the process of creating the module trained the detector on real videos from real objects: construction sites, industrial enterprises, power plants. Users sent us something; we received something ourselves, going to the objects; something was shot when there were building or repair areas; something was taken from free sources of internet online broadcasts.
This is victory? Not so fast…
We are well aware that the function that users need, according to them, and the function that they buy and actually use is not always the same thing. For the first 1.5 months of sales of the absence of helmets detector, we purchased it in 5 countries, and we rate this result well. But in the future it is necessary to continue to assess the relevance and real usefulness of the module: to track the detector's repeated purchases from those who have already begun to use it; find out the specific results of the implementation of the function in the structure of the video system; track if there are any calls to technical support for the module, etc. And if in practice the need and actual use of the module is not confirmed, have the courage to say goodbye to it. As we once did with the interactive search module (see the article “Development in our own juice or how we understood that we are not doing what users need” ).
The way of development using customer development techniques is not the only correct one. But, in our opinion, it allows you to make video analysis modules not with engineering developments, but with functions that give real benefit to real people.
Source: https://habr.com/ru/post/346726/
All Articles