pid的基本调整方法(关于B端需求文档)
编辑导读:产品经理不是在写需求文档,就是在写需求文档的路上。尽管写需求文档是一个基础功,但是如何写好,以及B端和C端写需求文档有什么区别,值得我们深究。本文作者对此进行了分析,与你分享。
接上两篇内容《B端原型绘制入门》和《快速入手甲方项目》的最后内容,这两篇一个是原型一个业务,现在继续说一下落地,也就是需求文档怎么写。昨天上午刚交付了最近负责的小程序前后端文档,加起来快2W字,最终开发也签字确认了,趁着热乎跟大家分享一下。
一、需求文档模板到底能不能套着写?市面上的文档模板太多了,直接可以搜到的,各种教学,各种视频都在讲,你一个新人怎么能不会写文档,所以这里面的水分,相信付过费的才能知道。
模板是可以套的,比如说公司内不是没有模板,那我能不按他模板写自己写吗,一般情况下不能,在写文档之前大家要明白一个事实,就是你现在到底在公司承担的是什么角色,是团队的冲锋还是后勤补给。这里不涉及到职位,是什么角色大家自己掂量着判断,如果是后勤部队,那你写的文档只写了核心业务,基本跳转,剩下的部门写的没那么专业,是没问题的。至于模板上什么页面响应了,硬件支持了,你不写一点问题没有,删掉就可以了。但如果你是团队的冲锋,你要负责团队和开发部门的对接,需要向不懂网络老板汇报,这时候就需要搞明白所做的东西需要哪些支持了,总不能项目做完,没有环境支持,该买设备买设备,该买服务器买服务器,都要考虑到。
还要注意一点就是模板归模板,不能死套,举个例子,比如模板上让你写了产品功能,需求描述,功能介绍,没说贴图的事,某个页面存在六个面包屑,每个页面都有几个业务,你能不贴图像写作文一样描述需求吗,是不行的,复杂的业务记着贴图描述。
所以那些简历造假的,找到的工作能力不配职位的,这才是他们头疼的问题。
二、C端文档和B端文档的区别先说结论:
C端重跳转,页面状态,分享路径等
B端重业务逻辑,数据的输入输出,约束条件等
这次正好负责了前后端的文档撰写,能更好根据自己这一段的经验来描述,有一个很大的感受就是前后端是有很大关联的,举个例子,前端的用户分为两种,一种是VIP,一种是普通用户,在前端我需要给VIP账号更好的体验,让他能干更多的事有更多的权利,这句话很明显是一句没有经过处理的需求描述,那转化成产品需求应该是什么呢,“普通用户拥有的权限为XX,XX,VIP用户拥有的权限为XX,XX,XX,XX,未登录时默认展示全部,当用户登录后,进行展示内容分层”,这是产品需求,也是经过梳理后的业务需求,这句话需要写在前端的文档里,那我现在怎么去描述后端的这部分?大家可以做个小思考。
经过这样的前后端梳理,是很有趣的,而且能有一个全局的思考,不会随便说一些奇怪的需求,见识的多了,也就理智了,这句话也适用于生活。再举个例子,拿之前很火的一个传统行业提出的需求“手机屏幕能跟随手机壳变色”来说,如果这个人懂基本的技术实现方式,数据库,一些业务边际他就不会提出这个,当然这个也有点夸张,但我相信大家还是有遇到过这样的人。
三、具体应该注意什么,怎么写?先说基本的,什么项目背景,角色,阅读对象等乱七八糟的写不写,这取决与你们公司的流程,是产研一家,还是人家根本不知道你这些东西,如果不知道你就要好好写了,如果天天在一块探讨业务,那还写个屁,还有最后面的功能性需求,例如页面响应,拓展需求,易用需求等,上面说过了你要不是冲锋陷阵的,就不用写,你也不会写,只需要把基本核心业务,基本流程写清楚,原型上做好跳转就行了,这一步也不是像我说的那么简单,是需要锻炼和总结的,而且当面临大型程序时是很容易出错的,这就需要之前的总结了。
中间的最重要,也就是菜单/页面描述,需求描述这些,我有个习惯,在文档写之前先把这部分的目录写好,也就是页面结构序号先写上,这样后期会比较清晰,然后就是把写好的描述标题,依次按页面粘到结构上就可以开写了。
页面/模块描述不要瞎写,该页面/模块主要实现什么业务就写上什么,如果实在没有,只是展示,那就写XX信息展示,这块优先写业务,其次操作。
数据排序/来源,有就写没有就不写,来源不知道的就自己搞清楚,如果有来源别忘了搞清楚输出,排序一般为倒序,特殊情况自己考虑
页面描述,优先写清楚所有跳转,跳转涉及到的业务也清楚,判断,业务流程,操作,按钮,各种权限,字段都要考虑到,这就是基本的文档撰写,建议不知道的不要不写,如果现在在团队里有人带,建议都问清楚,这对后续业务理解有很大帮助
字段描述,这块可以比作开发的基本工作手册,这里有一个容易犯的错误就是,画原型的时候咱们会把所有文字处理好,是肯定不会换行和省略号的一般,但如果用户就是要瞎写,或者标题就是特别长怎么办,再或者你花了登录页,什么约束都没写,用户设置密码五个1,这写问题后续是不是很可能出现问题?所以文档这块内容要描述清楚,文字多的一行放不下了怎么处理,上传的地方限制的数量,大小,让输手机号,用户输一堆密码该怎么限制,这些都是基本的,要描述清楚,就算你不懂什么格式,限制,那就写“不允许换行,多的做适应性处理”,那开发也可以自由发挥,就怕没有写到,而开发也没有注意,那后续就很可能出现问题。
四、写在最后上面所有的内容还需要考虑一个前提,公司怎么要求的,如果有硬性要求还是要按规章制度走,可以找兄弟部门或者内部要一份标准的,在去调整文档,剩下的欢迎讨论补充,大家一起进步。
作者:胡子邯 ;公众号:产品经理的日常反思
本文由 @胡子邯 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
,
免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com