November 21, 2013 at 01:49The story of one failure
We have a lot of letters written on a paper fence on how to manage projects. As many, if not more, scribbles are devoted to what success stories came out of this. Nauseous, uninteresting, sickened. Consider the story of one failure, it is always more interesting and attractive (apparently, because of the nature of humanity, gloating more than rejoicing). Let's get started.
Private project. Not simple, but not particularly difficult. In order not to go into the jungle of fingering, let's call it project 1. With company A. Which is the executor of one important task of company B. Very large, and even specific in its products, and as a result, very loving to bring a big bag of joy for its big money in the form of improvements and approvals on the head of those who worked with her. And there is a representative of company A named B, and there is his boss G. Tumana was let in, sadness was instilled into the reader’s heads, you can move on.
Well what to say. Quite an interesting stage, interesting in that in the open spaces the outsourcing is mediocre in the classical sense. TK is some kind of mishmash of letters on some third-party resource that provides something of a kind of flip chat of galactic proportions, which can be scrolled to infinity, wandering around the intricacies of arrows, dependencies and signatures. A pile of documents drawn up for some reason in the form of presentations and Excel files, but oh well, we're not used to it.
Quickly acquainted with this menagerie, I go to the office of company A to talk with B about what they really want. In about 4 hours, a set of sketches of the interface, the logic of the program’s work is formed, and there is an understanding that a mishmash of multiplications, subtractions, divisions and other brackets in Excel claims to be a business process calculation. And even there is an understanding of how to do this. Agreements are reached on the implementation, timing, payment - in battle. After some time, the program appears.
A simple project is gradually beginning to be supplemented by autumnism. Osenism is a requirement that appears at the customer’s work on the program. As a rule, this is a given. I have not yet seen a single project out of more than 120 projects for the development of web, desktop, embedded systems and code for microcontrollers, in which it would clearly correspond to the original ToR. If you believe in the advance of the Martians and in three elephants on three pillars - then please, you can also blindly believe in a fixed TK. But, as a rule, nuances, ideas come up during work, and I just “forgot it” - at least I got used to it. But at one of the stages of the iteration of the finishing touches, I began to understand that they are increasingly affecting business logic, and I began to actively curtail this process. Business logic is the cornerstone of software, and if not, then this is a problem akin to a meteorite falling in comparison with the spilled kefir, which is "oh little button here." We agree on the second stage.
At this stage, B offers, and I agree that B, being a programmer who wrote software for company A and then transferred to the state, will write new business logic in a programming language. On which - it’s not important, it’s important - different from mine. And this, in fact, doesn’t matter if it’s just not a brainfac - the languages are about the same, and if there is documented code, it’s quite simple to figure out what the program does, the essence of which is to calculate user actions. As it turned out, it seemed to me that way, excuse my pun. I will not judge the manner of software development. Everything happens, I saw different things. I personally read during reverse engineering of the firmware of the control unit of one very large automaker comments that made me laugh, and some of the solutions used in this software were horrifying. And nothing - apparently in production (since I read it), and drives millions of cars sold. Another thing is important. Debug code rewritten by the rules took 4 times more time than planned. There was even an seditious idea to copy-paste the code and make a converter from the data structure into that set of variables, and, based on the results of code development, convert it back.
Let me go back to the beginning. Company A makes a product for B. A very large B. To which they go periodically to show an intermediate result. Why - it’s not clear. For after each meeting I get a bunch of requirements for visual design and the logic of user interaction. With the introduction of new logic in code that has not yet been worked out. With even more reduced deadlines after each meeting. The flow of deterministic chaos is growing.
As a result, employee B is removed by head G from work, and G takes matters into his own hands. Also a moot point. I got the business logic as as is code. At the reconciliation during the transfer there were a lot of round eyes - I learned from the fact that I was not given the banal requirements for software, which were and, most importantly, were not "super_top_secret." G - when he delved into the meaning of business logic, which was complicated by several orders of magnitude from what was required.
Bida, longing and grief.
I am a wonderful programmer. I rent everything on time. Is always. I do not make mistakes. I am writing perfect code. All customers are cattle and oligophrenics, not understanding how lucky they are.
It seems to have forgotten nothing. So it would be necessary to end this story. If I wanted to cry in a vest. But remember the beginning of the article? Let's take an example of a fakap, and not a success story, to analyze what should have been done. We are all strong in hindsight, so the banal “it was necessary to write down all the requirements in the statement of work, sign the contract and sit on the ass exactly after the completion of the statement of work” I will not write. This mistake is obvious as God's day, and it is difficult to call it a mistake - remember the Martians and elephants.
Lack of arrival before the start of the second stage. Remember - at the first I arrived and we talked about work. On the second, I did not do this, being sure that it was the same, only in profile. As a result - I got a lot of improvements "move this, but add it here."
Consent to a code instead of a text job. One of the key mistakes, even worse than the first. Oh, this glorious "I once ....". Everyone has this "once upon a time." I also used to repair cars. Even had my own service. And this does not help me weakly, when they start to carry frank nonsense at the service station. But the property of our memory is such that we remember the good, and the bad is erased. Yes, I threw cars because I gave all the time to work, and just burned out. It became sick. But do I remember the feeling when I was sick? Nope. This is just a beech set. Fact. Naked. And that’s all. But Bukhalovo in the evenings in the company of guys, pokatushki, interesting tuning projects, funny cases - I write and a smile on my face, I swear. Five more years will pass, and maybe I will again get involved in cars. How to know?
“Once upon a time” is very closely connected with pleasant memories. And therefore - it seems simple, funny, interesting. And when the model that you promised to transfer to work suddenly doesn’t work, when reality pokes your nose at the fact that the code needs to be debited (which, by the way, was discovered after vulnerability in the boundary conditions) - then yes, such as a job and not a priority. And there is no joy. No. Therefore, the logic was sent to me 6 times late from what was declared.
And I am a lop-eared fool. Well-versed in what “I once coded”. He knows perfectly well that this is the most terrible customer. But, nevertheless, behaved once again.
Consent to revision. Or rather, the lack of their control. When working, I try to perform no more than 10% of the alterations from the original task before an intermediate or final delivery. Here the score was lost, by me.
Consent to cut deadlines. "Planning-designing-writing-testing." There are no miracles. If the terms from the declared are cut in 2 times, then this leads to their increase in 2 times. Since something will be omitted in any case, and will only lead to an increase in the resulting period (and not the period when it reports “readiness”).
That's all for today. I hope the experience will be useful to comrades. Goodnight.
In the beginning there was a desire
Private project. Not simple, but not particularly difficult. In order not to go into the jungle of fingering, let's call it project 1. With company A. Which is the executor of one important task of company B. Very large, and even specific in its products, and as a result, very loving to bring a big bag of joy for its big money in the form of improvements and approvals on the head of those who worked with her. And there is a representative of company A named B, and there is his boss G. Tumana was let in, sadness was instilled into the reader’s heads, you can move on.
Stage 1
Well what to say. Quite an interesting stage, interesting in that in the open spaces the outsourcing is mediocre in the classical sense. TK is some kind of mishmash of letters on some third-party resource that provides something of a kind of flip chat of galactic proportions, which can be scrolled to infinity, wandering around the intricacies of arrows, dependencies and signatures. A pile of documents drawn up for some reason in the form of presentations and Excel files, but oh well, we're not used to it.
Quickly acquainted with this menagerie, I go to the office of company A to talk with B about what they really want. In about 4 hours, a set of sketches of the interface, the logic of the program’s work is formed, and there is an understanding that a mishmash of multiplications, subtractions, divisions and other brackets in Excel claims to be a business process calculation. And even there is an understanding of how to do this. Agreements are reached on the implementation, timing, payment - in battle. After some time, the program appears.
Off-season
A simple project is gradually beginning to be supplemented by autumnism. Osenism is a requirement that appears at the customer’s work on the program. As a rule, this is a given. I have not yet seen a single project out of more than 120 projects for the development of web, desktop, embedded systems and code for microcontrollers, in which it would clearly correspond to the original ToR. If you believe in the advance of the Martians and in three elephants on three pillars - then please, you can also blindly believe in a fixed TK. But, as a rule, nuances, ideas come up during work, and I just “forgot it” - at least I got used to it. But at one of the stages of the iteration of the finishing touches, I began to understand that they are increasingly affecting business logic, and I began to actively curtail this process. Business logic is the cornerstone of software, and if not, then this is a problem akin to a meteorite falling in comparison with the spilled kefir, which is "oh little button here." We agree on the second stage.
Stage 2. The path to collapse
At this stage, B offers, and I agree that B, being a programmer who wrote software for company A and then transferred to the state, will write new business logic in a programming language. On which - it’s not important, it’s important - different from mine. And this, in fact, doesn’t matter if it’s just not a brainfac - the languages are about the same, and if there is documented code, it’s quite simple to figure out what the program does, the essence of which is to calculate user actions. As it turned out, it seemed to me that way, excuse my pun. I will not judge the manner of software development. Everything happens, I saw different things. I personally read during reverse engineering of the firmware of the control unit of one very large automaker comments that made me laugh, and some of the solutions used in this software were horrifying. And nothing - apparently in production (since I read it), and drives millions of cars sold. Another thing is important. Debug code rewritten by the rules took 4 times more time than planned. There was even an seditious idea to copy-paste the code and make a converter from the data structure into that set of variables, and, based on the results of code development, convert it back.
Let me go back to the beginning. Company A makes a product for B. A very large B. To which they go periodically to show an intermediate result. Why - it’s not clear. For after each meeting I get a bunch of requirements for visual design and the logic of user interaction. With the introduction of new logic in code that has not yet been worked out. With even more reduced deadlines after each meeting. The flow of deterministic chaos is growing.
As a result, employee B is removed by head G from work, and G takes matters into his own hands. Also a moot point. I got the business logic as as is code. At the reconciliation during the transfer there were a lot of round eyes - I learned from the fact that I was not given the banal requirements for software, which were and, most importantly, were not "super_top_secret." G - when he delved into the meaning of business logic, which was complicated by several orders of magnitude from what was required.
Bida, longing and grief.
Total?
I am a wonderful programmer. I rent everything on time. Is always. I do not make mistakes. I am writing perfect code. All customers are cattle and oligophrenics, not understanding how lucky they are.
It seems to have forgotten nothing. So it would be necessary to end this story. If I wanted to cry in a vest. But remember the beginning of the article? Let's take an example of a fakap, and not a success story, to analyze what should have been done. We are all strong in hindsight, so the banal “it was necessary to write down all the requirements in the statement of work, sign the contract and sit on the ass exactly after the completion of the statement of work” I will not write. This mistake is obvious as God's day, and it is difficult to call it a mistake - remember the Martians and elephants.
Mistakes
Lack of arrival before the start of the second stage. Remember - at the first I arrived and we talked about work. On the second, I did not do this, being sure that it was the same, only in profile. As a result - I got a lot of improvements "move this, but add it here."
Consent to a code instead of a text job. One of the key mistakes, even worse than the first. Oh, this glorious "I once ....". Everyone has this "once upon a time." I also used to repair cars. Even had my own service. And this does not help me weakly, when they start to carry frank nonsense at the service station. But the property of our memory is such that we remember the good, and the bad is erased. Yes, I threw cars because I gave all the time to work, and just burned out. It became sick. But do I remember the feeling when I was sick? Nope. This is just a beech set. Fact. Naked. And that’s all. But Bukhalovo in the evenings in the company of guys, pokatushki, interesting tuning projects, funny cases - I write and a smile on my face, I swear. Five more years will pass, and maybe I will again get involved in cars. How to know?
“Once upon a time” is very closely connected with pleasant memories. And therefore - it seems simple, funny, interesting. And when the model that you promised to transfer to work suddenly doesn’t work, when reality pokes your nose at the fact that the code needs to be debited (which, by the way, was discovered after vulnerability in the boundary conditions) - then yes, such as a job and not a priority. And there is no joy. No. Therefore, the logic was sent to me 6 times late from what was declared.
And I am a lop-eared fool. Well-versed in what “I once coded”. He knows perfectly well that this is the most terrible customer. But, nevertheless, behaved once again.
Consent to revision. Or rather, the lack of their control. When working, I try to perform no more than 10% of the alterations from the original task before an intermediate or final delivery. Here the score was lost, by me.
Consent to cut deadlines. "Planning-designing-writing-testing." There are no miracles. If the terms from the declared are cut in 2 times, then this leads to their increase in 2 times. Since something will be omitted in any case, and will only lead to an increase in the resulting period (and not the period when it reports “readiness”).
That's all for today. I hope the experience will be useful to comrades. Goodnight.
