Easy to read Facebook

Those so-called "processes" do not exist within Facebook, and these steps are not necessarily necessary. For different types of projects, some of the time requirements are higher, so more emphasis on speed, some of the higher quality requirements, so more emphasis on project management processes (process). So please read the reader to think carefully, which is in line with their own actual situation, you can learn from. Which is not suitable, need flexible application.

The author of this article: Wanghuai, Facebook's second Chinese engineer and the first Chinese research and development manager. He pioneered the field of Facebook's payment security and customer service tools. He left Facebook in 2011 and returned as an angel investor, hoping to help entrepreneurs with his Facebook experience.

Before detailing the nine steps of the Facebook product development process, it is important to make it clear that I am thinking about the steps that may arise in my own practice of doing products and projects on Facebook. The so-called "process" does not exist within Facebook, and these steps are not necessarily necessary. For different types of projects, some of the time requirements are higher, so more emphasis on speed, some higher quality requirements, will be more emphasis on project management processes (process). Please read the reader carefully, which conforms to their own actual situation, you can learn from; What is not suitable, to be flexible master.

Sketch vision, set goals

Have a clear goal before you do everything, and have a big vision (Vision) before you focus on the details, which will guide you in the future. For the perspective of thinking, mainly around the following three points.

1. Why set this goal, not the other one?

2. Before doing one thing, there should be a picture of what this thing is like in the mind, and then a lot of things are going on around the final screen.

3. What do you plan to do to achieve this vision? This requires that the final goal be materialized into an imagined image, or even quantified, before the final goal can be easily understood by others.

So how do you set goals? On Facebook, the usual approach is to follow the "SMART" rule.

s very detailed and specific (specific). Goals must be clearly defined, unable to be confused or misunderstood.

m--can be measured (measurable). Only measurable goals can always be clearly done, how far away from the target, and whether the current is above or below the expected progress.

Bisphenol must be difficult and challenging (aggressive). Easy to achieve goals, it is easy to make employees slack off, once lost the passion of fighting, not to mention their potential.

Runnable realistic (realistic), this is a balance on the point. Too difficult a goal, the staff will be exhausted, if the final still failed to complete the task, the confidence in them is a very big blow.

T must have a deadline for implementation (Time-bound). There is no point in not realizing the goal of deadlines, because you don't know when you should get there.

With a goal, there may be a detailed project plan, all of which should be relevant to these goals. Unrelated projects will be distracted (distraction) and resolutely resisted. Next, most of the group's time is spent on projects related to these goals.

Gather ideas and prioritize

With the goal, there are a lot of related ideas, but it's hard to tell which one is going to reach these goals, and it's impossible to try all the ideas out, often to end up with a sense of "gambling" and to focus on a few core ideas. That's one of the reasons Facebook has to recruit the best engineers. Engineers should not only be good at writing programs, but also have the ability to choose ideas, you should not only have a very deep thinking on this issue, a large number of analysis, but also have the courage to make a decisive bet, and have a high hit rate.

So where do these ideas come from? The most natural way is the one that has been in the past, the ones that you know exactly what to do, and the vague ideas that are difficult. In very fast-growing companies, there is absolutely no shortage of such vague ideas. At Facebook, it's usually a lot of ideas from technical managers, product managers, and engineers. Colleagues in charge of business operations (Business Twist) also contribute ideas. For the next one months, I will start to send a brainstorming meeting to the relevant people a week or so before the month of 25th, and expect them to email me what they think they should or want to do before the meeting. I do the sorting and make the meeting more efficient. Of course, offline discussion and sharing are also good opportunities to generate ideas.

The next most important thing is to analyze the idea-how to pick the ideas that are most likely to produce results. Theoretically, if there is unlimited resources, we should try all the ideas. But at Facebook, where resources are scarce at all times, we have to put limited resources into ideas that are likely to have the greatest value.

Here, I would like to highlight the top X (first x only) rule: only the first x that has the most impact on the goal. We will discuss all the ideas, discuss them according to the impact of each idea on the target and the resources it needs (mainly human and time-"People Week"), then sort (press p0,p1,p2 ...). Way), and finally pick the first few items. After analysis, it is easy to decide on several obvious ideas, and it is easy to decide what to remove, the key is the remaining ideas, do not have enough energy to try them all, this will test your ability to choose.

