Web projects of the "first freshness" - "quality refrigerator"
It has long been noticed that web projects differ in different classes of "freshness" ...
Programmers rarely leave such projects, because the pleasure of being able to work with the right code and reasonable architecture often suppresses periodic calls for salary increases and career growth. A person can actually work for three and five years, especially if he is given the opportunity to become an importer of the product and add part of his brain and heart to it.
')
For a manager, it is pleasant to manage the development of such a product, by iterations + TK, or by working in a trusted Scrum / Agile mode. The notches of non-critical risks and fragmentary timing shifts are smoothed out by the general feeling of product reliability and viability. The manager is burning with ideas, getting richer with features, and after the regular implementation of his top priorities he gets a dose of moral satisfaction and optimism ... and wants to continue working in this company :-)
Technical support is engaged in the correction of minor errors, collecting mainly customer requests in prioritized bouquets.
In short, there is something like a fragrance and awe, and this is noted by all - tops, and managers, and developers, and support.
Unfortunately, such projects / products are found ... infrequently. But - there are.
Programmers, by hook or by crook, are trying to squeeze in and jump into tasks related to the “right” modules / components of the product. There really is order, purely and there is a desire to add something new, to show creativity.
The groups of developers involved in the development of certain parts, let's call them “rotting” parts of the product, begin to show signs of demoralization, mood swings, sarcasm regarding “genetic fools who wrote this module” or “weak character managers who swallow deadlines from above or from the side, regardless of their opinion development teams. " There are conversations on the topic "it is urgent to rewrite the block / module from scratch before it is too late."
The range of assessments of tasks related to the revision of the “decaying” parts is large enough, which increases the risks of the progressive development of the product in this direction. In principle, managers are already beginning to get nervous, shout at developers, and fires of local staff turnover are breaking out.
The support still holds the defense, closing the problem areas of the product with summer students for 3 months or by employees with a lack of a nervous system.
Periodically, colleagues note olfactory signs of a fragmented dead man’s appearance, but consider them temporary (managers, programmers most likely already shout about the problem and extinguish the fire, hoping to be heard).
The strangest thing in this situation is that certain project management groups, sometimes tops, deliberately wear gauze bandages and earplugs in their ears, squeezing a deceptive smile out of themselves to customers. Apparently they are used to working in companies for no more than 2-3 years, so they simply do not care about the impending disaster.
And imagine, programmers can work in such projects! But these are usually special personalities:
1) Crazy geniuses. Colleagues, one might say, are engaged in bringing to perfection tiny pieces of the product, enjoying from this, quite sincerely not noticing the terrible corpse stench and penetration of decomposition liquids under clothes. It does not matter to them to make a manicure for a beautiful girl or to paint the nails of a carelessly torn foot :-)
2) Trolls on pumping. Colleagues are inspired by extreme mess and pump their knowledge in the field of XP and design patterns on a richly represented biomaterial. Of course, no one thinks about refactoring, much less modularity - just chopping.
3) Students. The guys need to get any experience at any cost. Well, it’s scary if they break your billing in 75 places and in practice they begin to distinguish the second normal form from the third one, irrevocably losing a couple of financial transactions and sending a list to the client list of 5000 addresses: “Test !!! Fuck1 - ok, fuck2 - error, fuck3 - null. "
There will be a big turnover in your development team, you will have to lure people - but attention, people will still remain. True work - is unlikely.
“Military doctors” is perhaps the only type of managers who will try to rectify the situation in such a project by conducting hourly amputations and morning defibrillations. Colleagues will beat their heads against the wall, adequately understanding what is happening, but, as a rule, they are not enough for a long time and they leave themselves. Some particularly brave "military doctors" will be able to have time to tell the senior management that it is time to close the project, that this is a budget hole - for which they are likely to end the day with a roundabout in the personnel department.
"Maniacs" - in such extreme projects, managers appear from nowhere, which ... turns out to be JUST like. They will run to work until late at night, “standing on the boat,” methodically finishing off in the swamp of developers and downstream managers with a paddle.
"Proxy with a sense of humor." These colleagues, having authority and managing resources and hoping to work in the company for 2-3 years, act simply - they hire and dismiss. And they are having fun pushing the “military medics” together (and even more interesting if confronted with a “maniac”). Of course, no one is going to think about the end result, much less counting money. Simply, having five such projects, you can play in a proxy for 2-3 years, until they understand your policy.
But what about crisis managers? :-) I am convinced that they should come to the products of the "second freshness" - and here you probably will not change anything.
If you are lucky enough to start a web project from scratch, then this is quite an achievable task. But if you got the product of the "second freshness" - all is not lost either.
To do this, you need to build a "fridge" that does not allow the product to rot through - a system of strict quality control and motivation.
You need to understand that you can talk a lot about quality, write, run around with a rag and dust, but there is always MINIMUM, below which the quality bar in a product should never fall for a long time. Learn the spinal cord to feel this criterion - do not you feel? come with experience - intuition develops.
In the meantime, follow the simple rules that have been verified by experience:
1) Do not try to find a lot of good programmers. Try to find one and let it be 2-3 times more expensive. The rest can be students, beginners, secondary, etc. - according to the project budget.
2) If the project has complex business logic, billing, etc. - use a ready-made solution / framework ( ZendFramework , BitrixFramework , etc.) - so that you don't have to do anything complicated. If it fails, be sure to find one, good, system analyst.
3) These colleagues should not create anything. Their task is tight control and screening. Through them, either the code, the API, the architecture pass — or they do not pass without compromise. Yes, at first you will have a personnel turnover, but then, people will remain (or the above specialists will educate them) who will be able to do things that are passed through the superior quality and common sense filter.
4) Ask expert colleagues every day:
- Is the product being modular? Expected answer: Yes, or the task to refactor.
5) Make sure that a certain percentage of time is always allocated for refactoring (changing the code WITHOUT adding new functionality). It is very important.
6) If experts tell you that developers can write unit tests - let them do it. So you are lucky. If they do not know how and do not learn, it does not matter. Modularity will save us.
7) Do not be afraid to test the project on ... employees of your company and certain groups of clients. The more you find the eye, the better. Understand, you will never be allowed to form a testing department with a staff of 100 or more people :-)
8) Checklists. A surprisingly effective tool for maintaining the quality of processes on-line at an acceptable level, which has a direct analogue in the ... military army regulations. Non-observance of the point - and the soldier’s half heads splash at a radius of 5 meters. Write and develop checklists: from programming and security code audit rules, to the process of laying out project changes to combat servers.
9) Take care of your project team by all means - both from colleagues and from the tops. Praise and encourage creativity, create an atmosphere of life. Do not let anyone hopelessly break the “fridge” that keeps your product / project fresh.
Do not be discouraged if your project has become rotten all the same - try to return it to a fresh state as soon as possible by increasing the time for refactoring and holding back the external pressure of inadequate terms and changing requirements. You must succeed.
Good luck!
First freshness
Programmers rarely leave such projects, because the pleasure of being able to work with the right code and reasonable architecture often suppresses periodic calls for salary increases and career growth. A person can actually work for three and five years, especially if he is given the opportunity to become an importer of the product and add part of his brain and heart to it.
')
For a manager, it is pleasant to manage the development of such a product, by iterations + TK, or by working in a trusted Scrum / Agile mode. The notches of non-critical risks and fragmentary timing shifts are smoothed out by the general feeling of product reliability and viability. The manager is burning with ideas, getting richer with features, and after the regular implementation of his top priorities he gets a dose of moral satisfaction and optimism ... and wants to continue working in this company :-)
Technical support is engaged in the correction of minor errors, collecting mainly customer requests in prioritized bouquets.
In short, there is something like a fragrance and awe, and this is noted by all - tops, and managers, and developers, and support.
Unfortunately, such projects / products are found ... infrequently. But - there are.
Second freshness
Programmers, by hook or by crook, are trying to squeeze in and jump into tasks related to the “right” modules / components of the product. There really is order, purely and there is a desire to add something new, to show creativity.
The groups of developers involved in the development of certain parts, let's call them “rotting” parts of the product, begin to show signs of demoralization, mood swings, sarcasm regarding “genetic fools who wrote this module” or “weak character managers who swallow deadlines from above or from the side, regardless of their opinion development teams. " There are conversations on the topic "it is urgent to rewrite the block / module from scratch before it is too late."
The range of assessments of tasks related to the revision of the “decaying” parts is large enough, which increases the risks of the progressive development of the product in this direction. In principle, managers are already beginning to get nervous, shout at developers, and fires of local staff turnover are breaking out.
The support still holds the defense, closing the problem areas of the product with summer students for 3 months or by employees with a lack of a nervous system.
Periodically, colleagues note olfactory signs of a fragmented dead man’s appearance, but consider them temporary (managers, programmers most likely already shout about the problem and extinguish the fire, hoping to be heard).
The strangest thing in this situation is that certain project management groups, sometimes tops, deliberately wear gauze bandages and earplugs in their ears, squeezing a deceptive smile out of themselves to customers. Apparently they are used to working in companies for no more than 2-3 years, so they simply do not care about the impending disaster.
Trash can
And imagine, programmers can work in such projects! But these are usually special personalities:
1) Crazy geniuses. Colleagues, one might say, are engaged in bringing to perfection tiny pieces of the product, enjoying from this, quite sincerely not noticing the terrible corpse stench and penetration of decomposition liquids under clothes. It does not matter to them to make a manicure for a beautiful girl or to paint the nails of a carelessly torn foot :-)
2) Trolls on pumping. Colleagues are inspired by extreme mess and pump their knowledge in the field of XP and design patterns on a richly represented biomaterial. Of course, no one thinks about refactoring, much less modularity - just chopping.
3) Students. The guys need to get any experience at any cost. Well, it’s scary if they break your billing in 75 places and in practice they begin to distinguish the second normal form from the third one, irrevocably losing a couple of financial transactions and sending a list to the client list of 5000 addresses: “Test !!! Fuck1 - ok, fuck2 - error, fuck3 - null. "
There will be a big turnover in your development team, you will have to lure people - but attention, people will still remain. True work - is unlikely.
Management. There is a theater of the absurd.
“Military doctors” is perhaps the only type of managers who will try to rectify the situation in such a project by conducting hourly amputations and morning defibrillations. Colleagues will beat their heads against the wall, adequately understanding what is happening, but, as a rule, they are not enough for a long time and they leave themselves. Some particularly brave "military doctors" will be able to have time to tell the senior management that it is time to close the project, that this is a budget hole - for which they are likely to end the day with a roundabout in the personnel department.
"Maniacs" - in such extreme projects, managers appear from nowhere, which ... turns out to be JUST like. They will run to work until late at night, “standing on the boat,” methodically finishing off in the swamp of developers and downstream managers with a paddle.
"Proxy with a sense of humor." These colleagues, having authority and managing resources and hoping to work in the company for 2-3 years, act simply - they hire and dismiss. And they are having fun pushing the “military medics” together (and even more interesting if confronted with a “maniac”). Of course, no one is going to think about the end result, much less counting money. Simply, having five such projects, you can play in a proxy for 2-3 years, until they understand your policy.
But what about crisis managers? :-) I am convinced that they should come to the products of the "second freshness" - and here you probably will not change anything.
Is it possible to keep the product always in the “first freshness”?
If you are lucky enough to start a web project from scratch, then this is quite an achievable task. But if you got the product of the "second freshness" - all is not lost either.
To do this, you need to build a "fridge" that does not allow the product to rot through - a system of strict quality control and motivation.
You need to understand that you can talk a lot about quality, write, run around with a rag and dust, but there is always MINIMUM, below which the quality bar in a product should never fall for a long time. Learn the spinal cord to feel this criterion - do not you feel? come with experience - intuition develops.
In the meantime, follow the simple rules that have been verified by experience:
1) Do not try to find a lot of good programmers. Try to find one and let it be 2-3 times more expensive. The rest can be students, beginners, secondary, etc. - according to the project budget.
2) If the project has complex business logic, billing, etc. - use a ready-made solution / framework ( ZendFramework , BitrixFramework , etc.) - so that you don't have to do anything complicated. If it fails, be sure to find one, good, system analyst.
3) These colleagues should not create anything. Their task is tight control and screening. Through them, either the code, the API, the architecture pass — or they do not pass without compromise. Yes, at first you will have a personnel turnover, but then, people will remain (or the above specialists will educate them) who will be able to do things that are passed through the superior quality and common sense filter.
4) Ask expert colleagues every day:
- Is the product being modular? Expected answer: Yes, or the task to refactor.
5) Make sure that a certain percentage of time is always allocated for refactoring (changing the code WITHOUT adding new functionality). It is very important.
6) If experts tell you that developers can write unit tests - let them do it. So you are lucky. If they do not know how and do not learn, it does not matter. Modularity will save us.
7) Do not be afraid to test the project on ... employees of your company and certain groups of clients. The more you find the eye, the better. Understand, you will never be allowed to form a testing department with a staff of 100 or more people :-)
8) Checklists. A surprisingly effective tool for maintaining the quality of processes on-line at an acceptable level, which has a direct analogue in the ... military army regulations. Non-observance of the point - and the soldier’s half heads splash at a radius of 5 meters. Write and develop checklists: from programming and security code audit rules, to the process of laying out project changes to combat servers.
9) Take care of your project team by all means - both from colleagues and from the tops. Praise and encourage creativity, create an atmosphere of life. Do not let anyone hopelessly break the “fridge” that keeps your product / project fresh.
Do not be discouraged if your project has become rotten all the same - try to return it to a fresh state as soon as possible by increasing the time for refactoring and holding back the external pressure of inadequate terms and changing requirements. You must succeed.
Good luck!
Source: https://habr.com/ru/post/123464/
All Articles