Favorite administrative rake Internet

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 in my favorite organizational rakes, which 90% of the Internet companies that I had to advise. Of course, there is a chance that I was just lucky. But I have little faith in such fatal luck for different cities and different scales.
')
As a result, I picked up some pack, with which I propose to play Captain Obvious

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

Well, that is, yes. Since almost all the problems that I mentioned were administrative, then I proposed solving them administratively. This implies the addition of a model contract. The bottom line is that at some point I took upon myself the behavior paradigm of “EVERYTHING that needs to be done - describe it through a contract”, that I drive this moment through a conversation with an automatic machine, not fixing on it at all.

It would seem that I have now adjusted the big thesis against the automation of contractual work. I myself am a dirty little hand climb in the text.

And so, and not so.

Some of the beauty of automation is that it allows practical techniques to be turned into a legally organized plane, without forcing the consumer to think "how to describe it in the correct terms." Let's go over the rakes that I especially love. And, if such a booze has 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 I wrote comments "and the fuck start working before the contract." Comments from a person not from the industry, as is clear. The story, when the customer is ready to send the prepayment immediately, but the agreement with him is consistent for a long time, is very common. And there are very annoying surprises.

Solution: to describe the contract period in the contract as the specifics of the contract and to describe the situation when the agreements prior to signing and fixed in the contract diverge. Ideally, it would be a good idea to also fix the earlier agreements in a non-contractual form, memorandums, for example. The main point is that the signed agreement does not cancel any earlier agreements, as happens by default, but confirm their existence.

2. Sudden changes in TK.
As you know, TK is not only a technical project, it is also a Point of View, and it can change. We remember my favorite postcard on the topic.



Accept the new paradigm - changes in TK are not a problem if they are paid. As I used to say at a time when we were doing a lot of sites “this is not a problem, this is a budget”. Pledge requirements management (and generally, learn to call TK a requirement, like adults), describe the formula for how much you will have to pay extra for one or another scale of changes, with some reasonable initial one. And, in fact, no problem. To the question “why should we pay extra”, you put your finger in the contract, and you will be happy or break the contract. And the last - even more happiness, if you look at the alignment.

The same applies to recycling.

3. Recycling.
Laying in the contract of processing initially, you deprive the situation of the suddenness of these processing. Namely, suddenness is usually a stumbling block. Especially it shoots on the little things.

When suddenly there is a need to redo everything, for some sudden reason, this is a big problem, and the customer is usually able to realize it. Well, because it is GREAT. But the small garbage that was lost during early planning, but which should be done, because without it, garbage turns out - it does not cause such an understanding. Well, there is work for half an hour. Ok hour And we had already done three of them that week, and there was no talk of money. Are you shit today?

The same method - first, from the very beginning we are laying 10% of the production budget for processing. They will definitely be, we know. Only this should be done without silently raising the budget by 10%, but by describing it separately and promising to return it if suddenly they are not. We all understand that there is almost no chance of such a turn. And then to write there: it’s supposed to be seven hours, so that the eighth hour starts, you must prepay the next 10%. No other way. And in the course of work do not forget to write about ongoing processing.

This approach provides double predictability for the client. Firstly, he knows in advance that there are reprocessing, that they are paid and that they are considered in those units that you have recorded. Secondly, at the time of invoicing, he already has experience of observing the modifications and how the money is spent on them, which means that he has the opportunity to estimate in advance how the next installment will be spent (or not).

4. Terms flying due to the fault of the client.
99% of clients 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 dates are shifted, and claims are still presented to the performer.

A rational way is a full-fledged rules for working with documents when you work with a customer. That is, sometimes the point about the fact that delays caused by the customer’s fault are added to the terms of the contract rolls. But it is still a subtle matter. But the rules - the unconditional thing. Write the rules. Moreover, prescribe them reasonably. If you write that the customer MUST respond within 24 hours, then this will not only not work, but most likely will not sign. But the reasonable requirement that the customer notifies you after receiving a request for material or approval, by what day and time he will give an answer, usually finds understanding. Attached to this table is about the standards of postponement, depending on the speed of response, we get an excellent time calculator, which is easy to use and to which it is easy to appeal.

These are the 4 typical problems. There were five of them in the lecture, because the fifth one was connected with the acceptance of creativity. But this is a misfortune that is impossible to qualitatively resolve administratively, therefore, in today's text is not included.

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