This time, we will talk about product technology, team, and project management.
At the beginning of this year, I played with the simplest & off-site team, a part-time designer (doing visual + interactive + front-end), a part-time technology (server + Web), an iOS client developer, they are in Beijing, the rest of the roles are all me.
at that time, the small number of people did reduce the loss of communication and coordination, but the barrier of not working together in different places and the "jet lag" caused by part-time work (some people can work at night and on weekends) are more troublesome. moreover, such a team has a premise - it must be a very mature and professional player. it's hard to find it locally all at once, full-time.
in the past two months, there is another kind of play, the team role is slightly more, the centralized office, but everyone's experience is not very rich, mostly 1 to 3 years, no professional training of novices. first up, spent a lot of time with everyone to set the rules, the rules must be required, but must not be complicated, the following to share this simplified product process and project management methods, as shown in the figure.
simplification of roles
according to the current situation of things and teams, do a reasonable simplification, this is still quite a test of experience, you must see a team with a very fine division of labor, and then understand how each role is differentiated step by step, the purpose of the setting, in order to do a good job. for example, for the status quo of "small (project name)", our approach is: do not distinguish between interaction and vision, no full-time testing and national testing, no operation and maintenance dbas and other subdivisions of all development commitments, the front end or listed separately, so a total of four roles: product, design, front end, development. of course, for the simplest team, you can also remove one, product, design, development of these three roles are indispensable, note, is three roles, not necessarily three natural people.
simplification of the process
again, you need to see more complex processes and know what each step is to prevent in order to simplify reasonably. the minimum requirements, four key nodes, these nodes are in addition to the product technical team, the key people of the market operation also have to participate, i think it is impossible to cut anymore.
project initiation meeting: determine the purpose, why, and what to do;
needs review: determine how to do it (for small projects of less than 2 weeks, it can be combined with the project establishment meeting, and the overall time is controlled within 2 hours);
function review: simply put, it is to demonstrate the product in the test environment and determine whether the team wants to do it (about 1 hour);
release on the line: determine whether the user wants it, what the user wants... get feedback and form a closed loop.
two branching processes
change: at the beginning, it can be reduced to a person's decision to accept the change.
daily: that is, scattered small needs, only grasp a little, all needs must go through the product, can not operate directly to find development, to ensure that the product manager knows all the demand information.
simplification of documentation
it can almost be a three-piece set of prd, design draft, and code. everything else is solved with kanban and lihui. then, with special emphasis on one, communication planning, the vast majority of issues are communication issues. everyone should agree that it is a daily meeting? choose a collaboration tool online? writing a weekly newspaper? ...... if this problem is not solved, the later make-up lessons will definitely make up for what you don't want.
practical application of kanban
in the process of research and development projects, we found that the most primitive kanban board and standing will be easy to use, first of all, the basic element used in the kanban board - the task card, that is, a sticky note.
Task description: one word + one sentence (if a word can be said clearly, you can not use a sentence), such as a "Detail page production" written by front-end students; a "background order management requirements refinement" of product students.
man-hour evaluation: for 2 to 4 weeks of the project, accurate to 1 to 4 hours of granularity is more reasonable, if the workload of a note is more than 8 hours, you need to split, this assessment, at the beginning is not accurate it does not matter, every day will be reviewed, do a good job is definitely more and more accurate.
Deadline: It is said that The Deadline is the first productive force, just write the date.
priority: in the actual operation process, there is no writing, and the more tasks there are, the more needed.
the three corner marks are a small innovation
the top left indicates an extension, and a small number of extensions is normal and allowed, but it should be monitored. if it is found that most people have a large number of delays, it means that the plan is unreasonable and needs to be adjusted, and if a small number of people are found to have a large number of delays, it is more likely to be a personal problem, and the postponees need to work overtime to catch up with the progress. at this point, the team should reach a consensus, and it is shameful to let others wait and waste other people's time.
the top right indicates a sudden mission, a small number of bursts is normal and allowable, but if there are a large number of bursts, it means that the plan is insufficient, inexperienced, or there are "external forces" that often interfere with the progress of the project.
The bottom left indicates a continuous task, which can be posted in Doing all the time, such as "handling user feedback" for product personnel, and non-continuous tasks should be from Doing to Don every day.
the basic idea of agile is to optimize the methodology while doing it, and the team will come together.
cards in multiple colors can also be flexibly applied, for example, we only have 4 characters now, exactly 4 colors - product, design, front end, development.
with sticky notes, then let's make kanban.
Todo、Doing、Done
What is in Todo is the part of the information that needs to be done in this project and has not yet been done, and only needs to be clearly marked:
Task description: It can be summarized, such as "mobile phone version of the design", especially what to do after a long time, split the sticky note from Todo to Doing immediately, and discard the old sticky note.
Priority: Together with the hour evaluation, determine which sticky notes should be taken into the Doing every day.
The hour assessment and the deadline can be determined simultaneously when the sticky note is taken from To do to The Doing.
If there are too few sticky notes in the Todo, it means that there is no plan for what to do in the future, or that the current project is coming to an end.
Doing said that the day to do things, if the sticky notes are too small, or the total working hours are much less than 8 hours, it means that there is a problem with the work arrangement, of course, usually the average of 5 to 6 hours a day is reasonable. If you do a good job, paste 3 to 5 sticky notes every day, some of which must be completed, and some of which can be impacted by the bones.
Done is something that has already been done, and as the project progresses, more and more, remember to collect it and archive it at the end.
Vertical axis is divided into roles, each role is divided into different people, in the Todo stage of the sticky notes, some are only determined roles, not sure who will do it, such as the development task "build a test environment".
daily standing meeting (called standing assembly, which means standing together to meet)
a fixed time every day, which can be a morning, or before the end of work every day, every week to change people to convene and host.
What was done today, while saying it, took the Doing one; what to do tomorrow, while saying what to do, while saying it, took the Doing from The Todo.
at the meeting, everyone should pay special attention to the tasks that need to cooperate with each other and have pre-reliance.
there is also some information that can also be written on the kanban board, such as the date of several key nodes of the current project (functional review, release and launch), who is the host of this week's meeting (weekly rotation), and the day on which the current kanban information has been updated.
after each project is completed, it will also be reviewed to see what "good needs to be maintained; bad needs to be improved" in the management method.
Over, as you may also see, there's a lot of Scrum localization in there.
No comments:
Post a Comment