9 дней...

Кошка Мийка, продолжение

Тяжело видеть как исчезает в небытии память - запахи, вес на руках, прикосновение шерсти. Постираны и убраны тряпочки (войлочные подстилки), непромокаемое покрывало с дивана, выброшены ставшие ненужными флакончики с остатками антибиотиков, рецепт мази для Mia, Shchelokova...

Кошка Мийка

Кошка Мийка умерла. В ветеринарном госпитале должны были сегодня сделать эвтаназию. Чуда не произошло. 28 декабря 2021 - 28 сентября 2022.

Rapid development: Taming wild software schedules

Rapid development: Taming wild software schedules
Steve McConnel
Microsoft Press, 1996
ISBN: 1-55615-900-5

Despite possible expectation this book is not about software tools and technologies but about project managemet.

Part 1 Efficient Development

1. Welcome to rapid development

2. Rapid-development strategy

3. Classic mistakes

4. Sodtware-Development fundamentals

5. Risk management

Part 2 Rapid development

6. Core issues in rapid development

7. Lifecycle planning

8. Estimation

9. Scheduling

10. Customer oriented development

11. Motivation

12. Teamwork

13. Team structure

14. Feature-Set control

15. Productivity tools

16. Project recovery

Part 3 Best Practices

17. Change board

18. Daily build and smoke test

19. Designing for change

20. Evolutionary delivery

21. Evolutionary prototyping

22. Goal settings

23. Inspections

24. Joint Application Development (JAD)

25. Lifecycle Model Selection

26. Measurement

27. Miniature milestones

28. Outsourcing

29. Principled negotiations

30. Productivity environments

31. Rapid-development languages (RDL)

32. Requirements scrubbing

33. Reuse

34. Signing up

35. Spiral lifecycle model

36. Staged delivery

37. Theory-W management

38. Throwaway prototyping

39. Timebox development

40. Tools group

41. Top-10 risks list

42. User-interface prototyping

43. Voluntary overtime

Read on Jun. 10  - Aug. 20, 2022, approx 27 hours

Making Things Happen

Scott Berkun
Making Things Happen
O'Reilly 2008
ISBN: 9780596517717

Chapter 1. A brief history of project management

• Project management is everywhere, and it's been around for a long time. 
• If you keep a beginner's mind, you'll have more opportunities to learn.
• Project management can be a job, a role, or an activity.
• Leadership and management require an understanding of, and intuition for, several common paradoxes. These include ego/no-ego, autocracy/delegation, and courage/fear.
• Watch out for pretension and over-involvement in your management activity. The process should support the team, not the other way around. 
• If you are a dedicated manager, look for ways to capitalize on your unique perspective of the team and project. 

Chapter 2. The truth about schedules

• Schedules serve three functions: allowing for commitments to be made, encouraging everyone to see her work as a contribution to a whole, and enabling the tracking of progress. Even when schedules slip, they still have value.
• Big schedules should be divided into small schedules to minimize risks and increase the frequency of adjustments.
• All estimates are probabilities. Because schedules are a collection of estimates, they are also probabilities. This works against schedule accuracy because probabilities accumulate (80%×80% = 64%).
• The earlier that estimates are made, the less accurate they are. However, rough estimates are the only way to provide a starting point for better ones. 
• Schedules should be made with skepticism, not optimism. Invest in design to shed light on assumptions and generate reliable confidence.

Chapter 3. How to figure out what to do

• Different projects demand different approaches to planning.
• How planning is done is often determined by who has what authority. Requirements, design, and budget are the three kinds of project authority that impact planning.
• There are some common deliverables for planning projects: marketing requirements documents (MRDs), vision/scope documents, specifications, and work breakdown structures (WBSs).
• The most powerful way to plan a project involves use of three equal perspectives: business, technology, and customer. The customer perspective is often the most misunderstood and misused.
• Asking questions forces good thinking and directs planning energy effectively.
• The process of defining requirements is difficult, but there are good references for how to do it well.
• Problem statements and scenarios are a simple way to define and communicate requirements. They are easily converted into design ideas without losing clarity about what's important and what isn't.

Chapter 4. Writing the good vision

• Vision documents distill other planning materials into a single, high-level plan.
• Writing things down serves the author and the team. It provides the basis for discussion and a point of reference that doesn't rely on our fallible memories.
• The amount of detail in your vision document varies with the nature of the team and the project.
• Team goals should derive from goals defined in the vision. Individual goals should derive from the team goals.
• Good visions are simple, goal-driven, consolidated, inspirational, and memorable.
• Volume does not equal quality. It takes more effort to be concise than not. 
• Keep the vision alive by asking questions about the utility of the vision to daily decisions on the project.

Chapter 5. Where ideas come from

• Many teams don't properly manage the time between requirements and specifications.
• Quality requirements and design explorations are the best use of that time. Ideas are good or bad only in relation to goals or other ideas.
• Constraints are useful in finding ideas, but thinking outside the box isn't necessarily the answer. Sometimes the best solution is finding a clever way to work within the constraints.
• Questions, perspectives, and improvisational games are tools for finding new ideas.
• The best place to start with design ideas is the customer experience.
• Ideas develop into designs through conversations between different people with different kinds of expertise.

Chapter 6. What to do with ideas once you have them

• Ideas have their own momentum. It will take longer to rein in creative work than you expect. Changes will cascade through a project.
• Create checkpoints for creative work to track and manage it. Common checkpoints include proof-of-concept, idea groupings, three alternatives, two alternatives, and one design.
• Use affinity diagrams to consolidate ideas.
• Prototypes enable the project to confront issues early and learn from mistakes without significant risk.
• Use iterations, or the periodic refinement of a prototype, to ask questions, evaluate progress, and decide on the next steps.
• Create an open-issues list to track questions that need to be resolved before specifications can be completed.

Chapter 7. Writing good specifications

• Specs should do three things: ensure that the right product gets built, provide a schedule milestone that concludes a planning phase of a project, and enable deep review and feedback from different individuals over the course of the project.
• Specs solve only certain problems. Team leaders should be clear on what problems they are trying to solve with specs, and what problems need to be solved through other means.
• Good specs simplify. They are primarily a form of communication. Specifying is very different from designing.
• There should be clear authority for who writes and has control over the spec.
• Closing the gap is one approach to managing open issues and to accelerate the end of the specification process.
• A review process is the simplest way to define and control spec quality.

Chapter 8. How to make good decisions

• There is an important skill in meta-decision making, or decisions about which decisions to invest time in.
• Size up decisions before spending too much time on them.
• Look for the zone of indifference and opportunities for effective use of singular evaluation.
• Use comparative evaluation for the decisions worthy of more investment. All decisions have emotional components to them whether we admit it or not.
• Pros and cons lists are the most flexible method for comparative evaluation. They make it easy to involve others and get additional perspectives on decisions.
• Information and data do not make decisions for you.
• You improve at decision making by reviewing past decisions and exploring them for lessons and opportunities for better tactics.

Chapter 9. Communication and relationships

• Projects happen only through communication. In modern times, speed isn't the communication bottleneck, quality is.
• Relationships enhance and accelerate communication.
• There are several frameworks for how people communicate with each other. PMs should be familiar with them so that they can diagnose and resolve communication breakdowns.
• There are several common communication problems, including assumptions, lack of clarity, not listening, dictation, personal attacks, and blame.
• Role definition is the easiest way to improve relationships.
• Ask people what they need in order to do their best work. Ways to do this include: listening, clearing roadblocks, teaching, and reminding them of goals.
• Relationships and communication are not low-priority work. They are essential to all of the individual activities that take place during a project.

Chapter 10. How not to annoy people: process, email, and meetings

• Project managers are prone to annoying others. Some of it is avoidable. People get annoyed for many reasons. Often, it's when they feel their time is wasted, when they are treated like idiots, or when they are expected to endure prolonged tedium and mistreatment.
• Good processes have many positive effects, including accelerating progress and preventing problems. But, they are difficult to design well. Non-annoying email is concise and actionable, and it quickly allows readers to determine whether they are impacted enough to need to read more than the subject line or first sentence.
• Meetings run well when someone facilitates them.
• Frustrating meetings occur when the goals are mismatched to the type of meeting.

