在本文中，作者主要分享的是在一次版本迭代的时候遇到的一些问题，踩到的一些坑。enjoy~

作为一个今年刚走出校门的产品新人，刚一毕业我就接手了公司的一条产品线（当然，产品的整体架构已经由产品总监搭好）。

我负责的产品线是一个服务流程化的系统，主要是用于在销售完成售后之后，让服务人员通过系统流程化的为用户提供服务，处理业务。这个系统包含两部分：一部分是内部服务人员使用的工单系统，一部分面向用户的H5页面。可以大致归类为一个TO B的产品。

公司原有的工单系统由于是定位于SAAS系统，希望提供给行业一个通用的解决方案，然后最终发现并不能销售出去。因此我接手这条产品线的第一个大版本就是对整个工单系统进行的重构，这个版本从今年四月份开始设计，到最近终于要准备上线。5个多月期间，我经历了一个完成的产品周期，自己也从单纯设计页面，渐渐成长为可以慢慢提出自己的一些想法并推动实施的人。

这个版本不出意外的话将于下周上线，产品的基本骨架搭建完成。虽然版本成功上线了，但由于其中走过非常多的弯路，导致开发与我们产品都是非常的疲惫。因此我称之为一次“失败”的迭代。

成功固然可喜，但失败却十分宝贵。通过这次失败，我踩了基本上一个刚入门的产品经理都会踩的坑。因此。我在此做一次复盘，希望大家引以为戒。

1. 沟通

作为一个产品经理，沟通是一个非常重要与关键的技能。不管是需求的获取、方案的讨论以及最终的执行，都极度依赖于产品经理的沟通能力。关于沟通，我将分别用三个产品经理工作中最常沟通的角色来依次说明我踩到坑与解决的方法。

1.1 需求方——天坑1：需求传话筒

作为一个主要面向内部用户的产品，产品主要的需求方就是公司的服务人员。刚开始我很欣喜的发现需求方给过来的需求是如此的“明确”，甚至自带“解决方案”。

相较于普通的TO C产品，一天到晚做用户调研，揣摩用户心理，然后提取需求。这种内部产品的需求沟通与获取看似如此之“简单”，作为产品经理只要画画原型，然后推动方案实现就好。

因此一开始我就抱着这种想法，一接到服务人员的需求，马上去实现，充分体现了年轻人的“朝气”与“活力”，直到有一次我踩到了下面的坑：

一次，服务人员反馈过来说，我们H5页面的提示不够详细，他们每个服务订单都需要在微信上跟用户解释与提示很多东西，希望能在H5中增加更多的提示语，同时把需求提示的地方，时机与文案都给了过来。

面对如此之“明确”需求，我当然是马上开干，拉着设计马上设计出提示语展现的样式，然后推动开发进入开发。由于只是提示语的修改，没多久版本就上线了。

一段时间之后，与服务人员一次无意中的沟通发现，他们的与客户微信沟通并没有因为提示语的上线而减少。

1.2 开发——天坑2：产品该不该懂技术

关于产品该不该懂技术，不同人有不同的看法，主要分为两种看法：1.产品经理不要懂技术，过多的思考技术的实现会局限产品的创意；2.产品经理应该懂点技术，这样设计的产品不至于飘在空中，不能实现。

在做产品之前，我写过一段时间的代码（几个月的网页前端），同时由于是产品重构，是大版本，作为一个产品新人，我在前期设计的时候充分发挥了“不怕苦，不怕累”的精神，兢兢业业、勤勤恳恳的设计完了产品的每一个细节，恨不得把一天掰成两天，也因此为了赶时间，我没有与开发做任何沟通。

最终到需求评审会议上，见识了一回什么叫刀光剑影:当我讲解完我的方案时，开发马上来一句，这个基于我们现有的工期安排与技术架构，是无法实现的。

结果，在过完第一次评审之后，我把设计方案做了大幅度的调整，甚至要去修改整个方案最底层的流程逻辑。但是由于马上要第二次评审，服务重新梳理整个流程，因此，只能基于原有的方案强行修改，导致最终方案虽然可以走完整个流程，但是在某些环节的衔接上出现“畸形”。

1.3 测试——天坑3：异常情况处理

作为一个产品新人，方案设计的时候，最难的不是满足主流业务场景的需求，最难的是去思考各种异常情况与解决方案。

一个人肯定是存在思维惯性与思维盲区的。但正是这种惯性与盲区常常造成产品的各种各种BUG。

同时有些极其特殊的异常情况，有时候我们可能已经想到了，但是觉得实际使用时不会出现，因此没有出相对应的解决方案，结果到测试时会被测试各种嫌弃（当然，被QA在测试过程中检测出来已经是非常幸运了，如果是老板或者用户提出这个问题那才是真正的严重。）

我们这次版本中，有一个页面在逻辑层面做了限制，只允许同时只有一个人进入该页面。该页面中有个按钮点击之后会触发业务流程的流转，同时跳出该页面。

