Happy ProductOwner - riding a powder keg
You are a project manager and you have been instructed to create a complex online store with perverted billing for 4 months. You want to work in this company for the next 2-3 years - they pay well, the projects are loud. Tops believe in you. At stake is your professional reputation.
Let us see how to ride your own development unit and achieve success.
')
Process
If you have the authority and enough energy - use Agile / Scrum in an inhuman version. If things do not go there, you can tighten the nuts and go to the lightened RUP, finishing off communism with a nuclear strike. Now there is no time to plant bureaucracy and write TK per 1000 pages.
What are we doing?
Need to collect requirements for the project. Quick and basic. Unfortunately, a large number of people in companies in our country, as a rule, profane their positions. A clever people, fortunately, an overwhelming minority. If you ask specialized specialists questions in the forehead about how their working day is arranged, which the online store should automate - get ready to overcome the desire to come to work with a baseball bat and start crushing the parasites.
I do not advise directors to ask direct questions to departments — they will make their worst enemies - you still discover the secret that employees in their departments ... do not know what they are doing :-)
If you are so unlucky, look for any adequate analyst to collect the requirements and protect his life. Try to find support from the tops. You will not find - quit.
Sometimes the company still manages to collect project requirements.
Bring together
On the basis of the information collected, make several artifacts of extreme importance:
1) Glossary. This word = value. If you don’t do it, you will not be able to continue to communicate with “smart” employees from the departments, you will not be able to understand the analyst and you will not understand the development to which we will soon go.
2) The logical data model is a square of words from the glossary and the relationships between them are shown (1 - *, * - *, 1 - 1). This tool are our children in school now in the study of logic. The most difficult thing is to arrange the right relationships and reveal entities.
3) Interface prototypes. Draw prototypes of website pages with a freehand or foot analyst. No details.
4) If business went and you and the analyst understand everything - identify the roles and their actions. Just list in the plate. If not, it doesn't matter.
Achtung. The most difficult thing is to bring everything together. We spend 1-2 full days. It is possible on the wall, blackboard. A miracle happens - you will see the main parts of the system as a whole. If you don’t see for yourself, try to see the analyst, give him a bonus :-). It is very important.
Now we need to try so that experts from other departments see the same thing and coordinate with you the logical architecture of the system. It sounds ridiculous and stupid. But sometimes lucky Yes, people will include a fool, to pretend that they did not finish school ... - lies, any person is able to describe the terms, the connections between the terms and their role in the overall system. Help them in this, connect tops :-)
If you are lucky and managed to make people think, perhaps for the first time in their lives, send an analyst on vacation, he deserved.
Planning releases
The logical spine of the product you saw is 50% success. Next thing technology. We go to the developers. We distribute features into complex / medium / simple ones with a predetermined average rating of each category.
If there are more than five hundred features, include the second analyst in the team, otherwise you will go to hell with your mind and bring the developers there as well.
Programmers will appreciate features much better if they see interface prototypes, a glossary, a log. data model, roles and tasks. And we did it.
I do not recommend holding a show called StoryMapping - unless your task is to entertain people and create a party atmosphere. A formalized tool I think is suitable only for simple systems or ... giant systems.
The most priority features are included in the first release. As a result, we get a rough plan of project releases. We declare a hard date for the launch of each release and the project as a whole.
Special releases
I strongly recommend that you include load testing on test data as one of the final stages. Otherwise, you can start the project, and it ... will be bent in 2-3 days.
The release of quality is still very useful - comprehensive beta testing is conducted within the company. Check all the functionality again.
Choose a reference point
An important point. You need to decide and make an informed decision:
Writing from scratch
If your task is to pump programmers, I recommend writing a project ... from scratch :-). If you need to start an online store in 4 months - forget this item as a bad dream.
True, if you go this way - you will become a friend of the programmers of your team, they will greet you in the corridors. Still - they gave people such an opportunity to get better :-)
We write with "unit"
The chief of developers (if he hides behind teams, find him necessarily - there’s always such a thing in the company) can suggest reducing development time by using a “low-level” framework. There are several of them for PHP: ZendFramework, Yii, Symfony, CakePHP ...
Choose or not? I will give advice - if you write a unique complex system that processes large amounts of data and serves millions of visitors per day (like FaceBook ;-)) - choose a low-level framework, do not write from scratch. ZendFramework - just designed for enterprise class tasks.
The fact is that experienced programmers are very, very few, especially in our country, and low-level frameworks are written just by such people, so do not take risks and use their achievements.
Your friends will be about the second half of the development team, because they understand that it is possible to upgrade a little on the framework. The first half is lost to you.
But our task is to start in 4 months :-) Therefore, the framework will most likely not save us.
We write on the basis of a box solution
Here the first key task is to understand how the box works and whether its logic goes into your task of creating an online store with perverted billing. I recommend to figure it out yourself and make the analyst figure it out. If it turns out that is suitable - you are lucky.
The second key task is to make sure that the development team can, on the basis of the box, make you a project on time. If the box has good technical documentation and a system of free / paid certification of developers and you can train people to work with it for two or three weeks - the chances of success increase significantly.
Big minus - the developers are likely to stop talking to you. They will have to work and solve clear business problems by refining someone else's code - and this is very striking for the motivation of a novice programmer. Everyone wants to create reality on their own :-)
Choosing a boxed solution ... If you have a very strong and experienced development team in the PLO, with an average salary in Moscow in the region of 100k and a team of about ten people in a team - Magento is a good fit for a tricky store.
If you are limited in resources and terms (3 developers, 3-4 months) and expect that besides the functionality of the online store, you will soon need to provide technical support for clients, survey services, forums, blogs, integrated search, integration with 1C, support Russian payment systems, if you want to launch a project INDEPENDENTly through the admin panel to manage the site, without attracting programmers for the slightest change in functionality - then of course the box from 1C-Bitrix is ​​beyond any competitors. You will run on time and the next 2-3 years will spit into the stream - managing the site through the admin panel without attracting developers.
Moreover, if you do not want to swear with the development team about "why the online store began to slow down, customers complain" or "why the online store was not available yesterday from 9 to 11 am" :-) - IMMEDIATELY create a web-type project -cluster - the benefit in the above box is such an opportunity .
Your team's programmers scream from using any box and make you dark :-) I was helped by such a trick - for the self-realization of the programmers I asked them to do complex tasks based on a cool low-level framework, for example ZendFramework. As a result, the sheep remained intact, and the wolves are fed.
Doing sprints
In your selfish interests - the quality of the features performed during the sprint. Due to the lack of a hard waterfall quality control cycle, you risk running into the rapid development of fecal consistency features.
And do not think that if you spend a fraction of your time in the sprint instead of implementing the features on the team writing unit tests, this will save you from diving into the quagmire of ugly quality. Unit tests need to be able to write, and finding such people is difficult.
If you do not want to test the raw functionality released in the sprint at night and on weekends, try to do everything so that the development carefully checks what it does before the demonstration. For the quality of each sprint, you are personally responsible for the head of the development department or the technician - the team, as we remember, is a collective unconscious and cannot answer for anything (people come and go and do not pay alimony, but you will have to babysit the project).
If you are not satisfied with the quality of the sprint - pull the switch and stop the gov ... but the conveyor. Gather a meeting and sort out the causes of the identified problems with the development manager / tech-manager - it’s usually useless to discuss quality issues in retrospectives, it’s wasting time.
Quality is a systemic, not an emotional process. The task cannot be solved at the same level at which it arose. Until the system measures are taken in development: a tracker is set up, Continuous Integration is implemented, etc. - Do not go further, do not accept the sprint, the pipeline is worth it.
Unfortunately, sometimes you have to fight on the topic of quality with the developers - and require personnel changes in the team and the management of developers.
Sometimes it is possible to achieve the creation of a department of testing and require skipping completed sprints through it. Fight and achieve.
Load sprints
To control that the project will work with the expected volume data, after the implementation of a large feature in the sprint series - conduct its load testing, not postponing it for later. If it turns out that the system is hanging and not processing the expected amount of data - collect the meeting with hands. development / tehdir and arrange debriefing. Until the system measures are taken - the conveyor is stopped, the sprint is not taken. Again, such system tasks as the quality of architecture and programming are poorly solved at the level of retrospectives. Decide on a higher level.
The analyst is your friend
Charge the analyst to carefully verify that the requirements put on the sprint in features and additionally commented in the logical data model, interface prototypes and glossaries are fully implemented, as it is thoughtfully and written. Unfortunately, it is often necessary to drag and finish up to the end, as it is written, features from one sprint to another.
Record the time spent on the "finishing touches" features associated with inattentive reading of the description of the requirement. If the percentage of disorder in a team has increased to a critical level - look for a developer / scrum master and ... hit - it is his task to ensure discipline in teams.
Examination of ratings
It may happen that in a team, everyone will begin to overestimate the estimates on PlanningPoker - this is beneficial for programmers, since You can not rush and do the work in a measured pace, sipping coffee. True, it is not beneficial to you. Talk to an expert in the field of development - techdir (if you haven’t managed to spoil relations with him :-)) - if his grades are lower than those given by the team, you are not lucky :-) - I recommend in this case to refuse PlanningPoker and evaluate them yourself previous assessments and your accumulated experience at this point in time - coordinating the assessment procedure with an expert you trust. There are no options left.
Process adjustment
What is good about flexible Scrum methodologies is the openness of the process. If it fails and the project collapses - it is visible to all, it can be seen well. It may turn out that:
- the developers in the team were weak and inexperienced
- Scrum-master turned out to be a rag, there is no leader in the team, hanging out and razdolbaystvo, which is expressed in the complete reading of requirements to the end, careless work and numerous bugs
- technical director is hiding from you, considering that your task is to educate programmers :-)
You can tighten the nuts in the direction of the simplified RUP:
- With an analyst, write a statement of work on the iteration
- Evaluate the TK with the head of the development department / tech.
- The development thoroughly tests the results of the iteration on its own, demonstrating the successful execution of unit tests (at least at the time of receiving the work)
- Carefully accept the work done, the analyst also helps you in this.
Yes. It will be a war of capitalism with communism. But the chance to win and launch an online store, though not for 4 months, but for ... a year, remains :-)
Let us see how to ride your own development unit and achieve success.
')
Process
If you have the authority and enough energy - use Agile / Scrum in an inhuman version. If things do not go there, you can tighten the nuts and go to the lightened RUP, finishing off communism with a nuclear strike. Now there is no time to plant bureaucracy and write TK per 1000 pages.
What are we doing?
Need to collect requirements for the project. Quick and basic. Unfortunately, a large number of people in companies in our country, as a rule, profane their positions. A clever people, fortunately, an overwhelming minority. If you ask specialized specialists questions in the forehead about how their working day is arranged, which the online store should automate - get ready to overcome the desire to come to work with a baseball bat and start crushing the parasites.
I do not advise directors to ask direct questions to departments — they will make their worst enemies - you still discover the secret that employees in their departments ... do not know what they are doing :-)
If you are so unlucky, look for any adequate analyst to collect the requirements and protect his life. Try to find support from the tops. You will not find - quit.
Sometimes the company still manages to collect project requirements.
Bring together
On the basis of the information collected, make several artifacts of extreme importance:
1) Glossary. This word = value. If you don’t do it, you will not be able to continue to communicate with “smart” employees from the departments, you will not be able to understand the analyst and you will not understand the development to which we will soon go.
2) The logical data model is a square of words from the glossary and the relationships between them are shown (1 - *, * - *, 1 - 1). This tool are our children in school now in the study of logic. The most difficult thing is to arrange the right relationships and reveal entities.
3) Interface prototypes. Draw prototypes of website pages with a freehand or foot analyst. No details.
4) If business went and you and the analyst understand everything - identify the roles and their actions. Just list in the plate. If not, it doesn't matter.
Achtung. The most difficult thing is to bring everything together. We spend 1-2 full days. It is possible on the wall, blackboard. A miracle happens - you will see the main parts of the system as a whole. If you don’t see for yourself, try to see the analyst, give him a bonus :-). It is very important.
Now we need to try so that experts from other departments see the same thing and coordinate with you the logical architecture of the system. It sounds ridiculous and stupid. But sometimes lucky Yes, people will include a fool, to pretend that they did not finish school ... - lies, any person is able to describe the terms, the connections between the terms and their role in the overall system. Help them in this, connect tops :-)
If you are lucky and managed to make people think, perhaps for the first time in their lives, send an analyst on vacation, he deserved.
Planning releases
The logical spine of the product you saw is 50% success. Next thing technology. We go to the developers. We distribute features into complex / medium / simple ones with a predetermined average rating of each category.
If there are more than five hundred features, include the second analyst in the team, otherwise you will go to hell with your mind and bring the developers there as well.
Programmers will appreciate features much better if they see interface prototypes, a glossary, a log. data model, roles and tasks. And we did it.
I do not recommend holding a show called StoryMapping - unless your task is to entertain people and create a party atmosphere. A formalized tool I think is suitable only for simple systems or ... giant systems.
The most priority features are included in the first release. As a result, we get a rough plan of project releases. We declare a hard date for the launch of each release and the project as a whole.
Special releases
I strongly recommend that you include load testing on test data as one of the final stages. Otherwise, you can start the project, and it ... will be bent in 2-3 days.
The release of quality is still very useful - comprehensive beta testing is conducted within the company. Check all the functionality again.
Choose a reference point
An important point. You need to decide and make an informed decision:
Writing from scratch
If your task is to pump programmers, I recommend writing a project ... from scratch :-). If you need to start an online store in 4 months - forget this item as a bad dream.
True, if you go this way - you will become a friend of the programmers of your team, they will greet you in the corridors. Still - they gave people such an opportunity to get better :-)
We write with "unit"
The chief of developers (if he hides behind teams, find him necessarily - there’s always such a thing in the company) can suggest reducing development time by using a “low-level” framework. There are several of them for PHP: ZendFramework, Yii, Symfony, CakePHP ...
Choose or not? I will give advice - if you write a unique complex system that processes large amounts of data and serves millions of visitors per day (like FaceBook ;-)) - choose a low-level framework, do not write from scratch. ZendFramework - just designed for enterprise class tasks.
The fact is that experienced programmers are very, very few, especially in our country, and low-level frameworks are written just by such people, so do not take risks and use their achievements.
Your friends will be about the second half of the development team, because they understand that it is possible to upgrade a little on the framework. The first half is lost to you.
But our task is to start in 4 months :-) Therefore, the framework will most likely not save us.
We write on the basis of a box solution
Here the first key task is to understand how the box works and whether its logic goes into your task of creating an online store with perverted billing. I recommend to figure it out yourself and make the analyst figure it out. If it turns out that is suitable - you are lucky.
The second key task is to make sure that the development team can, on the basis of the box, make you a project on time. If the box has good technical documentation and a system of free / paid certification of developers and you can train people to work with it for two or three weeks - the chances of success increase significantly.
Big minus - the developers are likely to stop talking to you. They will have to work and solve clear business problems by refining someone else's code - and this is very striking for the motivation of a novice programmer. Everyone wants to create reality on their own :-)
Choosing a boxed solution ... If you have a very strong and experienced development team in the PLO, with an average salary in Moscow in the region of 100k and a team of about ten people in a team - Magento is a good fit for a tricky store.
If you are limited in resources and terms (3 developers, 3-4 months) and expect that besides the functionality of the online store, you will soon need to provide technical support for clients, survey services, forums, blogs, integrated search, integration with 1C, support Russian payment systems, if you want to launch a project INDEPENDENTly through the admin panel to manage the site, without attracting programmers for the slightest change in functionality - then of course the box from 1C-Bitrix is ​​beyond any competitors. You will run on time and the next 2-3 years will spit into the stream - managing the site through the admin panel without attracting developers.
Moreover, if you do not want to swear with the development team about "why the online store began to slow down, customers complain" or "why the online store was not available yesterday from 9 to 11 am" :-) - IMMEDIATELY create a web-type project -cluster - the benefit in the above box is such an opportunity .
Your team's programmers scream from using any box and make you dark :-) I was helped by such a trick - for the self-realization of the programmers I asked them to do complex tasks based on a cool low-level framework, for example ZendFramework. As a result, the sheep remained intact, and the wolves are fed.
Doing sprints
In your selfish interests - the quality of the features performed during the sprint. Due to the lack of a hard waterfall quality control cycle, you risk running into the rapid development of fecal consistency features.
And do not think that if you spend a fraction of your time in the sprint instead of implementing the features on the team writing unit tests, this will save you from diving into the quagmire of ugly quality. Unit tests need to be able to write, and finding such people is difficult.
If you do not want to test the raw functionality released in the sprint at night and on weekends, try to do everything so that the development carefully checks what it does before the demonstration. For the quality of each sprint, you are personally responsible for the head of the development department or the technician - the team, as we remember, is a collective unconscious and cannot answer for anything (people come and go and do not pay alimony, but you will have to babysit the project).
If you are not satisfied with the quality of the sprint - pull the switch and stop the gov ... but the conveyor. Gather a meeting and sort out the causes of the identified problems with the development manager / tech-manager - it’s usually useless to discuss quality issues in retrospectives, it’s wasting time.
Quality is a systemic, not an emotional process. The task cannot be solved at the same level at which it arose. Until the system measures are taken in development: a tracker is set up, Continuous Integration is implemented, etc. - Do not go further, do not accept the sprint, the pipeline is worth it.
Unfortunately, sometimes you have to fight on the topic of quality with the developers - and require personnel changes in the team and the management of developers.
Sometimes it is possible to achieve the creation of a department of testing and require skipping completed sprints through it. Fight and achieve.
Load sprints
To control that the project will work with the expected volume data, after the implementation of a large feature in the sprint series - conduct its load testing, not postponing it for later. If it turns out that the system is hanging and not processing the expected amount of data - collect the meeting with hands. development / tehdir and arrange debriefing. Until the system measures are taken - the conveyor is stopped, the sprint is not taken. Again, such system tasks as the quality of architecture and programming are poorly solved at the level of retrospectives. Decide on a higher level.
The analyst is your friend
Charge the analyst to carefully verify that the requirements put on the sprint in features and additionally commented in the logical data model, interface prototypes and glossaries are fully implemented, as it is thoughtfully and written. Unfortunately, it is often necessary to drag and finish up to the end, as it is written, features from one sprint to another.
Record the time spent on the "finishing touches" features associated with inattentive reading of the description of the requirement. If the percentage of disorder in a team has increased to a critical level - look for a developer / scrum master and ... hit - it is his task to ensure discipline in teams.
Examination of ratings
It may happen that in a team, everyone will begin to overestimate the estimates on PlanningPoker - this is beneficial for programmers, since You can not rush and do the work in a measured pace, sipping coffee. True, it is not beneficial to you. Talk to an expert in the field of development - techdir (if you haven’t managed to spoil relations with him :-)) - if his grades are lower than those given by the team, you are not lucky :-) - I recommend in this case to refuse PlanningPoker and evaluate them yourself previous assessments and your accumulated experience at this point in time - coordinating the assessment procedure with an expert you trust. There are no options left.
Process adjustment
What is good about flexible Scrum methodologies is the openness of the process. If it fails and the project collapses - it is visible to all, it can be seen well. It may turn out that:
- the developers in the team were weak and inexperienced
- Scrum-master turned out to be a rag, there is no leader in the team, hanging out and razdolbaystvo, which is expressed in the complete reading of requirements to the end, careless work and numerous bugs
- technical director is hiding from you, considering that your task is to educate programmers :-)
You can tighten the nuts in the direction of the simplified RUP:
- With an analyst, write a statement of work on the iteration
- Evaluate the TK with the head of the development department / tech.
- The development thoroughly tests the results of the iteration on its own, demonstrating the successful execution of unit tests (at least at the time of receiving the work)
- Carefully accept the work done, the analyst also helps you in this.
Yes. It will be a war of capitalism with communism. But the chance to win and launch an online store, though not for 4 months, but for ... a year, remains :-)
Source: https://habr.com/ru/post/122493/
All Articles