Do not step on our rake with TK: an epic contest experience and a couple of tales

A well-known example of an inaccurately supplied TK.

In general, my colleagues and I have compiled a selection of epic cases with TK, which, perhaps, will help someone not to repeat our mistakes. Well, or amuse.

Once I got a project designed for one and a half years with a sooo difficult customer. Status: half a year has passed, but the technical specifications are still being agreed. Subscribed to one, but the customer stubbornly continued to put forward new requirements. The task was not even to finish on time or earn money, but to leave with dignity, with minimal losses for all.
')
It was difficult - not the word. In a long flight, I read the TK of 20 pages. It had such a feature: if you read it fluently, it may seem that it is written correctly and accurately. But if you start digging into the details of the engineering implementation, then a lot of unexpected ones pop up at once. Some of the requirements of the subparagraphs, such as 3.2.5 and 4.8.2.9, could contradict each other or simply be mutually impossible in the real world.

Why is it impossible to reconcile TK right away?

It is not a secret that at tenders and tenders it is extremely rare to have a sufficiently complete technical task (or at least detailed acceptance criteria, or simply distinct technical requirements). Any vague item of documentation can provide you with an incredible amount of surprises and an increase in work by an order of magnitude. Here are just a couple of examples from real documents, according to which it was necessary to somehow estimate the amount of work and subscribe:

• "The system must have an intuitive graphical user interface," translated into Russian, it most likely means something like: "In addition to the console, you need a GUI in Russian and with a lot of explanations, because the secretary will manage the complex." Probably. Because it may turn out that the customer has his own ideas about intuition, and he will insist on them. But most often this phrase is typical for documentation and, in general, not very dangerous.
  
  
• “The system should provide a simple and flexible setting of access rights for the system user,” this is already an order of magnitude worse. It does not describe what the rights are, and the difference in the details of the network roles can affect the architecture. And, accordingly, on the equipment that is needed in the project.
  
  
• Once met after a detailed description of the workflow system is: "The retention period should be customized by period," - try to guess what the customer had in mind. You are interested to begin with, what kind of information we are talking about and where it will be stored. With equal success, this may turn out to be a common phrase that an archive of records should be available (which is very simple), and that it should be backed up to a separate site.

Most often, alas, before submitting an application for a contest to assess such pitfalls is simply impossible. In the “bad” case, the average fork of possible deviations from our version of the reading is estimated, and approximately this amount of work is laid. You can not write to the maximum: then in any competition it is impossible to win. On the other hand, if the customer is well-known, or if it is clear that they already have and what are the requirements in general, you can roughly estimate the features of the project.

Ecological balance

Naturally, it is quite difficult to completely register a technical project without special (and very deep) knowledge of the question. The customer, as a rule, does not always have such knowledge. Therefore, the contractor always knows that the terms of reference will be supplemented on the fly, and the customer will know that the contractor will not understand him. The less the degree of additions to TK and misunderstanding - the more adequate the parties. But, I repeat, misunderstanding almost always happens on large projects.

What happens next? Then comes the interesting ecological balance.

In bad case:

• If, seeing a huge TZ suddenly appeared, the contractor refuses the contract of the state customer on his own initiative, he can be added to the “black list” of suppliers.
• The customer will not receive the result, but will already spend the money.

In the usual case, when “exactly according to the TK” the project clearly does not work:

• The contractor needs a contract for the portfolio, for further work with this customer or simply because you need to do work (for reputation). In this case, he is ready to put up with some modifications, but he is waiting for concessions and compromises from the other side.
  
  
• The customer understands that if he is done exactly according to the TK, surprises can begin in the opposite direction, and he, again, will lose time and money and get a non-working solution, which he himself has described more or less accurately.

In the end, everyone understands everything and agrees. Of course, there are individual projects where a large customer can literally drive an integrator with his TK. Only he understands very well that if he does this, this integrator will not come to him in contests anymore. And in many jobs in the country there are only 2-3 companies that in general can pull this, purely in complexity and scope of the project. Staying at one-on-one with the last one is scary, the executor will dictate the terms already.

For example, here is the project. There was a line in the statement of work: “The system should be put on monitoring.” This resulted in a separate project: it was impossible to either estimate the labor costs or plan. And the customer saw everything differently. He has an internal regulation, historically established. Then begin the so-called "graters". On the one hand: “We will do for you according to the TZ”, on the other - “We will not accept that.” It is clear that both sides are right to one degree or another, and they don’t want to bring the matter to conflict: on the one hand, I repeat, the court and “get what you want”, on the other - wasted money and time. Nobody just needs this.

As a result, in other parts of the TZ we made concessions, and we understood what the customer’s requirements are. For the following projects we are already a proven supplier, and we have an exact base for calculations, without forks.

What if absolutely bad

Last year I got a project in a state of epic fail. We were warned that the customer, to put it mildly, is very strange. Exact TZ was described after the start of work for several months. In general, to say that it is difficult to say nothing. In each line of the compiled TZ - questions. The task is to complete the project with minimizing losses.

At first I broke the TOR into several documents. The fact is that they coordinated it with the whole team of managers, because they were afraid of responsibility. And each time they found something new. The document, divided into parts, was coordinated in divisions, and the matter finally went. They began to understand not "what you wrote," but "what you want." And further: “what you want is impossible and unnecessary, let's better like this” - slowly managed to come first to the realizable requirements, and then to a compromise.

Somewhere it was decided quickly, somewhere it was suggested to take it according to their TZ and to watch what would happen. The customer saw that the work was really going, agreed that it was right, and did not press until everything moved. In general, taxied out.

Personal meetings and trips

Another fun thing is if the customer wants to meet for every sneeze. It is especially nice when it is the oil industry from the Far East. In one project there was a tradition - every little thing was discussed once a week at a meeting. There were 12 people from the company, 5 people from the manufacturer of iron and three of us. And safety. In the end, they could also be beaten apart and transferred to a telephone conference. On the phone, the men did not see each other, they did not rejoice on Friday, and therefore the meetings went 3 times faster.

On the other hand, in order to understand a person better, you need to meet at the beginning, then you can communicate remotely by mail. This has already been tested on many projects.

Again, personal meetings are needed to solve complex issues. Any serious decision or stage - to meet. By phone does not work.

Iron

Once participated in the competition for work and equipment supply, did not win. But the winning company still hired us to work for subcontracting: there were simply no specialists in the country anymore, the topic is very specific. Well, we are not proud, we will only do the work. Two weeks before delivery, it turns out that the general contractor ordered the wrong iron. More precisely, that, but not in that configuration. We knew what comments to write to the order and what specific magic words to say to the supplier. And here, roughly speaking, one letter in the model is mixed up. In Russia, such iron simply does not physically exist. Before delivery - 2 weeks.

We asked the vendor to replace these boards. And as for the vendor, this project was prestigious, after all, the first installation of such hardware. We found new boards, a special plane, and a special person, and, voila, they came to us even 2 days earlier.

But, really, for two weeks I had to drink valerian and live in two time zones at once. During the day at the facility to control, “drag”, rescue and “snatch”, and at night - on the mail and the phone with colleagues from the states think how to bring the much needed hardware for us.

Work with foreigners

It is also "fun" to work with foreign contractors and customers. After that, you start to love domestic employees. In Russia, maybe, there is no development methodology, more precisely, an ordinary waterfall: there is a task, documentation and phases to it. Almost everyone knows what a technical project is, let it be somewhere better, somewhere worse. And foreigners often often ignore many stages. Even the concept of TK is not - there is a statement of work or technical requirements.

We are responsible for hardware, foreign colleagues for software. We offer them: let's write out clearly what is part of the work, where the area of ​​responsibility is, we will do a normal TZ: what we are doing, what the result is, in order to later test it and pass it regularly. They: “Yes, why is this necessary? There is also a description of the works! ”- and there is a two-page document in the spirit:“ Our professional engineer will come and do everything, do not worry. ” And they also added: “We have a description of the system on the site - this is it”. They signed as a result without a detailed TZ. Implemented as is. They actually signed the system and finished it only after 2 years (two generations of the system changed), and a part of the functionality was specially developed for this customer.

And the problem was that they had everything sharpened for America, and Europe has its own internal standards for data processing. And they did not meet them. The customer, of course, did not accept the standard system. Around this moment, colleagues acutely realized why they needed an exact TK. More precisely, they need it, not the customer.

It is very difficult to get from them the details of the work. They can pull for weeks, telling what is included in their service. Sometimes one gets the feeling that the task there is for the manager to sell 100 kilograms of service to each contract, so he writes without details. Then, of course, all this is discarded, but the nerves on the road spoil a lot.