Cross-team communication

Once you've decided what you want to do, you'll need to discuss how to dock with the other related group's plans. You certainly don't want to think that the Brotherhood can work on a project with you, but find that the other person does not put the project related to you into their plan. The communication here is to allow the relevant groups to do things that are complementary to each other, rather than wrangling each other, causing unnecessary internal friction.

There are two types of people who are particularly in need of communication.

1. Communication between different functions, including engineers, product managers, designers, as well as upstream and downstream teams or departments related to the project.

2. Communication between the related engineering brothers. Because we often share the technology or the framework of each other, we set out to do things to see if there is a match between each other, if we need their cooperation, it depends on how to include their plans.

Tell everyone who might be concerned

We will convene a final plan to finalize the meeting. Mainly by the engineers and product managers and a number of very relevant people, such meetings are small-scale, because they do not want to make decisions in the other non-product technology personnel to participate in the voice of others have been in the previous cross-team communication process has been fully considered. If the work ahead is better prepared, the meeting speed is very fast, generally about half an hour or so.

When the whole plan is settled, an email will be sent to all those who care about the project and the people who are involved in the work. And will put the boss, boss's boss in the receiver, to ensure that they are clear, understand and support our team's plan.

Design Products

For any project, the implementation generally involves four dimensions: function (Feature Set), expected finish (time to harsh), budget (Budget, mainly personnel, as well as servers, bandwidth resources, money, etc.), complete the quality (Quality, Including scalability scalability, performance configured, etc.). Whether you make a plan or not, all decisions revolve around these four aspects. If the progress is delayed, then you can remove or streamline a function, or postpone the completion of the time, or increase the number of people, increase investment, or reduce quality, nothing more than in these four aspects of trade-offs.

It is important to know what the first version (V1) looks like when designing a product. The final state of the product can be conceived at design time, but the company will not allow a large amount of resources to build a so-called Ultimate version. Be sure to think about what the first version contains, what time to release, how many people to configure, how much money to spend on marketing, and what effect.

This can avoid the initial investment is too large, but the product is not the market needs, and then make a big change or even give up the situation of the product, which is undoubtedly a great waste.

For a technical system or framework, a meeting of relevant experts is usually convened to introduce the new system and discuss why the system is being made, its pros and cons, and its relevance to the existing system. This kind of seminar is relatively technical, there is generally no product managers involved (they do not understand the background of the technology), more of the relevant experience to invite the background engineer to participate.

The special emphasis here is that Facebook is very careful not to repeat the development of new technology systems. One principle is: a good open source system, with open source, a good commercial product, the purchase of commercial, must be developed by themselves or with the core competitiveness of Facebook, then focus on the development of a set, rather than duplication of efforts to develop multiple sets of similar systems. And for some systems that are tied to core data, Facebook will develop itself even if there is a commercial system on the market.

In addition, Facebook never expects a person to do everything for a project. I would ask a team member to take responsibility for a project, but to get him to drive the whole project doesn't mean that everything is done on his own. I will ask him to be good at using the strength of the entire company, learn to take the initiative to get help from others, to complete a project with less effort, and to grow in the process. I would encourage efforts in that direction if other groups were to help do something more appropriate.

But if a project is not successful at last, the project leader cannot be excused for not being able to provide help. Therefore, even if others promised to help, the project leader still need to learn to motivate others, supervision of others, through the "lyric reasonable" or even "bullying" and other means to get timely help.

But Facebook's culture encourages doing so only when it is appropriate to ask for help, and the work that belongs to the core of a project must be done by the team itself. Others generally can only be in their systems to give or technical advice, the main challenge is on their own. Only in this way can a team truly grow.

Designated Project Responsible person

To assign a clear responsibility to each project, it is generally an engineer. The biggest advantage of this is that responsibility is clear, and each project has a very clear owner (owner), which makes it difficult to shirk responsibility.

The second advantage is the ability to exercise staff. Facebook does not want junior engineers to be permanently screwed up, hoping that every engineer will lead a task to drive the project forward. A project with a clear responsibility can "force" the engineer to assume responsibility.

The third advantage is the ease of communication. Any colleague who is interested in a project can understand the progress of the project, and the person who is responsible for the project is the object of his communication, without necessarily having to find a technical manager or product manager.

