From Mr. Tompkins' Notebook

Mr. Tompkins is a pretty decent man already. The first acquaintance with him took place back in 1938, when physicist and Odessa Georgy Antonovich Gamov published in the British magazine Discovery a series of stories about a man who, in his dreams, fell into alternative worlds, where the values ​​of physical constants are radically different from those in the real world that leads to completely unexpected results. So Gamow popularly explained the concepts of modern physics to the inexperienced reader. The unhappy sleepy was that same Mr. Tompkins.

Almost 60 years later, Tom DeMarco decided to share his infinite wisdom and in an equally popular form to present ideas from Peopleware , written in collaboration with Timothy Lister. The result was the “ Project Management Novel ” in which our old acquaintance Mr. Tompkins is abducted by the sexy brunette Laksoy Hooligan and taken to the mysterious country of Morovia, where he has the opportunity to conduct a real experiment on managing software development projects ...

At the end of each chapter, Mr. Tompkins summarizes and records his thoughts, which, in essence, are the axioms and postulates of project management for DeMarco and Lister. Of course, it would be better to read the entire book as a whole — otherwise, it would be impossible to understand how these principles are applied in “real” life. But if there is no time (or just want to refresh the memory), then you are predisposed to your attention ...

Four basic rules of management

• Find the right people.
• Give them the job for which they are best suited.
• Do not forget about motivation.
• To help them rally into one team and work further. (Everything else is administrative nonsense.)

Safety and change

• If a person does not feel safe, he will resist change.
• Changes are necessary for a manager to work successfully (they are probably necessary in any other activity).
• Uncertainty makes a person avoid risk.
• Avoiding risk, a person misses all the new opportunities and benefits that could bring him change.
• It is easy to intimidate a person with direct threats, but you can also just let him know that, if necessary, he can be treated rudely and cruelly. The effect will be the same.

Negative motivation

• Threats - the most inappropriate kind of motivation, if you care about the performance of employees.
• No matter what you threaten, the task will not be completed anyway, if from the very beginning you took too little time to complete it.
• Moreover, if people fail, you will have to fulfill your promises.

Body parts required for project management

• For guidance, we need heart, gut, soul, and scent. So that:
  
  • need to lead the heart;
  • feel gut;
  • to invest in the team and project soul;
  • have a nose for all sorts of nonsense and nonsense.
• Commander-in-Chief on the battlefield as a project management metaphor
• By the beginning of the battle, the commander-in-chief's work was already completed.

Interview and recruitment

• To hire a person to work, the manager needs all his abilities: heart, soul, scent, and the ability to feel gut (for the most part the latter).
• Do not try to hire people alone - it is much better to use the intuition of two managers in this process.
• Ask the new team members to take on the project for the work that they have happened to perform successfully in the past, and postpone other ambitions and growth until the next project.
• Ask for a tip: the person you have chosen for your team can certainly advise who you should hire.
• Listen more, talk less.
• And all this will work better if you slightly tinker a pack.

Productivity increase

• There are no short-term measures that would quickly increase productivity.
• Increased productivity is the result of long-term effort.
• Any performance enhancement that promises immediate results is really nothing more than "bird's milk."

Management of risks

• To manage a project, it is enough to manage its risks.
• Create a risk list for each project.
• Keep track of the risks that cause the failure of the project, not just the final risks.
• Assess the likelihood and cost of each risk.
• For each risk, determine the indicator - a symptom by which you can determine that the risk turns into a problem.
• Assign a special person to manage risk, and let him not support the motto “We can do everything!”, Which cultivates the authorities.
• Create accessible (possibly anonymous) channels for reporting bad news to superiors.

Play defense

