【SOP】 R&D Process

【SOP】Research & Development Process

Main Development Flow

Project initiation → Requirement consensus → Requirement review & design review → Technical review → Development → Test case review → Submit for testing → Debug → Test report → Gray‑scale release → Full release.

Core Process

Requirement Review

• Discuss the requirement’s goal in depth with the product team, ensuring it aligns with our OKR direction and has clear expected improvements for specific metrics; these will serve as acceptance criteria.
• Clarify requirement details with the product team, assess feasibility, identify potential difficulties, and provide development‑side suggestions for better implementation and future code maintenance.
• For edge cases or other logic, think carefully and confirm details, adding as much technical information as possible.

Technical Review

Based on the understanding of product requirements, define how to implement them technically. The review must cover:

• Any work involving multiple platforms must have a technical review.
• Any work requiring coordination across multiple locations must have a technical review.
• Projects with a timeline longer than 3 days must have a technical review.
• The technical review must produce clear, detailed documentation and involve the product team, all relevant developers, and testers.

3. Timeline Estimation Method

For requirements or projects with a timeline exceeding 2 days, this method applies.

Project members, based on their grasp of the technical solution and a breakdown of each module’s feature list and technical challenges, estimate the schedule.

After the estimate, coordinate with the project manager or product manager for development scheduling. If resource conflicts arise, reach consensus on priorities and adjust accordingly.

The timeline estimate must include the following elements (the “1+5+1” hour‑estimation method):

• 1: Actual development time for business requirements

• 5: Other time

  • Prep: time for designing the technical solution
  • Communication: time spent discussing the technical solution with collaborators (product, operations, external AI team, other external technical or requirement providers) and meetings
  • Communication: time for joint debugging with other platforms
  • Technical: time to overcome technical difficulties
  • Technical: time to develop dependent foundational modules

• 1: Time to fix bugs in the previous version

After each project, allocate time for a Code Review to ensure code quality.

4. Feature Development

When development is complete, compare the implementation against the PRD line by line to verify that every requirement has been fulfilled, avoiding any omissions.

5. Test Case Review

This is the third‑level understanding of the requirement (first is requirement review, second is technical review) from a testing perspective. It usually occurs during development, before submitting for testing. Requirements:

• All relevant developers must participate, listen attentively, and consider each test case carefully to ensure it matches their understanding. Any doubts or uncertainties must be raised on the spot for clarification.

6. Submission for Testing Guidelines

Key points:

• Even the smallest change must be recorded in the Release Notes so testers are aware.
• Before setting a testing date, be sure to confirm the integration plan with all collaborators (verify that the timing meets expectations).

7. Debug Phase

• For bugs related to P0 and block, provide daily progress updates and resolve them within 3 days at most; if unresolved, request escalation support.
• For every bug, document the root cause, solution, and impact scope when fixing it.
• Bugs marked as “Confirmed” in TB must be verified on the same day.

---

Originally written by Li Wei (李唯_) and published in Chinese on 后端技术栈全书 (Full-Stack Backend Engineering). Translated and adapted for DriftSeas with permission.