SaaS Case Studies

This project uses an Agile development model. Here’s a look at the project development process:

#Image 1 (Flowchart)#

If you’re familiar with Agile development, you might wonder why this seems different from what you’ve seen before. Agile development is a methodology that uses iterative and incremental approaches during the development process. This diagram represents the development process for a specific project and is a practical flowchart. Due to differences in each team’s work habits and methods, each version may vary. The one above is the version we use.

Here’s a brief overview of the five key stages in the development process:

  1. Project Start: This involves requirement communication. There are two sources of requirements: before the project launches, they mainly come from the core team’s ideas and creativity; after launch, they primarily come from user feedback and requests from the product manager.
  2. Review Stage: The review is essentially a continuation and result of requirement communication. The key difference between review and requirement communication is the participants. Requirement communication involves the boss and operations, which are not shown in this flowchart. The purpose of the review is to provide the technical team with “documentation” to rely on during the development and launch phases.
  3. Testing Stage: There are three rounds of testing (including the pre-launch version) to ensure product stability and to avoid bugs after launch.
  • First Round: After the code is completed and deployed to the test environment, this round often reveals bugs.
  • Second Round: Testing the pre-launch version. Ideally, no bugs should appear in this round.
  • Third Round: After the iteration is released, immediate regression testing is performed. This stage often requires team members to work overtime. If everything runs smoothly, you can go home; if bugs are found, relevant personnel need to stay and fix them.

If bugs persist after three rounds of testing post-release, both the testing and development teams share the responsibility. This can also indicate that the leader of the development team is incompetent and unable to fulfill their role.

Now, let’s look at the details. First, check out the documentation produced over 2 years of iterations:

#Image 2 (Yuque, Development Team, Document Homepage Screenshot)#

Product documents, development documents, testing documents, update notes, and specifications. Product documents, development documents, and testing documents are all considered “confidential materials.” Update notes can be released to the public, such as showing update details in games like King of Glory.

Let’s start with the specifications. Specifications are established when the project team is first formed and are continuously refined as the team develops.

Now, let’s examine the product documents:

#Image 3 (Product Document Homepage, Directory Page)#

From this, you can see that this SaaS product has two “multiples”: one is the multiple terminals involved (PC version, WeChat Mini Program, Android, iOS) which means it needs to cover most terminals. The other is the multiple roles, as this platform connects enterprises with banks. On the platform, enterprises need administrators and operators. Banks also have many roles, such as branch managers, administrative staff, and client managers.

What I want to emphasize is that many people often overlook the platform backend administrators and operators when discussing requirements. A competent internet product should also involve operations staff, customer service, and the boss, each requiring different permissions. Especially the boss, who is an important role in the backend of the platform and typically requires special handling. The permissions for the boss differ significantly from those of regular business users.

Finally, regarding development documents: Programmers don’t just write code. Code is a language that communicates with servers, but others may not understand it. Even a new programmer might not fully grasp it. This highlights the importance of development documents. The quality of a team’s development work, their seriousness and responsibility, is reflected in their documentation. A qualified product will have documents such as PRD, mind maps, flowcharts, and prototypes. Code should also come with development documents.

If a development team delivers without documentation or provides poorly written documentation, it’s advisable to be cautious when hiring them.

While you’ll find plenty of information online about the user-friendliness of product functions, the attractiveness of the product interface, and the quality of interactions, my aim here is to provide you with “substance.” I hope this can offer you practical insights and real help in your business.