what it should be, composition and technology of creation

I have worked in IT as a consultant, programmer, salesman for over 18 years in total. Over the years, I have tried different methods of interacting with clients and approaches to drafting terms of reference. And the best option in my opinion, I will describe in this article. I myself have long been using this method of drawing up technical specifications and interaction at the first stages of cooperation. And now I decided to share with you.

One of the biggest challenges in any business, especially a big one, is getting started. There are always a lot of questions at the start. Where to begin? How to start in such a way that you get the result you want? And this is where philosophy comes to the rescue.

Why is it so important to start right? Only one beginning leads to only one end.

This is important to understand. For example, if we built a barn instead of a bath, most likely, we built a barn from the very beginning. In the future, of course, we can transform the barn into a bathhouse or a bathhouse into a barn. But that is another story. The point here is that how we start will determine how we end up. No matter how trivial it may seem, many people simply do not think about such things.

According to dialectics, the result, for example, an implemented IT system (importantly, not just implemented, but implemented!) Is an expanded beginning.

As you can see, both philosophy and life suggest one thing: the beginning and the result are always connected. And if we are talking about the result, we are also talking about the beginning. At the same time, the beginning is very, very important for us.

It all starts with an idea

In the beginning there was a word …

At the beginning of creating any software, you need a word. This is a brief. In other words, an idea. When we want to create any kind of software, we first need to form an idea.

This idea can be a description of a process, some kind of task described in a condensed form. Such a description should be short, take no more than 1-2 paragraphs (1 ton of characters) and clearly express the essence of what we want to get as a result.

For example, the idea might be: “Develop an IT system for controlling mutual settlements” or “Develop an IT system for automating sales.” It can also be a description of the process, for example, in this form:

“If there is a need for a product that is not available, the seller creates a purchase request document and sends it to the buyer for approval. The buyer checks the need for the purchase of this product, and if the buyer permits the purchase of the goods according to the purchase request, then the seller is informed about the permission to purchase the goods, and the buyer creates an order for the supplier. Otherwise, the application is canceled with a comment containing the reason for the refusal to purchase. The seller is informed about the refusal to purchase. “

Thus, at the very beginning, we need to concisely and clearly formulate the idea. It is from her that we will build on in the future and focus on it in order to get the desired result.

How to formulate an idea

An idea is not as easy as it might seem. It is very important here to clearly articulate what exactly you want to get. For this, I propose to ask the leading specialist or responsible person in as much detail as possible what exactly he needs. After that, you need to formulate the idea not only succinctly, but necessarily in a form that will be understandable to this person. After that, the formulated idea is necessarily agreed upon.

It is very important in the process of formulating an idea not to go aside and not go into details that are unnecessary at this stage. Often at this stage, people try to write out detailed briefs. As a result, the focus is on detail and nuance. In fact, this is not correct.

The main thing is the idea, i.e. a clear understanding of the goals that you want to achieve as a result of the project. It can be described by text, it can be immediately in the form of a graphical process. The most important thing is a clear and unambiguous understanding of the result. Leave the details for later steps.

What if we wanted something completely different from what happened in the end?

This question-objection is often asked by customers. It usually sounds like this:

“We wanted a CRM system, but we wrote that we needed an ERP” or “We needed a CMS for the site, and we wrote a CRM”.

Terminology errors are a common problem. And in the IT field, the terminology is complex and very important. Therefore, I personally devote many publications to the correct terminology.

To avoid problems and misunderstandings, it is best to learn the terminology beforehand. Take the time to make sure that you name the final product correctly in the idea.

Well, if in the process of approvals there were no difficulties, and you received a result that helps to solve the assigned tasks, most likely you simply misused the terms. And when they say “CRM” they really mean ERP or vice versa.

Once again: pay as much attention to terms as possible. Clarify their meaning in the articles on my website, when communicating with experts, in reference books. This will help to more accurately formulate the goal, avoid disagreements and draw up the correct terms of reference.

Graphical description of the process