• Reduce losses.
• The success of the project can be achieved rather by reducing unnecessary effort than by striving for new victories.
• The sooner you stop unnecessary work, the better for the entire project.
• Do not try to create new teams unnecessarily: look for already existing and well-established teams in the team.
• Leave the teams working together even after the end of the project (if they themselves want it), so that your replacement managers will have fewer problems with badly working teams.
• Consider that a team that wants to continue to work together and beyond is one of the main goals of any project.
• The day we lose at the beginning of the project means as much as the day lost at the end.
• There are a thousand and one ways to spend a day in vain and not one to bring this day back.

Modeling the development process

• Model your assumptions and guesses about how the process will work.
• Discuss these models with your partner to better understand the process and make the necessary corrections.
• Predict work results using a model.
• Compare the results obtained in the simulation process, with the real.

Perverted policy

• At any time you need to be ready to give up work and ask for a calculation ...
• ... but this does not mean that by doing so you will be able to avoid the consequences of a perverted policy.
• Perverted politics will get you everywhere, even in the healthiest and cleanest organization.
• The main sign of a perverted policy: personal goals and influence, rather than the general interests of the company, are at the forefront.
• This can happen even when personal goals directly contradict the goals of the organization.
• One of the side effects of a perverse policy: having a well-staffed team becomes unsafe.

Metric Data Collection

• Determine the size of each project.
• Do not be zealous at first with the choice of the unit of measurement - if you later have to work with real data, to begin with, abstract units will also come down.
• Build complex metrics based on simple (those that are easy to calculate in any software product).
• Collect archival data to read productivity on already completed projects.
• Work on formulas for calculating complex synthetic metrics until the results obtained most accurately reflect the ratio of abstract units to the amount of work specified in the archived data.
• Swipe through the entire archive database trend line, which will show the expected amount of work in the form of a ratio of the values ​​of complex synthetic metrics.
• Now for each new project it will be enough to calculate the value of the synthetic metric and use it when determining the expected scope of work.
• Do not forget about the “noise level” on the performance line and use it as an indicator when determining tolerances from the general trajectory.

The development process and its improvement

• A good development process and its continuous improvement are very worthy goals.
• But there are also working goals and objectives: a good worker will focus attention on them, even if you did not ask for it.
• Formal programs aimed at improving the existing development process will cost the team dearly, both temporarily and in monetary terms. Even individual efforts to improve the process can push the team far back. With regard to the possible increase in productivity, even if this happens, it is unlikely the benefits of this increase will cover the costs.
• One can hope to get a positive result from one of some well weighed and carefully selected improvements in the method of work. In this case, it can cover the money and time it took to implement it.
• Attempting to implement more than one improvement in methodology is a bad thing. Programs aimed at improving many of the techniques and skills (for example, moving to the next level of CMM) are likely to lead to the fact that the time will only increase.
• The danger of a standardized development process is that, after routine operations, people may not notice an opportunity to save time and effort to develop a project.
• As for the excessively large teams, there the standardized process will be strictly adhered to as long as it allows everyone to feel at work (no matter if the project is beneficial or not).

Do the work differently

• There is only one way to reduce development time, when it is already short, to reduce the time it takes to debug the program.
• Projects with high performance require much less time to debug and fix errors.
• Projects with high performance require much more time to design.
• You can't force people to do something differently if you don’t care about them, if you don’t care about them. In order for them to change, you must understand (and appreciate) them themselves, what they do and what they strive for.

What gives pressure from above

• People will not begin to think faster if the leadership will put pressure on them.
• The more overtime, the lower the performance.
• A bit of pressure and overwork can help focus on a problem, understand and feel its importance, but long-term pressure is always bad.
• Perhaps the management likes to apply pressure so much, because it simply does not know how else to influence the situation, or because alternative solutions seem too complicated to them.
• A terrible guess: pressure and overtime are designed to solve only one problem - to keep a good face on a bad game.

Angry boss

• Anger and disrespect are contagious. When top management demonstrates anger and disrespect for subordinates, middle managers begin to replicate their behavior. In the same way, children who were punished in childhood often become violent parents afterwards.
• Disrespect and anger, according to some bosses, should make subordinates work better. This is a typical carrot-and-stick policy. But did disrespect from the authorities ever lead people to work better?
• If the boss shows disrespect for his subordinates, this is a sign that he cannot hold office (and not a sign that he has bad subordinates).