Regular meetings

For each development project, we have to be clear about the specific progress, because what we do today is the foundation of tomorrow. Regular discussions, based on the urgency and importance of the project, can be conducted on a daily basis or one or two times a week. Generally each meeting in 10-30 minutes, and the more frequent meet time should be shorter.

When a meeting is held, all the people involved in the project, around the project, all the relevant tasks and progress quickly over, each person to their own day (or the previous week) to complete the task report. If you encounter difficulties, we will focus on the discussion, to help solve. It is better not to find some stupid excuses to stall, which will lead to the things that have been promised have not been completed on time and in quality.

Understanding Progress Summary Reports

For the development manager who is in charge of a team, have a thorough and timely understanding of each project that is being carried out in the group and know the latest progress. The green light, of course, is good, to give encouragement; in the yellow light state, to give appropriate help, remove the stumbling block, accelerate the project progress; at a red light, to understand why this is so, can also take appropriate measures to remedy the situation. In addition to action, it is very important to reflect, to find out why not in the yellow light in time to discover and give help, and then learn to avoid the same mistakes in the future.

For teams fighting in the frontline, regular project meetings can allow all combatants in a project to maintain consistency in access to information and a common basis for communication. However, it is not easy to understand the progress of a project, such as a co-worker who cares about a project or the boss of a boss. As a research and development manager, I will summarize the progress of all the projects currently under way in the group at five a week to form a newsletter that will send emails to all those who are paying attention to the product and give them a chance to learn about it.

Release product monitoring data

After the product has been developed, of course, it will be launched. Some products require risk control before they are launched. For example, payment-type products often do pre-release evaluations (Pre-launch Review).

The so-called pre-release evaluation, is before the release, according to the specific products or the characteristics of the release, do some such as release strategy, the core data to be monitored, product demonstrations, core algorithm changes and other aspects of the discussion. When making a product discussion, I ask the attendees to think about it-"What if there's a big problem with this release?" The main purpose is to think about the nodes that may be wrong before the release, if it is a big risk, to do some necessary protective measures; if it is a small risk, be aware that you are risking it and be prepared to remedy the problem once it has occurred. In addition, as Facebook releases more products and often interact with each other, a pre-release assessment will let you know when the product will be launched.

A release of the project is the valve-controlled grayscale release, is the control of the selection of the release of the population and its proportion. Grayscale publishing is to control the scope and speed of publishing, but how to know the quality of a certain stage of product release, under what conditions to improve the scope of gray publishing? Only through data monitoring to determine the status of the release. Two types of data need to be monitored.

A class of data reflects the current state of the system, such as the total number of accesses, the amount of access and the proportion of the total, the number and proportions of fatal range errors, the speed of access, the most error-type statistics, and so on. The statistics and presentation of these data should be real-time in order to ensure that if a problem occurs, it can be detected and taken in the shortest time possible.

Another type of data reflects the user impact of the new functionality (either impact or business Insight). This part of the data can directly reflect the purpose of starting the product or function. Only this part of the data feedback is positive, and its changes to an acceptable level, you can consider expanding the scope of the publication.

Not all publications are successful. From my experience, the pursuit of a perfect release is unrealistic, regardless of the previous pre-launch review how comprehensive, each release has such or such a problem arises, the best situation is that every time the problem is new, not the last time the error has occurred. But after the problem occurs, usually through Post-mortem try to learn from the mistakes as much as possible, so that each release brings the value of learning to maximize.

The so-called Post-mortem, through the analysis of past problems, summed up the action plan can be taken to avoid the recurrence of similar mistakes. It is not only suitable for the problem research of product release, but also used in the post analysis of any emergent events.

Summary

The above is my summary of the Facebook product development process, of course, for each specific product, not necessarily strictly follow these steps, but the general idea is similar. As needed, some of the steps can be omitted. The fundamental purpose is to release the product as early as possible after it meets the basic quality standards, and then iterate quickly based on the monitoring data.

I have communicated with some domestic start-up companies on the product development process, hoping that the Silicon Valley company's ideas can bring them inspiration. However, Facebook's practices do not necessarily apply to Chinese Internet companies. On Facebook, many times before you prove you can't, assume you have the ability to do a difficult task. Since Facebook is the best person to recruit, this assumption is proven to be feasible in most cases.