Favorite administrative rake of the Internet provider

The second series, you can start reading here.

A couple of weeks ago I was invited to read something useful in the developers section at the Digital Thaw conference in Nizhny Novgorod. There was very little time and I threw my favorite organizational rake on which 90% of the Internet companies I consulted jumped on. Of course, there is a chance that I was just lucky. But I have little faith in such a fateful luck in different cities and different scales.

As a result, I picked up some bundle, with which I propose to play Captain. Evidence.

Having valiantly reported, I sat down to talk with the guys pulling up from the hall, and during the course of the conversation I heard from one of them that my speech was about the fact that everything should be pulled into the contract . It was damn unexpected, it should be noted.

Well, that is, yes. Since almost all the problems that I spoke of were administrative, I proposed to solve them administratively. And this implies the addition of a model contract. The bottom line is that at some point I took over the paradigm of behavior “ALL that needs to be done - describe through the contract” so that I drive this moment through the conversation automatically, without being fixed on it at all.

It would seem that I have now adapted a big thesis AGAINST the automation of contractual work. I myself climb into the text with dirty hands.

And so, and not so.

Some of the charm of automation is that it allows you to turn practical techniques into a legally organized plane, without forcing the consumer to think "how to describe it in the right terms." Let's go over the rake that I especially love. And if such a booze had already gone, I would not have refused something more cunning; come to the comments.

1. Work before signing the contract.
This is a well-known nuance, about him even the last time they wrote me a comment "and start to work on horseradish before the contract." Commentary from a person is not from the industry, as is understandable. The story when the customer is ready to forward the prepayment immediately, but the contract with him is consistent for a long time, is very common. And very annoying surprises happen.

Solution: describe the contract period in the contract as the specifics of the contract and describe the situation when the agreements prior to signing and fixed in the contract are diverging. Ideally, it would be nice to also fix early agreements in non-contractual form, with memoranda, for example. The main point is that the signed agreement does not cancel any early agreements, as happens by default, but confirms their existence.

2. Sudden changes in TK.
As you know, TK is not only a technical task, it is also a point of view, and it can change. Recall my favorite postcard on the topic.



Accept the new paradigm - changes in TK are not a problem if they are paid for. As I liked to say during the period when we made many sites “this is not a problem, this is a budget”. Put requirements management in the estimate (and in general, learn to call TK a requirement, as adults), describe the formula, how much you will need to pay for a particular scale of changes, and some reasonable one should be laid down. And, in fact, no problem. To the question “why should we pay extra”, you poke your finger on the contract, and you will be happy or break the contract. And the latter is even greater happiness, if you look closely at the alignment.

The same goes for recycling.

3. Processing.
By laying down the refining agreement initially, you are depriving the situation of the suddenness of these refining. Namely, surprise is usually a stumbling block. Especially it shoots on trifles.

When suddenly there is a need to remake everything to hell, for some sudden reason, this is a big problem, and the customer is usually able to realize this. Well, because it's BIG. But the small garbage that was lost during the early planning, but which should be done, because without it garbage is obtained - it does not cause such an understanding. Well, there for half an hour. OK hour. And we already made three such ones that week, and there was no talk of money. Is it crap today?

The same technique - firstly, from the very beginning we lay 10% of the production budget for processing. They will definitely be, we are in the know. Only this must be done without silently raising the budget by 10%, and having described it separately and promise to return if they suddenly do not exist. We all understand that there are almost no chances for such a turn. And then write in the same place: suppose, for example, seven hours are laid in order for the eighth hour to begin, the next 10% must be paid in advance. No other way. And in the course of work, do not forget to WRITTEN inform about ongoing refining.

This approach provides dual predictability for the client. Firstly, he knows in advance that there are refineries, that they are paid and that they are counted in the units that you have written down. Secondly, at the time of invoicing, he already has experience in monitoring improvements and how money is spent on them, which means he has the opportunity to figure out in advance how the next installment will be spent (or not).

4. Dates flown by the fault of the client.
99% of customers underestimate how long they will prepare materials for you, how long it will take to discuss each iteration, and so on and so forth. As a result, the deadlines are shifted, and claims are still presented to the contractor.

A rational way is a full-fledged regulation of working with documents when you work with a customer. That is, sometimes the point about the fact that delays caused by the fault of the customer are added to the terms of the contract, rolls. But this is still subtle matter. But the regulation is something unconditional. Write down the rules. Moreover, prescribe them wisely. If you write that the customer MUST answer within 24 hours, then this will not only not work, but most likely will not subscribe. But the reasonable requirement is that the customer notifies you after receiving a request for material or approval, by what day and hour he will give an answer, usually finds understanding. Attached to this is a table on the standards for postponing deadlines, depending on the speed of receipt of answers, we get an excellent timing calculator,

These are 4 typical problems. There were five of them in the lecture, because the fifth was related to the acceptance of creativity. But this is a disaster that cannot be administratively resolved in a quality manner, and therefore is not included in the current text.

All 4 declared topics are quite easily algorithmized, which means they should be included in automation. I repeat my question: what other organizational problems with site building do you catch at home? Share it and after a while we will have an excellent Tricky Agreement.