Effective engineers need to evaluate choices and present alternatives to stakeholders. Some examples include: the best way to deploy an application to a client, strategies for addressing application issues, or what feature set to build first.
Clients depend on us to identify and clearly communicate possibilities so they can make the best possible decision given the available information. When a situation is complex there is generally not an obvious or ideal choice. When these types of situations arise, and they will on a complex project, engineers need to be able to clearly frame the problem and present solutions.
Here is a simple, logical and known protocol to use.
- Short description of the problem
- Objectively present 2-3 possible solutions
- Define Pros/Cons for each solution
- Make a recommendation
There are a few design smells that you should avoid.
- Overly verbose – Stay high-level and keep it simple. Ideally, the write-up will only be 1 page.
- Too technical – The document should be written for your audience. Discuss impact and implications instead of bytes and bits.
- Too many options – Lots of permutations are confusing and generally add little value. Focus on defining a few high-level options (many permutations can usually be rolled into one option) and then tackle the permutations if that option is selected.
- Favoring a particular solution – Only favor a solution in your recommendation. The recommendation holds no weight unless you have objectively evaluated alternatives.
Please share any other good pointers that you might have on this topic.