How I learned to work in terms of technical specifications: unobvious advantages of an obvious solution
Beginner developers who try themselves as freelancers often underestimate the value of terms of reference. I confess, once I also thought that technical specifications were an unnecessary scribbling of time losing their mediocrity, or a way to ignore the importance of themselves and their work. And this, as it seemed to me, was a completely justified position: the orders that I occasionally came across, I carried out easily, and if there were questions and surfaced previously unspecified nuances, I skillfully agreed with the customer. Of course, many will say that working on a technical project is obvious. But the scale of the sad consequences of the work without a technical task is completely unobvious.
The fact is that the customers came to me mainly on the recommendations, the tasks and the ways of their solution were similar. I famously combined freelancing with a permanent job (by the way, completely unrelated to development). Everything was great until a really serious customer appeared on the horizon with a really serious order.
The first meeting with the customer (then still potential) was just wonderful. Even then, I clearly understood the importance of communication technologies in business. And, although the business at that time was not even small, but microscopic, my attitude to communicating with the customer was more than serious. I famously demonstrated the latest work done by me, described the process of finding certain solutions on the way to creating a perfect final product, and openly revealed the advantages that these solutions had. The representative of the customer listened to me, opening his mouth. He showed some schematic scribbles on crumpled sheets of paper, showed similar systems, I immediately generated and expressed successful ideas. After a while, the order was mine.
')
From this point on my story loses its positive color. At the negotiations with the customer, I made a fatal mistake by making the usual move, which earlier allowed me to easily “win” former customers. Namely: relying on the initial data in the form of vague drawings on crumpled sheets, I indicated the cost. Of course, I made a reservation that this cost is indicative, but later on my rashness did not work in my favor.
The fact is that this time the customer was a department of a very large telecommunications company. As I learned later, a competition for the development and implementation of a certain monitoring system was played out among the departments. The head of the department, who later became my customer, decided to get a victory in the competition in his own way - to make some kind of necessary system, just not on paper - as the rest did, but in the form of a ready-made “doll”. But done in record time. Therefore, the technical assignment was set forth on crumpled sheets: the competition commission, on whose decision it depends, which department will receive the honorable task of creating the system and the budget due to it, most likely would not have bothered with the little things. As a result, a substantial part of the questions was underdetermined or omitted altogether.
But at that moment I was not aware of all this. And I judged as usual: what is not stipulated on the “crumpled sheets” I decide myself in the course of work. The negative consequences of this decision were not long in coming.
More or less on time, I did the work and passed the system in the form of the “doll” that my customer planned. The first stage of development has been completed. Next was the task of making our “doll” a more or less working system.
And at this stage a number of unpleasant nuances connected with the customer opened. And there were the first negative notes in our relationship:
The result of the above events was not only a deterioration in relations with the customer, but also an avalanche-like growth in the volume of work for the same money, and, even worse, in the same time frame. And the terms of work, which I defined at the negotiations, were, to put it mildly, naive - the lack of experience with such a customer affected. I honestly tried to meet the deadlines, but the volume of my negative emotions with a huge waterfall overflowed the edge of the cup of my patience.
Being late for the “two stages” I addressed the head of the department with an e-mail, in which I shared in detail the painful ones and set out my vision of the situation. The most important thing is that I demanded to form a technical task as a matter of urgency, noting my personal interest in the successful completion of the project (which was absolutely true). At the end of the letter, I stated that, despite this very interest, further cooperation without a technical task could not continue. Two weeks later, the technical project was presented - the customer developed it on his own, without my participation (however, the lack of proper qualifications in the organization of web systems and, as a result, a proper understanding of what ultimately needs to be received, affected the technical project miserably). As a result, it turned out concise, simple and understandable. The only trouble is that its volume was 4 sheets, and this is for the system, which at that time was developed for six months already! The nullity of the volume of this task on the background of the size of the system becomes clear if you run a little ahead - when the system was ready, it took 20 sheets to describe its installation and configuration, and the manual for working with it took more than 70 sheets. To top it all, the last item was a transition to a completely different platform (another DBMS and another operating system were corporate standards). The customer (in the person of the manager and several of his subordinates) explained that, yes, these corporate standards were known from the very beginning, but did not consider it necessary to inform me about the future mandatory transfer to another DBMS. And in general, another, different from the corporate, platform was originally chosen intentionally to (supposedly) speed up the development process (as the manager saw the optimization of the task for the earliest possible victory in the competition). And for dessert - the dates remained the same. Our cooperation ended pitifully: I was forced to abandon further joint plans, although the customer tried to “please” me with promises of further orders. At the same time, I was forced not to take money for the unfinished work.
Of course, if the customer at the negotiation stage had detailed me, at least in a nutshell, all the nuances of this order and the conditions for working on it would probably be a decision, the budget and the number of developers would be different. But history does not tolerate the subjunctive moods - so now it doesn’t matter what could be. It is much more important to make me (and my dear reader) understand the situation and draw the right conclusions from the above.
And then I, just, would like to make out all the mistakes that I made, initially without attaching much importance to the writing of a technical task.
After that story, quite a lot of time passed. Without technical specifications, I have not only not taken up work for a long time, but I do not even designate the cost of the project. Moreover, further experience has shown that technical specifications give the developer a number of other advantages that are not obvious to many, including experienced developers. About this and about what rules and approaches I adhere to in my work now, I will tell you more.
The technical task must be written either by the developer or the developer together with the customer. Often, customers do not understand anything in matters with which they turn to the developer. There are exceptions, of course, but these are just exceptions confirming the rule. If you require the customer to write a technical assignment on his own, in most cases the result will be several sheets containing vague meaning, which took the customer a week, two, three to write. And, losing precious time, you will have to find out again what the customer wants after all and in what form. And this negatively influences the psychological component of cooperation (it begins to seem to the customer that he knows you from the cradle - and that you have been making this order from his very childhood, although you could have finished everything for a long time). Therefore, the most sensible solution would be to take the initiative. Two advantages of this approach are obvious: the absence of negatives on the part of the customer (the developer will not “load” the customer, while he himself famously spells out the competent TK in a short time - the customer will be absolutely delighted), and the saving of precious time.
Terms of referencemay be part of marketing. I fear the word "marketing." And it is especially funny to hear about marketing when it comes to single freelancers, but in this context I consider it most appropriate and therefore will develop my thought.
Firstly, a competently created technical assignment can clearly illustrate the complexity of the project, which will help you justify the cost and terms of work. Secondly, the customer rarely handles the order only to you, more often he communicates with your competitors, choosing the performer most favorable to him. To each, he somehow describes the task. If he already has a technical task, written by you (independently, or together with the customer), then it is his customer who will send it to other possible performers for an alternative rendering of the project. Note! Only the solutions proposed by you, but competently formulated in the terms of reference, the customer will present your competitors as their own requirements! If you have written a technical task in sufficient detail, “sharpening” it for yourself and your own tricks, describing the ready-made developments in the form of a serious target functionality, the customer comes to your competitors not with a request “yes, you have to do nonsense”, but with a weighty technical task, which some simply scare, others will make a transcendental price. As a result, your chance to receive this order rises sharply.
Terms of reference allows you to avoid wasting precious time, and helps to adjust the budget. In the course of writing TK, quite obscure nuances often surface. Thinking through and calculating each item and each piece of functionality allows the customer himself to take a different look at the task. Perhaps the previous paragraph caused you indignation: "what a rogue, breeding customers." So, here I want to rehabilitate myself: I often unobtrusively try to force the customer to look at a particular issue from a different point of view: to abandon any elements and parts of the task if they have no meaning. This allows again - to save time, but the main thing - to save customer's money. Often the words "but it will be a little cheaper" play a key role in communication.
Technical specification is an advertisement. Probably, most freelancers will agree with me: - the best customers are either regular customers or customers that you have been recommended to. Competently composed and pleasantly designed technical assignment often remains with the customer even after the project has been completed, and he willingly shows it to those whom he recommends you with the aim of convincing the interlocutor of your seriousness and professionalism. Such customers are just a fairy tale. They are confident of your professionalism even before the start of negotiations, and you save time and (more importantly, time) your own emotional strength.
Terms of reference helps to keep the brand. This thesis could be attributed to the clause on marketing or advertising, but I want to consider it separately.
Imagine - you do not understand anything in matters (for example, site building) a person who has some kind of business, and you are not ready to spend a lot of time trying to enter into alien and uninteresting questions for you. You just need a website. Denoting the freelancer an abstract vision of the future site, you get a clear, detailed and pleasant technical task on a beautiful form (I almost said the company). In addition to everything else - the specialist who provides this technical task willingly and convincingly gives advice, communicates and generally - is fully open. I think the technology of communication in this issue plays a significant role.
I think that all developers in the course of their professional development accumulate a certain toolkit, which further helps them to reduce development time (in rare cases, to improve the quality of the resulting products). Therefore, if you decide to work on the terms of reference, it should also have a certain template containing inalienable attributes (in addition to the direct description of the task).
Of course, all of the above calls into question the term "technical task". Perhaps, it is worth using the terms “technical proposal”, “description”, “agreement” and so on ... but in any case - the meaning of the publication is completely different. I wish you a pleasant, profitable and productive work!
UPD : thanks to my partner Alexander Afanasyev, whom I consider to be the co-author of this article.
The fact is that the customers came to me mainly on the recommendations, the tasks and the ways of their solution were similar. I famously combined freelancing with a permanent job (by the way, completely unrelated to development). Everything was great until a really serious customer appeared on the horizon with a really serious order.
So, the first meeting is the first mistakes.
The first meeting with the customer (then still potential) was just wonderful. Even then, I clearly understood the importance of communication technologies in business. And, although the business at that time was not even small, but microscopic, my attitude to communicating with the customer was more than serious. I famously demonstrated the latest work done by me, described the process of finding certain solutions on the way to creating a perfect final product, and openly revealed the advantages that these solutions had. The representative of the customer listened to me, opening his mouth. He showed some schematic scribbles on crumpled sheets of paper, showed similar systems, I immediately generated and expressed successful ideas. After a while, the order was mine.
')
From this point on my story loses its positive color. At the negotiations with the customer, I made a fatal mistake by making the usual move, which earlier allowed me to easily “win” former customers. Namely: relying on the initial data in the form of vague drawings on crumpled sheets, I indicated the cost. Of course, I made a reservation that this cost is indicative, but later on my rashness did not work in my favor.
The fact is that this time the customer was a department of a very large telecommunications company. As I learned later, a competition for the development and implementation of a certain monitoring system was played out among the departments. The head of the department, who later became my customer, decided to get a victory in the competition in his own way - to make some kind of necessary system, just not on paper - as the rest did, but in the form of a ready-made “doll”. But done in record time. Therefore, the technical assignment was set forth on crumpled sheets: the competition commission, on whose decision it depends, which department will receive the honorable task of creating the system and the budget due to it, most likely would not have bothered with the little things. As a result, a substantial part of the questions was underdetermined or omitted altogether.
But at that moment I was not aware of all this. And I judged as usual: what is not stipulated on the “crumpled sheets” I decide myself in the course of work. The negative consequences of this decision were not long in coming.
Tender won, go further
More or less on time, I did the work and passed the system in the form of the “doll” that my customer planned. The first stage of development has been completed. Next was the task of making our “doll” a more or less working system.
And at this stage a number of unpleasant nuances connected with the customer opened. And there were the first negative notes in our relationship:
- Since the customer was not one person, but the department my phone and my email became publicly accessible ... Anyone who came up with bright, in his opinion, (or just some) thoughts about my work, considered it necessary to immediately communicate them to me personally by phone or any other way convenient to him ... or by all means at once. My requests to the head of the department to reduce the number of employees communicating with me, as a rule, had a short-term effect. After a couple of days, my phone began to burst again at any time convenient for anyone, and endless streams of various (sometimes contradictory) proposals and wishes were sent to the mail.
- Frequently occurring contradictions in the solution of certain issues were reduced to the dispute "discussed - not discussed", "determined - not determined", "agreed - did not agreed." I operated on scans of crumpled pieces of paper, the customer rightly noted “this is only a mockup when we painted it, we didn’t know all the nuances”. In addition, it was necessary to rake megabytes of letters.
- The head of the department is a busy person, and often on very important issues one had to communicate with his subordinates. And they, for the most part, yesterday's students, in various disputable situations strove to whitewash themselves in front of their superiors. Their favorite excuse "I told him that, he just misunderstood."
- On the part of the customer, the following questions were heard on various issues: “you are a professional, think up how it should be arranged,” or “we don’t know how it should look, but we don’t like what it looks like now.”
Last straw
The result of the above events was not only a deterioration in relations with the customer, but also an avalanche-like growth in the volume of work for the same money, and, even worse, in the same time frame. And the terms of work, which I defined at the negotiations, were, to put it mildly, naive - the lack of experience with such a customer affected. I honestly tried to meet the deadlines, but the volume of my negative emotions with a huge waterfall overflowed the edge of the cup of my patience.
Being late for the “two stages” I addressed the head of the department with an e-mail, in which I shared in detail the painful ones and set out my vision of the situation. The most important thing is that I demanded to form a technical task as a matter of urgency, noting my personal interest in the successful completion of the project (which was absolutely true). At the end of the letter, I stated that, despite this very interest, further cooperation without a technical task could not continue. Two weeks later, the technical project was presented - the customer developed it on his own, without my participation (however, the lack of proper qualifications in the organization of web systems and, as a result, a proper understanding of what ultimately needs to be received, affected the technical project miserably). As a result, it turned out concise, simple and understandable. The only trouble is that its volume was 4 sheets, and this is for the system, which at that time was developed for six months already! The nullity of the volume of this task on the background of the size of the system becomes clear if you run a little ahead - when the system was ready, it took 20 sheets to describe its installation and configuration, and the manual for working with it took more than 70 sheets. To top it all, the last item was a transition to a completely different platform (another DBMS and another operating system were corporate standards). The customer (in the person of the manager and several of his subordinates) explained that, yes, these corporate standards were known from the very beginning, but did not consider it necessary to inform me about the future mandatory transfer to another DBMS. And in general, another, different from the corporate, platform was originally chosen intentionally to (supposedly) speed up the development process (as the manager saw the optimization of the task for the earliest possible victory in the competition). And for dessert - the dates remained the same. Our cooperation ended pitifully: I was forced to abandon further joint plans, although the customer tried to “please” me with promises of further orders. At the same time, I was forced not to take money for the unfinished work.
Of course, if the customer at the negotiation stage had detailed me, at least in a nutshell, all the nuances of this order and the conditions for working on it would probably be a decision, the budget and the number of developers would be different. But history does not tolerate the subjunctive moods - so now it doesn’t matter what could be. It is much more important to make me (and my dear reader) understand the situation and draw the right conclusions from the above.
And then I, just, would like to make out all the mistakes that I made, initially without attaching much importance to the writing of a technical task.
The same advantages of technical specifications, which are obvious
After that story, quite a lot of time passed. Without technical specifications, I have not only not taken up work for a long time, but I do not even designate the cost of the project. Moreover, further experience has shown that technical specifications give the developer a number of other advantages that are not obvious to many, including experienced developers. About this and about what rules and approaches I adhere to in my work now, I will tell you more.
The technical task must be written either by the developer or the developer together with the customer. Often, customers do not understand anything in matters with which they turn to the developer. There are exceptions, of course, but these are just exceptions confirming the rule. If you require the customer to write a technical assignment on his own, in most cases the result will be several sheets containing vague meaning, which took the customer a week, two, three to write. And, losing precious time, you will have to find out again what the customer wants after all and in what form. And this negatively influences the psychological component of cooperation (it begins to seem to the customer that he knows you from the cradle - and that you have been making this order from his very childhood, although you could have finished everything for a long time). Therefore, the most sensible solution would be to take the initiative. Two advantages of this approach are obvious: the absence of negatives on the part of the customer (the developer will not “load” the customer, while he himself famously spells out the competent TK in a short time - the customer will be absolutely delighted), and the saving of precious time.
Terms of reference
Firstly, a competently created technical assignment can clearly illustrate the complexity of the project, which will help you justify the cost and terms of work. Secondly, the customer rarely handles the order only to you, more often he communicates with your competitors, choosing the performer most favorable to him. To each, he somehow describes the task. If he already has a technical task, written by you (independently, or together with the customer), then it is his customer who will send it to other possible performers for an alternative rendering of the project. Note! Only the solutions proposed by you, but competently formulated in the terms of reference, the customer will present your competitors as their own requirements! If you have written a technical task in sufficient detail, “sharpening” it for yourself and your own tricks, describing the ready-made developments in the form of a serious target functionality, the customer comes to your competitors not with a request “yes, you have to do nonsense”, but with a weighty technical task, which some simply scare, others will make a transcendental price. As a result, your chance to receive this order rises sharply.
Terms of reference allows you to avoid wasting precious time, and helps to adjust the budget. In the course of writing TK, quite obscure nuances often surface. Thinking through and calculating each item and each piece of functionality allows the customer himself to take a different look at the task. Perhaps the previous paragraph caused you indignation: "what a rogue, breeding customers." So, here I want to rehabilitate myself: I often unobtrusively try to force the customer to look at a particular issue from a different point of view: to abandon any elements and parts of the task if they have no meaning. This allows again - to save time, but the main thing - to save customer's money. Often the words "but it will be a little cheaper" play a key role in communication.
Technical specification is an advertisement. Probably, most freelancers will agree with me: - the best customers are either regular customers or customers that you have been recommended to. Competently composed and pleasantly designed technical assignment often remains with the customer even after the project has been completed, and he willingly shows it to those whom he recommends you with the aim of convincing the interlocutor of your seriousness and professionalism. Such customers are just a fairy tale. They are confident of your professionalism even before the start of negotiations, and you save time and (more importantly, time) your own emotional strength.
Terms of reference helps to keep the brand. This thesis could be attributed to the clause on marketing or advertising, but I want to consider it separately.
Imagine - you do not understand anything in matters (for example, site building) a person who has some kind of business, and you are not ready to spend a lot of time trying to enter into alien and uninteresting questions for you. You just need a website. Denoting the freelancer an abstract vision of the future site, you get a clear, detailed and pleasant technical task on a beautiful form (I almost said the company). In addition to everything else - the specialist who provides this technical task willingly and convincingly gives advice, communicates and generally - is fully open. I think the technology of communication in this issue plays a significant role.
Technical specification of the winner - how it should be
I think that all developers in the course of their professional development accumulate a certain toolkit, which further helps them to reduce development time (in rare cases, to improve the quality of the resulting products). Therefore, if you decide to work on the terms of reference, it should also have a certain template containing inalienable attributes (in addition to the direct description of the task).
- Date and Signature of the Parties
- Executive contact information
- Name (even if working) of the project or product
- Table of contents
- Goals and objectives of the project (if it is a project) or product (if it is a product)
- Technical nuances of implementation, strict and specific requirements for the platform on which the project or product should be implemented
- Deadlines
- Cost of
- Item on the alienation of rights to the final result of activities in favor of the customer (the item is rather rare in our country)
Conclusion
Of course, all of the above calls into question the term "technical task". Perhaps, it is worth using the terms “technical proposal”, “description”, “agreement” and so on ... but in any case - the meaning of the publication is completely different. I wish you a pleasant, profitable and productive work!
UPD : thanks to my partner Alexander Afanasyev, whom I consider to be the co-author of this article.
Source: https://habr.com/ru/post/109724/
All Articles