这个产品方案1.0版本是我们Skywen天问信息杭州研发团队在接近一年的团队产品全流程实践经验基础之上总结形成的。主要由我们的杭州研发团队产品经理丁琳主刀，大家进行协助和整理总结。接近一年时间，研发团队经历了数不清的项目赶工，需求重构，研发报错，以及客户投诉等问题。一步一步走过了最艰难的阶段，在针对B端项目的全流程研发过程中，每个人都在迅速的成长，从产品需求，UI原型，前后端协作，线上运维，客户沟通交付等环节积累了大量的实战经验。在这一路的总结和反思中，我们形成了最初版本的产品方案。我们在总结工作经验的同时，也在努力为下一个阶段的产品方案2.0版本的方向和构建准备了很多思考。
以下是我们丁琳经理的产品方案1.0版本的内容陈述。
方案说明
1.0方案简单介绍了我们小团队是如何在大半年的时间内形成适合我们的工作模式，并且从0到1进行产品的研发直至交付。在此之前，项目往往会存在流程不具备基本灵活性、与客户或开发沟通存在“盲点”、项目经常性延期、客户测试时反馈问题较多等等问题，团队不断磨合的过程，慢慢总结并且在一个个项目中就不断调整、优化，以求摸索到最合适的团队方案。在接下来S过渡到2.0期间，我们也会不断在产品本身的进步方向、测试用例上的规范、复盘工作内容的细致化等等方面持续探索。
项目流程
流程没有标准，适合自己团队才是最好的
其实每个研发团队都存在自己的模式，这个模式不一定是最好的，但一定要是最适合的。我们将其分为了——项目策划、产品UI、研发测试、测试交付、项目复盘五个阶段，下文将对各个阶段的规划和任务进行详细的描述。
1. 项目策划
1.1 项目沟通
在和客户进行对接时，我们首先在沟通过程中理顺清楚要做产品的类型是什么、核心功能是什么、产品目标有哪些、怎么做、操作流程是什么样的、使用场景有哪些、目标用户又是谁、最后需要达到一个什么样的效果、什么时候完成等等。
前期沟通在一定程度上决定了产品质量
**
在项目沟通阶段，沟通的质量对于一个产品来说是非常重要的，它的质量在一定程度上来说决定了一个产品的交付成果。尽管每个客户都有自己的想法，并且会提出一些建设性的意见，但往往客户的意见与想法并不是完全正确的，这个时候就需要挖掘到其真正的需求是什么，达到双方都满意的一个效果。
1.2 项目方案
在与客户沟通之后，需要出项目方案给客户，方案以思维导图的形式向客户展示用户端和后台系统端的功能结构或页面结构，以图来展开说明每个模块下功能点，最后给出一个合理的工时预估和预算。关于工时的预估还存在一些问题，将放在本文最后进行说明。
找到好用的轮子用起来
**
写方案时需要根据业务去寻找竞品，进行竞品分析。大多数时候，我们都可以找到合适的轮子，以此为基础再根据现有的业务逻辑进行优化，而不必要重新造轮子了。
多维度去考虑需求的优先级
**
客户的想法往往是大而全且抽象的，这个时候就需要根据功能将需求进行拆解、排序，分成一个一个小版本进行规划。实际情况的需求排序会根据众多因素因素来进行调整。例如，客户要求某次要功能要在第一个版本上线，功能之间依赖程度过高无法拆成多个版本快速迭代等情况。到底如何去排优先级，制定的标准是什么，什么方法最适合自己团队，这些都将是2.0方案继续探索的方向，
1.3 原型确认
项目方案定下来之后，就要开始推进原型的确认。对于是先出原型还是先出PRD文档，对于我个人来说之前一直都是有一个困惑，后来两种模式都实践后发现，对于我们自己的小团队并且敏捷开发的模式来讲，先出原型会更高效，原因有三：
- 先出原型可以最快、最直接给到用户我们的方案是什么，也可及时进行更改调整
- 需求文档需要非常细致，如果在前期打磨的时间很长那么就会耽误整个项目的进度，将工时都压缩在了UI和开发身上，这是非常不利的，也会打乱节奏
- 开发往往很不喜欢看许多文字的文档，所以文档更多是作为记录留存，以免遗漏某些需求点
每个“点”都是为了完成目标而存在
产品页面的信息和布局需要展示清晰且简单的用户操作步骤，可以支持并帮助用户更高效的完成目标，一个文案或一个图片都会分散用户的注意力，因此还需要考虑到各个模块之间的关联性。
除此之外，有时也会根据项目的紧急情况，来输出原型，若项目紧急，简单和客户沟通之后可以先出部分原型图交给UI，一些“模块库”类的功能或非核心功能省略原型部分直接进入设计阶段，与UI沟通好什么地方要做位置的预留，以便进行迭代。
2. 产品UI
2.1 产品逻辑
输出原型客户并确认之后，交给UI去出设计图，尽管在设计稿上做了简单交互，但是有时客户还是难以体会到实际使用起来的感受，特别是网站类的项目，在此方面需要细致的沟通，否则在研发结束后客户不满要做整体页面上的变动。
确保开发理解产品背景
项目进行研发之前有必要与开发进行项目简单的沟通，有些专业的名词或者背景需要事先和开发沟通，便于他们理解，更详细的内容主要依据需求文档。在写需求文档时要记录文档信息和版本历史，对于后期整理迭代是非常有必要也会很清楚的记录下来，避免在传递过程中信息流失。若项目紧急，和开发先用设计图沟通产品逻辑，需求文档后面及时进行补充。
3. 研发测试
3.1 内部测试
由于我们还没有测试人员，因此在测试上一般由产品和UI进行测试。每个人的思维都有一定的局限性，导致在内部测试阶段很多问题无法及时发现，就交付给客户，留下了一些隐患问题，这样的用户体验很不好。**
测试用例已经提上2.0的日程，大多用例都是由运营担任测试的角色进行编写，评审通过后去测试，一些主流程或主要功能点则产品去完成测试用例的编写并测试。接下来，将这个制度规范化并且在使用过程中不断进行优化。
4. 交付维护
4.1 客户测试
在内部测试通过后交付给用户进行使用测试，在这个过程当中及时记录客户的使用反馈，毕竟有些功能往往在使用过程中才能真切的让客户获得感受，并及时优化当前版本、修复问题、随时调整进行更新迭代。
由于内部测试流程的不完整、不规范性导致现阶段我们的客户测试阶段亟待完善，客户总是在交付后有一些新的问题，若是小版本交付又会涉及到后续版本开发周期的问题，因此，目前我们是bug类问题第一时间解决，客户提的一些新需求进行“初处理”，放到后面的版本去迭代，以免打乱整体进度。**
5. 复盘工作
项目以小步快跑的模式进行研发，同时项目的延期导致在此阶段我们做的复盘工作并不细致也不系统化，只做简单的沟通。因此，在下一步的探索规划中复盘工作也要更加全面、规范。
交付时间和预计时间之间的差值
复盘是要有意识的从自身过去行为经验进行学习，同时也是为了总结积累“模块库”。但往往由于工期的原因，复盘也是最容易被我们所忽略的。为了找到结果和预期之间产生偏差的原因，就要及时从结果中剥茧抽丝的找到根源，以此来缩小下一个项目结果和预期产生的负差值。
写在最后**
为什么要做产品规划
**
由于客户需求变动、市场监管等原因，产品具有不确定性，因此需要最快的产品研发速度和最小可行产品，来及时收集用户反馈，以快速迭代、敏捷开发的模式产出功能才是最适合的。通过前期的需求沟通摘出最小的闭环流程，但同时也可能会出现因为主观判断没有考虑到用户的期望值的问题，所以应该及时与客户进行沟通，在项目周期内不断寻求客户可接受的最小或最优边界，并及时调整。
如何做产品的规划
**
不更改项目预计时间的情况下，对功能范围做调整。这种方式就需要明确版本范围，什么时间应该实现哪些功能模块，然后通过任务之间的依赖关系来进行规划安排，从而得到项目计划。另外一种就是时间计划已经安排好，然后依据时间来确定需求范围，但是这种情况往往比较少。**
如何尽量避免项目延期
**
如果期望时间是在5天，和开发沟通后这个可能需要7天的时间，那么我们完全可以在项目进行开发之前对需求做减法，分出产品版本，降低某些功能的优先级，在5天之内做出一个可使用的功能，在陆续去做一些优化项或是优先级低的功能，这样就可以减少延期的风险。
需求如何排出优先级
**
先做必要型需求，再做不重要的子功能，就算项目发生了延期或者是其他的情况，那么第一个版本也可以正常使用，最起码核心功能上线了，没完成的部分在下一个版本更新迭代进去。**
除以上说的几点之外，关于产品本身还有以下几点需要更深一层的继续思考，都是接下来持续探索的方向。
- 如何避免同类型产品过于相似
- 期盼型需求体现在哪里才能更好地提高用户体验
- 每一个元素都在向用户传递些什么信息、
- 如何让用户按照产品设计的思路、流程、路径来使用产品
