先看下这个场景:
项目A，技术支持的同事L，某日rtx上找我。
L:“hi，我们有个项目，需要你支持一下，设计师已经完成设计图了。”
我：“需要怎么支持。”
L:“我直接找开发了，但是开发说要产品的人先梳理一下，输出需求文档。”
L:“麻烦花半天的时间帮忙梳理一下，就是设计图上的这些功能。”
我：“那我可以找谁了解需求呢。”
L:“看设计图就行，或者找设计师H。设计图是领导C直接和设计师讨论敲定的。客户也表示认可。”
L:“哦，对了，公司已经有一个X系统了，我们初步设想是在这个系统上去加功能。”
结果，这个项目的需求梳理工作多次反复，都没有沟通清楚。原因有以下几点：
- 领导C、技术支持同事L、设计师H都认为我们的工作是不重要的、无所谓的。这点从他们跳过产品，直接找设计、找开发，可以看出来。
- 由于需求来源领导C已经和设计师H经过了长时间的沟通，在他们看来，需求已经很清楚了，没什么好沟通的。所以在我接收工作后，在做需求调研的时候，会出现领导不配合的情况（出差、开会、没时间）。
- 未能正视不同项目的差异性，总想着用现成的系统东拼西凑来满足。
- 事先给客户看了设计图，客户先入为主地接受了这一版设计图。后期发现设计图缺乏可行性，但是此时改起来也非常困难，需要反复与客户沟通。
- 未能区分需求和解决方案的区别，大家一直在说需要哪些功能，其实就是一直在讨论解决方案，但是需求（业务目标）都还没搞清楚的时候，讨论解决方案又有什么意义呢。
- 最后一点说说我的问题，明明知道很多不合理的地方，却很大程度上选择了迁就、接受，没有指出问题。最后出了问题，却又回过头抱怨。（如果再一次，我一定会通过邮件的方式，把自己的意见告知所有人。如果他们不接受，至少让他们知道可能的后果。）
写这篇文章的目的，不是为了批判同事、也不是为了抱怨公司管理混乱，而是想说说，怎么把产品的工作做好，毕竟这才是工作复盘的目的嘛。我认为，把本岗位的工作流程梳理清楚了，同事就知道怎么和你配合了。好了，以下就是我从混乱的工作中梳理出来的工作流程，不管如何，先按这种思路实施，边实践边看效果吧……
产品工作流程
这一切从那封邮件说起……
项目是从一封邮件开始的。
有同事喜欢在rtx上发项目需求，建议还是通过邮件吧。毕竟rtx上聊天信息很多，容易覆盖有效信息，邮件可以分类整理，查找起来很方便。
来，先分析一下这封邮件
一封有效的立项申请邮件，至少应该包括以下信息。
- 需求提出方
- 项目背景说明
- 业务主角及业务目标（需求）清单
- 其他要求
- 合同情况：
有合同，需要提供一签订合同中关于系统功能的描述；
无合同，启动需要（由总监拍板）以邮件的形式通知项目相关人员。 各阶段的截止时间点
其中，相关干系人分为以下几类：
业主：业主是系统建设的出资方、投资者。虽然大多数情况下，业主指的就是系统的需求提出者和使用者，即业务方，但并不是绝对的。
业务方：业务范围、业务模式、业务规则的制定者，一般指也无妨的高层人物，比如总经理等。业务提出者只关心结果，不关心具体细节。
业务管理者：是指实际管理和监督业务执行的人员，一般是指中层干部。业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。业务管理者应该是需求评审小组的成员。
业务执行者：是指底层的业务操作人员，是与将来的计算机直接交互最多的人员。
第三方：与这项业务相关的其他人和事物。比如，购物网站系统，涉及到网上银行来完成交易，那么网上银行就是相关干系人。
用户：预期的系统使用者。
此处常见的坑
坑一：
前文的案例中，技术支持的同事L，绕过产品方案，直接用大致的实施方案和设计图与客户进行了沟通。实施方案与设计图的合理性没有得到产品和开发同事的确认。
正确的方法是：
技术支持的同事将客户的需求搜集起来之后，将尽可能多的信息反馈给产品方案同事，由产品方案同事进行梳理之后与开发共同确认实施方案。
坑二：
技术支持的同事认为这个需求很简单，可以随便弄一弄。
正确的做法：
表明自己的态度，必须要在需求分析的很清晰之后，才会找开发确认实施方案并安排排期。
坑三：
同事认为这个事情很简单，所以预留的需求分析时间非常紧张。
正确的做法：
一个简单项目的需求梳理工作，大概需要2天的时间。再着急也不能糊弄。如果前期没有梳理清楚修，制定合理的方案，后期实施会造成反复的返工。这个时候，我们要把自己的想法以及预计所需时间反馈给技术支持同事，由他去协调。
需求分析与方案输出
这个阶段需要进行需求调研、分析，与开发确认具体实施方案。
此处常见的坑
坑一：
找开发咨询实施方案时，有的开发同事会很不耐烦，“这个你不用明白，我们开发知道怎么搞就行。”
正确的做法是:
产品方案同事在整个项目中起到了协调、统筹的作用，我必须要很了解方案，这样才能顺利的将整个方案的思路传达给客户与其他同事。如果，这个工作做不好，整个项目就会走向失控。一旦出了问题，开发会认为产品没有做好需求分析，而技术支持的同事则认为产品制定的方案有问题。
方案确认
1.获得技术支持同事的理解与认可；2.获得客户的理解与认可。
客户可能提出看似严重不合理的需求，不能被动的接收，要多问几句为什么，了解客户最终的意图。遇到客户不接受我们提出的方案时，要多问为什么并做进一步解释，而不是全盘接受。
在此基础上，如果客户要换方案，而我们认为该方案有严重不合理的地方。此时要明确指出该方案的弊端，以邮件形式告知所有人，主要是负责该项目领导。需要领导拍板，确认实施方案后，再继续。
项目排期
确认具体的实施方案后，找到开发、设计进行排期，并将排期结果，以邮件的形式发送给项目相关人员。
实施
作为该项目需求的主要接口人，要避免技术支持同事直接找开发、设计改需求。
理想的沟通模型