After the customer has formulated the idea, we need to conduct a more detailed interview, understand the important nuances, after which a graphic description of the process is created.

Why is the process so important? You can read more about this in my article “Business modeling», Which describes the main approaches. You may also be interested in the article “About the process approach», Where you can also read in detail about why processes are important and how to work with them.

In a nutshell, we need to decompose the task at hand into a specific process or processes. I personally recommend using the BPMN format for this. At the moment, this is the standard that is most developed from the point of view of business automation.

You can also read more about BPMN in my publications.

• Comparison of IDEF3, IDEF0, BPMN and DFD notations

• How to describe a business process in BPMN and others notation format.

Regardless of the choice of tool, the diagram should answer the question “How do we want to get this or that result.”

For example, if we are talking about sales, it should be clear from it what is the beginning, for example, a customer request, and the end of the process. This can be shipment, conclusion of a contract, etc.

Another example is Customer registration for services. Here you also need to describe the sequence of actions, starting from the moment of the client’s request to the moment of directly registering for the service.

Text description

Now that we have described the process graphically, discussed it, received consent, the time comes, as they say, “to add meat to the bones”. Those. on the resulting frame in the form of a general diagram, we begin to “build up” the details of how exactly the work will be done at each of the stages.

In the graphical model, we cannot detail all the nuances in detail. Moreover, this is not necessary, unnecessary details only complicate the perception. There is a textual description for this.

For example, in the graphical model, we indicated “Create a request”. In the diagram itself, that’s enough. But in the text description, we indicate what is needed to create an application. This can be a list of fields (Client, Order Amount, Comment, etc.).

Similarly, when creating a Deal based on an order, the text describes the fields “Deal Amount”, “List of Products”, “Client”, “Stage”, etc.

Requirements for text description:

1. The textual description should fully describe the process that is in the graphic description.

2. Additionally, the textual description should contain everything that is necessary for the development of a solution and its transfer to the work of programmers.

If an idea is needed for management, mainly a BPMN diagram – for management and senior employees, i.e. those who will make decisions and generally control the situation, then a text description is needed for programmers. With the help of a diagram and a text description, they will already be able to implement the solution.

Plan

We already have an understanding that of the necessary and useful tools are already available. There is knowledge where we have to come. The plan reflects the sequence of actions that are needed to achieve the goal.

For example, in our process a call should be created and the conversation recording should be automatically connected. Hence, we need:

1. Connect IP telephony, if it is not already in use.

2. Integrate telephony with the system.

3. Set up a call recording and select a storage for these recordings.

Another common example – at the moment, the site is filled in manually. It is necessary to set up automatic upload to the site. In terms of our plan, we set the task: “Automatic uploading of data to the site. Development of scripts for transferring data from the accounting system to the information site ”.

Thus, in the plan we collect automation tasks, and also indicate the contractor and deadlines. In this case, there is no need to indicate the names of the performers. It is important to indicate simply in the plan: “programmer”, “consultant”.

I personally understand this:

• A programmer is the person who will write the program code.

• A consultant is a person who will supervise the programmer’s work.

• The Senior Consultant is the person who will provide the overall management of the project.

Sometimes, if there is a need for this, I indicate that a certain task will be performed not just by a programmer, but, for example, by a 1C programmer.

Plan requirements:

1. The plan should reflect all the tasks that need to be completed in order to get from what is, what should be.

2. The plan should indicate clear deadlines for completing tasks, and who the executor is.

You can also study these stages of work in more detail from my article “Using GAP analysis to identify and agree on project tasks.”

Invoice and / or calculation

In the calculation, we take those tasks that are estimated in the plan in hours and days, and calculate their cost. If the calculations are internal, the calculation is sufficient. If your customer is another company, you will need an invoice.

Here, too, everything is simple. We take a task, recalculate it for working hours, multiply it by the cost of an hour, and get a calculation of the cost of the task. You can study the technique itself in detail in the article “How to calculate the cost of implementing a software product”