From Mr. Tompkins Notebook

    Mr. Tompkins is already a pretty decent person. The first acquaintance with him took place back in 1938, when the physicist and Odessa citizen Georgy Antonovich Gamov published in the British journal 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, which leads to completely unexpected results. So Gamow popularly explained the concept of modern physics to an inexperienced reader. The hapless sleepyhead was the same Mr. Tompkins.

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

    At the end of each chapter, Mr. Tompkins sums up and writes down his thoughts, which, in essence, are axioms and postulates of project management for DeMarco and Lister. Of course, it would be better to read the whole book as a whole - otherwise you will not understand how these principles are applied in "real" life. But if there is no time (or you just want to refresh your memory), then your attention is expected ...

    Four basic management rules


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

    Security and Change


    • If a person does not feel that he is safe, he will resist change.
    • Changes are necessary for the leader to work successfully (they are certainly 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’s easy to intimidate a person with direct threats, but you can also just let him know that on occasion they can be treated rudely and cruelly. The effect will be the same.

    Negative motivation


    • Threats are the most inappropriate kind of motivation if you care about employee productivity.
    • Whatever you threaten, the task will still not be completed 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 Needed for Project Management


    • Leadership needs heart, gut, soul, and scent. So that:
      • need to lead the heart;
      • feel inwardly;
      • invest in the team and project;
      • to 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 work of the Commander-in-Chief has already been completed.

    Job interview and recruitment


    • To hire a person to work, the manager needs all his abilities: heart, soul, scent and the ability to feel with one's gut (for the most part the latter).
    • Do not try to hire people alone - it is much better to involve the intuition of two managers in this process.
    • Ask new team members to take on the project for the work that they have already successfully completed in the past, and to postpone other ambitions and growth until the next project.
    • Ask for a tip: the person you selected to join your team will probably advise who else you should hire.
    • Listen more, speak less.
    • And all this will work better if you slightly rig the deck.

    Productivity increase


    • There are no short-term measures that would quickly increase productivity.
    • Increased productivity is the result of long-term efforts.
    • Any productivity boost that promises immediate results is actually nothing more than bird 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 are causing the project to fail, not just the ultimate risks.
    • Assess the likelihood and cost of each risk.
    • For each risk, define an indicator - a symptom by which you can determine that the risk turns into a problem.
    • Assign a special person for risk management, 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


    • Cut losses.
    • The success of the project can be achieved by reducing unnecessary efforts rather than 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 in the team for already existing and worked out teams.
    • Leave the teams to work together even after the end of the project (if they themselves want it), so that the leaders who come to replace you have less problems with badly working teams.
    • Consider that a team that wants to continue to work together further 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 is a thousand and one ways to spend a day in vain and not a single one to bring this day back.

    Development Modeling


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

    Perverse politics


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

    Metric Data Collection


    • Determine the size of each project.
    • Do not be zealous at first with the choice of a unit of measurement - if later you have to work with real data, abstract units will come down to begin with.
    • Build complex metrics based on simple ones (those that are easy to calculate in any software product).
    • Collect historical data to calculate labor productivity for already completed projects.
    • Work on the 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 archive data.
    • Draw a trend line through the entire archive database that will show the expected amount of work as 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 to determine the expected amount of work.
    • Do not forget about the “interference level” on the performance line and use it as an indicator when determining the permissible deviations from the general path.

    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 employee will concentrate on them, even if you did not ask him about it.
    • Formal programs aimed at improving the existing development process will cost the team dearly - both temporarily and financially. Even individual efforts to improve the process can push the team far back. As for a possible increase in productivity, even if this happens, the benefits of this increase are unlikely to cover the costs.
    • One can hope to get a positive result from one well-balanced and carefully selected improvement in the working method. In this case, it can cover the money and time required for its implementation.
    • Trying to implement more than one methodology improvement is a disastrous business. Programs aimed at improving many techniques and skills (for example, moving to the next level of CMM) are likely to lead to a time increase.
    • The danger of a standardized development process is that during routine operations, people may not notice the opportunity to save time and effort in developing a project.
    • As for the excessively large teams, there the standardized process will be strictly followed as long as it allows everyone to feel at work (it does not matter whether it is useful for the project or not).

    Do the job differently


    • There is only one way to reduce development time when it is already not enough - to reduce the debugging time of the program.
    • High-performance projects require much less time to debug and fix bugs.
    • High-performance projects require much more design time.
    • You can’t get people to do things differently if you don’t care about them, if you are not interested in them. For them to change, you must understand (and value) themselves, what they do and what they strive for.

    What gives pressure from above


    • People will not begin to think faster if management will put pressure on them.
    • The more overtime, the lower the productivity.
    • A little pressure and overtime can help focus on the problem, understand and feel its importance, but long-term pressure is always bad.
    • Perhaps management is so fond of applying pressure because it simply does not know how else to influence the situation, or because alternative solutions seem too complicated to them.
    • A terrible hunch: pressure and overtime work are designed to solve only one problem - to maintain a good face in a bad game.

    Angry boss


    • Anger and disrespect are contagious. When senior management demonstrates anger and disrespect for subordinates, middle managers begin to copy their behavior. Similarly, children who are punished in childhood often later become violent parents.
    • Disrespect and anger, according to some bosses, should make subordinates work better. This is a typical carrot and stick policy. But has ever disrespect from the authorities led to the fact that people began to work better?
    • If the boss demonstrates disrespect for his subordinates, this is a sign that he cannot occupy his position (and not at all a sign that he has bad subordinates).

    Foggy specs


    • The ambiguity of the specification indicates that there are unresolved conflicts between the 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 are more likely to blame themselves for their inability to understand what is written than to scold the authors of the specification.

    Conflict


    • A project in which several parties are involved is bound to run into a conflict of interest.
    • The process of creating and distributing software systems is a hotbed of all kinds of conflicts.
    • In most companies where software is created, no one specifically deals with conflict resolution.
    • Conflict deserves understanding and respect. Conflict has nothing to do with unprofessional behavior.
    • Report to everyone that you will try to take into account the interests of all participants, and make sure that it is so.
    • Hard to negotiate. It is much easier to mediate.
    • Announce 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 an intermediary.
    • Do not forget: we are on one side of the barricades. On the other side is the problem itself.

    Who is the catalyst for the project?


    • There are catalyst people. They help create a healthy team, relationships, fighting spirit. Even if they didn’t do anything else (and as a rule, they do so much), their role in the project remains one of the most important.
    • Mediation is another area in which human catalysts are simply irreplaceable. However, mediation can be learned, it is not very difficult.
    • The first step to mediation should be a small ceremony. For example, you could say the phrase: “Will you let me try to help you resolve this dispute?”

    Humans tend to make mistakes


    • It seems to us that the worst thing is not to know something. Actually, it’s much worse to be sure that you know when it’s actually not.

    About staff


    • If at the very beginning the project is made by a large team, this reduces the effectiveness of the most critical part of the work - determining the architecture of the system (because all developers need to be given some work soon).
    • 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 work groups.
    • This will lead to a loss of independence, an increase in the number of assemblies and meetings, and general discontent.
    • Ideally, it would be good to first type a small team that would create a well-thought-out system architecture, and only then, for the last, sixth part of the development time, you could add new staff to this team (who would work directly on coding).
    • A terrible assumption: it seems that those teams that do not have tight deadlines finish work faster!

    Problems of sociology


    • Meetings should be small. To do this, you need to make sure that people are not afraid to skip meetings they do not need. 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, you can focus on the main goals and objectives of the meeting: reduce the composition of the working group, improve the quality of program code, etc.
    • Protect people from insults and abuse of the authorities.
    • Remember: fear = anger in work. Those leaders who like to yell at their subordinates and humiliate and insult them in every possible way, are really just afraid of something.
    • Observation: if for everyone the manifestation of rudeness and anger towards subordinates would always mean that the boss is simply afraid, then none of the bosses would behave simply out of fear that his fear would be 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.
    • Do not waste time or endanger yourself in order to verify the previous postulate from your own experience.
    • Sometimes the only way out of the situation is waiting. Try to wait until the problem resolves on its own or until you find a way to get away from it.
    • Miracles, of course, do happen, but it's better not to count on them.

    Anger and stinginess


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

    Common Sense Basics


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


    Also popular now: