在很多软件公司，尤其是一些创业团队，大家可能对这样的情况很熟悉：项目经理或者产品经理（产品狗）口头或者简单的记录下软件产品的大概功能，就让兄弟（程序员）)的研发团队疯狂编码。然后去喝茶撩妹或者回家陪老婆……这种撸起袖子做事的方式，看似简单高效，容易直接沟通，又能快速迭代。却不知如果发现没有正式的、实时更新的功能需求设计文档，我会付出三四倍的代价来弥补。最后会导致产品狗和程序员之间的“狗战”……1.WHY——为什么需要功能需求设计说明书？在没有功能设计文档的情况下，主要有以下几个问题：1.前期调研团队沟通成本如何让团队中的所有人对软件产品的功能需求设计达成共识？没有功能设计文档，反正我也想不出办法。当项目组人多的时候，沟通成本就变得非常高。研发人员很容易有一个通病：自以为理解了一小块需求，马上开始埋头……代码。最后，它很可能与项目经理和客户真正想要的功能相去甚远。更可怕的是，研发人员设计好了数据库，代码都写的差不多了。这时候产品狗突然跑到程序员面前说我们的需求要改了。殊不知，“对于产品狗来说，那一点点改动，可能会让程序员耗上几天几夜。”那个小改动可能会导致之前设计的数据库和代码代码无法使用。对于程序员来说，没有什么比加班几个月写代码，最后被产品狗说需求变了，需要删改改写代码更可怕的了。估计加薪只能用来安慰受伤的心灵。还有一个隐藏的东西就是每个程序员都认为自己写的代码牛逼（其实对于大部分人来说，这只是一种错觉，你的代码不好），不愿意删掉自己以前写的代码。东西啊，总想在原来的代码基础上做改动，让他们删代码比杀了他还难。作为公司的技术总监，我每隔几天就要给CodeReview团队所有的人审查代码，让他们去掉不用的代码，但他们的回应总是加两个//。注释掉他们编写的代码，而不是进行实际删除。他们总是有自己的理由，“这个只是暂时注释掉，以后会用到”，但最终的结果是，那些代码就像尸体一样，一直都在，干扰着团队成员的正常思维。所以只能逼着他们干掉那些“暂时没用，以后要用的代码”。2.初步任务进度安排和分配本文件也是任务进度安排和分配的重要依据。功能需求设计文档之前的所有任务进度表都是废话。不知道该干什么，怎么才能得出一个合理的任务安排。如果拿出来，我不相信这是经过仔细分析的进度计划。我知道，那只是给领导看的。3、中期产品经理需求变更软件在开发过程中难免会遇到功能需求变更。程序员会被召集起来解释所有的变化吗？走出会议室，每个人可能都有自己的理解。下一场战争正在悄然逼近……4.后期测试团队产品测试测试团队应该在项目Kickoff时参与，而不是在产品开发完成之后。测试团队应充分理解功能需求设计文档，并据此编写具体的测试用例文档。否则，只能是对界面进行简单的表面测试，而真正的bug却不在表面。这些BUG会隐藏得很深，一旦被发现可能会造成很大的损失。测试团队此时很难覆盖所有的测试用例，他们甚至不知道产品有什么功能。测试用例尽可能详细，尽量保证测试用例完成，以保证产品可以上线发布。下图是我们在登录注册时使用的一些用例：2.WHERE——文档应该放在哪里？一个产品狗（或者一个群）写好文档后，需要发给项目经理、研发人员、销售人员、运营推广人员等，如何保证每个人的文档都是最新的？如果用QQ，邮箱等方式，每次更新是不是都要重新通知大家：“嘿，兄弟们，文档改版了，我发给你一个新的。”每个人的计算机中都有多个版本的文档。时间长了，忘记哪个文件是最新的；产品狗不记得是否所有相关人员都发送了最新的文件。研发人员可能会说版本管理是通过SVN来完成的，每个人分配一个账号。“我的天，什么是SVN？”-销售人员和运营推广人员可能看起来很困惑。更好的方法是通过基于云的工具让团队进行实时协作。这样就可以实现分享和实时讨论，告别反复修改版本和发邮件的麻烦。如果你能FQ，那么你就可以使用GoogleDocs、OfficeOnline。否则你可以使用Graphite文档，一起写。3.WHAT-功能需求设计文档是什么？它应该包含什么？功能需求设计文档中最重要的是描述产品必须包含的所有功能。越详细越好，可以结合产品原型设计图进行说明。让参与项目的每个人都知道产品是什么，包含哪些页面，如何跳转到页面等。本文档是产品经理、项目经理、研发人员、销售人员、运营推广人员了解的桥梁交流。一个好的功能需求设计文档是一个软件产品成功的关键。考虑到本文档的读者，本文档不应包含有关特定编程技术的说明。不管你用的是C#/.NET、JAVA还是其他，这应该是其他研发团队内部使用的文档。大多数人的第一反应是在网上找一个功能需求设计文档模板。我个人觉得那些模板90%是完全没有必要的。他们都太正式了。不要使用没有实际意义的基于模板的内容。只会让文档成为摆设，浪费大家的时间。那么一份合格的软件需求设计文档应该包括哪些内容呢？1.项目背景项目的实际背景、具体应用场景、一般要解决的问题、目标读者、版本修改记录、文档作者和修改者信息。2.功能点详细说明表示产品包含的所有功能点。功能、界面、界面的描述要充分、详细，每一个交互的地方都要有具体的说明。同样，一定要详细描述每个页面的功能。3、产品未包含的功能点说明除了说明产品包含的所有功能点外，还应说明软件未包含的功能，这一点也很重要。4.使用场景（图感）将复杂的业务逻辑融入到具体的使用场景中，让项目经理、研发人员、销售人员、运营推广人员更容易达成共识。5.流程图众所周知，“一图抵千言”。如果能用图片说明，就尽量用图片说明。使用很多无聊的词可能不是很有效。Flowchart是一种图形化表示逻辑和算法的工具，对开发者编码特别有帮助。Windows用户可以使用Visio，Mac用户可以使用OmniGraffle，还可以使用免费的在线绘图、实时协作工具ProcessOn。之前用ProcessOn画了一个缓存网络请求的流程图。这里提供一个参考：6.人员角色的“实例化”结合上面说的“画面感”，实现人员和角色的实例化。比如我们的产品需要实现以下功能，可以用两种方式来表达：医生测量病人的血压，并记录在系统中。上海华山医院肾内科王医生正在为32号病房1号病床的患者刘阿姨测量血压，并将测得的血压100/70mmHg输入透析管理系统。哪种方式更容易理解？尤其是对医学知识了解不多的码农。当然，可能有人会觉得第一种方式更简洁。可能是我举的例子不够好，也可能是我的理解力不够强。（不过不要怀疑我的智商！哈哈哈。。。）7、结合产品原型设计图，产品原型设计图可以粗略的勾勒出产品的总体框架。方便项目经理、研发人员、销售人员、运营推广人员等在产品开发前对产品有一个相对直观的了解。没有原型，这些人肯定不可能在同一个频道上交流。（如果你做了，那就赶紧把你的简历发给我，我决定录用你！）常用的原型制作工具有Moknife、Mockplus、Axure。废话不多说了，举个例子吧。本软件用于北京某医院集团肾内科透析患者，包括医院管理系统、院外大数据平台、医疗端APP、患者端APP...版本作者修改时间审稿人v1.0.0CharlieChu2017-2-12VivianWong场景一：肾内科王医生在31号病床为刘阿姨做透析电脑操作。在医疗端APP和患者端APP上……刘阿姨患者家属登录患者端APP后，可以实时查看刘阿姨透析过程的所有信息，还可以查看血压、血糖、体重等历史数据……当刘阿姨在家用蓝牙血压计测量血压时，会自动同步到医院。如果刘阿姨的血压超过预设值，医院的王医生就会在刘阿姨手机上查看血压异常报警信息。王医生可以立即与刘阿姨的家人进行实时通讯……
