| Hard agree. My current workplace culture (at least in the HW dept) is much more towards zero-documentation than anything I have experienced before and it has been a nightmare as a relatively new employee. I waste so much time in reviews because I have done something non-standard despite having checked the standards docs but it turns out the standards have changed and no one bothered to update the docs. We don't even write specifications for products before we start work on them; if I make some architectural changes during the design, there is nowhere to record it. Drives me insane. IMO there are two things that should be documented about any project:
1. The product itself: at least its interfaces, features and general architecture
2. The process of design: what changes were made vs the original spec, why, and when If you want to know anything contained in that set of information here, you have to know who worked on the project so you can ask them about it, and then they have to be able to remember. It's not uncommon that changes are suggested and discussed multiple times within a project, or that changes are made but the reasons why are forgotten before the project is even complete. I often joke that projects here are more "observed" than managed. Exactly as you say - emails/meetings are ideal tools for discussion and decision making but for lasting records, you need documentation. |