Chapter 11. What to do when things go wrong

• No matter what you do, things will go wrong.
• If you can stay calm and break problems down into pieces, you can handle many difficult situations. (Remember the rough guide.)
• There are some common situations to expect, which include oversights, being forced to do stupid things, resource shortages, low quality, direction changes, personnel issues, and threats of mutiny.
• Difficult times are learning opportunities. Make sure you and your team take the time to examine what happened and how it could have been avoided.
• Taking responsibility for situations, regardless of who caused them, always helps to expedite resolving the problem.
• In extreme situations, go into damage-control mode. Do whatever it takes to get the project to a known and stable state.
• Negotiation is useful not only in a crisis situation, but also in management. Good negotiators work from people's interests, not their positions.
• Have clear lines of authority at all times. People should know who has decision-making power before a crisis occurs.
• People respond to pressure in different ways. Be observant and open in how you help the team deal with the different kinds of pressure.

Chapter 12. Why leadership is based on trust

• Trust is built through effective commitments.
• Trust is lost through inconsistent behavior on matters of importance.
• Use the granting of authority and trust to enable people to do great work. Granted power comes from the organizational hierarchy. Earned power comes only from people's responses to your actions. Earned power is more useful than granted power, although both are necessary.
• Use delegation to build trust on your team and to ensure your team against adversity.
• Respond to problems in a way that will maintain people's trust. Support them during crises so that they bring issues to you instead of hiding them. Trust in yourself is the core of leadership. Self-discovery is the way to learn who you are and to develop healthy selfreliance.

Chapter 13. Making things happen

• Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.
• The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal. There is a bright yellow line between priority 1 work and everything else. Things happen when you say no. If you can't say no, you effectively have no priorities.
• The PM has to keep the team honest and close to reality.
• Knowing the critical path in engineering and team processes enables efficiency.
• You must be both relentless and savvy to make things happen.

Chapter 14. Middle-game strategy

• Mid-game and end-game correspond to the middle and end of the project. If on any day the project is not going well, it's your job to figure out what's wrong and resolve it. Repeat this throughout mid-game.
• Projects are complex nonlinear systems and have significant inertia. If you wait to see acute problems before taking action, you will be too late and may make things worse.
• When your project is out of control, you are flying behind the plane, which is a bad place to be. Sanity checking is the easiest way to stay in front of the plane. There are both tactical and strategic sanity checks.
• Consider how to take action to correct a situation in the safest way possible. The larger the action, and the further along the project is, the more dangerous the actions are.
• The coding pipeline is how work items are managed during implementation. There are aggressive and conservative ways to manage the pipeline.
• Milestone-based planning and the coding pipeline provide opportunities to make safe course corrections for projects.
• Change control (DCRs) is how you throttle the rate of medium-and low- level change on a project.

Chapter 15. End-game strategy

• Big deadlines are a series of small deadlines.
• Any milestone has three smaller deadlines: design complete (specs finished), feature complete (implementation finished), and milestone complete (quality assurance and refinement finished).
• Defining exit criteria at the beginning of milestones improves the team's ability to hit its dates.
• Hitting dates is like landing airplanes: you need a long, slow approach. And you want to be ready to take off again quickly, without having to do major repairs.
• You need elements of measurement to track the project. Common elements include daily builds, bug management, and the activity chart.
• You need elements of control to project level adjustments. Common elements of control include review meetings, triage, and war team.
• The end of end-game is a slow, mind-numbing process. The challenge is to narrow the scope of changes until a satisfactory release remains.
• Now is the time to start the postmortem process. Give yourself and your team the benefit of learning from what went well and what didn't.
• If fortune shines on you, and your project makes it out the door, be happy. Very, very happy. Many people, through no fault of their own, never get that far. Plan a grand night. Do ridiculously fun and extravagant things (including inviting this author to the party). Give yourself stories to tell for years to come.

Chapter 16. Power and politics

• Politics are a natural consequence of human nature. When people work together in groups, there is a limited amount of authority, which must be distributed across different people with different desires and motivations. All leaders have political constraints. Every executive, CEO, or president has peers or superiors who limit their ability to make decisions. In general, the more power a person has, the more complex the constraints are that they must work within.
• There are many different kinds of political power, including rewards, coercion, knowledge, referent, and influence.
• Power is misused when it's applied in ways that do not serve the project goals. A lack of clarity around goals, unclear resource allocation or decision-making processes, or misunderstandings can contribute to the misuse of power.
• To solve political problems, clarify what you need. Identify who has it, and then assess how you might be able to get it.
• If you are involved in project management, you are defining a political playing field around you. It's up to you to decide how fair or insane it is.

Read on Jan. 26  - Mar. 20, 2022, approx 25 hours

Project management for the unofficial project manager

Kogon K., Blakemore S., Wood J. 

Project management for the unofficial project manager. 

Franklin Covey Book. 2015 

ISBN 978-1-941631-10-2 

CHAPTER 1: The New World of “Unofficial” Project Management

    Authors briefly analyze the current situation in the project management 

45% of projects are either overdue or canceled altogether. 

Only 45% of projects actually meet the goals they're supposed to meet. 

    They introduce two ideas: 

1. Project management is the work of the twenty-first century. This means that everyone is a project manager. 
2. Project management is no longer just about managing a process. It’s also about leading people—twenty-first-century people. This is a significant paradigm shift. It’s about tapping into the potential of the people on the team, then engaging with and inspiring them to offer their best to the project.

    In the modern world

MANAGE PROJECTS, LEAD PEOPLE

CHAPTER 2: People + Process = Success

The authors explore the difference between formal and informal authority: 

Informal authority inspires people to want to play on your team and win.

They explain "Four foundational behaviors" which will help to earn informal authority:

1. Demonstrate respect 
2. Listen first 
3. Clarify expectations 
4. Practice accountability

And explain the exact meaning and value of each. Also, they briefly introduce five process groups according to PMI:

1. Initiate
2. Plan
3. Execute
4. Monitor and Control
5. Close

CHAPTER 3: INITIATING THE PROJECT: Move Ahead or Go Around in Circles?

Importance of project initiation. Sensitivity to initial conditions. Scope creep. Stakeholders. Key stakeholders (Any person who determines the success or failure of the project). Interview key stakeholders using D.A.N.C.E. (Decisions, Authority, Need, Connection, Energy). Effective interview technic. Creating and approved Project Scope Statement.

CHAPTER 4: PLANNING THE PROJECT: Milestone or Mirage? 

Risk management strategies. Risk assessment - Impact x Probability = Actual Risk. Project schedule. WBS. Project team. Duration. Critical Path. Project budget. Communication plan. 

CHAPTER 5: EXECUTING THE PROJECT: Clear the Path or Fall on Your Face? 

Create team accountability. Team Accountability Session. Performance conversations.

CHAPTER 6: MONITORING AND CONTROLLING THE PROJECT: Keep Your Sanity or Lose Your Mind? 

Keep stakeholders informed about project status. Scope change management. Scope creep vs scope discovery.

CHAPTER 7: CLOSING THE PROJECT: End Happily—or Just End? 

Steps and tools to close the project. Confirm fulfillment of project scope. Complete procurement closure. Document lessons learned. Submit a final status report to stakeholders and obtain required signatures. Archive project documents. Publish your success. Celebrate Project Close with Rewards and Recognition.

To sum up - a nice introductory book in project management with some insights on how to manage projects for people without formal training/appointment.

Read on Dec. 26  - Jan. 16, 2022, approx 7 hours

Pete Millet NuHybrid

Finally decided to buy components and assemble a DIY headphone amplifier designed by Pete Millet http://www.pmillett.com/nuhybrid.html

It looks great and sounds great and it has enough power to pump 250 Ohm Beyerdynamics 990 Pro headphones.

I like the result, the only concern is that the quality of this concrete implementation is not good as it should be because I had to replace some passive elements with equivalents. So the next project is to measure frequency response manually using the EspoTek Labrador board.