Complicated subject area - who can find answers?
Web projects, like women, are different - smart, beautiful, seductive, and ... instantly insane. Quite often web projects are Saitics with simple logic and clear technologies. To fill up such a project - you need to try very hard, and even then conscience will torment all your life for laziness and stupidity.
But sometimes the project comes to you tasty and interesting, beautiful and complex, with deadlines looking outfrom under ... the next quarter. For the evening, you can only grasp into a third of his subject area - both from the functional and technology side. Adrenaline (and testosterone) of course rolls over - to solve such a difficult task, beautifully, very much, but when you wake up in the morning you see that you have turned gray - unsuccessfully trying to find an algorithm in a half-slumber.
The worst begins as similar systems approach the day of launch. The smallest errors and under-ideas made during the design begin to squeeze water into the cabin at a depth of 5000 meters.
There are no ready-made recipes for how to win and release such a project on time. But I will try to make out the often occurring risks associated with the flow of demands and give recommendations on how to increase the chances of winning.
I will describe the chain a little non-standard, from the bottom up - from the technical implementation to the requirements, and not vice versa, as often occurs.
')
The developer bears a big burden of responsibility for his code - increasing with each new line. Therefore, he writes a program and wants to solve the tasks of the project correctly and accurately, without probabilities and logical mucus. After all, the generated code is a machined metal construction on hinges with electric motors, crystallization of a mathematical algorithm. Heresy about flexible code, customizable design patterns, refactoring and 10,500 unit tests came up with corrupt managers :-)
It is equally difficult and important for a programmer to understand and implement an algorithm for sorting strings in a file in an RB-tree, tracking down possible states of an asynchronous network tcp server socket, or processing data from an authorization form. It is necessary all the same to penetrate into all details, carefully and deeply. But in order for the developer to do his job well, you need someone who can give exact answers to his specific formal questions: “how many eyes the necromorph has, how many arrows to stick in a vampire, etc.” - immediately or at a specified time. If you force the developer to understand the subject area himself and walk around the cemeteries at night with a machete in search of answers - who will write the working code when?
Since the developer is responsible for the implemented software code and for him every mistake is given a pain in the heart and the growth of karma - any ambiguities, murkiness, water and confusion in the requirements during programming - these are the most stupid and unnecessary risks that you need to try to minimize. Most importantly - they can be reduced!
It is known that making major changes to the program code later (yes, I know about programming patterns, but they are not omnipotent), when it is debugged, tested, licked - not only indefinitely shifts the duration of the web project, but also permeates the system with subtle errors .
In the end, ask the superintendent, after plastering and wallpaper stickers, to replace the wiring in the walls with a thicker and copper ... at his expense - well, the foreman had to, damn, provide for this scenario of changing requirements? :-) It is stupid - and in development it is a frequent case, unfortunately.
Moving up the chain.
From the management of the company, the web project manager is responsible for the success of the project, incl. by identifying and reducing project risks - i.e. he must give answers himself or find someone who will answer the developer exactly to the emerging questions on the subject area.
For example, you can include an analyst, expert or sensible representative of the customer in the project team - who will not sleep at night until he has in detail dug up all the subtleties and logic of the designed system. Or the manager himself must plunge into the project, the subject area and do the work himself.
If the manager begins to “translate arrows” in the endless recursion within the company, ignore the details of the project from the height of the Earth's orbit, start up “foggy,” startle with questions or answer questions just to get rid of - this porridge will leak into production and dry out as inability to live covered with useless tests and this nightmare will be revealed with the next demonstration of the functionality to the client. It remains - to rewrite everything, tearing the deadline and budget ... or blow up.
Even small missed portions of “water” in the requirements, especially concerning fundamental things, greatly undermine the stability of the system being created. Yes, if you have a team of very experienced fighters - they are likely to localize the "water", impose isolation on it and will scream about the inaccuracies and turbidity of the subject area, until they finish. But usually the problem is revealed the day before the launch.
With the requirements of the manager (expert, analyst) will have to ... ehh ... to work, rolling sleeves. I can recommend the following useful tools:
- glossary
- usecases or usage scenarios
- relations between the glossary entities between themselves (1 to many, N to M, etc.)
- activity diagram or regular school block diagram
In the course of clarifying the requirements, both the entities of the system and their properties and interaction between the entities are clarified.
Here is an example: “the buyer may belong to a group of customers receiving a discount.”
Questions, answers to which should be clear before starting development:
- The buyer can be included in several groups?
- How is the discount calculated in this case? Need a formula.
- For how long does the buyer join the group?
- When removing a buyer from the group, notify him? By email or SMS?
etc.
All questions will have to be given an exact and formal answer, and not to blame it on the developer: "the programmer somehow decided, he's smart, I don't know how."
1) Check the chain of requirements from the manager, analyst - to the programmer. People understand what they are doing, how will it work in detail?
2) As far as the client, as an expert in the subject area, is involved in the design process and clarify requirements. Or is he waiting and dreaming? :-)
3) Ask the web project manager a couple of questions specifying the details of the subject area and if water will flow in response ... take measures for emergency motivation :-)
4) Talk to the developers - who and how answers questions on the subject area, how clearly and consistently? Do they understand everything?
5) How often do the requirements change and the subject area “travels” due to the “lack of understanding” of the project manager in the details and the beginning of “understanding” before the deadline? How often do you have to change the code the day before launch and why (and 2 weeks to fix bugs at night) because of the lack of development of the subject area before bleeding from the eyes?
Compliance with the listed measures of improving the flow of requirements from top to bottom - dramatically increases the chances of a web project for success!
Good luck to all.
But sometimes the project comes to you tasty and interesting, beautiful and complex, with deadlines looking out
The worst begins as similar systems approach the day of launch. The smallest errors and under-ideas made during the design begin to squeeze water into the cabin at a depth of 5000 meters.
There are no ready-made recipes for how to win and release such a project on time. But I will try to make out the often occurring risks associated with the flow of demands and give recommendations on how to increase the chances of winning.
I will describe the chain a little non-standard, from the bottom up - from the technical implementation to the requirements, and not vice versa, as often occurs.
')
Role - Developer
The developer bears a big burden of responsibility for his code - increasing with each new line. Therefore, he writes a program and wants to solve the tasks of the project correctly and accurately, without probabilities and logical mucus. After all, the generated code is a machined metal construction on hinges with electric motors, crystallization of a mathematical algorithm. Heresy about flexible code, customizable design patterns, refactoring and 10,500 unit tests came up with corrupt managers :-)
It is equally difficult and important for a programmer to understand and implement an algorithm for sorting strings in a file in an RB-tree, tracking down possible states of an asynchronous network tcp server socket, or processing data from an authorization form. It is necessary all the same to penetrate into all details, carefully and deeply. But in order for the developer to do his job well, you need someone who can give exact answers to his specific formal questions: “how many eyes the necromorph has, how many arrows to stick in a vampire, etc.” - immediately or at a specified time. If you force the developer to understand the subject area himself and walk around the cemeteries at night with a machete in search of answers - who will write the working code when?
Since the developer is responsible for the implemented software code and for him every mistake is given a pain in the heart and the growth of karma - any ambiguities, murkiness, water and confusion in the requirements during programming - these are the most stupid and unnecessary risks that you need to try to minimize. Most importantly - they can be reduced!
It is known that making major changes to the program code later (yes, I know about programming patterns, but they are not omnipotent), when it is debugged, tested, licked - not only indefinitely shifts the duration of the web project, but also permeates the system with subtle errors .
In the end, ask the superintendent, after plastering and wallpaper stickers, to replace the wiring in the walls with a thicker and copper ... at his expense - well, the foreman had to, damn, provide for this scenario of changing requirements? :-) It is stupid - and in development it is a frequent case, unfortunately.
Moving up the chain.
Role - Manager
From the management of the company, the web project manager is responsible for the success of the project, incl. by identifying and reducing project risks - i.e. he must give answers himself or find someone who will answer the developer exactly to the emerging questions on the subject area.
For example, you can include an analyst, expert or sensible representative of the customer in the project team - who will not sleep at night until he has in detail dug up all the subtleties and logic of the designed system. Or the manager himself must plunge into the project, the subject area and do the work himself.
If the manager begins to “translate arrows” in the endless recursion within the company, ignore the details of the project from the height of the Earth's orbit, start up “foggy,” startle with questions or answer questions just to get rid of - this porridge will leak into production and dry out as inability to live covered with useless tests and this nightmare will be revealed with the next demonstration of the functionality to the client. It remains - to rewrite everything, tearing the deadline and budget ... or blow up.
Even small missed portions of “water” in the requirements, especially concerning fundamental things, greatly undermine the stability of the system being created. Yes, if you have a team of very experienced fighters - they are likely to localize the "water", impose isolation on it and will scream about the inaccuracies and turbidity of the subject area, until they finish. But usually the problem is revealed the day before the launch.
Instruments
With the requirements of the manager (expert, analyst) will have to ... ehh ... to work, rolling sleeves. I can recommend the following useful tools:
- glossary
- usecases or usage scenarios
- relations between the glossary entities between themselves (1 to many, N to M, etc.)
- activity diagram or regular school block diagram
In the course of clarifying the requirements, both the entities of the system and their properties and interaction between the entities are clarified.
Here is an example: “the buyer may belong to a group of customers receiving a discount.”
Questions, answers to which should be clear before starting development:
- The buyer can be included in several groups?
- How is the discount calculated in this case? Need a formula.
- For how long does the buyer join the group?
- When removing a buyer from the group, notify him? By email or SMS?
etc.
All questions will have to be given an exact and formal answer, and not to blame it on the developer: "the programmer somehow decided, he's smart, I don't know how."
Ways to reduce risks
1) Check the chain of requirements from the manager, analyst - to the programmer. People understand what they are doing, how will it work in detail?
2) As far as the client, as an expert in the subject area, is involved in the design process and clarify requirements. Or is he waiting and dreaming? :-)
3) Ask the web project manager a couple of questions specifying the details of the subject area and if water will flow in response ... take measures for emergency motivation :-)
4) Talk to the developers - who and how answers questions on the subject area, how clearly and consistently? Do they understand everything?
5) How often do the requirements change and the subject area “travels” due to the “lack of understanding” of the project manager in the details and the beginning of “understanding” before the deadline? How often do you have to change the code the day before launch and why (and 2 weeks to fix bugs at night) because of the lack of development of the subject area before bleeding from the eyes?
Compliance with the listed measures of improving the flow of requirements from top to bottom - dramatically increases the chances of a web project for success!
Good luck to all.
Source: https://habr.com/ru/post/204206/
All Articles