Subcontracting was still funny. They love to make such a feint with their ears: they say, the main work is done, let's sign and close, the rest will be completed quickly there and then. Mostly works. And we as a general contractor to them: “No!” And why close when not everything works? As a result, it turns out that Russians are harmful. Because the foreigners then the quarter ends and the bonus must pay, then something else. We - them: "We do not mind you." And yes, it turns out that they can’t decide for months on these minor additions.

Altruism and courage

Another feature, perhaps, of purely Russian projects is “Chip and Dale rush to the rescue.” Rarely, but there are epochal things, for example, the iron fails directly to surrender. But altruism and courage make us invincible. Where a foreign contractor would give up and start a standard replacement through a vendor, we can raise everyone’s ears, and on the threshold of their general will appear somewhere in Sweden, or even worse - with a soldering iron, get into a piece of iron and fix it. Of course, it does not help, but in general it works. True, an extra screw always remains.

Customer regulations

The most surprises begin after the phrase: "The work must be completed or agreed in accordance with the regulations of the customer":

• Regulations may not be attached to the documentation of the competition. Search for yourself.
• The rules may change: for example, if these are requirements for an engineer of stadiums according to a European standard, it may turn out that by the end of the work the Europeans have accepted new requirements.
  
  
• There was a security service in one financial institution, which even the regulations did not show. Just came bezopasnik and said: "This is impossible. Why - I will not say. " And left.
  
  
• There are internal requirements such as: “Living in Moscow for at least 10 years” or “Not involving foreign citizens in the work”.
  
  
• In banks, there is often a whole regulation on the basis of documents of the Bank of Russia, which may not be indicated as requirements in the competition - for them this is a matter of course. It comes to the contract and implementation - this thing appears with the words: "And here are the requirements for the system." And there is a division of rights, administration, personnel requirements for certificates.
  
  
• Sometimes there are “forgotten” requirements for backups, training at least 10 specialists and so on, all this must be asked every time.

Often there are their own standards for documentation. This is also an incredible hit: there was a project when the description took longer than the work itself. On the other hand, if the customer forgets about the documentation, we must remind him, otherwise they will not be able to support later. Yes, and we, most likely, and support, so the documentation is definitely needed.

But often the situation is worse: the composition of the documentation is not indicated, the customer refers to GOST. And there, for example, there are three testing periods - business-like, trial operation, final commissioning. For some customers, for some reason, the final delivery is up to trial operation, for example.

Sometimes it happens that the customer simply makes a mistake in the TK. We bring equipment, but there is no place to put it, there is simply no place. What to do? Again seek a compromise.

Acceptance plan

Most importantly - do not be lazy and make at least a simple plan for acceptance. The test method is not an extra thing. Write worth it. On acceptance, the customer often understands that he hasn’t yet tested something and suggests changing the testing program. It is better to foresee everything at once. It removes a lot of conflicts and helps a lot in banks.

About ten years ago it was, for example, like this. Our engineers handed over the system, documentation - miserable, no requirements. The Far East, ours: “Sign the acts, and we will go.” The customer got meticulous, but adequate. He says: “You will sit down in a helicopter now, but I will stay here alone with this one. Let's really check. " Well, on the move, they invented a testing methodology, showed what worked and how. Signed. I almost stayed to stay for an extra week.

Or there was a case, they handed over the system. All signed, all happy. And here it turns out that the security guards do not want to use as IT specialists wrote the requirements. Where they were when the project was written is not clear. We met, helped over the requirements, found an option that suits everyone. On the same day, we compromised on another difficult area. This is how it works.

Generally

In general, the situation is changing: over the past 8 years, customers have matured a lot, they have become more serious about business. Previously, there was no paper at all, even the layout scheme often could not be conveyed. Now everything is written. We, too, picked up the rake, began to insist that the project had the necessary documentation, this is our defense too. The goal is for everyone to understand.

Customers in key positions had people from integrators who saw the process from the other side. The market has grown, due to this culture has risen. Western experts came, also well aware of what and why.

But I must say, if we had proposed 10 years ago how to work today, no customer would have listened to us. Culture was not useless. I remember it was even so in those dark years: the acceptance program was signed. It got to the point, the customer says: "It must be otherwise." We: "Here is the document signed by you." He: "Yes, throw it out, we need it differently!"