this article would like to share with you the project management experience of startups, and hope that the small partners on the road to entrepreneurship can also gain something.
project characteristics and challenges of startups
Speaking of startups, one of the biggest pain points faced in the early stage of entrepreneurship is how to achieve an efficient and low-cost project management model – small steps, fast running, rapid iteration? How to effectively organize the R&D team to iteratively update the product version in a controllable and visual scope category? Nowadays, most Internet startups follow the idea of agile development, and even many mature large companies follow this development management model. Agile development is a human-centric, iterative, step-by-step approach to development. "Fix time, Flex Scope" is the core concept of agile iteration.
in startups, many entrepreneurs use task boards, daily meetings, plan cards and other means of project management in the early stage of project management, which is also a relatively common project management method. because this way will be more convenient, there is no "routine", can make people clear at a glance, quickly see what is happening now, what will happen in the future. but there are several challenges here:
- manual offline operation, record pasting consumes time and energy;
- modification and deletion is troublesome, inconvenient to update at any time;
- historical records cannot be seen and historical data cannot be reviewed;
- subtask splitting is inconvenient, and cannot be modified after splitting;
- it is inconvenient to manage people, and as the team expands, the operation becomes more and more difficult.
how do we do it on our entrepreneurial path?
in the past two years, on the road of entrepreneurship, we have experienced team building from 0 to 1 until the r&d team has more than 40 people, including products, design, research and development, and testing. the entire r&d team runs its own products according to the rhythm of one project, and once split the small project team to run other projects. whether it is a large project group running or a small project group running, it is based on the product as the core orientation for functional iterative development. more than 40 people are in an office area (basically no off-site communication problems), the entire project adopts agile development, version iteration process in the run, product version iteration nearly 30 times, basically maintaining the process of iteration every 1-2 weeks.
although it ran fast, we also had some problems with the project management problems common to startups at the beginning.
The entire grid product is divided into android/ios/web/PC and other multi-system and multi-platform. But backstage personnel are common, basically a 1-to-many relationship. This multi-terminal collaborative development method requires a mature set of project processes to manage, and the whole team has also tried to use offline methods such as task kanban to manage project research and development. However, there are still several problems
time and energy consumption: initially, everyone was still willing to accept the offline manual way of writing operations to record their tasks, and then everyone had to spend a lot of time every day to handwrite the task list and paste the cards. in the end, the whole team found it very troublesome to write in this way, and gradually abandoned the process of manual writing and moved into the management of online tools.
update removal hassle: everyone on the team needs to update the tasks they completed today every day, and most of the time they start to worry when they pick up a pen to rewrite the content when they update. after writing a day of code to leave work, i have to rewrite to update today's task, especially when i encounter a task that needs to be deleted and re-required.
history not found: each day you can only see what was done that day and what was done yesterday. when the whole wall is densely packed, when you want to find a person for a task, your eyes have to stare for half a day. at this time, everyone really wants to have a "search" function. especially after the end of each iteration, when counting everyone's task progress, it is almost a collapse. at this point, i wish i had a tool that would help me do this.
subtask splitting is inconvenient: product requirements will always split subtasks, and r&d also needs to split more detailed subtasks during development. at this time, it is particularly troublesome to use manual methods to do it, especially when the dismantled subtasks are to be split and modified.
personnel management troubles: our entire kanban name was fixed, and as new colleagues came in and old colleagues left, the entire kanban board needed to be updated. at this time, you need to clear all the tasks on the board and then rearrange them.
after trying to move to online tool management, the iteration rhythm of the entire r&d team has accelerated significantly, and the iteration that was originally completed in nearly two weeks has now been shortened to one week. the time of daily morning meetings and standing meetings has also been shortened from half an hour to 15 minutes. the r&d team's daily work time has been shortened from nearly 10 minutes to update today's task to 1-2 minutes to get home from work. from this phenomenon, it can be seen that an effective tool can help r&d teams to improve efficiency.
in terms of product iteration process, we adopt the r&d rhythm of the cycle, and the iterative sequence of the entire product development is roughly requirements collection – requirements analysis – functional planning – prototyping – requirements review scheduling – development phase – testing phase – go-live phase, where a complete iteration is achieved.
for project time management, offline excel form management was originally adopted, and then it gradually transferred to online tool management.
here's a closer look at what we've done at each stage of a product iteration project.
requirements gathering phase
the product department has its own requirements collection and analysis methods, and we will build a "demand pool" in which the product will collect all aspects of the requirements into the pool. the demand for the demand pool mainly comes from the market, users, competitors, bosses, and product managers. we will use online tools to classify and manage requirements, such as app needs, operational needs, web demand, and so on. the requirements in the demand pool are consolidated and deleted periodically.
during the requirements collection phase, the product department will communicate in detail with colleagues in operations, marketing, business, etc., to ensure that the purpose and significance of each requirement are understood.
requirements analysis phase
for the established "demand pool", the product is regularly evaluated, and the evaluation is also based on the discussion within the product, and before the discussion, we must ensure that we understand the background and meaning of each demand, and do not shoot the needs alone. we advocate products as the core orientation of the company, so the decision-making power of product experience is very important, which directly affects the company's strategic direction. therefore, when analyzing the needs of the demand pool in detail, it must be based on the perspective of users, markets and companies.
the demand analysis for a demand pool does two main things:
- organize the requirements pool content and filter product features from two dimensions: priority and importance.
- after prioritizing and importance of the requirements pool, mark the requirements, create new iterations, and associate the requirements.
- once you've identified the requirements to be done, you need to start refining them. at this time, the skills of the product manager are tested.
functional planning phase
after determining the requirements to be done, in order to ensure the integrity and division of labor of the requirements in the research and development stage. module splitting and task splitting of product requirements is required in the functional planning stage. ensure that the granularity of the requirements is consistent with the module of the r&d time review, and if you do not know how to split it, you need to communicate with the r&d students in advance.
after the task is split, in order to ensure timely synchronization to r&d colleagues, it is necessary to associate the sub-task with the online tool to the iteration, with two main purposes:
it can make r&d know the scope of functions and modules of the next phase at the same time, and carry out technical framework construction or technical pre-research in advance.
facilitate collaborative design of product colleagues (multiple people responsible for a module).
on the online tool, requirements can be related, such as parent-child relationship, which is convenient for continuous searching, and the tree structure is easier to see at a glance.
prototyping phase
the most difficult thing to manage during the prototyping phase is the versioning issue, which includes versioning of two types of files.
prototype manuscript for product managers
first of all, the number of prototype revisions will be much larger than the design draft, mainly because some requirements will be reviewed or problems will be found during development. modified or supplemented. in addition, most of our startup prototypes have interactive instructions together, and there are generally more modified/supplementary text descriptions. moreover, the prototype is used more for r&d and testing students, so each time the version is recorded and modified after synchronization is a huge workload. the best way to do this is to set up a unified svn or online management tool that can be synchronized in real time if there are changes.
the design draft is also similar, generally the design draft changes less frequently, but we will also be unified in the name of the version in order to keep pace, uploaded to the online management tool, unified management. ensure that the information is synchronized and timely, and the research and development process will not use different versions and lead to different functional effects of several terminals.
requirements review scheduling
we usually have 3 reviews, two times before, but found that there is a lot of repetitive communication during development, and many requirements r&d colleagues have not figured it out. the main reason for the analysis is that the demand review meeting is short, and it is difficult to understand all the logic in a short period of time. so i changed it to 3 times later, and added a "pre-review meeting".
at the first "pre-review meeting", the requirements details are not discussed, only the framework and process. let everyone know what to do in the next iteration, and first have the concept in mind. generally, the time of the pre-review meeting will be in the testing stage of the previous iteration, so that before the next review meeting before the end of this iteration, everyone has time to familiarize yourself with the framework and process in advance, so that you can review the second requirements review with questions. at the same time, you can also encounter some problems with large technical changes at this review meeting, or technical difficulties to know the product in advance and evaluate whether to adjust the demand.
at the second review meeting, it is a formal review, and the product requirements will be reviewed from each detail. everyone listens with questions, passes quickly where there are no problems, and focuses on the identified solutions where there are problems, which saves a lot of time. because they are all online demand management, problems are directly marked on the spot, and the place of the mark is modified after the meeting. there are records, and they are not omitted.
the third review meeting mainly went through the second place that needed to be modified, and by the way, deepened the understanding of the needs of the r&d students. usually, the third judging meeting will be held on the second day of the second judging meeting. we generally choose the second time in the afternoon of the previous day and the third time in the morning of the next day. use the evening time to modify requirements so you can save project time.
this is followed by the project scheduling in the afternoon of the next day, and the personnel will be allocated directly on the sub-tasks that have been split by the online tool, including developers, testers, and then the development cycle will be arranged. the purpose of online management is that after assigning personnel, everyone can log in and see the responsible tasks, and the system will automatically calculate the development cycle.
the development phase
developers can complete development according to the schedule time of each subtask, before the time node of each requirement. several meetings are scheduled during the development cycle:
- daily morning meeting: every morning, all the staff participate, focusing on yesterday's progress, today's arrangement, and encountering problems. it takes about a few tens of seconds per person, without discussing a detailed solution. colleagues who are having problems or need to discuss them in detail in small groups after the morning meeting. the purpose of the morning meeting is to make everyone's arrangement clear, synchronized and know the problems to be solved.
- weekly meetings: weekly meetings are generally scheduled on friday afternoons. about 1 hour, mainly synchronize the overall progress of the project, and focus on solving the rules and institutional problems.
- ad hoc meetings: ad hoc meetings are generally organized when major problems in the development process are encountered and can be solved if they need to be solved. usually the stakeholders and bosses of the problem participate.
- sharing sessions: once a week, a sharing session for project members is scheduled, prepared by one person to share what they have heard and felt. create a friendly atmosphere where teams are willing to share.
- in the development stage, the management of the project is mainly an online tool, and the tools for synchronization and communication are generally online management platforms and online chat tools. because we were all working together, when we had a problem, we yelled and the people passed.
testing phase
test colleagues write test cases based on their needs in advance, and test cases are reviewed before development. test cases are updated to online tools so that everyone can see them. testing is also conducted based on the use case of the review to prevent subjective judgment. testing issues encountered are also automatically submitted to the bug pool and associated with the corresponding developers to ensure that no bug changes are missed.
because the startup test manpower is small, we generally find bugs for all employees, and we can set up some prize activities. for example, whoever finds more bugs can get rewards.
go-live phase
when all the tasks are tested, you can go live. before going online, the product and operation need to list the corresponding responsible content. create a checklist and check one by one for missing issues. if the general version is online, a test quality report will be published by the test email and a recommendation will be made whether it can be launched. the product will be judged based on email feedback to determine whether it can be launched. in this way, there is a double insurance, and the synchronization work can be completed by one email, and the efficiency of the line can be improved.
in addition to the r&d team, the company also assigns operations and business to the unified management of the project. in order to synchronize the information of various departments with each other, let the technical students understand the business to help them better develop based on the business level, let the business students understand the technical difficulties better, can put forward more reasonable needs, and use the development language to communicate with the development colleagues.
the above is a startup project management process summarized from the practical projects of entrepreneurial experience, and it is not necessarily applicable to every startup, but some of these methods can be tried by both large companies and small companies.
No comments:
Post a Comment