QA在测试的过程中，一人同时打开两个该页面（本产品是web产品，该页面只限制只用同时有一个人打开该页面，但没限制一个人大概多个该页面），在一个页面点击的触发流程的按钮，然后在另一个页面再次点击该按钮，然后就出现了BUG。

理论上，这种BUG，在用户实际使用过程中是不太会出现的，但是一旦出现，就会降低用户的产品体验。

但是从另一个角度来讲，这种异常流程的处理会消耗大量的开发资源，当这种异常流程处理提给了开发，开发会觉得你特别的“事儿”（我本来不知道这个词的，但是最近经常被开发用这个词说指摘，然而我到现在还是不太能准确理解这个词是什么意思）

2. 方案设计

作为一个产品新人，接到这个版本任务时，十分兴奋。新人常常有一个毛病，就是拼命压榨自己的时间，提高效率，巴不得马上就能完成设计，快速出成绩。但这为我的整个方案设计埋下了很多问题。

首先是设计全局性的问题。本次产品重构的过程中，与非常多的列表页，并且列表的字段也有很多重复的地方，然而我设计的时候直接就是凭感觉来安排每个页面每个字段的前后顺序，最终原型提交到UI手中的时候，UI不得不花时间，重新整理各个字段的前后顺序，保持所有页面的统一。

第二点是设计通用性与可扩展性的问题。我们本次设计工单系统的时候，我们把订单与工单在设计时看做一体，做了严格的一对一强耦合的关系。结果出现了当服务人员需要关闭工单的时候，把原本不需要关闭的订单也必须一起关闭才行。本版本也不支持一个用户一笔订单中购买多个服务的场景。为了解决这个问题，我们有不得不重新梳理订单与工单的关系，在今后的版本中将两者解耦。

第三点是设计的完美性。作为一个处女座的产品，相信很多新人会跟我一样，对自己的设计会追求完美，力争覆盖所有的用户场景，帮用户尽可能的解决所有问题，让用户用到我们产品的时候，会有一种惊喜的感觉。在本次工单系统的设计方案中，我这很多流程环节，设置了一些在特定条件下，不需要服务人员手动去触发流程，而是系统根据一定条件，进行自动的流转。当这个方案提交给开发的时候，遭遇到了很大的抵触：因为每种设计背后都必然会对应着开发成本，我们的开发认为这些开发成本极高，相较于对服务人员的效率提升来说是得不偿失，我们应该把这些开发精力放在解决主要矛盾上。因此这些自动流转的功能在最终需求评审的时候被砍掉。

3. 最终执行

在经过千辛万苦的需求收集与方案评审之后，终于进入了开发阶段，然而此时才是万里长征第一步。

3.1 需求变更

虽然需求变更是万恶之源。然而在实际的开发，难免会出现需求的变更。这来自于两方面：一是开发在开发过程中发现实际的开发难度大于原先所设想的难度，要求砍需求或者变更需求；二是我们产品自身在这过程中，发送我们原来需求存在漏洞的，需要完善与变更。不管来自于哪方面，最终的结果都是需要变更需求。

本次迭代有一个流程环节是通过数量来控制状态的流转：需要达到一定数量才会发生流转，而之前的系统是数量一发生变化状态就流转。同时，我们每一个列表页对应着订单一个状态。

在开发这个功能的时候，我们的后端工程师发现这个状态的流转控制，开发的成本远大于原先预想，因此要求变更需求。经过一个多小时的讨论，我们最近决定把状态流转的条件跟以前保持一致，但是在一个列表页中同时承载这两个状态。

3.2 消息同步

另外一点，前期设计的时候，需求变更频繁。而当时为了赶进度，产品需求设计与UI设计处于半并行的状态。而我与与UI又没有保持及时的沟通，UI照着老的需求来设计。因此最终输出给开发UI稿，开发实际开发的时候发现，UI稿上的文案与最终需求文档存在较大出入，开发不得不两边来回对照，耗费大量时间。

3.3 新人与需求的完善度

第三点是，本次版本开发过程，中途加入了两个新入职的开发与一个测试。在设计之初时，由于开发都是一直是在做工单系统。因此有些需已有的功能，在描述时没有十分的详细。常常描述为：“与现有保持一致”。然而当新人加入之后，由于对之前版本不了解，开发时只能凭借自己的感觉去开发。到最终测试的时候发现，很多原有的功能与交互出现了问题，最终又花了大量的实际去修改。

4. 后记

由于时间原因，本周我就写了我在这次版本迭代的时候遇到的一些问题，踩到的一些坑。

下周我会继续把握对怎么应对，避免这些问题的思考与方案写出来，与大家一起讨论。

当然大家也可以在评论区想我提出你应对这些问题的解决方案，我们一起讨论。

作者：Jeff，一个做过市场，当过运营，写过代码，创过业的产品新人。

本文由 @Jeff姐夫 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议