"Is the code done yet?" "It's 80% done, like playing a game. This is the final level before the boss battle!"
"Did you finish testing the functions?" "I've tested most of them, but there are still a dozen test cases to go. It's like doing a quiz, you've got 80% right, but you still need to work on the last few tricky questions."
"Is the PRD done yet?" "It's an internal review now; like a foodie tasting a dish, our Prd needs to go through multiple rounds of refinement to achieve the perfect flavor."
The intermediate state of "omnipotence."
The intermediate status is a mysterious and versatile state that anyone can create. For example, a design may be in an evaluation state, where the invention is not yet complete, but it seems to be finished. So who is primarily responsible for this state, the designer or the reviewer? This is why evaluation states usually have two situations:
The evaluation period is very long, even exceeding the design time.
The evaluation becomes formalistic, and the problems leak into later processes, causing high costs to fix.
Anyone can create countless intermediate states, and they can usually make sense at first glance, but upon closer inspection, they are all wrong. But do we have the energy to deal with a massive number of intermediate states? A large amount of excellent creativity is used here; it is simply a breeding ground for creativity. Therefore, please block this path, cut off these "smart" ideas, and do something stupid instead.
Therefore, please get rid of intermediate states and make a clear definition of what is to be delivered, first by establishing the Definition of Done (DoD).
The DoD of a specific feature, for example, this feature has been developed and is in a deployable state, verified by the product owner.
The DoD of an iteration, for example, all planned features of this iteration have been completed.
The DoD of a release, for example the entire software is in a releasable state, and the release plan has been defined.
Once we establish a clear DoD in our collaboration, we can even solidify it through processes to efficiently and effectively complete our work.
Delivery
This is the first issue to communicate because delivering stable software that meets business requirements is the fundamental responsibility of a technical person.
Most collaboration problems are caused by the need for a clear Definition of Done (DoD). Different parties have different understandings of what "Done" means, and they use various intermediate states to cope with the situation, which leads to inefficiency and wasted time in the end.
Function development completed
It means that the developer has gone through the requirements analysis, solution design, code implementation, and unit testing and has passed the acceptance test by the testing personnel, ensuring that the code is in a deployable state and the relevant documents have been completed.
Code writing completed
It means that the developer has written the functional code, the unit test code, and the integration test code, and the tests have passed. The code has also passed the code style check and the test coverage check.
Therefore, when referring to "function development completed" or "code writing completed" in subsequent communication, please refer to the above requirements. If you are unsure about what "Done" means in your work, please immediately confirm with relevant colleagues.
The above delivery information was taken from the department's culture document, which provides a clear and minimal definition of "Done." When a team member changes the status of their work, everyone in the team knows exactly what it means.
Remember:
There's only completed and not completed, and 99% of the time, there's no difference between the two.