Team interview question: what to do if money for a project is received and spent, but the project is not ready
Question from a real interview (6 years ago)
Position: development team leader, team leader, technical leader in software development company for web and mobile applications.
Situation: the team gets the project, quite a long time. With the customer have made the technical task, the schedule of performance and agreed on the gradual payment of work. Let's say a plan for the year, and the customer will make payment 4 times, every quarter.
')
A year has passed. Payment received all, 100%. And those task is completed by 80%. You need another 20% to do. The most important thing that the architect of the project claims is that these 20% do not fit into the model, it is necessary to rewrite it again. I, as a candidate for the head of development, should analyze the situation, make a decision, coordinate with the customer.
6 years ago I was confused. And now, too, I do not have a 100% answer. My answer did not suit then. I do not know if it will suit now.
Finale first. If a project that is 80% complete cannot be completed due to poor architecture, an architect will be dismissed or removed from this project. But it is better to dismiss. Although sorry. But he stuck on the beauty of the code. But it turned out not flexible. He had time, he tried, but this is the situation. Dismiss, appoint another. Tell the customer that the project has been delayed, you need extra time and money. We will rewrite again in another year. The customer will refuse. We will not be able to return the money. The reputation of the company is spoiled. Bad reviews. Either we will return the money, but we are ruined. All in f ** e. We rewind the tape with this film back, at the time of the beginning of the final conversation with the customer.
Final second. The project is 80% ready, 20% is left, there is no more money from the customer. Tell the team what to do with the remaining 20% ​​for free. Part of the team will quit, maybe the same day. Or tense up and do, despite the assurances of the architect. They are stiff in black, they will write terrible terrible decisions, the most smelly r **** code. The customer will receive his decision with a delay of 3 months. Reputation saved. Company saved. Lost part of the team and team spirit. You can continue, but rewind the final again.
Final Three. Find out in the team the reason why 20% cannot be resolved. We inform the customer that 20% cannot be realized. Tell the truth, sprinkle ashes on your head. “Tried to the very last, but nothing comes out. The task is not solved programmatically. They searched for the whole year, they could not find them. Other solutions are needed. Let's get these 20% zafilim, we will reformulate, we will try to do it differently. ”The customer has an almost ready solution, maybe even already in operation. He does not want to quit what he has already paid and what he already uses. He agrees to finish the requirements, “flex”, reformulate, continue. Reputation saved. Team saved. The architect stroked against the coat, but retained. It seems out of the situation, but ... we wind off the tape, now a year ago.
Prequel In fact, the customer always overpays for the sake of such situations. The risk includes risk, because the company should always have a stock. If this customer does not pay, then he pays for another, on another project. Because the team always lies when assessing the time, especially in the future for a year. Where they gave a grade per day, there will be three days. Where they gave an assessment a year, there will be three years. And because people always overestimate their strength. Because you can not see the pitfalls in advance. Because besides programming, design, testing, and operation are necessary - these are large overhead costs that cannot be counted in advance. Another team may not be involved all, but some part can sit without work. They also want to eat, but for now they have nothing to do. They need a reserve. For Christmas gifts need a reserve. The cleaner needs a reserve.
Therefore, the rate per hour is sometimes triple. Teams that knock down prices, dump, may not survive in the described situation and die at the end of some zaflennogo project, if something went wrong. Or not to survive the holiday season. Or do not give a New Year's gift. Or fire the cleaning lady. So, we initially ask the customer to pay all these overhead costs and even this file. And at some point in time we extract reserves and pay extra time to eliminate the problem of 20% due to the kind of subcutaneous financial team fat. In the case of an unsuccessful final for the customer there is a waste of time, he just waits until we calm down all our cockroaches, stop panic and finish this damn piece of code. But the customer may not have to pay extra, but the team will not have to work for free.
Remake Now, about the architect's file. Yes. This is his personal file. Let him drink vodka and become sad. In a year, IF the project starts, IF it is dismissed, IF the team collapses, IF the company goes bankrupt. But we do not even get to this situation! Because we are a team.
Accept the fact that I am giving the right decisions now. Six years have passed since that interview. Now I am sharing my experience and am not mistaken.
Read? Received? Believe it? And now I will say that you were wrong. Because I lied to you. I will not say what exactly I lied, but I lied, and you believed. You rebuilt your train of thought, deciding that it is now correct. But he is not correct. And you will be mistaken if you use this train of thought. But this is such a literary move to evoke emotion. Everything is easier. More ordinary.
I could be wrong. You may be mistaken. The customer could make a mistake even when setting a technical task. An architect could have made a mistake in choosing architecture and technology. Come up with what is not needed. Do not come up with what you need. And the development team may be mistaken - to do everything at random, in the wrong place and with bugs. Could be wrong with the timing. Could be wrong with the choice of algorithms. All are mistaken. The rule “live and learn” is relevant. The principle of OpenMind is relevant. People make mistakes and learn from it. The best programmers were wrong dozens of times. Behind the ideal architecture are hiding a dozen solution curves. In the carefully hidden list of experiences of leading developers and architects there is a guest book on files without a database, sites on a table layout, the application “Hello, World!” With a “segmentation fault”.
But there is no single person who is smarter than everyone. There is no smarter even among the team. There are a little more experienced. He burned and DON'T GIVE burn to others, IF he was asked. He won and CAN give advice to a winning strategy, IF he asked. For this you need to ask him. Not the fact that more experienced is an architect, well, that is, it makes decisions. He may be a tester who says that this part of the solution is extremely bad, because in the past he could not manage to write a test for it. This could be a search engine optimization specialist who would say that due to SUCH an architectural approach in the past, the organic traffic project did not exist at all, the search engine did not even see all the beauty, because it is exclusively RIA, and SPA, and browser-side only . This can be an admin who says that THIS package is not going to Debian 5 + Python 2.27 at all, which are installed on servers by the customer, so we will have to write all the algorithms on our own, and not use a ready-made package.
In that part of the film, which is between the beginning and the end of the tape, which I quickly squandered - there MUST be something that can allow the team to make decisions together, to foresee the situations of these 20% unsolvable. There the architect is studying. Everyone there learns. There the team helps each other. There the team becomes more experienced. Her skills are growing.
But I do not know exactly how this is done. I know how I build up my skills. I know how to help those who ask for help with a specific technology. But there is no 100% right decision. Especially in how exactly to choose a technology or skill area.
For example, I studied AngularJS 1, VUE, js 2, Twitter Bootstrap 3, Semantic UI 2, MEAN, Phalcon 3, Yii 2, Laravel 5, Grunt, SCSS over the year. Pumped so that my head is spinning from feeling your own coolness. But in the solutions of the company where I work, these technologies are not used. I am torn from pride, and the team is neither cold nor hot from my skills. They could ask me what language or framework to choose for a new project, but I don’t have to choose - we have been working on the same stack for three years, and we are not going to rewrite it. Mono product. There were directions or situations in which the team needed new skills - I didn’t think about them, because I didn’t know about this need.
Why did I study these technologies at all? Wanted and studied. The more experienced you become, the easier it is to learn. I already have a continuous process of learning something. Could study something else, I am generally open to knowledge, I like to try and experiment. Question: what to experiment with? Now I see that if a year ago I was told that it would be in May, and in September it would be - I would have arranged and studied the necessary. And since I chose myself, I was mistaken to some extent, because I did not ask the team. In May, he was not ready there, in September he was not ready there. There were difficult situations and decisions were taken at random, randomly, eliminating bugs and plugging holes blindly. Barely experienced a possible situation of falling out of the organic search. Somehow we experienced self-grown DDoS against ourselves.
Another point is the growth of personal skills, but there is no growth in benefits for the company. At the end of the year I would raise the question: please make me a salary more - I won how smart I am, I can do this and that, here! But if the team assessed my contribution, then they would have decided about me that I was a superfluous link. I constantly learn something, but if that - “it must be studied further.” I know something, but in a specific situation I can not say anything. My mistakes with the choice of technology - this is my load.
Long week of reflection and self-digging. Teamwork. Consultation with other teams. Search for similar situations and solutions. Rough sketch. Here's what happened: uptlo.com - all project ideas on the main page. I will not be promoting - almost nothing works :) But I think the project would be useful for teams to jointly increase skills in the right direction. And if someone wants to learn, so that even with benefit - he will have a choice of relevant topics. Or if the team needs a person with the right skills - they can show it, set the requirements. This is not about technical skills like “development experience on Phalcon / Flask / Express” - teams often need soft skills (soft skills), which make up up to 80% of the skills of a tough specialist. Well, there to communicate with customers, in a team to fix decisions, write a report or make those tasks. So this is relevant for any subject area, for any profession. And at the end of the year, assess how much the team has become more experienced, how much each has become more experienced. In particular, whether he deserves a pay raise.
Returning to the topic topic: "What if the money for the project is received and spent, but the project is not ready," for my film about the interview six years ago.
In view of the foregoing, the final remake:
Now we are ready to show and put into operation what we have. And, most likely, it is already even being exploited. The support team is already collecting feedback, recommendations, suggestions, bug reports from end users. Testers are testing. Designers and layout designers improve the interface. The development team is already finishing the project. There is no architectural incompatible 20% in the project. In general, we are working on this project to eliminate the comments and will be issued as a supplement at our expense, until we close the requirements of the original task. You will not have any downtime. We separately collect a list of new requirements that do not agree with those tasks, new features. Let's move on to the maintenance and development of these and other new features, if you choose our team to continue working on the project ... To the scenario of the sequel to our film.
Digital image for the cover of the Analog Star borrowed from Miguel-Santos
Position: development team leader, team leader, technical leader in software development company for web and mobile applications.
Situation: the team gets the project, quite a long time. With the customer have made the technical task, the schedule of performance and agreed on the gradual payment of work. Let's say a plan for the year, and the customer will make payment 4 times, every quarter.
')
A year has passed. Payment received all, 100%. And those task is completed by 80%. You need another 20% to do. The most important thing that the architect of the project claims is that these 20% do not fit into the model, it is necessary to rewrite it again. I, as a candidate for the head of development, should analyze the situation, make a decision, coordinate with the customer.
6 years ago I was confused. And now, too, I do not have a 100% answer. My answer did not suit then. I do not know if it will suit now.
Finale first. If a project that is 80% complete cannot be completed due to poor architecture, an architect will be dismissed or removed from this project. But it is better to dismiss. Although sorry. But he stuck on the beauty of the code. But it turned out not flexible. He had time, he tried, but this is the situation. Dismiss, appoint another. Tell the customer that the project has been delayed, you need extra time and money. We will rewrite again in another year. The customer will refuse. We will not be able to return the money. The reputation of the company is spoiled. Bad reviews. Either we will return the money, but we are ruined. All in f ** e. We rewind the tape with this film back, at the time of the beginning of the final conversation with the customer.
Final second. The project is 80% ready, 20% is left, there is no more money from the customer. Tell the team what to do with the remaining 20% ​​for free. Part of the team will quit, maybe the same day. Or tense up and do, despite the assurances of the architect. They are stiff in black, they will write terrible terrible decisions, the most smelly r **** code. The customer will receive his decision with a delay of 3 months. Reputation saved. Company saved. Lost part of the team and team spirit. You can continue, but rewind the final again.
Final Three. Find out in the team the reason why 20% cannot be resolved. We inform the customer that 20% cannot be realized. Tell the truth, sprinkle ashes on your head. “Tried to the very last, but nothing comes out. The task is not solved programmatically. They searched for the whole year, they could not find them. Other solutions are needed. Let's get these 20% zafilim, we will reformulate, we will try to do it differently. ”The customer has an almost ready solution, maybe even already in operation. He does not want to quit what he has already paid and what he already uses. He agrees to finish the requirements, “flex”, reformulate, continue. Reputation saved. Team saved. The architect stroked against the coat, but retained. It seems out of the situation, but ... we wind off the tape, now a year ago.
Prequel In fact, the customer always overpays for the sake of such situations. The risk includes risk, because the company should always have a stock. If this customer does not pay, then he pays for another, on another project. Because the team always lies when assessing the time, especially in the future for a year. Where they gave a grade per day, there will be three days. Where they gave an assessment a year, there will be three years. And because people always overestimate their strength. Because you can not see the pitfalls in advance. Because besides programming, design, testing, and operation are necessary - these are large overhead costs that cannot be counted in advance. Another team may not be involved all, but some part can sit without work. They also want to eat, but for now they have nothing to do. They need a reserve. For Christmas gifts need a reserve. The cleaner needs a reserve.
Therefore, the rate per hour is sometimes triple. Teams that knock down prices, dump, may not survive in the described situation and die at the end of some zaflennogo project, if something went wrong. Or not to survive the holiday season. Or do not give a New Year's gift. Or fire the cleaning lady. So, we initially ask the customer to pay all these overhead costs and even this file. And at some point in time we extract reserves and pay extra time to eliminate the problem of 20% due to the kind of subcutaneous financial team fat. In the case of an unsuccessful final for the customer there is a waste of time, he just waits until we calm down all our cockroaches, stop panic and finish this damn piece of code. But the customer may not have to pay extra, but the team will not have to work for free.
Remake Now, about the architect's file. Yes. This is his personal file. Let him drink vodka and become sad. In a year, IF the project starts, IF it is dismissed, IF the team collapses, IF the company goes bankrupt. But we do not even get to this situation! Because we are a team.
Accept the fact that I am giving the right decisions now. Six years have passed since that interview. Now I am sharing my experience and am not mistaken.
Read? Received? Believe it? And now I will say that you were wrong. Because I lied to you. I will not say what exactly I lied, but I lied, and you believed. You rebuilt your train of thought, deciding that it is now correct. But he is not correct. And you will be mistaken if you use this train of thought. But this is such a literary move to evoke emotion. Everything is easier. More ordinary.
I could be wrong. You may be mistaken. The customer could make a mistake even when setting a technical task. An architect could have made a mistake in choosing architecture and technology. Come up with what is not needed. Do not come up with what you need. And the development team may be mistaken - to do everything at random, in the wrong place and with bugs. Could be wrong with the timing. Could be wrong with the choice of algorithms. All are mistaken. The rule “live and learn” is relevant. The principle of OpenMind is relevant. People make mistakes and learn from it. The best programmers were wrong dozens of times. Behind the ideal architecture are hiding a dozen solution curves. In the carefully hidden list of experiences of leading developers and architects there is a guest book on files without a database, sites on a table layout, the application “Hello, World!” With a “segmentation fault”.
But there is no single person who is smarter than everyone. There is no smarter even among the team. There are a little more experienced. He burned and DON'T GIVE burn to others, IF he was asked. He won and CAN give advice to a winning strategy, IF he asked. For this you need to ask him. Not the fact that more experienced is an architect, well, that is, it makes decisions. He may be a tester who says that this part of the solution is extremely bad, because in the past he could not manage to write a test for it. This could be a search engine optimization specialist who would say that due to SUCH an architectural approach in the past, the organic traffic project did not exist at all, the search engine did not even see all the beauty, because it is exclusively RIA, and SPA, and browser-side only . This can be an admin who says that THIS package is not going to Debian 5 + Python 2.27 at all, which are installed on servers by the customer, so we will have to write all the algorithms on our own, and not use a ready-made package.
In that part of the film, which is between the beginning and the end of the tape, which I quickly squandered - there MUST be something that can allow the team to make decisions together, to foresee the situations of these 20% unsolvable. There the architect is studying. Everyone there learns. There the team helps each other. There the team becomes more experienced. Her skills are growing.
But I do not know exactly how this is done. I know how I build up my skills. I know how to help those who ask for help with a specific technology. But there is no 100% right decision. Especially in how exactly to choose a technology or skill area.
For example, I studied AngularJS 1, VUE, js 2, Twitter Bootstrap 3, Semantic UI 2, MEAN, Phalcon 3, Yii 2, Laravel 5, Grunt, SCSS over the year. Pumped so that my head is spinning from feeling your own coolness. But in the solutions of the company where I work, these technologies are not used. I am torn from pride, and the team is neither cold nor hot from my skills. They could ask me what language or framework to choose for a new project, but I don’t have to choose - we have been working on the same stack for three years, and we are not going to rewrite it. Mono product. There were directions or situations in which the team needed new skills - I didn’t think about them, because I didn’t know about this need.
Why did I study these technologies at all? Wanted and studied. The more experienced you become, the easier it is to learn. I already have a continuous process of learning something. Could study something else, I am generally open to knowledge, I like to try and experiment. Question: what to experiment with? Now I see that if a year ago I was told that it would be in May, and in September it would be - I would have arranged and studied the necessary. And since I chose myself, I was mistaken to some extent, because I did not ask the team. In May, he was not ready there, in September he was not ready there. There were difficult situations and decisions were taken at random, randomly, eliminating bugs and plugging holes blindly. Barely experienced a possible situation of falling out of the organic search. Somehow we experienced self-grown DDoS against ourselves.
Another point is the growth of personal skills, but there is no growth in benefits for the company. At the end of the year I would raise the question: please make me a salary more - I won how smart I am, I can do this and that, here! But if the team assessed my contribution, then they would have decided about me that I was a superfluous link. I constantly learn something, but if that - “it must be studied further.” I know something, but in a specific situation I can not say anything. My mistakes with the choice of technology - this is my load.
Long week of reflection and self-digging. Teamwork. Consultation with other teams. Search for similar situations and solutions. Rough sketch. Here's what happened: uptlo.com - all project ideas on the main page. I will not be promoting - almost nothing works :) But I think the project would be useful for teams to jointly increase skills in the right direction. And if someone wants to learn, so that even with benefit - he will have a choice of relevant topics. Or if the team needs a person with the right skills - they can show it, set the requirements. This is not about technical skills like “development experience on Phalcon / Flask / Express” - teams often need soft skills (soft skills), which make up up to 80% of the skills of a tough specialist. Well, there to communicate with customers, in a team to fix decisions, write a report or make those tasks. So this is relevant for any subject area, for any profession. And at the end of the year, assess how much the team has become more experienced, how much each has become more experienced. In particular, whether he deserves a pay raise.
Returning to the topic topic: "What if the money for the project is received and spent, but the project is not ready," for my film about the interview six years ago.
In view of the foregoing, the final remake:
Now we are ready to show and put into operation what we have. And, most likely, it is already even being exploited. The support team is already collecting feedback, recommendations, suggestions, bug reports from end users. Testers are testing. Designers and layout designers improve the interface. The development team is already finishing the project. There is no architectural incompatible 20% in the project. In general, we are working on this project to eliminate the comments and will be issued as a supplement at our expense, until we close the requirements of the original task. You will not have any downtime. We separately collect a list of new requirements that do not agree with those tasks, new features. Let's move on to the maintenance and development of these and other new features, if you choose our team to continue working on the project ... To the scenario of the sequel to our film.
Digital image for the cover of the Analog Star borrowed from Miguel-Santos
Source: https://habr.com/ru/post/324346/
All Articles