最大网站建设公司,一键免费生成网页的网站,seo网站优化推荐,程序员做网站赚钱在很多软件公司#xff0c;特别是一些创业型的团队中#xff0c;对于这样的情景可能大家都很熟悉#xff1a;项目经理或者产品经理#xff08;产品狗#xff09;口头或者简单记录一下软件产品的大致要做的功能#xff0c;直接就让研发团队的兄弟#xff08;程序猿#… 在很多软件公司特别是一些创业型的团队中对于这样的情景可能大家都很熟悉项目经理或者产品经理产品狗口头或者简单记录一下软件产品的大致要做的功能直接就让研发团队的兄弟程序猿去狂撸代码。然后他就去喝茶撩妹或者回家陪老婆了...这种撸起袖子就开干的方式看似简单高效便于直接沟通能够快速迭代。却不知发现没有一份正规且实时更新的功能需求设计文档会付出三四倍的代价来弥补。最终会引发一场产品狗和程序猿之间的“猿狗大战”...一、WHY - 为什么需要功能需求设计说明书在没有功能设计文档时主要有如下几个问题1、前期研究团队沟通成本如何要让团队里面的所有人员对软件产品的功能需求设计有一个共识没有功能设计文档反正我是想不出有什么办法。当该项目的团队人员越多沟通成本就变得很高。研发人员很容易有一个通病以为自己了解了一小块需求就立即开始埋头狂撸......代码。最终很可能与项目经理和客户真正想要的功能相差甚远。更可怕的研发人员把数据库设计好了代码也已经写得差不多了这时产品狗突然跑到程序猿这说我们的需求要做一点变化大家都知道“对产品狗来说那一点变化可能会害得程序猿撸过几天几夜”。那很小的变更可能导致之前设计的数据库码的代码都不能用了。对于程序猿没有什么比加班加点写了几个月的代码最终被产品狗告知需求变了代码要删除重新写更可怕的。估计只能用涨工资来安慰一下那受伤的心灵了。还有一个比较隐藏的事情是每个程序猿都认为自己写的代码很牛逼其实对于大多数人这只是一个错觉你写得代码并不优秀不太愿意删除之前所写的东西总是想在原有的代码基础上进行修改让他们删除代码比杀了他还难。作为公司的技术负责人我每几天都会Code Review团队里面所有人的代码一直要求他们把不用的代码去掉但他们的应对方式总是加两个//。注释掉他们写的代码而不是去做真正的删除动作。他们总有自己的理由“这只是暂时注释掉后面会用到”但最终的结果是那些代码就像尸体一样一直在那里干扰着团队人员正常的思路。所以我只能强制性让他们那些“暂时没有用以后会用到的代码”干掉 。2、前期任务进度安排和分配该文档也是任务进度安排和分配的重要依据。在没有功能需求设计文档之前的所有任务进度计划都是瞎扯淡都不知道具体要做什么东西哪能拿出合理的任务进度计划。如果你拿出来了我也不相信那是经过认真分析做的进度计划我知道那只是用来看领导看的。3、中期产品经理需求变更软件在开发过程中难免会遇到功能的需求变更将程序猿们召集在一起把所有的变更讲一遍当走出会议室的时候可能每个人都有自己的理解。下一场战争已悄然临近...4、后期测试团队产品测试测试团队应该在项目Kickoff之时就应该介入而不是在产品开发完成之后。测试团队应该对功能需求设计文档充分了解且以此来编写具体的测试用例文档。否则只能是在界面上进行简单的表面测试而真正的BUG并不在表面这些BUG会藏得很深等发现的时候可能已经造成很大的损失。测试团队想覆盖全部的测试用例此时已经相当困难他们甚至都不知道产品有哪些功能。测试用例应该尽可能详细尽量保证测试用例走完能确保产品能上线发布。下图为我们在登录注册时用到的一部分用例二、WHERE - 文档应该放在何处功能说明文档一定要保持实时性任何变更的需求新增的需求都必须在该文档中体现。一只产品狗或一群在编写完文档后要发给项目经理、研发人员、销售人员、运营推广人员等人如何保证每个人的文档都是最新的呢如果通过QQ邮件等方式是不是每次更新都要重新通知所有人“嘿各位兄弟文档作了一次修改我给大家都重新发一份新的”。每个人电脑里面都有好几个版本的文档时间长了自己都忘记哪个文档是最新的产品狗也记不清是否是所有相关的人都发了最新的文档。研发人员可能会说通过SVN来作版本管理啊给每个人分配一个帐号。“天啊SVN是啥”-销售人员、运营推广人员估计一脸懵逼。更好的办法是通过团队实时协作的云端工具。从而实现分享和实时讨论告别反复修改版本再发送邮件的麻烦。如果你会FQ那你可以使用Google Docs、Office Online。否则你可以使用石墨文档、一起写。三、WHAT - 什么是功能需求设计文档 应该包含那些内容功能需求设计文档最重要的是描述产品所要包含的所有功能越详细越好可以结合产品的原型设计图来讲解。让项目所有相关人知道产品是什么包含哪些页面页面如何跳转等。该文档是产品经理、项目经理、研发人员、销售人员、运营推广人员沟通的一个桥梁一份好的功能需求设计文档是软件产品是否能成功的关键。考虑是该文档的受众这份文档不应该包含具体的编程技术上的说明。不管你是用C#/.NET、JAVA还是其它这应该是另外研发团队内部使用的一份文档。一般人第一反映就是去网上找一份功能需求设计文档模板我个人感觉那些模板90%根本没有存在的必要。都太过形式化不要没有实际意义和模板化的内容只会使文档成为一个摆饰反而是在浪费大家的时间。那么一份合格的软件需求设计文档应该包括哪些内容呢1、项目背景项目产生的实际背景、具体的运用场景、大致要解决什么样的问题、针对的阅读对象、版本修改记录、文档作者以及修改人信息。2、详细的功能点描述写明产品所包含的所有功能点对功能、界面、接口的描述一定要充分详细每处可以交互的地方都要给出具体的说明。再次强调一定要详细描述每一个页面所拥有的功能。3、产品不包含的功能点说明除了写明产品所包含的所有功能点外还应该写明软件所不包含的功能这一点也很重要。4、使用场景画面感将复杂的业务逻辑融入到具体的使用场景中更容易让项目经理、研发人员、销售人员、运营推广人员不同背景的人产生共识。5、流程图大家都知道“一图胜千言”能用图说明的尽量用图来说明只通过大量枯燥的文字可能效果并不太好。流程图是一种用图形表示逻辑和算法的工具特别对研发人员撸代码很有帮助。Windows用户可以使用VisioMac用户可以使用OmniGraffle还可以使用免费在线作图,实时协作工具ProcessOn。我之前就用ProcessOn画了一个设置了缓存的网络请求的流程图这里作个参考6、人员角色“实例化”跟上面提到的“画面感”相结合将人员和角色能够实例化。比如我们的产品要实现如下功能有两种表达方式医生给患者测量血压并记录到系统中。上海华山医院肾内科的王主任医生在给32号病区1号病床的患者刘阿姨测量血压将测量到的血压100/70mmHg输入到透析管理系统。哪种方式更便于理解特别是对医疗知识不太了解的码农们。当然可能有人觉得第一种方式更简洁。可能是我举的例子不够好也可能是我的理解能力不够强。但不要怀疑我的智商哈哈哈...7、结合产品原型设计图产品原型设计图可以粗枝大叶地产品大致的框架。便于项目经理、研发人员、销售人员、运营推广人员等人在产品未开发之前对产品有一个相对直观的认识。没有一个原型图想到这帮人拉到同一个频道沟通一定是不可能的事。如果你做到了那么赶紧把你的简历发我我决定录用你常用的原型设计工具有墨刀、Mockplus、Axure。扯了这么多来个例子吧。本软件是给北京某医院集团肾内科透析患者所使用的软件包括院内管理系统、院外大数据平台、医护端APP、患者端APP...版本作者  修订时间 审核人     v1.0.0Charlie Chu2017-2-12Vivian Wong使用场景一肾内科的医生王医生给31号病床刘阿姨进行透析上机操作王医生在院内透析管理系统上点击上机操作信息会传递到院外的大数据平台以及医护端APP、患者端APP上...刘阿姨患者的家属登录到患者端APP后可以实时查看刘阿姨透析过程中的所有信息还可以查看血压、血糖、体重等历史数据...当刘阿姨在家中通过蓝牙血压计测量血压时自动同步到医院内部如果刘阿姨的血压超过预先设置的值院内的王医生则会在自己的手机上查看到刘阿姨的血压异常报警信息王医生可以立即跟刘阿姨的家属进行实时沟通......此处省略N字...本软件(v1.0.1版本)不包括的功能需求如下医生与患者的实时IM医生排班设置修改密码患者积分功能模块详细描述一、APP登录页面由于本产品不存在患者自己注册的场景所有的患者录入都发生在院外透析系统中患者及家属在院外只需要输入相应的手机号即可登录系统。登录页面只有两个输入框一个手机号一个密码。当用户要输入手机号时手机应该弹出纯数字键盘最多只能输入手机号固定的11位。密码最多输入10位。当用户点击登录时APP与后台服务器进行交互不输入手机号和密码直接点击登录按钮应该提示用户输入手机号和密码。输入手机号但不输入密码点击登录提示“请输入密码”。输入不正确的手机号点击登录应该提示“不存在该用户”。输入小于11位的手机号应该提示“请输入正确的手机号”。二、登录后首页下图是左侧是一个首页右侧是一个点击透析预警的详细页面:首页包括功能点资讯信息轮播 首页顶部资讯信息轮播功能点击可以跳转到新的页面可以查看资讯详情。病情咨询 点击“病情咨询”模块患者查看向指定的医生了解自己的病情。透析记录 点击透析记录患者可以随时随地查看自己的过往透析记录。食物速查 点击食物速查可以查看所有类别的食物成份含量。透析上下机实时信息列表 当患者在医院内进行透析上下机等操作时会记录患者的透析上机时间 、下机时间等信息。点击其中的一条记录跳转到透析详情页面如上图右侧所示。四、HOW - 如何保证文档质量要保证文档能够实时更新同步而不是疲于应付。那就是让大家都通过该文档来进行沟通谁有问题直接去看文档需求一旦变更首先就更新到文档。研发人员严格按文档上的描述来开发在没有文档之前对不起拒绝开发任何口头、QQ或邮件上的新的功能需求一概不理提前是产品狗要比较给力否则老板还是会让你狂撸代码...原文作者CharlieChu原文出处https://www.cnblogs.com/charliechu版权归原作者所有转载仅供学习使用不用于任何商业用途如有侵权请留言联系删除感谢合作。数据与算法之美用数据解决不可能长按扫码关注