Before implementing a new feature, I like to make sure what problems we are going to solve, why we should solve them, and how much time we can implement this feature.
Here are 7 steps I usually do before I involve in a complex feature implementation.
These steps bring many benefits to the development process. For example,
Boost the accuracy of problem-solving.
Keep the mind clear and not get lost in the codebase.
Improve the efficiency of the implementation.
Communicate effectively and efficiently with other engineers.
Let's take the software onboarding for example. (source: What is SaaS onboarding?)
1. Define the problem
When new users start to use the system, they might face different problems or say frustrations.
Here are some examples:
New users don't know what they can do after registering an account.
New users are overwhelmed by the complicated usage of the system.
New users don't know how many steps they should do to complete all of the required settings.
In some companies, Define the problem might not be the engineers' job. However, as an engineer, we still can collect the information from PMs or related team members.
They define the problem and we can try to understand what the problem is. This helps us get clear on what we are going to do and why solving this problem is important to the users and the company.
This step is the key point to help us build the right things.
2. Write down the user story
When we fully understand the defined problem, it's time to brainstorm the solutions with your team members. If PMs have defined the user story, we still can discuss it with PMs, especially when we think the user story can be more specific or better.
Here are some user stories examples:
As a user, I can watch a welcome video that can tell me what I can achieve with the system.
As a user, I can see a dashboard immediately after registering.
As a user, I can see the dashboard which lists all of the required tasks I need to complete before launching a website.
As a user, I can receive a newsletter that includes 3 recommended features that match my needs.
3. Write the POC
After getting enough information, we finally can start to think about how to implement the feature.
Due to the feature being complex, I usually write down the POC (Proof of Concept) first.
POC is like a blueprint. When writing the POC, you will have many questions in your mind. In order to answer these questions, one of the approaches I will do is to explore the codebase.
4. Explore the codebase
Here are some questions usually in my mind:
How many/Which models do I need? How about the association between models?
Does any data need to migrate before/after the feature releases?
Will the existed users be affected after the feature release? If the answer is yes, how many things need to be done first before I implement this feature?
If there are modules/services I can reuse?
How many modules/services that I need to re-design?
...more
Exploring the codebase is a process to answer your questions, brainstorm better practices, and collect the limitation.
5. Design the code flow
After exploring the codebase, I like to make a simple code flow with Figma. This is a good way to keep the mind clear, not get lost in the codebase, and take care of different situations.
Fake code flow example
6. Communicate with PMs and other engineers
To make sure your design makes sense, the code flow source is useful, especially when you have a topic and want to discuss it with your tech leader or team members.
What's more, this can help the PR reviewers quickly understand which scope they are reviewing.
7. Break down the tasks
The code flow is like a map, it helps us break down the tasks more easily.
If a task is smaller enough, it can be completed as soon as possible. Moreover, we can help reviewers to reduce the cognitive loading.
And the final step is: Just do it.
I do not always follow these 7 steps sequentially, but these steps do improve my delivery efficiency and quality.
I hope you find this information helpful.
