与开发架构聊聊，产品文档与技术可行性评估

　　笔者与开发和架构的好友讨论了两个问题：文档要多细致、为什么开发说功能实现不了。希望读完文章的你能得到一些启发。
　　近期和开发和架构的好友一起探讨了软件开发中的产品文档细致程度和技术可行性评估方面的细节问题，我们从各自的角色和职责出发，更全面地回答了这两个问题：
　　产品和交互文档需要写多细致呢？
　　为什么开发会说这个功能实现不了？
　　1。产品和交互文档需要写多细致呢？
　　提出这个问题的原因是：
　　我平时写产品和交互文档的时候担心文档写的细致需要花费许多时间，如果开发根本不看，会产生不必要的浪费，而且敏捷宣言中有一条就是“工作的软件高于详尽的文档”；但是也有如果文档写的少了，开发遗漏细节的担心，所以抛出这个问题问问文档的使用者们（重要干系人）。
　　1。1架构好友的观点
　　因为每个开发的能力和经验不一样，就算是约定俗成的技术实现方式，也不能做到都知道，如果文档不写出来，可能有些开发实现的细致一些，有些开发实现的粗糙一些，那还是写出来比较好。
　　她认为开发是比较喜欢需求和交互文档细一点的。而且，文档写的细致验收时标准也明确。
　　1。2前端好友的观点
　　文档不用写的太精细，交互设计和视觉设计规范中有的内容不用写，有疑问的地方我会直接找PM和设计师沟通的。
　　1。3测试好友的观点
　　文档越精细越好，这样我可以直接从产品和交互文档copy进测试用例里面，比如：“文字折行，最多三行，超出部分使用省略号”需要细致到这种程度，如果同时将这些直接体现在原型图上，那就更好了。
　　这样，测试标准和PM想要的标准会更统一。
　　1。4我自己的经验
　　文档需要写得精细一些，因为从需求到开发可能会经历很长的时间，当时的想法如果不记录下来，到后面可能自己都不记得与团队讨论过的一些很细节的点了。需求文档描述的不够细致，会带来沟通成本和不必要的返工。需求可以一开始尽可能的考虑清楚，当然如果中途有补充和变动，在敏捷开发的模式下，必要的变更大家都是可以理解的。
　　跟产品和交互文档的使用者们讨论之后，我们都更倾向于将文档写得细致一点的观点，以下为我在日常项目中的文档，此处原型图不方便公开。
　　1。5我在日常项目中的文档
　　产品功能列表
　　产品PRD文档
　　流程图
　　原型图和交互文档（必备，配图略）
　　2。为什么开发说这个功能实现不了？
　　对于这个问题，大多数没有技术背景的产品经理都会遇到，我们的疑问是开发真的实现不了，还是不想做呢？
　　我的几个开发好友，坦诚的跟我说过确实存在技术忽悠PM的事情存在，有时真的是任务太重了，或是产品经理的脑洞太大了，不得已而为之。
　　人人都是产品经理平台中梁锋的文章已经给出很好的答案《研发说方案无法实现，产品经理怎么办？》梁锋将方案无法实现归纳为四种情况：
　　确实无法实现
　　不知道可以实现
　　不知道是否可以实现
　　可以实现但是就是说不能实现
　　2。1确实无法实现
　　产品经理需要自己想想做这个功能的目的是什么，是否可以通过其他方案来实现，条条大路通罗马。
　　区别于开发的技术思维，产品经理一定要具有业务思维，不要技术说不能实现或是时间来不及的时候，就无可奈何、束手无策了。
　　举个真实的例子：在开发多项目并存，资源紧张的情况下，关于点滴日报系统新增下载团队周报功能，开发评估需要两周，并且两周后才可以开工，意思是用户一个月之后才能使用该功能，短期内确实无法完成该任务的开发。
　　产品经理不能开发一说没办法了，就认为没办法，不能让用户等着呀，产品经理需要另想办法，让用户可以提前使用该功能。
　　开发只是从技术的角度给PM建议，PM还需要有业务思维，急用户之所急，痛用户之所痛。
　　我们当时的解决方案是，可以每周五从SQL中导出团队周报发给用户（Manager权限用户），直至这个功能开发好。这样用户的需求就可以提前满足了。
　　2。22。3不知道可以实现、不知道是否可以实现
　　这是因为开发人员的水平问题，PM可以咨询技术专家，调研行业和竞品解决方案。
　　2。4可以实现但是就是说不能实现
　　PM可以将这个功能的意义讲给开发听，获得开发的认同感和参与感；亦或是开发任务太重了？
　　如果真的拿不准开发到底能不能实现，架构好友支了一招：
　　当开发说功能不能实现时，产品经理可以这样说：我上家公司做过这个功能，要不我帮你问问他们是怎实现的？
　　当然，产品经理如果能问出开发说需求不能实现背后的原因，双方好好沟通，一起想办法解决问题是更好的解决方案。
　　另外，产品经理平时需要多多学习技术知识，才能和开发无障碍的沟通。
　　以上为工作日常的碎碎念，你会不会也有这种小纠结呢？感谢以上提供观点的开发小伙伴们。