foreword
Many product newcomers, when getting started with a product, want to know how to draw a prototype and how to write a requirement document, which is very strange.
One product has one requirements document, just like you can find many articles about requirements documents on the platform; after reading so many articles, none of the requirements documents is unified. Why? I think it may be better to determine the reasonable format of the requirements document and whether to use the requirements document according to the actual situation of the requirements and the urgency of the development at that time. In any case, the requirements document is very important as a product inheritance document!
Tell everyone how to write the requirements document, but rarely say why it is written like this? Everyone focuses on how to achieve and how to present it, but they don't pay attention to why it is written like this? As many famous masters often say about art and Tao, art is important, Tao is more important, knowing why is more important!
1. The origin of all things
When encountering any problem, the most common way of thinking is: the three elements of the problem-what, why, and how to do it. This is the most common way of thinking in almost all industries and all groups of people when facing things.
The author believes that based on the most classic, efficient, and practical way of thinking, each person can summarize their own way of thinking for different knowledge systems, ways of thinking, and experience summaries.
The method I often use is what I learned from my social economics teacher many years ago. I have made supplements and optimizations and share it with you:
At a specific time, a specific place, a specific group of people did a specific event for a specific reason. What are the expectations before the specific event is achieved, what is the actual effect, what is the gap in the middle, and how to optimize the way to deal with such events in the future.
According to the above way of thinking, we regard the requirement document to be written as a specific event, and realize the analysis of the requirement document by analyzing the pre-conditions and post-supplementary content of the specific event being triggered.
2. What is a requirements document?
The author defines the requirements document as: a content document used to explain the product and satisfy the development of collaborative personnel. There are two important points in this definition:
-
- explain
That is to explain what the product to be developed is. The "what" here is different from the product description document, which is similar to the product manual and is used to inform users how to use my product.
The "what" here is to inform the relevant personnel of the product, what functions the product has, how to present this function, and how to realize it. Specifically, it includes the following aspects:
(1) Why do you want to make this product?
Where does the product come from? Iterative optimization of internal versions, bug fixes, new features, business department requirements, or user feedback requirements.
It is necessary to clearly explain the project background of the product. On the one hand, it will help developers better understand the overall project, so that the project plan, project progress, and project completion can be formulated more smoothly; on the other hand, the archived documents after product development are completed
. It is helpful for follow-up review of the product, version iteration, bug traceability, and even when there is a personnel change, it helps the receiving personnel to quickly understand the project and be familiar with the cause and effect of the product as a whole.
(2) What conflicts does the product resolve?
Requirements come from user conflicts, and irreconcilable problems such as difficulties, doubts, and anxieties encountered by users in use are waiting to be resolved.
When conducting research, interviews, and other communications with users, fully understanding user conflicts and pain points that need to be solved urgently will help product managers grasp the direction more accurately during the product planning stage and make products that better meet user demands.
At the same time, in the communication of understanding conflicts, in addition to accurately obtaining the core demands of users, many non-core demands will also be obtained. These come from the subconscious needs of users, which will provide good help for future product development.
Listing these requirements and sorting them into the demand pool will help to compare with users and businesses when communicating again in the future, so as to eliminate the false and preserve the true, and prioritize the needs in the demand pool, and according to the actual business development stage and the company as a whole Requirements, divide the product stages, and realize the needs in the demand pool, so as to promote the development of the product in a better direction.
(3) What purpose does the product fulfill?
The realization of any product is not only to meet the needs of users, but also to achieve more goals when resolving conflicts. And this purpose is divided into two dimensions, the material level and the spiritual level.
1) Material level
The launch of the product solves the company's business-level process, meets business needs, and satisfies the use of users. This is the primary and core purpose of the product.
And after satisfying the core purpose, is there any extended product demand—reduced operation steps, optimized interaction process, and promoted the realization of customer acquisition, activation, retention, conversion, secondary promotion and other links at the company level? effect.
2) Spiritual level
The launch of the product has solved the difficulties, doubts and anxiety of the users, and solved the irritability of the business department in the process of not being able to use it normally. This is the feedback of the core purpose of the product in the hearts of the users.
At the same time, on the premise of solving the negative emotions with the highest priority of users, improving the user's perception of the product and the favorability of the corporate brand is the best effect that the product can achieve.
-
- Meet the Collaborative Staff
That is, which coordinators are shown the requirements document. The "collaborators" here are not just developers, but all participants involved in the process from the delivery of the prototype to the final launch of the product.
These collaborators have different requirements for requirements documents based on their respective positions and responsibilities. This is what all product managers should pay special attention to when writing requirements documents.
Taking the author's current company as an example, the collaborators include the following groups:
Product managers: Most companies will have more than one product manager. When each product manager is in charge of his own product line, the output requirements document is necessary for the work of other product managers.
Designers: Professionals who can do visual experiences such as static pages, gifs, and interactive designs.
Front-end development: Professionals who mainly input static pages and interactive dynamic effects, including various judgment logics, and finally use HTML as the output style.
APP development: Professionals in the page style, interaction style, and logic output of the APP that users can see.
Background development: Professionals who build tables in the background, set logic rules, and transfer data and fields through the interface.
Test engineer: Professionals who test products in conventional and unconventional environments, and detect all existing factors and hidden dangers, are the last line of defense to ensure that the product goes online without bugs.
-
- The relationship between "explaining" and "satisfying collaborators"
Everything that exists has a cause and effect. Satisfying the coordinators is the cause, and in order to satisfy the coordinators, the output requirements document is the result. The interaction between cause and effect contributed to the final delivery and launch of the product.
3. What is the meaning of the requirements document?
Giving the right things to the right people and satisfying the needs of coordinators is the meaning of the existence of requirements documents.
How to write a requirements document that meets the demands of the coordinators? First of all, it is necessary to observe the specific work scenarios of different coordinators, based on the conflicts in their work scenarios, discover their needs, and then output the solution, which is the best requirements document.
-
- Product manager's request
(1) Version requirements discussion and requirements review meeting of the product department.
In the discussion of the version task, when talking about the planned functions with other product managers, the version records, project background, project framework diagram, and flow chart can quickly let other product managers understand the overall project and give opinions based on the project background .
(2) There is an intersection with the content that other product managers are responsible for.
When each product manager is responsible for part of the content of a complete project, the requirement documents for each part of the function will help other product managers find out whether the connection in the intersection is appropriate and the overall integration of each functional module from the document.
(3) Bug handling.
再厉害的程序员也不敢保证产品上线后不出现任何问题，当产品上线后出现问题，需求文档有助于产品经理快速找到规划的初衷，根据之前的情境给出精准的解决方案。
（4）版本迭代。
当产品在不同时期，做不同的版本迭代时，之前的需求文档尤为重要，有助于负责该项目的产品经理快速熟悉往期规划的初衷、目的和当前的效果及不足，并在迭代版本中对往期问题进行修复，在新的规划中避免不必要的坑。
（5）人员异动。
如果出现人员异动（人员项目变更、人员离职等），有助于新接手的产品经理快速熟悉项目，确保项目规划不会因个人经验、个人喜好、习惯等原因，出现太大的偏差。
基于以上场景和目的，其他产品经理对需求文档的诉求需要得到的信息：谁、在什么时间、因为什么原因，做了什么内容，满足了什么人的需求，变动内容及节点、阶段性规划。
-
- 设计师的诉求
设计师是项目实施阶段的第一步。确定版的需求在落地执行时，首先是由设计师开始制作设计图。项目的整体功能有哪些、基于什么背景、未来的规划方向，需要在文档中给出建议和说明，有助于设计师按照产品经理的设想，设计出符合或高于期待的产品设计图。
基于上述场景和目的，针对设计师角色，产品经理在编写需求文档时，需要告知的信息：因为什么原因，给什么特点的群体，做什么图，当前竞品什么情况、公司什么情况、市场什么情况，想达到什么效果，后期发展方向（业务、功能、设计方向等）。
-
- 开发人员的诉求（前端、APP、后台、测试）
前端开发：开发过程中，侧重了解涉及前端部分的页面功能、交互效果、交互逻辑；
APP开发：开发过程中，侧重了解页面元素、页面样式、功能、与后台间的接口参数传递；
后台开发：开发过程中，侧重了解功能、这些功能在后台的数据结构搭建、如何建表、功能逻辑、与前台兼的接口参数传递；
测试工程师：在产品实现过程中，侧重从产品规划中了解整体功能，从而写测试用例，以及产品上线前根据设计图的样式、文档表述的功能规则，做功能测试。
基于删除场景，产品经理在编写需求文档时，需要告知开发人员的信息：因为什么原因，针对什么项目，做什么功能，包含哪些页面元素、页面样式、交互逻辑、实现效果。
-
- 注意事项
尽信书不如无书。各公司的组织架构、部门角色划分、业务开展的推动因素、公司发展所处的阶段均不相同，虽大道同源，但总有差异化表现。
需要产品经理针对协同人员做好分层、分类，切实与相关人员深入沟通，了解他们的习惯，了解他们的认知，输出他们需要的需求文档，才能够确保信息的透明化，保证开发人员全面了解规划的内容。
同时，辅助以良好的沟通机制和技巧，则有助于开发效率的提高和产品上线的进度保障。
四、如何写需求文档？
-
- 写文档先看人
需求文档与产品经理前期做用户调研时的用户画像很相似。
在做用户画像时，通过与目标群体各种方式的沟通，获取用户的基本信息、兴趣、习惯、家庭情况、对产品相关业务的了解程度、接受程度、烦恼和期待等等，从而建立用户档案，输出用户的判断结果。
在写需求文档前，面对我们的用户——相关协同人员，产品经理需要去了解他们。了解他们的工作方式、工作习惯、工作态度、工作认知、工作能力等与工作相关的内容，同时，对他们与人相处的方式、生活习惯、兴趣爱好等等的了解，有助于产品经理更全面的了解，从而建立更加立体的用户画像。
在输出判断结果时会更准确，写需求文档会更有侧重点——哪些是他们需要知道的，哪些是他们需要特别详细表述的，哪些是需要特殊标注的，哪些是省略表述即可的。
-
- 文档规范
（1）版本记录
谁：该文档是谁编写的，便于快速找到对应的负责人员，同时，后期有助于在需求文档库中建档分类。
时间：什么时间编写的该文档，旨在告知该功能是什么时间要开始做，便于后期溯源时，快速定位。
事件：针对什么产品、什么功能做的规划，其实就是文档标题。
版本号：便于记录产品不同版本的节点做了什么内容及调整，同时，针对不同的系统，有助于使用统一的版本号做管理。
上线计划：依据上线计划倒推测试周期、开发周期、设计周期，从而给参与该项目的协同人员约定好时间，便于更好的把控项目进度。
评审及修改：项目完成后的需求评审建议和结果，针对初稿内容做了哪些修改。此处一定要详细，后续调整内容时，评审建议和修改事项是很重要的可参考的细节点。
（2）版本说明
项目背景：清楚地写出为什么要做该项目，谁要求做的。
核心需求：为了解决什么冲突。
预期目的：想达到什么结果，后续有什么进一步的规划。
详细的项目背景有助于所有参与人员快速地了解项目是怎么回事。
（3）设计规范
设计规范来源于产品经理对该产品的整体了解：在做完市场分析、行业分析、竞品机构分析、用户调研之后，针对自己要做的产品，产品经理会形成自己的整体构思和产品走向模型。
而这个构思就是需要表达给设计师的理念——要做一款什么样的产品，要达到什么效果。
关于设计理念的表达，不同的公司有很大的差别，以及整个行业对这块内容都没有统一的观点。
一种观点认为，产品经理只需要输出黑白灰原型图即可，其他的都交给设计师处理，给设计师足够的发挥空间；
另一种观点认为，设计师对要做的产品，不了解缘由，直接去设计会有偏差，最终交付的产品大部分都不符合；
还有种观点认为，要看设计师的水平再来决定，水平高的不需要产品经理说什么，都可以交付足够让人惊艳的设计，水平低的说再多，也做不出效果，而大部分公司都属于第二种情况。
综上所述，岗位不同、职位不同、个人认知的不同，以及最重要的信息接收到处理个人间都是有差异的，最终呈现在产品上的内容就会有很大的差异。
而规避这类问题，最好的方式还是沟通。充足且有效的沟通，确保产品经理与设计师间的已知信息达到一致，双方的理念、想法、建议等越碰撞越容易做出更好的产品。
主要对接的内容包含两个部分：
信息与意向：传递产品信息，告知设计师关于该产品的设计原因、行业情况、要做的产品对标竞品是哪些，以后对产品的规划是什么、产品经理的意向是什么。
基础设计理念：产品主题、整体色调、各样式的字号、色号、全局页面的建议等。
（4）功能列表
功能列表为产品经理在经过足够多的调研和分析，从汇总的产品需求池中筛选出的当前应处理需求列表。
功能列表的作用为便于相关人员全面了解产品的功能，从而评估项目周期、处理优先级等。
功能列表主要表述都做什么功能，哪些重要且紧急。列表参数包含：
模块
功能点
功能点描述（详细）
优先级（高、中、低）
（5）角色列表
角色列表为表述清楚该产品上线后，参与到该产品中的群体有哪些。列表参数包含：
角色名称
职责：在产品参与中的简要说明
备注：特殊情形
(6) Framework diagram
The framework diagram shows what the product contains: modules and functions. It is convenient for developers to quickly and conveniently understand the overall situation of the product.
The frame diagram does not need to be very tall, it is certainly good to be tall, and it will make the users pleasing to the eye. However, it is more important that the function introduction is simple and easy to understand and that developers can understand and understand, and we must not lose sight of the basics.
(7) Flow chart The flow
chart is divided into two parts:
overall flow chart: the overall flow is the interaction process between the major modules of the product, and generally it is a positive process, supplemented by a partial judgment process and an exception handling mechanism function
flow chart: Functional flow is an interactive flow involving specific function points, including: forward flow, rule, judgment flow, and exception flow.
(8) Functional requirements
Functional requirements are specific functional points, and are the core of the requirements document. It mainly breaks down each function point in detail, including two aspects:
Front-end: For the front-end part, how the page comes, page elements, rules of each function point, interaction, jump rules, page elements of unconventional processes, interaction, jump rules, etc.
Background part: the realization of front-end functions depends on which logic and data in the background, whether new function modules are needed, the content of new function modules, data call, storage, interface data transfer, etc.
(9) Non-functional requirements
Non-functional requirements are extreme situations when users routinely operate products, and involve a lot of content. Here are a few more important points that need to be considered in routine planning: Product performance: product response to user operations, impact
on groups Operational concurrency prevention, etc.
Security: Confidentiality handling of company data and user information, authority settings for different roles, restrictions in use, etc.
Reliability: When there is an abnormal situation in the user's operation, whether the operation can continue, whether the data or usage status can be restored when encountering an abnormal situation, etc.
Scalability: Scalability is mainly for the internal of the company. After the product is completed, whether it is a designer, developer, or tester, whether the work done on the product can be reused elsewhere. Whether the user's usage in the product can be obtained by the system and used for analysis of different dimensions, etc.
Five, one more word
In the requirements document, the expression of functions is particularly important. The more detailed consideration is given to each function point, the more conducive it is for developers to evaluate the implementation difficulty, evaluation time, and achieve the desired effect smoothly.
Six, the last sentence
The more detailed the requirements document is, the better. There are many unnecessary explanations, and you don’t need to spend a lot of time writing them. The core thing is still: let the relevant personnel of your company understand quickly and comprehensively.
It is better to have no books than to believe in books, and each company is different. Product managers should stand more from the perspective of their own company, and output the requirements documents they need after fully understanding the relevant coordinators.
This article was originally published by @kuang on Everyone is a Product Manager.
The title picture is from Unsplash, based on the CC0 protocol
Note:
Likes, comments, and reprints are welcome. Please give the link to the original text in an obvious place on the article page
. Those who know, thank you for reading my article in the vast crowd.
Where is the signature without personality!
For details, please follow me
and continue to update
| © 2020 12 - Guyu.com | 【All rights reserved】 |