How to plan development without chaos?

VAYTI – a new DIY media for IT specialists I’ll talk about the principles that helped improve development processes and make them more transparent.

Recording business requests

In order to understand how much work comes into the team and how much we can handle, we need to start recording all the requests that come from the business. This can be done either in a notepad or on a blackboard, but we all know very well that there are task trackers for this.

I would like to add that businesses are ready to give you ideas at least several times a day. Here it is important to be close to the customer and make him think about the benefits of his proposals. It is often possible to prove with numbers that the next idea is not so cool.

I will give an example from my own experience. We have a bot that reminds cold clients that it would be nice to chat with us in a VK or TG chat. A customer comes and comes up with a great idea: “Let’s write on WhatsApp as a bot. There you can even be the first to initiate a dialogue, and we have the client’s phone number.”

Great idea, only WhatsApp allows you to send first only paid messages, or if more than 24 hours have passed since the last message. After analysis, it turned out that just to launch such a feature we need to spend $6,000, and then another $2,000 monthly.

After thinking again, the customer decided that the idea was not so cool, because the conversion into a contract would not allow such costs to be recouped.

Single Responsibility Principle

What to do with an urgent feature that seems very important to the customer and should be done yesterday?

We record this feature and pass it on to the analyst. Together with him, we break the request into stories, for which he becomes responsible. That is, if there is a discrepancy between what the customer asked to do and what actually happened, I know exactly who to ask.

At the same time, in the eyes of the customer, the implementation of improvements or services falls on my shoulders, that is, the business knows exactly who to ask if any problems arise.

Next comes the standard process, in which we find out the actual problems of the customer and try to solve them without affecting the developers. It often turns out that there are several ways, at least following the rules of “fast and cheap” or “long and high quality”.

We also find out the actual scope of work. A small change in business processes can lead to large changes in code. For example, a customer wants to change one field in the service: convert the text input “Customer City” into a drop-down list. But other services use the values ​​of this field, which means we are facing large-scale changes.

Thanks to the analysis, we can quite accurately predict the timing of work. Or we can even kill the development if an analyst shows the inconsistency of the customer’s idea using numbers or if the functionality has already been implemented as part of another feature.

And so we realized that without developers the customer’s problem cannot be solved and improvements are needed. We agree on the implementation option with the customer, warn about the timing, risks and costs. If all conditions are satisfactory, the analyst creates technical tasks, for which specific developers become responsible.

At this point, we can begin the development planning process based on the priority of a particular task. There are a great many ways of prioritization, information about them can be found on the Internet. For example, in our company there is a simple rule: the closer you are to the money, the faster you need to do it.

For each specific task, only one developer is assigned responsibility. If risks arise related to code quality or bugs, we know exactly who to go to to fix everything.

What to do with everything else?

Of course, we don’t engage in endless development of just features. We still have users of our services who have questions about the operation of the service, and we collect feedback from them.

Support records the user's request, question about the service or feedback. Employees try to solve the user's problem within their competence. If you have well-described documentation and you keep it up to date, then most often the support can handle it on its own, without the help of developers.

Otherwise, support staff creates a request and passes it on to developers or analysts. In the future, the request may degenerate into a bug or feature. Here the circle closes, and the feature, having gone through the stages of approval, falls on me.

PS

I deliberately avoided describing such things as planning, prioritization, and the terms Scrum and Kanban. In this article, I wanted to describe only an approach in which all tasks included in development have a clear hierarchy and responsibility. Then the development becomes transparent for the customer and everyone responsible for the delivery.