Computer application development projects. Special features
The scope of project management is very extensive, from the organization of events (not a tangible result) to construction (the house is a very tangible result). And in this area you can separately distinguish the category of projects "development of computer applications."
You need to very well understand the difference between these projects from the rest and especially from the projects of introducing computer applications into the business processes of the organization.
There are two risks that very often result in problems:
')
1. those who specialize in software development do not notice how they are stepping onto the implementation territory and the project begins to inflate ... usually with a fatal outcome;
2. those who specialize in implementation and organizational projects, without understanding the complexity, begin to develop and the quality of the results begins to fall significantly - and this is at best;
For those who are engaged in the net implementation or net development - these problems are unknown. But they are rare lucky ones.
Leaving the details ...
To begin with, let's look at the criteria by which we can distinguish a computer application development project:
1. the result of such a project is a computer application (web, windows, android, iOS ...), a module (functional block) or some significant change (what is a "significant change" - let's look at below);
2. these projects require deep knowledge of computer application architecture and the corresponding technology stack, but they imply minimal interaction with users or employees involved in any business processes.
Clause 2 - in the part “touch user interaction a little” - this is a key feature that distinguishes the project of developing a computer application from the project of introducing a computer application into business processes. This does not mean that there is no such interaction, of course there is, it is just minimal.
If during the development project, the share of interaction with people begins to increase, then such a project risks developing into an implementation project, and this is another weight category of complexity and risk.
A separate subcategory can be identified projects that should run when it comes to a group of changes, united by a single goal, which can last for a long time and affect multiple versions (releases).
If a change or a group of changes fits into one release, you should not start a project.
But if one change pulls up a series of other changes, here it is worth thinking about launching the project, because:
1. These changes need someone to coordinate, because changes can be made by various specialists, and there must be someone who will be in the know and will be able to coordinate different people
2. A single change can lead to changes in other mechanisms of the system; this causes various risks that also need to be taken into account and be prepared for them - this is best done through project management.
3. Often, a change forces developers to duplicate various mechanisms, to make new ones next to old and old mechanisms, upon completion of a series of changes, will need to be removed from the system. Without coordination, these “bits and pieces” can remain there forever, and this entails sad consequences in the long term.
For example :
In the task management system, it was necessary to expand the Participants block. Add the ability to choose not only employees, but also groups
- We started with the development of the interface, it turned out that we need to change the access subsystem
- We started to change the access subsystem, we realized that we need to leave the old one for some time, so a new mechanism was created nearby, without breaking the old one
- Made changes to the interface, made friends with a new model, debugged a new
- Now you need to remove the old mechanism
All 4 points - stretched for 5 months and 3 versions of the development. Without coordination, it would be much longer, and as a result, you could simply lose the target vector and forget about the fact that the old mechanism should be removed.
Very dangerous, but also extremely common is the situation when the customer asks to develop a certain system: accounting of finances, the work of sales managers or something like that.
It seems to be a simple development project at first glance. Need to develop something.
But the chances of success of this project is not much, because very soon it turns out that the application is ready, but for some reason the customer is not satisfied. The system does not work.
The reason is that implementation is a separate area of ​​expertise. And implementation projects are a separate category of projects.
The author has specialized in these projects for a long time, and all this time he did not believe in the existence of computer application development projects.
For a long time I managed to implement various IT projects, only with an edge affecting the development. This caused wild problems, because I always tried to avoid developers. It is better to introduce a typical product type 1C UPP 8, and then you can refine. And it is quite real, even though many 1C developers do not really believe in it
However, over the past yearI have managed to get lucky to be engaged in implementation projects, closely tied to development projects. It was an extremely difficult year.
After that, the definitions that you read at the beginning of the article were developed.
Probably for application developers - I have not discovered anything new. Those who sit behind the wall from the Internet far from the end users - they are only engaged in computer application development projects - all this is understandable like ash day.
But here are those who work in the IT departments of various organizations, so for them it is all harsh "labor wages."
I bet that in most organizations there are no such processes:
1. development project management
2. release management
3. change management by release
Although the practice of ITIL and says that they are needed, but many of these recommendations are neglected. Or tried, but failed.
I often have to deal with implementation projects, but this year I had to delve into the subject of development and put the above processes on stream.
What did you notice?
1. it became easier to predict resources and costs for the development of an information system
2. developers have more positive in their work, when you close not just a change or release, but a whole project that you have been purposefully pursuing and coordinating for a long time
3. especially good when the project is closed by the developer himself. This is not a minor change - this is already a project. Completely different sensations.
4. and, of course, the quality of development - tails are not lost, a series of changes are more accurate and with fewer errors
5. how far it was possible to understand, in SCRUM - the project’s equivalent is a “request” or “order”, which can come from the “Customer”, and which then needs to be broken down into tasks that can be closed in different releases.
What is your experience with implementing ITIL recommendations? And how do you define a computer application development project? Do they differ from implementation projects?
You need to very well understand the difference between these projects from the rest and especially from the projects of introducing computer applications into the business processes of the organization.
There are two risks that very often result in problems:
')
1. those who specialize in software development do not notice how they are stepping onto the implementation territory and the project begins to inflate ... usually with a fatal outcome;
2. those who specialize in implementation and organizational projects, without understanding the complexity, begin to develop and the quality of the results begins to fall significantly - and this is at best;
For those who are engaged in the net implementation or net development - these problems are unknown. But they are rare lucky ones.
Leaving the details ...
Distinctive features
To begin with, let's look at the criteria by which we can distinguish a computer application development project:
1. the result of such a project is a computer application (web, windows, android, iOS ...), a module (functional block) or some significant change (what is a "significant change" - let's look at below);
2. these projects require deep knowledge of computer application architecture and the corresponding technology stack, but they imply minimal interaction with users or employees involved in any business processes.
Clause 2 - in the part “touch user interaction a little” - this is a key feature that distinguishes the project of developing a computer application from the project of introducing a computer application into business processes. This does not mean that there is no such interaction, of course there is, it is just minimal.
If during the development project, the share of interaction with people begins to increase, then such a project risks developing into an implementation project, and this is another weight category of complexity and risk.
Major changes
A separate subcategory can be identified projects that should run when it comes to a group of changes, united by a single goal, which can last for a long time and affect multiple versions (releases).
If a change or a group of changes fits into one release, you should not start a project.
But if one change pulls up a series of other changes, here it is worth thinking about launching the project, because:
1. These changes need someone to coordinate, because changes can be made by various specialists, and there must be someone who will be in the know and will be able to coordinate different people
2. A single change can lead to changes in other mechanisms of the system; this causes various risks that also need to be taken into account and be prepared for them - this is best done through project management.
3. Often, a change forces developers to duplicate various mechanisms, to make new ones next to old and old mechanisms, upon completion of a series of changes, will need to be removed from the system. Without coordination, these “bits and pieces” can remain there forever, and this entails sad consequences in the long term.
For example :
In the task management system, it was necessary to expand the Participants block. Add the ability to choose not only employees, but also groups
- We started with the development of the interface, it turned out that we need to change the access subsystem
- We started to change the access subsystem, we realized that we need to leave the old one for some time, so a new mechanism was created nearby, without breaking the old one
- Made changes to the interface, made friends with a new model, debugged a new
- Now you need to remove the old mechanism
All 4 points - stretched for 5 months and 3 versions of the development. Without coordination, it would be much longer, and as a result, you could simply lose the target vector and forget about the fact that the old mechanism should be removed.
Dangerous moment
Very dangerous, but also extremely common is the situation when the customer asks to develop a certain system: accounting of finances, the work of sales managers or something like that.
It seems to be a simple development project at first glance. Need to develop something.
But the chances of success of this project is not much, because very soon it turns out that the application is ready, but for some reason the customer is not satisfied. The system does not work.
The reason is that implementation is a separate area of ​​expertise. And implementation projects are a separate category of projects.
The author has specialized in these projects for a long time, and all this time he did not believe in the existence of computer application development projects.
For a long time I managed to implement various IT projects, only with an edge affecting the development. This caused wild problems, because I always tried to avoid developers. It is better to introduce a typical product type 1C UPP 8, and then you can refine. And it is quite real, even though many 1C developers do not really believe in it
Total
However, over the past year
After that, the definitions that you read at the beginning of the article were developed.
Probably for application developers - I have not discovered anything new. Those who sit behind the wall from the Internet far from the end users - they are only engaged in computer application development projects - all this is understandable like ash day.
But here are those who work in the IT departments of various organizations, so for them it is all harsh "labor wages."
I bet that in most organizations there are no such processes:
1. development project management
2. release management
3. change management by release
Although the practice of ITIL and says that they are needed, but many of these recommendations are neglected. Or tried, but failed.
I often have to deal with implementation projects, but this year I had to delve into the subject of development and put the above processes on stream.
What did you notice?
1. it became easier to predict resources and costs for the development of an information system
2. developers have more positive in their work, when you close not just a change or release, but a whole project that you have been purposefully pursuing and coordinating for a long time
3. especially good when the project is closed by the developer himself. This is not a minor change - this is already a project. Completely different sensations.
4. and, of course, the quality of development - tails are not lost, a series of changes are more accurate and with fewer errors
5. how far it was possible to understand, in SCRUM - the project’s equivalent is a “request” or “order”, which can come from the “Customer”, and which then needs to be broken down into tasks that can be closed in different releases.
What is your experience with implementing ITIL recommendations? And how do you define a computer application development project? Do they differ from implementation projects?
Source: https://habr.com/ru/post/177235/
All Articles