Chapter 16 — Technical documentation and safety

Chapter 16 — Technical documentation and safety

Lesson map

Lesson 16 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Clear procedures"]
  N2["16.2 Safety and authorisation"]
  N3["16.3 Keeping current"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 Clear procedures"]
  N2["16.2 Safety and authorisation"]
  N3["16.3 Keeping current"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Learning outcomes]
    |
    v
[16.1 Clear procedures]
    |
    v
[16.2 Safety and authorisation]
    |
    v
[16.3 Keeping current]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) write clear technical procedures; (2) include safety and authorisation steps; (3) keep documents current.

16.1 Clear procedures

Amina writes procedures for tasks she has learned: running the baseline check, verifying firewall rules, checking certificates and testing restores. Each procedure lists the purpose, prerequisites, steps, expected results and what to do if results differ. She writes in short numbered steps with exact commands where needed. She learns that good procedures let another technician perform a task correctly the first time without asking the author. Including the expected result lets a technician tell at once whether a firewall verification or restore has gone wrong.

16.2 Safety and authorisation

Each procedure includes safety steps. Before changing a firewall, confirm the change is approved and schedule it outside trading hours. Before restoring data, restore to a test location, not over live data. Before running scripts, confirm they run against the correct system. She learns that technical mistakes can stop branches trading, so safety checks are part of professional practice and protect both the business and the technician. Restoring to a test location first, for example, would prevent outdated files from overwriting current online shop data.

16.3 Keeping current

Amina adds an owner and review date to each procedure and a change log at the end. When the shop platform was upgraded, the backup procedure became wrong, which caused the earlier failure. She recommends reviewing procedures whenever related systems change. She learns that out-of-date procedures can be worse than none, because they give confidence while leading people to do the wrong thing. Her review rule would have flagged the backup procedure as soon as the shop platform upgrade was approved.

Worked example

Amina writes four procedures with safety and authorisation steps, owners, review dates and change logs.

Synthetic case. Procedures are synthetic.

Errors and limits

Procedures go stale. Steps can be skipped.

Exercises

• EX061 — Procedure parts. What does each procedure list? Rubric: 3 = purpose, prerequisites, steps, expected results, what to do if different;; 2 = five;; 1 = vague;; 0 = none.
• EX062 — Restore safety. Where should data be restored first? Rubric: 3 = a test location, not over live data;; 2 = test location;; 1 = live;; 0 = none.
• EX063 — Stale danger. Why can out-of-date procedures be worse than none? Rubric: 3 = they give false confidence and lead to wrong actions;; 2 = false confidence;; 1 = vague;; 0 = none.
• EX064 — Firewall timing. When should firewall changes be scheduled? Rubric: 3 = outside trading hours, after approval;; 2 = timing;; 1 = vague;; 0 = none.

Synthesis

Clear, safe and current procedures let technicians work correctly and protect the business.

Continue studying — chapter 16 of 18

← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →