Help Desk system Okdesk. How we develop our startup: the balance between long-term strategy and customer wishes
Hello! Our team is developing Okdesk cloud service - Help Desk system for customer service in the b2b segment. Our sales strategy is not “pushing”, but solving the immediate problems of our customers. Therefore, we pay special attention to the development of the product functionality (perhaps everyone can write about themselves this way :).
In product development, we have to balance between long-term development plans and the current wishes of active customers. After all, it is necessary to maintain the loyalty of those who have already chosen our service (to improve the functions created, to increase the usability, etc.) and to develop new functional blocks targeted at those whose problems we are not fully resolving. The task seems simple if there are an unlimited number of hands, heads, and time — but in the real world, everything is different.
')
Under the cut, we will talk about how we solve the tasks described above, how the product development process is organized, and also share plans for 2017.
The development of an IT product can be compared to the construction of a building. At the beginning, you develop the building design, then you make the foundation and supporting structures, start communications, install windows. In principle, when the “box” is ready - you can hide from the rain and wind in it, warm up in the winter (if there is heating). But to feel comfortable you need to settle down - to engage in interior planning, repair, buy and arrange furniture. At the same time, you can complement and change the internal layout and decoration, if necessary, in the process of “using” the building without rebuilding it.
So in the “construction” of the IT product. There is an initial high-level development plan, formulated in terms of large functional blocks. This plan proceeds from the real problems of the clients, on whose solution the product is oriented. To draw up such a plan, an analysis of the market, competitors, and interviewing of clients are carried out (for example, we interviewed several hundred service companies from various industries). The high-level plan may change when receiving feedback from the market - but not radically (mainly in terms of priorities). A radical change of the plan is possible, but only with the change of the concept of the whole project, which is popularly referred to as “pivot”.
Without having at least some implementation of large functional blocks, it is difficult to formulate the correct requirements for details - interface elements, convenience, and other functions included in the block. After the implementation of the first version of a large functional block and the beginning of using new functions, product creators begin to accumulate suggestions for their development - through their own experience and receiving feedback from active users (more on this in the next section)
Thus, in the backlog of the product there are large “strategic” tasks, and smaller tasks are accumulated to improve the functionality created earlier. Large tasks are needed to expand the applicability of the product (business growth). Improvements are needed to ensure that the work in the system is comfortable and complete (increasing the loyalty of existing customers and reducing churn).
To maintain a balance between major tasks and improvements, we divided the product backlog by task type, and in each product release we include tasks of each type (usually one big one and several improvements made earlier). Thus, the development of the product goes “in two lanes”. This approach allows us to please existing customers and attract new ones, whose tasks we could not solve earlier.
Feedback from users is an important source of valuable product development requirements. All requests must be recorded and analyzed. And in the future to make a decision on the implementation of new functions.
There is no doubt that feedback from users is important. But not always and not from everyone. In this context, users are essentially of two types - customers and non-customers.
When “non-customers” only learn the system, they can give feedback. Usually this is a list of requirements in style: “I will buy if you make it ...”. Throwing headlong into the implementation of the required functions, hoping to get another client is meaningless (this temptation is especially strong in the early stages of the project, when each new subscriber gives a noticeable relative increase). Most often, these requirements are not the reason for refusal to purchase, but the reason. The reason may be anything (no money, happy with the current state of affairs, and so on). By the way, according to our already accumulated statistics, the percentage of those who simply look and do not make a purchase even during the year is quite high. Therefore, if the user says “I would buy if you did ...”, we reply “we will do if you buy ...”. And when such a user becomes a client, we are already fully working with his requirements. That is, the wishes of those who have moved to the stage of “Successful sale” in the funnel have real value. Customers have no reason to look for flaws or shortcomings. They report on what is stopping them or what is missing in the system as part of their daily work and business tasks.
It is important to understand that behind the stated requirement there is a real scenario of using the system. The submitted request is an already formulated solution to the problem the user has encountered. This solution is invented directly by them, often in a couple of minutes and without a systematic approach. The problem is that this solution is not always optimal. Therefore, we each time specify the usage scenario and the problem the user faces. Such an approach makes it possible to propose an optimal and systemic solution to a problem, which, with a high probability, sooner or later would arise for other clients. The implementation of user requirements “as is” can eventually turn the system into an unusable set of “patches” (which, unfortunately, most of the solutions become in a couple of years).
We give an example from our experience. Okdesk has a panel with real-time information about the work of the support service:
On square tiles displays the number of applications that meet a particular criterion. In particular, one of the tiles displays information about open but overdue applications. Some time ago, a request was received from one of our clients: to make it possible to customize the filtering parameters, by which the counting of applications in each of the tiles is performed. Began to understand the use case and the problem.
It turned out that in the company's business process, applications have statuses within which, for example, the applicant is expected to receive a response, or parts are expected to be delivered. Applications that are in these statuses for a long time are considered overdue by the system (and, accordingly, are counted on one of the tiles). The client proposed a solution - to set filtering parameters for the tile, whereby he will be able to exclude applications in “frozen” statuses from the counting. But we found another solution - to implement the option “Consider time” for status in the settings of business processes. Thus, the client will be able to set up the “freezing” of the time counter, and pending orders will not be considered overdue.
If we rushed to implement the user requirement “as it is”, we would spend a lot of time on its development (first of all - on the development of a convenient interface solution). But, having gone deep into the level of usage scenarios and problems, we were able to find a simpler and more understandable solution.
In the conclusion of the section I would like to draw attention to the obvious fact that feedback from the user expects feedback from you. If the user has formulated a requirement or wish to the system - it is important to give an answer about the development plans. And when (and if) the expected function is implemented, it is important not to forget to inform the user about this event. In many ways, providing feedback on user requirements overlaps with technical support processes. Therefore, it will be logical to collect the initial wishes of users and give them feedback in the Help Desk system.
For example, to support Okdesk users, we use Okdesk :). The main channels of receipt of appeals are email and client portal . Therefore, all calls automatically become requests in the system. If the appeal is a wish for the development of the system, we clarify the details of the user scenario and a description of the problem. User interaction takes place both within the framework of correspondence on request and within telephone conversations. After finding out all the details, tickets with wishes are transferred to the special status “Waiting for development”.
When releasing a new release, we check all applications in this status, and if some part of them is fully or partially solved by new functionality, we inform the good news to users. Users are satisfied and feel our care :)
A few words about how we have requirements and development management processes, as well as what tools we use.
Above, we have already described how a long-term development plan for a product is formed, where development options come from, and how work is carried out with feedback from customers. When you have a plan, you need to work on it.
Before developing the code, we write productions (specifications, TZ - for whom it is convenient). All requirements are divided into large functional modules and inside the modules are grouped into semantic blocks. For example, there is a large functional unit “01. Application Accounting Module. It has a number of semantic blocks “01.01. Application card ”,“ 01.02. Comments to the applications ”,“ 01.03. List of applications ”and so on. Separately, we keep a list of changes in the requirements for each release. For each requirement, we describe cases, solutions, and the reason for choosing one of the options. For all, we maintain (and update with changes) a list of Test Cases. We did not buy expensive specialized tools - Google Docs is currently missing.
When the requirement is ready, development begins. For all tasks, we conduct a Code Review (one of the project’s founders is responsible for the technological part). After that, the new function rolls out to the test server for surface visual testing - it is implemented by the same person who developed the requirement. If there are any remarks - they are sent for elimination, if there are no remarks - the task goes to detailed manual testing. After removing all the comments, the new task is covered by autotests in accordance with the written Test-cases.
After all the tasks of the current release are ready - we run the re-manual testing of the version where all the new functions are collected. If there are no comments, we cross our fingers and roll out new features to customers.
We are trying to release a new release every 3-5 weeks. In each release we include one big function and a number of improvements previously made. But there are large functional blocks that do not fit in one release - for example, a mobile application for working with applications from field staff will be released from week to week. Its development took about 3 months.
Tools used in the work: Google Docs for documents and requirements management, Redmine for development management, GitHub for code, Slack for communications, Okdesk for technical support and work with customer feedback.
And finally, some of our plans (plans) for the development of large functional units for 2017.
From week to week there will be a mobile application for full-fledged work with requests “on the road”. The mobile application will be available for Android and iOS platforms (first, Android, iOS will be released later).
Following the mobile application, it will be possible to account for service objects within customers (shops, buildings, branches and additional offices). And then - accounting of client equipment (from computer equipment to refrigerators and security systems) in relation, including, to service facilities.
And, of course, we will release a lot of various improvements that make working in the system more convenient and covering a large number of real client cases. It seems to be interesting!
All reasonable requirements, a systematic approach and good products!
Happy New Year!
In product development, we have to balance between long-term development plans and the current wishes of active customers. After all, it is necessary to maintain the loyalty of those who have already chosen our service (to improve the functions created, to increase the usability, etc.) and to develop new functional blocks targeted at those whose problems we are not fully resolving. The task seems simple if there are an unlimited number of hands, heads, and time — but in the real world, everything is different.
')
Under the cut, we will talk about how we solve the tasks described above, how the product development process is organized, and also share plans for 2017.
Balance between big features and small improvements
The development of an IT product can be compared to the construction of a building. At the beginning, you develop the building design, then you make the foundation and supporting structures, start communications, install windows. In principle, when the “box” is ready - you can hide from the rain and wind in it, warm up in the winter (if there is heating). But to feel comfortable you need to settle down - to engage in interior planning, repair, buy and arrange furniture. At the same time, you can complement and change the internal layout and decoration, if necessary, in the process of “using” the building without rebuilding it.
So in the “construction” of the IT product. There is an initial high-level development plan, formulated in terms of large functional blocks. This plan proceeds from the real problems of the clients, on whose solution the product is oriented. To draw up such a plan, an analysis of the market, competitors, and interviewing of clients are carried out (for example, we interviewed several hundred service companies from various industries). The high-level plan may change when receiving feedback from the market - but not radically (mainly in terms of priorities). A radical change of the plan is possible, but only with the change of the concept of the whole project, which is popularly referred to as “pivot”.
Without having at least some implementation of large functional blocks, it is difficult to formulate the correct requirements for details - interface elements, convenience, and other functions included in the block. After the implementation of the first version of a large functional block and the beginning of using new functions, product creators begin to accumulate suggestions for their development - through their own experience and receiving feedback from active users (more on this in the next section)
Thus, in the backlog of the product there are large “strategic” tasks, and smaller tasks are accumulated to improve the functionality created earlier. Large tasks are needed to expand the applicability of the product (business growth). Improvements are needed to ensure that the work in the system is comfortable and complete (increasing the loyalty of existing customers and reducing churn).
To maintain a balance between major tasks and improvements, we divided the product backlog by task type, and in each product release we include tasks of each type (usually one big one and several improvements made earlier). Thus, the development of the product goes “in two lanes”. This approach allows us to please existing customers and attract new ones, whose tasks we could not solve earlier.
Work with the wishes of customers
Feedback from users is an important source of valuable product development requirements. All requests must be recorded and analyzed. And in the future to make a decision on the implementation of new functions.
There is no doubt that feedback from users is important. But not always and not from everyone. In this context, users are essentially of two types - customers and non-customers.
When “non-customers” only learn the system, they can give feedback. Usually this is a list of requirements in style: “I will buy if you make it ...”. Throwing headlong into the implementation of the required functions, hoping to get another client is meaningless (this temptation is especially strong in the early stages of the project, when each new subscriber gives a noticeable relative increase). Most often, these requirements are not the reason for refusal to purchase, but the reason. The reason may be anything (no money, happy with the current state of affairs, and so on). By the way, according to our already accumulated statistics, the percentage of those who simply look and do not make a purchase even during the year is quite high. Therefore, if the user says “I would buy if you did ...”, we reply “we will do if you buy ...”. And when such a user becomes a client, we are already fully working with his requirements. That is, the wishes of those who have moved to the stage of “Successful sale” in the funnel have real value. Customers have no reason to look for flaws or shortcomings. They report on what is stopping them or what is missing in the system as part of their daily work and business tasks.
It is important to understand that behind the stated requirement there is a real scenario of using the system. The submitted request is an already formulated solution to the problem the user has encountered. This solution is invented directly by them, often in a couple of minutes and without a systematic approach. The problem is that this solution is not always optimal. Therefore, we each time specify the usage scenario and the problem the user faces. Such an approach makes it possible to propose an optimal and systemic solution to a problem, which, with a high probability, sooner or later would arise for other clients. The implementation of user requirements “as is” can eventually turn the system into an unusable set of “patches” (which, unfortunately, most of the solutions become in a couple of years).
We give an example from our experience. Okdesk has a panel with real-time information about the work of the support service:
On square tiles displays the number of applications that meet a particular criterion. In particular, one of the tiles displays information about open but overdue applications. Some time ago, a request was received from one of our clients: to make it possible to customize the filtering parameters, by which the counting of applications in each of the tiles is performed. Began to understand the use case and the problem.
It turned out that in the company's business process, applications have statuses within which, for example, the applicant is expected to receive a response, or parts are expected to be delivered. Applications that are in these statuses for a long time are considered overdue by the system (and, accordingly, are counted on one of the tiles). The client proposed a solution - to set filtering parameters for the tile, whereby he will be able to exclude applications in “frozen” statuses from the counting. But we found another solution - to implement the option “Consider time” for status in the settings of business processes. Thus, the client will be able to set up the “freezing” of the time counter, and pending orders will not be considered overdue.
If we rushed to implement the user requirement “as it is”, we would spend a lot of time on its development (first of all - on the development of a convenient interface solution). But, having gone deep into the level of usage scenarios and problems, we were able to find a simpler and more understandable solution.
In the conclusion of the section I would like to draw attention to the obvious fact that feedback from the user expects feedback from you. If the user has formulated a requirement or wish to the system - it is important to give an answer about the development plans. And when (and if) the expected function is implemented, it is important not to forget to inform the user about this event. In many ways, providing feedback on user requirements overlaps with technical support processes. Therefore, it will be logical to collect the initial wishes of users and give them feedback in the Help Desk system.
For example, to support Okdesk users, we use Okdesk :). The main channels of receipt of appeals are email and client portal . Therefore, all calls automatically become requests in the system. If the appeal is a wish for the development of the system, we clarify the details of the user scenario and a description of the problem. User interaction takes place both within the framework of correspondence on request and within telephone conversations. After finding out all the details, tickets with wishes are transferred to the special status “Waiting for development”.
When releasing a new release, we check all applications in this status, and if some part of them is fully or partially solved by new functionality, we inform the good news to users. Users are satisfied and feel our care :)
Requirements Management and Help Desk Development Process
A few words about how we have requirements and development management processes, as well as what tools we use.
Above, we have already described how a long-term development plan for a product is formed, where development options come from, and how work is carried out with feedback from customers. When you have a plan, you need to work on it.
Before developing the code, we write productions (specifications, TZ - for whom it is convenient). All requirements are divided into large functional modules and inside the modules are grouped into semantic blocks. For example, there is a large functional unit “01. Application Accounting Module. It has a number of semantic blocks “01.01. Application card ”,“ 01.02. Comments to the applications ”,“ 01.03. List of applications ”and so on. Separately, we keep a list of changes in the requirements for each release. For each requirement, we describe cases, solutions, and the reason for choosing one of the options. For all, we maintain (and update with changes) a list of Test Cases. We did not buy expensive specialized tools - Google Docs is currently missing.
When the requirement is ready, development begins. For all tasks, we conduct a Code Review (one of the project’s founders is responsible for the technological part). After that, the new function rolls out to the test server for surface visual testing - it is implemented by the same person who developed the requirement. If there are any remarks - they are sent for elimination, if there are no remarks - the task goes to detailed manual testing. After removing all the comments, the new task is covered by autotests in accordance with the written Test-cases.
After all the tasks of the current release are ready - we run the re-manual testing of the version where all the new functions are collected. If there are no comments, we cross our fingers and roll out new features to customers.
We are trying to release a new release every 3-5 weeks. In each release we include one big function and a number of improvements previously made. But there are large functional blocks that do not fit in one release - for example, a mobile application for working with applications from field staff will be released from week to week. Its development took about 3 months.
Tools used in the work: Google Docs for documents and requirements management, Redmine for development management, GitHub for code, Slack for communications, Okdesk for technical support and work with customer feedback.
Our plans for 2017
And finally, some of our plans (plans) for the development of large functional units for 2017.
From week to week there will be a mobile application for full-fledged work with requests “on the road”. The mobile application will be available for Android and iOS platforms (first, Android, iOS will be released later).
Following the mobile application, it will be possible to account for service objects within customers (shops, buildings, branches and additional offices). And then - accounting of client equipment (from computer equipment to refrigerators and security systems) in relation, including, to service facilities.
And, of course, we will release a lot of various improvements that make working in the system more convenient and covering a large number of real client cases. It seems to be interesting!
All reasonable requirements, a systematic approach and good products!
Happy New Year!
Source: https://habr.com/ru/post/317392/
All Articles