Recently I was reading the book "The Myth of the Man-Moon".
It is found that most task delays have little to do with research and development. Technology serves the business, but it cannot repay business debts.
The concept of tar pits originated from an unfortunate situation when digging pits. When digging a pit, you first get into the topsoil, which progresses quite quickly. But then we encountered asphalt or mud, a thicker material that slowed progress significantly. When mining pits, tar pits, no matter how small, can cause progress to be hindered.
Similar problems exist in software development. In the early stages of a development project, the team may make rapid progress, but as the project progresses, it may encounter some unexpected problems, such as technical difficulties, personnel adjustments, or changes in requirements, which cause delays in development progress .
So in recent actual work, I have indeed encountered a "tar pit".
In the early days of the "scheduled message sending" function, I quickly completed the development of some basic functions, such as scheduled task configuration, message templates, etc. But during the development process, I encountered the problem of unclear requirements description, which required a lot of time and resources to be solved. This problem is like a tar pit that hinders the progress of the project schedule.
Let’s review the process of taking over this task:
1. In the early stage, I knew what the function was and quickly understood the related technology stack.
2. Next step, architectural abstraction-implementing the interface
3. Unclear business requirements and changes in requirements lead to functional delays
4. Communicate with tests and products, organize requirements documents, and achieve consistency
5. Return to step 2 to reconstruct related functions
Obviously, assuming my estimated cost is program * programming system = 3n, the assumed cost I gave is 6n , but the actual cost is n*3*3 = 9n
The main problem may arise in the transmission of requirements, or in other words, the lack of requirements documentation .
What documentation is required?
Different objects require different levels of documentation. The following summary is only for product-research and development transfer.
Usage program: A descriptive text for the function. Most of the requirements description only depicts leaves and bark, and does not describe the picture of the forest.
- 1. Purpose: What is the feature? Why was this feature developed?
- 2. Range: valid input range, valid output range
- 3. Input-output format: ensure accuracy and completeness
- 4. Operation process: the normal operation process of this function and the handling of abnormal operations
- 5. Accuracy and verification: How to verify the expected results?
Note: A flowchart is not necessary if the summary text is concise enough.
Or to be more practical, I will give a case described in a popular document
- 1. The user wants to get the function of regular reminder. In the workflow, after completing node A, notify the relevant people of node B to continue processing.
- 2. The people related to node B are roles of X, Y and Z type. The message notification will tell X and Y what the role should do.
- 3. The output of the notification is: time, content, and some information about node A.
- 4. In functional operation, it can be configured by any type of role. The input range of each column option is ()
- 5. This function is completed when the user receives the message notification on the APP.
- 6. If the assembly is down or upgraded and messages cannot be pushed at the current point in time, the processing method is ()
- 7. Attached: Flowchart (including exception branch processing)
- 8. Attached: Notes on ambiguous nouns
- 9. Attachment: Possible impacts of related functions of this module