Foggy specs

• The vagueness of the specification indicates that there are unresolved conflicts between project participants.
• A specification that does not have a list of types of incoming and outgoing information should not even be taken into consideration. This means that it simply does not specify anything.
• No one will ever tell you that the specification is bad. People would rather blame themselves for their inability to understand what was written than scold authors of the specification.

Conflict

• The project, in which several parties are involved, will definitely face a conflict of interest.
• The process of creating and distributing software systems is a hotbed of all sorts of conflicts.
• In most companies where software is created, no one specifically deals with the issue of conflict resolution.
• Conflict deserves understanding and respect. The conflict has nothing to do with unprofessional behavior.
• Announce to everyone that you will try to take into account the interests of all participants, and make sure that it is so.
• Difficult to negotiate. It is much easier to mediate.
• Declare in advance that if the interests of the conflicting parties are completely or partially opposed, then the search for a solution will be shifted to the intermediary.
• Do not forget: we are on one side of the barricades. On the other side is the problem itself.

Who is the catalyst of the project

• There are people-catalysts. They help create a healthy team, relationships, morale. Even if they did nothing more (and as a rule, they do much more than that), their role in the project remains one of the most important.
• Mediation is another area in which people-catalysts are simply indispensable. However, mediation can be learned, it is not very difficult.
• The first step to mediation should be a small ceremony. For example, you can say the phrase: "Will you let me try to help you solve this dispute?"

Humans tend to make mistakes

• It seems to us that the worst thing is not to know something. In fact, it is much worse to be sure that you know, when in fact it is not.

About the staff

• If at the very beginning a project is made by a large team, this reduces the efficiency of the most crucial part of the work - defining the system architecture (because all developers should be given some work more likely).
• If the work is distributed to people and teams before the product design stage is completed, it will not be possible to create simple and effective models of interaction between people and working groups.
• This will lead to a loss of independence, an increase in the number of meetings and meetings, and general discontent.
• Ideally, it would be good to first dial a small team that would create a thoughtful system architecture, and only then, at the last sixth of the development time, this team could add new staff (who would work directly on the coding).
• A terrible assumption: it seems that those teams that do not put tight deadlines, finish the job faster!

Sociology problems

• Meetings should be small. To do this, you need to make sure that people are not afraid to skip unnecessary meetings. The easiest way is to publish the agenda in advance, and then always strictly adhere to it.
• Each project needs some kind of ceremony or ritual.
• With the help of ceremonies, one can concentrate the attention of the participants on the main goals and objectives of the meeting: reduce the composition of the working group, improve the quality of the program code, etc.
• Protect people from insults and abuse of bosses.
• Remember: in work fear = anger. Those leaders who like to shout at their subordinates and in every way humiliate and insult them, in fact, they are simply very afraid of something.
• Observation: if for all the display of rudeness and anger towards subordinates would always mean that the boss is simply afraid, then none of the bosses would behave like that simply out of fear that his fear will become noticeable! (This, of course, does not solve the problems of such a leader, but at least protects his subordinates).

About pathological policy (again)

• This pathology cannot be cured from below.
• You should not waste time or put yourself in danger in order to check the previous postulate on your own experience.
• Sometimes the only way out is to wait. Try to wait until the problem resolves on its own or until you find a way to get away from it.
• Miracles, of course, happen, but it's better not to count on them.

Malice and stinginess

• Anger and stinginess - this is the formula that those who are responsible for business failures begin to apply in bad companies.
• Anger and stinginess are directly opposed to the true goals of any good company - to be generous and caring towards their employees.
• When you notice in the company manifestations of anger and stinginess, know that their real reason is fear and fear of failure.

Basics of common sense

• The project should have two deadlines - planned and desired.
• These terms should be different.