Management of software projects: processes, tools, techniques

There are different ideas about how creative work is done. For many people, the creator is a person (poet, artist, inventor) who creates his creation at the moment of insight. Manage your insight? Oh no! It's impossible!

Nevertheless, the task of managing creativity at all times was relevant. Investors, managers, and the state would like to have predictability about when the developed creative product will be released (be it a book, an airplane, a computer program or a movie).

Creative work can be carried out both individually (by one creator - a scientist, artist, composer or poet), and collectively (when collectives of people from different specialties work on the creation of a work). In this article, I would like to concentrate on the issues of managing creative teams using the example of a distributed team of programmers, artists and designers from three countries, which produces an application sold all over the world. More than 10 million copies are sold every year. The annual revenue is 1 billion dollars.

Suppose we wanted to open a restaurant. By what criteria will the client evaluate it? Of course, this is the kitchen, design and service. Usually, the greatest number of “glitches” occurs during the maintenance process, i.e. where the human factor is great. A pretty young waitress seems to be attracting customers. But her mood turned bad, and instead of a friendly attitude, she begins to be rude. As a result, instead of attracting, customers are brave. In the software development industry, this is simply unacceptable. It is necessary that specialists of different specialties interact with each other, and communication barriers and all sorts of subjective things should be reduced to zero. Therefore, when working in a large international team, informal relationships between people are replaced by formalized business processes, and instead of subjective assessments (good,

In large projects, it is more profitable to buy the right specialist in the market, even if his salary seems excessive. When filming a movie, the producer does not teach his screenwriter how to write dialogs if he does not know how to do it, but simply buys a screenwriter to write dialogs on the market. They do the same in application development. If there is a misunderstanding between teams from different countries, then one team is sent on a long trip. With billions in revenue, the cost of a business trip does not matter: the main thing is to release the product on time.


Control options


The process of managing a real project is always based on the control of a group of parameters. It is only at school that one is taught to think by a function of one variable. Unfortunately, some leaders adopt school habits and try to find a universal remedy for management problems - a sort of pill for all diseases.

Example.In one company engaged in the development of mobile games, it was customary to write out a task on a card and put this card on a board. The board was lined with several vertical stripes. Each bar corresponded to a certain state of the problem. New tasks were placed in the far left lane. Then, as they progressed, they gradually moved to the right. The main criterion for success was management considered moving the card on the board from left to right. One of the drawbacks of this approach is the lack of consideration that work on a task may be suspended for a number of reasons, and the contractor may temporarily switch to another task. Another drawback is the number of tasks that are being worked on. In our project, within 1 month it was necessary to complete 200 tasks. Clear,

Here is a list of parameters that a project manager should control:

1. Timing.
2. Volume (number of useful functions).
3. The amount of work.
4. Utility (value for the Consumer).
5. Technical and technological complexity.
6. External quality (from the point of view of the Consumer).
7. Internal quality (from the point of view of a specialist, engineer, designer).
8. Risks.
9. The psychological state of the team.

Management processes


To control the parameters, processes are used, each of which comes down to a specific set of tools and procedures for their application. We list some of the processes that will be discussed below:

1. Task management.
2. Time management.
3. Quality management.
4. Risk management.

Task management


Appointment


Assessment of the volume of work and the distribution of tasks between employees.

Task control system


Goals


1. Evaluate and record the amount of work.

Note. Employees should not invent classes for themselves, but engage in tasks from a pre-approved list.

Example. At one job, I had a boss who answered the question “How long should this task be completed?” - always gave the same answer: "Yesterday." Later, when I became the boss, I became convinced that a mirror situation was happening with programmers. You ask someone: “When will you finish this work?” - and you get the answer: “Tomorrow by dinner. In the worst case, in the evening. ” But a day passes, another, and the task is still not done. In order to get into such situations as rarely as possible, we need a tool that prompts regularly the remaining amount of work.

2. Distribute tasks among employees. Make sure that every employee has a task, and not one of them is idle.

Note: According to the Minister of Economic Development of Russia (May 21, 2012 - June 24, 2013) Andrei Belousov, labor productivity in our country is 2-3 times lower than in developed countries, depending on the calculation methodology ( http://www.forbes.ru / kompanii / 245905-v-kakikh-otraslyakh-rabotayut-samye-neeffektivnye-rossiiskie-kompanii ).

Example. If you have ever watched how an accident on a heating main is being repaired, you probably noticed that one worker is digging a hole, and around him 10 people are standing and watching how it works.

You should also make sure that employees do not neglect some tasks to the detriment of others.

Example. In one of St. Petersburg's hypermarkets, plumbing department sellers prefer to be near Italian toilets and hot tubs, because the premium for selling expensive plumbing equipment is higher. As a result, if the Buyer wants to purchase a coupling or crimp, then he has no one to consult with. This is how sellers perform some tasks and ignore others. It turns out that employees set themselves or choose tasks that are “tastier”.

3. Find dependencies between different tasks.

Note (Vasilina Abu-Navas, Business Consultant, Practician Association):The task must necessarily be consistent with the tasks of other employees, the entire project or its part. Because, continuing the example with the worker, it may turn out that the worker dug up a hole, received money, all 10 “bosses” reported, and the next day he received an order to dig the hole urgently, because, for example, the president would take this road. They knew about this for a long time, they simply “forgot” to warn. And those who “dug”, as usual, did not specify the parameters of their task ... Or the worker dug a hole, but it turned out that he had to dig a little wider or a little deeper ... That is the task may be relevant, but at the same time it is not coordinated or not accurate.

4. Determine which tasks are blocked for one reason or another.

Example.According to the standards of the Kommersant newspaper, at one time the materials of journalists, drawings of artists and photographs of photojournalists had to be submitted by 6 o’clock in the evening. The editors also have a special person - a rewriter, whose task is to bring all the texts under a single style.

Description


The task control system can be presented in the form of a spreadsheet.

Table 1. Task List for GPS Mobile Navigation System
Title
Status
Responsible
Region
Residual labor (hours)
Add Intersection Search Screen
New
Ivanov I.I.
Address Search
24
Add hairdressers to the database for a map of Russia
Performed
Petrov P.P.
Search for places
8
Add new card design styles
Completed
Sidorov S.S.
Map
0
Find out why the route is not being built through the ring road in St. Petersburg
Blocked
Dmitriev D.D.
Route building
12

Parameters


The name briefly describes the essence of the changes. In the ideal case, it should contain a verifiable criterion by which one can judge whether the task is completed or not.

Examples:
  • Add a crossroads search screen. ( Note: The tested criterion is the screen. It either exists or does not exist.)
  • To find out why the route is not being built through the ring road in St. Petersburg. ( Note: The tested criterion is the construction of a route through the ring road.)

The name of the task may include the name of the program area (subsystem) to which the task belongs. This helps with a cursory glance at the task to understand which specialist should be assigned to it.

Examples:
  • Database - Search for places - Add hairdressers to the database for Russia. ( Note: The task immediately relates to two areas: from a technical point of view, to the database, because it needs to be changed; from a user point of view, to the search for places, because you can check the change in this section of the navigation system.)
  • Interface - Maps - Add new styles to the design of maps. ( Note: This task can also be attributed directly to two sections of the navigation system: the user interface, where you can choose the style of map design, and the map visualization subsystem.)


The subsystem can be indicated not only in the name of the task, but also in a separate column. This will allow you to “beat statistics” and evaluate the amount of work related to a particular part of the program.

If different subsystems of the program have different requirements for qualifications, knowledge and experience of employees, then such statistics allows us to assess the need for appropriate specialists.

A pie chart is best suited for the visual presentation of statistics:



Figure 1. Scope of work on the GPS mobile navigation system

The status of the task allows you to determine which tasks have already been completed, which are being carried out, and what tasks the work has not yet begun. It is recommended to have a special status, which signals that the task is blocked. If the employee establishes such a status, this means that the task is impossible for one reason or another.

Example. The task “Replace icons” cannot be completed if the artist did not have time to draw these icons.

The residual labor input contains an actual assessment of the task - how much time is left before the task is completed. It is given by the contractor at the end of each working day. Thus, the task is regularly reevaluated. This allows you to monitor progress and take certain measures in time if the team does not keep up to date.

Using


Initially, tasks are entered into the task control system at the project planning stage. The main difficulty lies in the fact that it is rather difficult to foresee all the tasks and accurately assess the time it will take to complete them.

It is recommended to work on the project iteratively - two-weekly or weekly iterations. (Iteration helps to quickly make some finished piece of work and quickly get feedback.) At the beginning of each iteration, detailed planning is performed, as a result of which iteration tasks are selected. If necessary, the tasks are detailed, and their wording and assessments are specified.

BY


To manage tasks, you can use ready-made free or low-cost task control systems:

A complex, sophisticated and expensive project management system can be replaced by the symbiosis of Redmine and Excel.

Time management


Appointment


Evaluation and monitoring of project implementation timelines.

Task combustion diagram


Goals


Allows you to:

1. Assess the current residual amount of work.

Example. The most common approach to managing timelines is by-eye control: “Like, do you have time to complete the task by Friday?” In the most striking form, I came across such an approach in a Russian-German company. On my first working day, a German owner came up to me and asked: “I have a birthday in three months. Will you manage to release the game for my birthday? ”

2. Determine the amount of lag from the plan.

3. Assess the progress of each employee and the entire team.

Note. In this case there will be a family of diagrams.

Diagram



Figure 2. The progress of the employee (real and predicted)

Description


To create a curve, an auxiliary table is constructed, in which the first column lists the names of employees, and the remaining columns contain the residual amount of work of the employee in hours for a specific date.

Instead of one digit, two are indicated - how much time is really left and how much should have remained according to the plan.

Table 2. Progress of employees
FULL NAME.
08/31/14
09/01/14
09/02/14
09/03/14
09/04/14
09/05/14
Ivanov I.I.
Really
38
32
28
20
14
8
Plan
38
thirty
22
14
6
0
Petrov P.P.
Really
40
32
26
18
eleven
0
Plan
40
32
24
16
8
0


Note (Anton Yakovlev, programmer): The approach described is obviously convenient in case of using Excel. With other systems, the approach may be different - Hansoft can generate such diagrams on its own.

Parameters


The diagram is two curves. One of them (drawn by a dotted line) shows the planned decrease in the volume of work, i.e. the way it should be. The second curve (drawn by a solid line) represents a real change in the volume of work. Each point on these curves is the planned or real amount of work that remained at the end of the day.

Using


Curves are plotted both for each employee individually and for the entire team as a whole.

At the end of each working day, data - the amount of remaining work in hours - is entered in the table. The data is taken from the column "Residual time-consuming" task table.

The reasons for the increase in the terms of tasks are analyzed and subsequently entered into a special knowledge base of the company.

Quality control


Appointment


Ensuring proper product quality.

Example. In 2013, the number of divorces in Russia amounted to 54.5% of the number of registered marriages ( http://womanadvice.ru/statistika-razvodov-v-rossii ). Such a number of “marriages” in the software development industry is simply unacceptable. Despite the fact that the state is an interested party in reducing the number of divorces, the reasons for such sad statistics are not collected and analyzed by the state. But when developing software, this is done.

Large corporations plan product quality prior to development. They not only predict the number of defects that will be found during the work on the project, but also the number of defects that will not be fixed.

Example.In one of the projects, 30 thousand (!) Defects were found. Of these, 15% have not been fixed. Despite the fact that these are non-critical or very rare errors, nevertheless, we can say that the application was released with 4,500 errors.

Defect forecast


Goals


  1. Assess the complexity of the project.
  2. Assess the resources needed to fine-tune quality.


Description


If the application is released on a regular basis (for example, each year a new version), then the forecast is reasonable based on historical data. It can be presented in the form of a table, which provides statistics on previous versions and forecast indicators for the new version.

Table 3. The forecast of the number of defects for the mobile navigation system GPS
Region
2013 year (reality)
2014 (forecast)
User interface
243
250
Route building
113
100
Address Search
53
fifty
Search for places
17
20
Map
194
200
Navigation
89
100
Audio
67
fifty
Total
776
770

Parameters


The column "Region" lists the subsystems of the program. They can be obtained by logical division for various reasons. Sometimes a program is divided into parts from the user's point of view (as in the table below). In other cases, technical criteria are used.

The middle column shows real historical data - the number of defects that were found in various parts of the program in the previous version of the program.

The last column indicates the forecast data - how many defects will be found in one or another part of the program when developing its next version.

Using


When the project starts, the quality control department creates a forecast for bugs. The historical data, the projected amount of work, the complexity of the requirements for the new version of the application, as well as the experience of the team itself are taken into account.

The forecast is given by subsystem. To increase accuracy, two different models are used. The first model involves splitting the program into subsystems based on various technical criteria.

For instance:
  • User interface
  • Database
  • Audio
  • Algorithms


The second model provides for dividing the program into subsystems according to user functions.

For instance:
  • Drawing a map
  • Route building
  • Navigation
  • Address Search


Different forecast models complement and test each other.

The forecast of the number of defects is not a simple formality, but a serious tool for planning work. It helps to determine the number of engineers by the quality that they are going to attract to the project. The forecast also allows you to calculate the time required to stabilize the program.

The forecast of the number of defects is a fairly conservative tool. Management reviews it very reluctantly, because any downward review of it can lead to the fact that difficult to reproduce errors will not be searched. It is assumed that in the absence of an appropriate standard, quality engineers will simply relax and do their job worse than they could.

Example.In one of the projects, the actual number of defects was below the predicted value. According to statistics, quality engineers could not cope with their work, because found fewer errors than ensued from the forecast. Despite the fact that the absence of a significant number of defects was objectively caused by the small number of implemented requirements, managers were afraid that there were hidden errors in the program and therefore did not revise the forecast for a long time, but preferred to arrange processing on weekends.

Defect Search Plan


It is a detailed forecast of the number of defects, disaggregated by subsystem and time. As a rule, a week is selected per unit of time.

Goals


  1. Distribute the resources responsible for quality control over time.
  2. Get a mechanism for monitoring the work of quality engineers.

Note: A defect search plan sets standards for all quality engineers. It is based on a previously made forecast by distributing the total number of defects by project weeks. The team of quality engineers receives weekly assignments - how many defects in the program it should find within a given week. Weekly tasks can be further detailed - by day and by employee. As a result, tasks for each engineer for each day will be obtained.

Description


The defect search plan is a table in which the desired performance indicators of the entire team of quality engineers for each week of the project are entered.

Table 4. Weekly defect search plan for the GPS mobile navigation system
Region
09/01/14
09/08/14
09/15/14
09/22/14
User interface
5
5
10
12
Route building
3
3
5
7
Address Search
5
5
5
8
Search for places
0
1
2
3
Map
3
5
7
8
Navigation
8
10
10
12
Audio
0
1
2
3
Total
24
thirty
41
53

Parameters


In each cell opposite the name of the subsystem, the
number of defects that will be found in it within a certain week is indicated .
Week end dates are specified in column headings.

Diagram


Based on the plan, a defect search schedule is constructed, which is an S-shaped curve.

The vertical axis shows the total number of defects found “in percent”, and the horizontal axis represents time.

The chart also postpones the key dates of the project: alpha, beta and final version.


Figure 3. A graphical representation of the defect search plan for the entire duration of the project

Using


Visually, three stages can be distinguished on the curve.

The first stage begins with the start of the project and ends with the release of the alpha version. At this time, the curve does not grow so intensely, because prior to the alpha version, priority is given to developing the program, rather than finding defects. Not all requirements are yet implemented, but what has been done may not be fully implemented.

In the second stage, between the alpha and beta versions, the curve grows very intensively. This is because at this point almost all of the planned requirements have already been implemented, and additional quality engineers are involved in testing the program, and programmers switch from implementing requirements to fixing defects.

Shortly before the beta, there are not many defects left. The most obvious ones have already been found and fixed. Unobvious errors begin to appear, which are more difficult to find and correct. The curve slows down its growth. And after some time, non-obvious errors also appear to be fixed, and the curve stops growing. At this point, a beta version of the program is being released. And then - if no new errors are detected - the final version is released.

By the time of the alpha version, the testing department should have found 30% of all defects. By beta, 98% of all defects should be found.

Management of risks


Appointment


To envisage risks that may complicate or disrupt the project, develop an action plan in case of a risk occurrence to neutralize its consequences.

Note: In systems engineering, there is a methodology called “Failure Modes and Effects Analysis,” https://ru.wikipedia.org/wiki/FMEA . According to the US Department of Defense standard, this procedure analyzes potential errors of the system, determines the results of their influence both on the system as a whole and on various subsystems, and classifies errors in relation to their criticality.

Risk management is similar to the analysis of the types and consequences of failures: risks are identified, their negative impact on the project is assessed, solutions are found to neutralize the negative consequences.

Risk register


Goals


1. Describe the identified risks.

Note: One of the characteristic problems in a number of companies (which are not even distributed and employees are in the same office) is that people do not share their experience. There is no exchange of information about standard errors, risks, decisions. We need to pull it all out into the white light and make it accessible to the whole company.

Note (Vasilina Abu-Navas, business consultant, Praktik association): There is even more: you need to describe the solution right away (if possible, you should find the perfect solution). Those. to identify the risk is not enough - you must immediately think about how to prevent it. Otherwise, the risks remain a "rake".

Example (Vasilina Abu-Navas, business consultant, association "Practitioner"):Our Client was faced with the task of unfreezing working capital in the amount of 25 million rubles for 1 month. It seemed that we took into account all the risks, except taxes, because the CFO was on vacation, and knowing that this task would be solved, he said nothing . We made an excellent plan for defrosting funds and implemented it. As a result, they hit a profit tax. If this risk were taken into account, it would be possible to spend the proceeds on the acquisition of real estate, and thereby avoid paying tax.

2. Assess the importance of each risk and the likelihood of its occurrence.

Example.The risk that the project will close due to a meteorite entering the office of the company is of high importance. Nevertheless, the probability of its operation is so low that it painlessly allows you to ignore this risk.

Example. One company developing a GPS navigator decided to change the map provider. The reason for the change is simple - the license cost is 2 times lower, and the card description format is the same. Nevertheless, the price of switching to the cards of the new supplier cost the company 2 to 3 person-years. That is how much effort has been spent on solving the technical problems that have arisen.

3. Offer an action plan in case the risk works.

Example.When creating one game for little girls, there was a serious risk of not meeting the deadlines. There were several reasons for this risk: a new team, an unfamiliar platform for which development was underway, and the lack of a well-functioning technological infrastructure. To reduce the risk, it was decided to organize the game in the form of a sequence of mini-games. Each such game was quite simple, not too rich in graphics and other characters. In addition, the player was deprived of freedom of movement, i.e. could only move in predetermined directions. This simplified the development process so much that one mini-game in the final quality was created in 5 person-days (this refers to the work of an engineer without taking into account the work of the artist).

4. Distribute risks among those responsible for their elimination.

Description


All identified risks are entered in a special table, as in the example below.

Table 5. Risk table for the GPS mobile navigation system
Risk
Importance
Probability
Weight
What to do?
Responsible
condition
If programmers do not receive new cards from the supplier before October 15, they will not be included in the release.
Average
Low
2
Contact the supplier by phone and send a reminder by email
Sergeev A.D.
Need to be reminded a couple more times
If the marketing department does not provide customer reviews before September 1, the team will not be able to take them into account in the next release
High
High
9
Request Marketing
Vladimirov K.P.
Received, located on the server in the 'Reviews' folder

Parameters


Each risk is written according to the formula:

If something is not <done> before the <certain date>, then <something negative will happen>.

Each risk should be evaluated in terms of its importance, i.e. negative consequences for the project when it is triggered. Usually limited to a scale of three ratings: low, medium and high.

The likelihood of a risk being triggered should also be assessed. For evaluation, you can also limit yourself to three values: low, medium and high.

The risk weight is calculated automatically based on its importance and probability. To do this, the estimated values ​​are converted into numerical values ​​as follows: the “low” value becomes equal to 1, “medium” - 2, and “high” - 3. Weight is calculated as the product of two ratings. For example, if the importance of the risk is high and the likelihood of its occurrence is also high, then the risk receives a weight of 9.

Using


With limited resources, you should first pay attention to the risks with the greatest weight.
When describing the risk, an action plan should also be added in case of its occurrence or to reduce the likelihood of its occurrence and / or its importance. For each risk, a person is appointed who is responsible for its neutralization.

Conclusion


  1. Software development projects are both individual and collective.
  2. Коллективные программные проекты требуют координации усилий многих людей. Нередко эти люди обладают разными специальностями, находятся в разных странах и на разных континентах и разговаривают на разных языках.
  3. Крупные корпорации имеют опыт по управлению достаточно большими (100 – 200 человек), интернациональными и распределёнными творческими коллективами. Этот опыт можно переосмыслить и использовать.
  4. Процесс управления реальным проектом основан на контроле целой группы параметров. Это только в школе учат мыслить функцией от одной переменной.
  5. Для контроля параметров управления рекомендуется использовать процессы управления, среди которых есть: управление задачами, управление сроками, управление качеством, управление рисками и т.д.
  6. Each of the management processes comes down to one or more tools and methods of their application. Among the tools there are: a task control system, a task combustion chart, a forecast of the number of defects, a plan for finding defects, a risk register.

The author thanks Vasilina Abu-Navas (Association "Practitioner"), I.L. Vikentieva (TRIZ-CHANCE system), Eduard Galiaskarov and Anton Yakovlev for their help in preparing the article.

Also popular now: