RE: RE: done by 95% or "Journey from Moscow to Petersburg"
If you argue with an idiot, it is possible that at this time he does the same. (WITH)
Recently I read two posts: this and this . They describe the conflict between the developer, who has spent time on the implementation of 95% of the task, and the employer who does not want to pay for an incomplete result.
Some time ago I got into a similar situation (on the side of the employee) and I succeeded in successfully resolving it, and in such a way that everyone was satisfied: both the employer and me.
')
=============
No, I in no way want to call the idiots of the authors or commentators of these posts. This refers to the stubborn unwillingness to give in to the interlocutor, even to the detriment of himself.
But before talking about solving my problem, I would like to draw attention to several issues related more to psychology than software development.
I will not explain why this happens. I propose to take it as an axiom. If anyone is interested, I recommend reading this book .
Now let's try to apply this to software development.
The problem lies in the late response to a situation where time (for the customer == money, for the contractor == work) is already lost and it is impossible to return it. In this case, each side tries to force the other side to incur the costs incurred (the customer tries to get the contractor to do the rest of the work for free, and the contractor tries to force the customer to pay for work that did not bring benefits to the customer).
Moreover, in most cases, it is not clear who is to blame for the loss of time: either the cause of external causes, or both: the employer and the performer were able to prevent the loss of time, but chose not to do so, hoping that they would be able to shift the responsibility on the opposite side. (Agree, in the case when the obvious fault of one of the participants is visible, no disputes will arise.)
If you try to apply the rules that we wrote above, it will become clear that a direct struggle will not lead to anything: both sides will be the losers (one of the parties will lose money (or work if it comes to the performer) + both sides will lose time and nerves spent on the dispute). Neither side can win by transferring the conflict to an “adequate dispute”, because both sides are in the same position (see above) and they will not be able to bring logical arguments that prove their case.
The only way out is to prevent this irrecoverable loss (for an employer this is the time spent on tasks he does not need, for the contractor this is unpaid time).
Predefined TK reduces time loss. TK gives a complete list of tasks necessary for the employer (guarantee that the work of the contractor benefits the customer + guarantee that the employer is ready to pay for these tasks). Unfortunately, it is very difficult to make a TZ in advance, because you need to provide a lot of details. In addition, sometimes it is simply impossible to make up the TOR in advance, because tasks change during the development process (let's not fool ourselves: only very small tasks do not change).
Output: you need to constantly monitor the development process, maintain a good "feedback" (from the customer to the performer). This will allow you to quickly and adequately respond to the situation and will allow both parties to immediately notice when time is wasted.
Adequately respond to the situation - admit your mistakes (and correct them), fairly and convincingly point out the interlocutor's mistakes, take into account other people's problems and try to resolve them together in the best possible way for both parties .
Actually, the description of my situation:
For a long time I worked for a fixed salary (remote work, labor costs were calculated based on the fact that I work 2 hours a day). There was no strict control of the tasks. Could freely change his work plan in order to perform the most important tasks for the office. Often engaged in non-core work: server administration, implementation, technical user support.
When the crisis began, the director personally wanted to control each developer (the benefit of the developers is small, because the main activity of the office is not related to software development). Every month a work plan was drawn up and a rule appeared: the salary was not paid until 100% of the tasks had been done.
At first, the mode of operation remained old; regularly, some of the work remained unfulfilled and this led to a great conflict between the director and the programmers. At the end of the month the director said: “finish the tasks and get the money”. Programmers said: "we will not work until we get paid."
What took time, it was difficult to determine.
Option 1: for small tasks not considered in the plan.
Option 2: the programmer poorly organized his work and spent some time wasted (for example, read the forums).
It is almost impossible to track down how much each of these reasons influenced the situation.
I came out of this situation as follows:
At the moment, everyone is happy: the director is satisfied that 100% of the tasks are being completed on time, and I am pleased that I am doing interesting work in the standard mode and get earned money without problems.
I'll try to summarize
The conflict between the employer and the executor arose not because one of them was bad / dishonest / unfair / idiot (underline the necessary), but because both could not organize the development process correctly (or did not want to strain).
Each of them could do it.
Well ... if you want something to be done - do it yourself.
Thank you all for your attention. If someone has questions - I will be glad to answer them.
Recently I read two posts: this and this . They describe the conflict between the developer, who has spent time on the implementation of 95% of the task, and the employer who does not want to pay for an incomplete result.
Some time ago I got into a similar situation (on the side of the employee) and I succeeded in successfully resolving it, and in such a way that everyone was satisfied: both the employer and me.
')
=============
No, I in no way want to call the idiots of the authors or commentators of these posts. This refers to the stubborn unwillingness to give in to the interlocutor, even to the detriment of himself.
But before talking about solving my problem, I would like to draw attention to several issues related more to psychology than software development.
- Everyone loves when they agree with him and begins to oppose when they disagree with him.
- If it is necessary for a person to do something, it is necessary for him to do it consciously and of his own will .
- In order to win the dispute, in no case can one contradict a person. We must try to bring the conversation to the level of discussion of logical and reasoned statements.
I will not explain why this happens. I propose to take it as an axiom. If anyone is interested, I recommend reading this book .
Now let's try to apply this to software development.
The problem lies in the late response to a situation where time (for the customer == money, for the contractor == work) is already lost and it is impossible to return it. In this case, each side tries to force the other side to incur the costs incurred (the customer tries to get the contractor to do the rest of the work for free, and the contractor tries to force the customer to pay for work that did not bring benefits to the customer).
Moreover, in most cases, it is not clear who is to blame for the loss of time: either the cause of external causes, or both: the employer and the performer were able to prevent the loss of time, but chose not to do so, hoping that they would be able to shift the responsibility on the opposite side. (Agree, in the case when the obvious fault of one of the participants is visible, no disputes will arise.)
If you try to apply the rules that we wrote above, it will become clear that a direct struggle will not lead to anything: both sides will be the losers (one of the parties will lose money (or work if it comes to the performer) + both sides will lose time and nerves spent on the dispute). Neither side can win by transferring the conflict to an “adequate dispute”, because both sides are in the same position (see above) and they will not be able to bring logical arguments that prove their case.
The only way out is to prevent this irrecoverable loss (for an employer this is the time spent on tasks he does not need, for the contractor this is unpaid time).
Predefined TK reduces time loss. TK gives a complete list of tasks necessary for the employer (guarantee that the work of the contractor benefits the customer + guarantee that the employer is ready to pay for these tasks). Unfortunately, it is very difficult to make a TZ in advance, because you need to provide a lot of details. In addition, sometimes it is simply impossible to make up the TOR in advance, because tasks change during the development process (let's not fool ourselves: only very small tasks do not change).
Output: you need to constantly monitor the development process, maintain a good "feedback" (from the customer to the performer). This will allow you to quickly and adequately respond to the situation and will allow both parties to immediately notice when time is wasted.
Adequately respond to the situation - admit your mistakes (and correct them), fairly and convincingly point out the interlocutor's mistakes, take into account other people's problems and try to resolve them together in the best possible way for both parties .
Actually, the description of my situation:
For a long time I worked for a fixed salary (remote work, labor costs were calculated based on the fact that I work 2 hours a day). There was no strict control of the tasks. Could freely change his work plan in order to perform the most important tasks for the office. Often engaged in non-core work: server administration, implementation, technical user support.
When the crisis began, the director personally wanted to control each developer (the benefit of the developers is small, because the main activity of the office is not related to software development). Every month a work plan was drawn up and a rule appeared: the salary was not paid until 100% of the tasks had been done.
At first, the mode of operation remained old; regularly, some of the work remained unfulfilled and this led to a great conflict between the director and the programmers. At the end of the month the director said: “finish the tasks and get the money”. Programmers said: "we will not work until we get paid."
What took time, it was difficult to determine.
Option 1: for small tasks not considered in the plan.
Option 2: the programmer poorly organized his work and spent some time wasted (for example, read the forums).
It is almost impossible to track down how much each of these reasons influenced the situation.
I came out of this situation as follows:
- I discussed the current work plan with the director: what tasks were completed, what tasks remained to be done and in what volume (by the way, this discussion took 3.5 hours, but it went quite calmly, despite previous talks on high tones). I promised to finish these tasks free of charge next month, after which the salary for the current month was paid without any problems.
- I compiled a VERY detailed description of how I am going to carry out the tasks (up to what I described, what actions take place when you press each button) and sent it to the director for approval. In essence, this is the same TK. It is quite natural that the director himself will not write it. It is also natural that he does not understand the point of paying for writing TK $ 800 to an individual. The TK I compiled did not meet the design standards, but, most importantly, it reflected the list of tasks. I spent very little time on it (about 2 hours)
- All tasks before appointment to me passed through the director. So he was able to control the tasks performed by me, and I was able to protect myself from secondary and unnecessary tasks (i.e. from those that would lead to loss of time)
- With the arising unplanned tasks, we did the following:
a) if the task is non-core, I refused to complete it (quite naturally: my time is limited + the task is not what I can do well). Usually, the director agreed to entrust it to someone else without any problems.
b) if the task still cannot be completed without my participation, then a change to the previously approved work plan is agreed upon (the least important tasks are determined, having the same amount in total and are transferred to the next month).
c) if it is impossible to throw out the necessary number of tasks from the plan, then the after-hour time is paid in double amount (as well as the extra-hour work must be paid). After-hours work was paid by the hour upon accomplishment with the condition of providing a very detailed report on how much and what time was spent (with details up to 30 minutes). - I made a rule for myself: notify the director as early as possible. “About everything” - basically, it’s about the accomplishment of tasks, as well as about changing the expected deadlines for completing the tasks (both up and down, indicating the reason).
At the moment, everyone is happy: the director is satisfied that 100% of the tasks are being completed on time, and I am pleased that I am doing interesting work in the standard mode and get earned money without problems.
I'll try to summarize
The conflict between the employer and the executor arose not because one of them was bad / dishonest / unfair / idiot (underline the necessary), but because both could not organize the development process correctly (or did not want to strain).
Each of them could do it.
Well ... if you want something to be done - do it yourself.
Thank you all for your attention. If someone has questions - I will be glad to answer them.
Source: https://habr.com/ru/post/66342/
All Articles