Hello, my name is Anton Fokin, I am the CEO of QTIM studio, we are engaged in custom development. Websites, applications, digital services, that’s all. Artyom Trushin, our CPO, helped me write the article. Let’s tell you how we removed the writing of technical specifications from our processes and reduced the average time for project development by 4 times.
Why did we refuse the terms of reference?
Reason 1. It is rarely used 100%
Why write technical specifications? With it, clients feel that they are protected: there is a document, which means we must receive certain functionality. In practice, literally 30 percent of this functionality remains, or at best 40. The rest is replaced by improvements, new ideas and unaccounted for points that emerge in the process.
When it comes to digital products that have value in themselves (for example, a mobile application for renting flying electric scooters), the TK will almost always end up in the trash. Because the product is alive, which means it must be written iteratively. If we are talking about the corporate website of Zaptekhrosgossnab LLC, then there is no question, you can design it in advance, write the technical specifications and make it strictly according to it.
Reason 2. No one knows anything for sure
I had a case with a marketplace: the client wanted a platform with a secure transaction. I start, I do it, when I get to it, it turns out that the payment flow that the customer wanted to work on is not implemented by any payment system. Although companies are promoting that all this already exists. I had to redo it all over again.
When the TK collides with reality, it will almost certainly break softly. Because the market, while you were writing the terms of reference, changed, new technologies or services appeared. Or services, on the contrary, were made manual and became inaccessible.
Reason 3. It’s a time waster
Writing technical specifications is a long process that takes about 25% of the total project time. Well, at least in Artyom’s and my universe this is so.
Interviewing the customer and writing the terms of reference is only half the adventure. Then there will be approvals and adjustments. Approvals tend to drag on: the customer will read, check, and try to provide for everything at once. But that doesn’t happen. In most cases, the client does not fully know what he wants to get in the end (see reason 2).
Reason 4. It’s a showstopper
I worked with one client, technical specifications took two months to write. The project could already be in full swing, but without a completed technical specification it would not move forward.
At the same time, the contractor-developer’s processes should also be taken into account. When the workload is close to full, you are unlikely to keep a team for a project that is waiting two months for approval of technical specifications. When everything is signed, it will take time to launch; you will be waiting for the necessary specialists from other projects. And delay is like death, as we know.
Reason 5. While you are writing technical specifications, everything has changed inside the client
Not in his rich spiritual world, but in his work processes. A lot of things can happen, for example, the client will switch to another CRM or warehouse accounting system, or something else. All your planned integrations will suddenly become irrelevant and you will have to recalculate and rewrite them. Time, time.
Reason 6. The client did not express everything he needed
The terms of reference are usually not written by the decision maker or the product owner. He doesn’t have time for that. The technical specification is written by a person dedicated to it. He interviews and interviews the client, and then writes down everything he hears. But the most necessary words come on the staircase (or in the elevator), so that outside the scope of the technical specifications there remains a whole stock of what was implied, but not spoken out loud.
Total. In my experience, when working with technical specifications, 60–70% of the functionality originally described in the document is lost. This happens due to new ideas or unconsidered issues that arise during the development process. In any case, you have to deviate from the technical specifications. And up to a quarter of the total time allocated for the project is spent on technical specifications. Artyom and I thought: well, screw him.
4 times faster: how we build the process now
Still, our work processes, even without technical specifications, are far from chaos. That’s how we set it up with our CPO.
Stage one: developing a user story
The client presents a regular user story in the format “I want the order history to open when this button is clicked.”
For example, PowerApp is an application for sharing chargers. Among the wishes, it should include a rental process, flexible tariffs, modern payment methods: SBP, Yandex Pay, and so on. With the help of clarifying questions, I collected the wireframe into one space – a matrix from which layouts are already formed.
Stage two: drawing layouts
I’m passing on the matrix. Designers, together with the project manager, think through user scenarios – the result is CJM. They discuss how things should work and the layouts are drawn based on that.
I encourage the team to look at the task from the user’s point of view – and describe how the site or application should work from his end. If you download all the tasks from ClickUp, you essentially get a technical specification – but it is not written in advance, but is formed in the process: described, edited, discussed. The result is the following design documentation.
In addition, there are no terms of reference for the entire project. It is written for each sprint, not in detail about each button, but about the main functionality, links to layouts and agreements with the client. That is, there is evidence of what we agreed on.
Third stage: frontend and backend development
Divided into sprints of two weeks. Every sprint I give the client a piece of functionality for testing in order to immediately check on the “expectation/reality” issue. At the same time, I work in the “sprint plus one” mode. There is a general understanding of the stages and the result, but it changes in real time – often I don’t know which module would be better to take purely based on the code base.
One of the clients, towards the end of the project, asked to draw up complete documentation, and Artyom and I took a whole sprint for this – about 100 hours. And they described the whole project. If every developer, after writing his task, documents everything, it would be very cool and correct. But it will take four weeks instead of two.
Stage four: working with bugs
Fixing bugs is a separate sprint, for which a budget and time are allocated. I always discuss bug rates with clients. Most often, we immediately say that there will be bugs after each stage – but I will fix them in the last sprint, because we work quickly. I have a conditional five months and do not have time to bring each stage to perfection.
How it works in practice
Client: online school.
Task: release your own platform with iSpring functionality in 5 months
QTIM was not the first team the client turned to. Another contractor worked on the project for a year and a half – with technical specifications – and did not complete it. I started working without specifications in modules – and made the platform in five months.
During the process, some modules were changed, and the result was completely different from what the client originally wanted. And so three times. If we worked with technical specifications, we would have to rewrite it every time, coordinate it, and recalculate the cost of the project. Five months would have turned into ten, a year, a year and a half – what happened to the first contractor.
I took on tasks in two sprints that I could show and submit. For example, we take 30–40% of the backend that none of the clients look at. By the end of the stage there should be a result that they will look at, check – and see that the project is moving forward. Thus, the client receives a certain value every month.
From a financing point of view it looks like this. Conventionally, the project costs 5 million and lasts 6 months. On average, I get paid 800 thousand a month. First they give 400, and the next 400 will be given when they are convinced that I have completed the tasks for this sprint. The client makes a postpayment, and I move on to the next stage – and so on.
So the client and I are moving to the last stage: the main functionality works, we skip the bugs and put them in a common table – we fix them in the last month. It’s always said. Of course, if the client has time to spare, it is better to fix bugs right away.
But there are nuances. What needs to be taken into account when refusing technical specifications?
The format in which I work is not suitable for everyone. On the one hand, it happens quickly, without bureaucracy. But everything has a downside. Here’s what you need to prepare for if you want to move your team to this approach.
Clients are not always ready to work without technical specifications
Many clients believe that technical specifications are a must-have that they cannot live without. It’s like when someone comes to you and asks you to create an online store using Bitrix. Why on it? Because the client does not know that there are a lot of other solutions that suit him better. It’s the same story with terms of reference: usually everyone has a familiar developer who advises making sure to draw up a technical specification. We’ll have to convince you. Frequent demonstrations of intermediate results work well – and when the project is 65% complete, the client usually calms down and trusts you.
It can be difficult to evaluate a project
Additional expenses often arise during operation. It is important to assess the risks immediately. I meet halfway and act in the interests of the client and his budget. If I realize that I’m doing something wrong, I just stop and do something else. I assess the situation quickly: there is no such thing that I stretch it out for several weeks.
Without technical specifications it is impossible to give an ideal assessment, so I estimate with a fork. For example, a client says that he wants a marketplace with such and such functions. I give an approximate cost based on my experience. We calculate how many people need to be allocated to the team: front, back, designer, manager – multiply by the rate, approximate period, we get a fork. In the process, the requirements are clarified and the picture becomes clearer. Usually, if I have to go over budget, I inform the client about it in advance.
You will need an expert autonomous team
To work without specifications and understand what the client wants, you need strong expertise. Each team member is important; no one passes unfinished or poorly done work further down the chain. Everyone, without exception, understands what business objectives they perform with their work. Project managers play a special role in this process – they are conductors who translate the client’s business problems into technical language. My projects work in pairs with designers – they make sure that everything is taken into account perfectly at the first stages. Next, they perform a controlling function and test the product based on use cases.
And communication within the team goes on without them. You can work without technical specifications only in this format. If people don’t know how to solve problems on their own, it’s a lost cause.
Strong thinking designers needed
A point that, in my opinion, is not given enough attention. Good designers work with projects, think through user scenarios, take into account all the points – what will work and how. If the designer and the manager have thought through everything, you will quickly agree on the layouts with the client and submit them for development. Think through everything down to every icon. How and in what cases will she behave?
Are you still writing technical specifications? Write about your processes in the comments or to me at Telegram.