In the previous article, "super hard dry: how to turn demand into a product solution?" in , the author from the pre-preparation, program design, demand review three levels, for us to share how to turn demand into a product solution. in this article, the author and we talk about what the focus is on the product development process after the review meeting.
In the previous article, i introduced you to the process of turning requirements into product scenarios, and a few points to pay attention to in order to pass the requirements review.
After passing the review meeting, the work of our products is to advance the project, pay attention to the progress, and get online on time. therefore, this article, i will be in the "practical" level, from the project scheduling - > requirements development - > the experience before going online - > products online, these four steps, to give you from the introduction, in the product development process to pay attention to.
Project scheduling
Through the needs of the review meeting, according to the priority of the needs, resource allocation, scheduled development.
If the plant is large, there will generally be a project manager to support the job, and in the case of small and medium-sized companies, it is usually the head of research and development who will assume the role of assigning the task.
At this point, the job our products need to do is to focus on the scheduling of their needs.
If it's a more urgent need, or if the leader is more concerned about the need, prioritize the needs as much as possible and develop resources for your own efforts.
In this scenario, communication skills are important.
In the case of higher priority requirements, my approach is to state the needs background with the other person, and then emphasize the importance of the requirements as quickly as possible, supplemented by the background of leadership concerns, to pass the pressure on to the past, to increase the priority of the requirements.
Secondly, in communication, it is best to communicate online, otherwise resources are not on schedule, the next leader asked, there are text file.
Demand development
after the requirements schedule, the general project manager will tell you through the established channels that your project has been assigned to the corresponding development, and that time, we can follow up on the requirements development situation.
as a rule of thumb, during the development phase, it is most likely to lead to a delay in demand. therefore, we should use the project management approach to avoid the risk of delay as much as possible. in general, the demand development follow-up process to ensure that the division of labor specific, quantitative work, risk control of these three points.
Specific division of labour: programme synchronization, dismantling
first, before we begin, we start by documenting the requirements documentation and the corresponding development.
strive for each other and their own needs to achieve the expectations are consistent, if it is a multi-end cooperation of the big needs, assignment to be specific to people, each work, each function module must be disassembled, and in the form of a meeting synchronization.
focus on the person in charge of the clear needs, drop the person in charge of the meeting minutes, and eventually synchronize within the project group.
Quantification: clear development cycle
once you've synchronized your scenarios, you need to be clear about when you're developing them. that is: we have to focus on who, when to start, when to expect to finish.
our team's development process, generally need to develop according to the needs of the documentation, out of the technical solution, and then submitted to the technical team, for internal technical program review, review and pass before you know the specific development workload.
therefore, in the early communication program, i will also first with the other side to clarify the technical document completion time and meeting time. after the technical solution is identified, align the specific development schedule with the relevant colleagues and synchronize it in the group.
here i have a little trick, is that i usually in the development assessment time, add 1-2 days, and then synchronize out. because people overestimate their ability to work, the development process is likely to exceed established expectations.
therefore, if the workload is determined, we can use the gantt chart above, the dismantled tasks, projected progress, actual progress, all into the table. we typically synchronize project progress with team members on tencent documents by establishing shared documents.
Risk control: set up feedback nodes to recover feedback on time
once the project schedule has been determined, it is time to formally enter the development phase. during the development phase, the most likely risk is that development is delayed because it is not developed at the scheduled time.
so, from two downward and upward perspectives, i'll show you how to keep risk under control:
1) down management: responsible for the project, timely understanding of the progress of the project
during the development process, after our project is scheduled according to gantt diagram, we need to set up additional feedback nodes, and then recycle feedback information regularly to know the progress of development of our needs.
if i have more than one need in parallel, i will spend 1-2 hours every morning and afternoon, respectively, to follow up the development progress of development, and tell each other, if there are difficulties need my support, to keep pace with me in time.
because, in practice, not all development is very active, so we have to take the initiative to understand the development progress, to see if there are program adjustments, development delays.
if there are adjustments in the scheme, especially those involving product functions, we should use the text in a timely manner, in the group with the project members to synchronize the reasons for the adjustment and the results of the adjustment.
then, take the time to update the requirements documentation as soon as possible, and make clear the adjustment time. in the case of large projects, you can schedule a weekly/twice project synchronization meeting to keep pace with the parties on project progress and difficulties encountered.
2) upward management: report progress in a timely manner with the leadership, synchronization difficulties
after understanding the progress of the project, we also need to keep pace with the leadership of their own needs progress, there are difficulties to be exposed in a timely manner. i have seen some new students who have just entered the line, may be due to emotional, dare not or embarrassed to explain difficulties with the leadership, and eventually led to the project delay.
in fact, this is a very bad "student spirit". it is also important for our work that we be able to properly seek leadership support when we encounter problems.
but note that what i'm saying here is "appropriate", we should pay attention to grasp the "degree", encounter difficulties we have to try to solve their own, can't say that every need to let the leader support, otherwise the leader will also doubt our ability to work.
it's my habit to lead and develop in a leading project group on Wednesday afternoons of every week, synchronizing development progress, completion time, and project difficulties.
i chose the midweek because i had set aside time to adjust, and if there was a problem, Thursday and friday could be adjusted in time, the time would not be too tight. if someone has questions about progress or needs, they can also discuss them in groups in a timely manner.
in addition to syncing progress and allowing time, there is one benefit: keeping files in groups with text to protect yourself.
The experience before going online
after the development of the demand is completed, the demand is only two steps away from the official launch - product testing and product inspection.
Product testing
after the requirements development is complete, first enter the testing process. in the testing phase, we first need to experience whether the core process of the product meets development expectations in the test environment.
Then, according to the requirements documentation, describe the background and requirements expectations for the test as a whole in order to test the output test case, which is primarily for the testing of the exception process. the point here is that the test's understanding of the product is consistent with yours, otherwise it is easy to see situations where some of the abnormal processes are not measured.
Finally, it is to let the test students work, but also to follow in the development stage, the demand to promote the three-step strategy - clear division of labor, quantitative work, risk control these three points.
Product experience walk-through
In this link, mainly for the needs of front-end pages, in the use of products and front-end page design. this part of the work usually requires interaction and design support from classmates to see if the experience here meets the expectations of the product design.
At this stage, the product also needs to experience the details of the product with the interactive design. this is a very honed product person, but can not be lazy work. i've met all the best product managers who have the ultimate in product detail.
I actually did not do well at first, mainly because i couldn't sink my heart to do it, so i often made mistakes because of carelessness.
But then i read a book called the list revolution: the main thrust of the book was that carelessness was a common in all walks of life. but all complex processes can reduce errors by establishing inventories.
That is: all the necessary items in the work, are listed, in the specific implementation of the time, an item check completed. this will greatly reduce the number of errors, so that no heavy leakage.
Later i also set up my own "on-line checklist", from the page from top to bottom to focus on the details, the process from the entrance to the exit page, one by one experience through.
Therefore, i suggest that if you do not set up a checklist of students, also began to set up a set of their own list, can greatly reduce the problem caused by carelessness.
Also, if there is a problem but the current version is too late to adjust, we can also put this optimization point in the requirements pool, the next version of the plan, and then put in.
Demand on-line
After completing the pre-online testing and walk-through, the requirements can be brought online according to the original schedule. some information may also need to be prepared before going live.
If the app goes live, you'll need to prepare some Store files, descriptions, pictures, or in-product help center documentation, smart customer service descriptions, but if it's a B-side product, you may need to prepare new features of customer service or sales training documentation.
Because the product is different, the need to prepare things may not be the same, here you have to prepare according to their own products or industry can be. of course, if it is more complex, you can also use the list mentioned above to establish a checklist.
In addition, i would like to say two things that i personally consider very important:
Focus on data changes: is the direction of product optimization
i didn't pay attention to the data changes in time after i had a lot of needs completed. at that time, my leader at the meeting had "reminded" me, he said: some students work habits or to strengthen, products online do not look at the data, you do not know whether you have this product feature user. what's the difference between not looking at the data and not doing what you need?
Later, in order to develop my habit, i was asked about the data of a feature every three to five. then, in order to reduce the embarrassment of being asked by my leaders, i spend an hour each morning looking at product data and trying to analyze the causes of data jitter.
Project re-opening: no re-entry
the need for a product to fail is far greater than the need for success. our team's products, in order to achieve a break, last year's new features in the product, none of them are failures.
In order to increase product retention, we have added the game module, check-in cashback ability, but also made the points system, membership system, can not be accepted by users.
But after the failure, we have been re-trading, because the re-entry, is the only thing we can get from failure the most valuable thing.
I think the best and fastest growing shortcut for the product is the re-entry. specific re-order, you can start from the overall product process.
Starting from the per-research-> demand analysis-> design-> demand development-> product testing-> product operation, the whole project process is re-opened.
Combined with the background, problems encountered at that time, the way of dealing with the time, etc. , to reflect and summarize, and finally to obtain an optimized plan.
We can also start with goals. Compare goal expectations with practical practices, compare differences, see deficiencies, and how i can optimize implementation if i do it again. in addition, we need to combine product data performance, more comprehensive thinking analysis, output optimization conclusions.
In this way, our project forms an optimized iteration closed loop that will not repeat another mistake when it comes to the next requirement or project.
No comments:
Post a Comment