Projects for the development of computer applications. Features

    The scope of project management is very extensive, from the organization of events (not a material result), to construction (a house is a very material result). And in this area, we can separately distinguish the category of projects “computer application development”.

    You need to understand very well the difference between these projects from the rest and especially from the projects of introducing computer applications into the organization’s business processes.

    There are two risks that often result in problems:

    1. those who specialize in software development do not notice how they step on the territory of implementation 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 in the best case;

    For those who are engaged in a clean implementation or clean development - these problems are unknown. But these are rare lucky ones.

    Going into the details ...

    Distinctive features


    To begin, let's analyze 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 “ significant change ”- we will analyze below);

    2. these projects require in-depth knowledge of the architecture of computer applications and the corresponding technology stack, but at the same time involve minimal interaction with users or employees involved in any business processes.

    clause 2 - in the part “little affect interaction with users” - this is a key feature that distinguishes a computer application development project from a project for 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 proportion of interaction with people begins to increase, then such a project risks escalating into an implementation project, and this is another weight category of complexity and risks.

    Significant changes


    A separate subcategory can be identified projects that are worth launching when it comes to a group of changes united by one goal, which can last a long time and affect several versions (releases).

    If a change or a group of changes fits into a single release, you should not start a project.

    But if one change pulls a series of other changes, then it’s already worth thinking about starting a project, because:

    1. These changes need to be coordinated by someone, because various specialists can make changes, and there must be someone who will be in the know and able to coordinate different people

    2. One 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 - it is best to do this through project management

    3. Often the change forces developers to duplicate various mechanisms, make new ones alongside old ones and old mechanisms to complete a series of changes will need to be removed from the system. Without coordination - these “flaws” can remain there forever and this entails sad consequences in the long run.

    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 it was necessary to change the access subsystem

    - They began to change the access subsystem, realized that it was necessary to leave the old one for a while, therefore, they created a new mechanism nearby, without breaking the old one

    - Made changes to the interface, made friends with the new model, debugged the new one

    - Now you need to remove the old mechanism

    All 4 points - stretched by 5 months and 3 versions of 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 needs to be removed.

    Dangerous moment


    A very dangerous, but also extremely common, situation is when the customer asks to develop some kind of system: accounting for finances, the work of sales managers or something like that.

    At first glance, it seems to be a normal development project. Something needs to be developed.

    But this project has not much chance of success, 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 ​​knowledge. And implementation projects are a separate category of projects.

    The author 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 was able to implement various IT projects, only affecting development over the edge. This caused wild problems, therefore I always tried to avoid developers. It is better to introduce a typical product of type 1C UPP 8, and then you can modify it. And this is quite real, although many 1C developers do not really believe in it.

    Total


    However, over the last year I ugorazdilo I was lucky to be engaged in the implementation of projects closely tied to development projects. It was an extremely difficult year.

    After that, those definitions were developed that you read at the beginning of the article.

    Probably for application developers - I have not discovered anything new. Those who are sitting behind a wall from the Internet far from end users - are only involved in computer application development projects - all this is understood as ash day.

    But those who work in the IT departments of various organizations, for them it’s all a harsh “work day”.

    I bet that in most organizations there are no such processes:

    1. development project management

    2. release management

    3. release change management

    Although ITIL practice says that they are needed, 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 topic of development and put the above processes on stream.

    What did you notice?

    1. It has become easier to predict the resources and costs of developing an information system

    2. Developers have more positive work when you close not just a change or release, but a whole project that has been purposefully led and coordinated for a long time

    3. It is especially good when the developer closes the project . This is not a minor change - this is already a project. Very different sensations.

    4. and, of course, the quality of development - the tails are not lost, a series of changes are more accurate and with fewer errors

    5. as far as I can understand, in SCRUM - the analog of the project is “request” or “order”, which can come from the “Customer”, and which then needs to be broken down into tasks which 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 you distinguish them from implementation projects?

    Also popular now: