Video Summary - Риски и оценки: фрагмент курса Crash course

Main ideas and lessons

Engineering work is constrained by “expectations” coming from money/resources, demands, and deadlines, with an implied end state of “satisfied expectations.”
Expectations are framed as three things:
1. Deadlines (time)
2. Functionality (what is promised vs. what is delivered)
3. Quality (harder to assess; split into objective vs. subjective views)

Quality: two notions

Objective quality (roughly measurable): e.g., bug rate per unit time (though even this depends on QA team quality).
Subjective/perceived quality: an expert reviews code and judges it against criteria tied to their expertise (which is itself difficult to measure).

Risks: primarily about timing impact

A simplified definition: risks are things that can affect the timeline.
In Scrum, if you risk missing a sprint deadline, you often cut functionality rather than move the deadline.
The video/course focuses on risks as they relate to when fixed functionality is actually completed, a viewpoint clearer in Kanban.

Five sources/classifications of risk (as presented)

The speaker identifies five sources, noting that real risks often blend multiple categories.

Technology risks
- Choosing untested technology → unexpected problems.
- Known technology suddenly causes fundamental bugs (e.g., in kernel-level components).
- Needing to learn new technology that no one on the team has deep experience with.
Communication risks
- Adding people slows the team due to communication overhead.
- Rule of thumb stated: team efficiency scales roughly with 0.9^(number of people) (example: 2 people → 0.81; 3 people → ~0.72), causing substantial lost efficiency.
- Includes misunderstanding, being misunderstood, etc.
Management risks
- Management introduces risk because it takes actions aligned with management goals.
- Example: customer changes priorities (“We need this, not that”), which the project team can’t fully control.
External factors
- Anything outside the team/system: disasters, outages, or interaction with external systems.
- External systems are risky because you can’t order them—only request coordination.
“You” risks (performer-related)
- Everything tied to the individual: illness, inability to work, reading misunderstanding, and ordinary human error.
- Includes also the person’s risk perception.

Key properties: risks are subjective

Risks are subjective because there is no universal “risk meter” for probability and cost impact.
Different people evaluate risks differently based on knowledge, experience, and technological familiarity.
Improvement goal: develop better risk identification (recognizing risks) and better handling of how risks are perceived and acted upon.

What constitutes “risk” (5 integral parts)

Risk requires five elements; if any are missing, it’s not a proper risk but “a conversation” instead.

What can happen (description of the event)
Probability (how likely it is)
Assessment of likelihood → expected impact
Proposed response/workout plan
- How to prevent it or reduce severity
Recorded decision/action outcome
- What was actually decided and will be done (must be written down)

How to reduce risk (two directions)

Risk mitigation reduces in two simultaneous directions:

Reduce likelihood
- Example: prevent database hacking/deletion via security practices and access control.
Reduce consequences
- Example: timely backups and proven recovery/copy protocols.

Emphasis: work in both directions—doing so often yields major benefit without “massive bloodshed” (a Pareto-ish idea).

Sometimes you accept risks

If the cost of mitigation is too high, you may accept the risk.
Accepting doesn’t mean doing nothing—sometimes you mitigate via partial documentation or replacement plans, which still cost money/time.

Risk management must be documented

The “easy way to mess up” is discussing risk but not recording it.
Written notes prevent distortion between “by ear” perception and the actual agreed plan.
Recommended book: Tom DeMarco & Timothy (as spoken) Waltz — Waltzing with Bears: Risk Management in Software Development Projects.

Risk assessment vs risk management: the thrust of the course

The approach: risk management = project management for adults.
Another thesis mentioned: “Don’t take on a project unless it has risks.”
Poor risk assessment happens due to:
- managers’ “fudge coefficients”
- celebrating success when risks don’t surface
- punishing less when things go fine
Worst risk: a risk that occurred but was not analyzed afterward.

Retrospectives as the mechanism to improve estimates and risk awareness

The course focuses on retrospectives:

After results (good or bad), analyze why outcomes happened
Identify risks that were missed or underestimated
Build a framework for future learning/awareness

“Risky estimates”: how estimates should be interpreted

Estimates are probabilistic, not deterministic:
- the deadline you give may correspond to some likelihood (e.g., median / 50% completion time).
Real-world completion times have long tails (not normal distribution).
This supports:
- discussing overall estimates using probability thinking
- avoiding demands for precise estimates for specific tasks (tails and uncertainty break normal assumptions)

Suggested practice: shift developer behavior from rigid estimating to early problem communication

Preferred team behavior: developers should communicate emerging problems early, rather than provide fixed precise task durations.
Managers may resist because it changes how they “manage.”

Five rules that increase an estimate (1.5× multipliers)

Personal method: each missing criterion multiplies the estimate by 1.5 (five rules total). If all apply poorly, estimates can blow up—intentionally reflecting uncertainty.

Clear acceptance test criteria are defined
- How you’ll know it works; acceptance criteria should not change.
- Also ties to management risk of shifting criteria.
Sufficient business analysis exists
- Includes at least:
  - happy path
  - planned business errors
  - exception flows
All elements required to solve the problem are known
- APIs, payment systems, components—either already understood or created.
- If something unknown exists, expect discovery-based delays.
Architecture won’t hinder the solution
- No technical debt blocking progress.
- No need to build large workaround structures.
- If architecture risk exists, multiply immediately.
A similar problem has already been solved before
- If the team hasn’t done something like this, the chance of correct risk assessment and sizing is near zero.

Additional “hot takes” / principles at the end

Worst repeated risk: the same risk occurring again with the same actions and same conditions.
A worsening scenario is better than no change
- If the same risk happens again and gets worse, it provides valuable information.
- “No change” can be worse because you don’t learn.
Improving “grades” (assessment/estimation quality) is continuous, but strict internal systems may break when the project changes.
Estimates should come from final performers
- Not from intermediaries or inflated manager narratives.
- Pressure to change numbers (e.g., “Petya says 40 hours”) leads to bad outcomes.
Accurate estimates cost speed
- Extra safety margins create time overhead; precision is paid for by slowing delivery.
Risk communication is about trust
- If people expect punishment or scapegoating, they won’t report risks.
- Covering up risks reduces both team safety and professional development.
- Analogy: instrument landing in darkness—without proper functioning (and training/trust), landing is nearly impossible.

Speaker(s) / sources featured

Speaker: the unnamed instructor/lecturer (course author) speaking throughout.
Named sources (books/quotes):
- Tom DeMarco
- (Timothy / Tim) Matthew (mentioned as co-author; book title as spoken)
- “Waltzing with Bears: Risk Management in Software Development Projects” (recommended book)
Organizations mentioned as context/examples:
- Scrum
- Kanban
- GitLab
- CrowdStrike (mentioned as an example of an outage/event)

Риски и оценки: фрагмент курса Crash course

Key takeaways