最近工作中遇到两件事，觉得有必要做一些总结：
1. 产品经理规划了“PC端用户中心”的新版本设计，需要在尽可能保留当前用户数据的前提下，实现用户体系的重构，并与其他产品（移动端、通行证）用户体系建立统一关系，最终实现账号统一
2. 由于开发资源紧张，版本经理将本应分配给其他同时的开发任务分配给了自己，并且要求在尽可能短的时间内完成开发并提测
遇到了问题
这两件事，很快都使我陷入了版本延期的窘境。连续近一个月的996，没能拯救排期的时间点，身体逐渐被疲惫填满，心态上越来越感受到压力，有点儿要自我怀疑了，为什么看似普通的开发任务，执行起来会这么困难？
基础服务型产品设计的分工
对于事件1中描述的“PC端用户中心”，我很清楚这是互联网产品的基础服务应用，它是所有产品的基础组成，记录了每一个用户的个人信息，但它不仅仅只是实现了用户登录这种简单操作，背后它维护着庞大的用户个人数据、账号关系、权限、安全，它记录着每一个用户在不同互联网产品中的“身份标志”，那么，重构这个服务，“坑”在哪里？
首先，角色的不同，看待事情的视角也是不一样的。产品经理在执行产品设计时，是以预期结果为导向的，他希望这个产品是什么“样子”？产生怎样的效果？并以此为目标打造产品框架和细节实现；而作为开发者，接到这样的产品需求，首先应该要问自己的是：1. 产品经理的设计目的是什么？2. 基于当前的现状，技术上要如何实现？
由于此前对用户中心这个服务不太熟悉，就直接被拉入了需求评审会议，导致我从一开始就走向了错误的方向：整个会议上，我一直在试图理解产品经理对于产品的“实现思路”，因为我并不了解当前“用户中心”的设计，我努力的记下产品经理所描述的每一个产品实现的细节，揣摩他的意图，尽可能的“吸收”产品经理和其他与会者的思维逻辑和辩论方案。。。直到之后的某个加班的夜里，我突然明白： 作为一个基础服务型产品，产品经理有权利去制定整个产品规划以及最终的产品实现效果，但是这个产品的细节的设计，应该由开发者来我来制定！再简单点说，作为基础型服务的产品设计，应该是由技术设计反推产品实现，产品经理把控设计目标。 所以，产品经理在一开始就“越界”了--他超量完成了本该属于我的工作。而我，由于一开始并不熟悉这个“用户中心”的服务，因此在一开始的产品需求评审会上便失去了话语权，只能做“专心听讲的学生”，不断地吸收别人的思路并点头。
“越俎代庖”的后果
在之后的开发过程中，我不断的发现产品设计与现实情况冲突所导致的开发“陷阱”，例如：
-
产品经理在设计产品时，并不会考虑当前用户数据的结构，他只是在构想一个近乎全新的产品，而作为开发者，要做的是在当前的“建筑”上，搭建另一个“建筑”，要考虑到数据与业务逻辑的兼容，这时我才发现，产品经理的一些逻辑设定，从代码逻辑的角度看，是不可实现的。 唯一的解决办法就是：让产品经理改设计
-
业务逻辑与技术逻辑相悖。大多数时候，业务逻辑是可以通过技术来实现的，但是当这个产品是一个基础型业务时，你就需要考虑很多关于“通用性”的问题，因为作为基础型服务，它不仅仅是给用户提供一个系统登录的接口这么简单，它同时也为其他服务提供接口支持，也就是说，产品设计，从系统集成的角度看，是不合适的 这个时候，我能做的，依然只是：让产品经理改设计
-
设计的每一次变更，都通过邮件或QQ群与相关人员进行信息同步。但是实际上，如果这个需求变更与自己当前的工作无关，那么多数情况下没有人会仔细审查这些变更的产品设计，也许是因为大家觉得，当初在需求评审会议上，自己已经表达过所有的想法与建议，后期的产品设计变更，应当只是一些小的细节。但是，当他们真正介入到相关的工作中，比如，测试工程师开始编写测试用例时，他们多数会面临和我类似的状况：测试人员站在用户的角度看，产品设计对于实际的用户场景是不友好的 于是，测试工程师们也做了和我同样的事情：要求产品经理更改设计
当每一个人出于自己的角度提出建议后，产品设计的矛盾反而更加凸显了。因为没有一个人从全局的角度去考虑问题，包括我。的确，一个基础型业务，涉及到众多因素的纠缠，既要保证产品本身的设计目的不偏离，也要保证技术实现的可行性，以及用户场景的友好。于是最终，在我修改了无数个版本后，经历了无数的争论后，我们又开了一次产品审计评审会议，确定最终的设计版本。而此时，由于代码不断地修改重构，我已经快不认识自己的代码了，它看起来像一堆乱麻纠缠在一起，我只能一遍又一遍的梳理，就好像在看别人的代码
一些总结
针对第一件事，写了很多，其实第二件事也具有类似的状况，反思了很多，先总结下来
提前熟悉要做的事
通常来讲，产品经理都会提前发起产品需求评审会议的邀约邮件。由于日常工作繁忙，很多时候我是选择忽略的，等到会议上再听产品经理讲解。这样的后果，就是我无法提前预知需求上可能存在的矛盾点，无法及时提出质疑或解决方案。
在产品需求评审会议上争论
抛出一切个人认为存疑的点，与所有人一同讨论，把所有设计上的隐患尽可能地提前排除掉。由于需求评审会议是相关人员同时在场的场合，任何一个疑问点都可以得到不同角度的建议和意见，这就避免了后期修改产品设计后可能引起的不断改版
向上司或同事提建议
没有实现规划的工作安排很致命，尤其是当我还对要执行的项目不熟悉而被“抓了壮丁”的时候，我是很郁闷的。因为我不知道这个工作的难点在哪里，“坑”在哪里，涉及面有多广，牵扯的组建和服务有哪些，工作量有多大等等。。。这个时候，版本经理让我评估工期的时候，我是很懵逼的。而此时版本经理通常会给我一个看似合理的工期规划，但是他很可能没有考虑到，我对即将执行的工作还一无所知，我可能需要和开发工期同样的时间来熟悉当前的产品业务逻辑是怎样的。所以，尽早地告诉他们，多考虑一下开发者的处境，不要总是“抓壮丁”，要有合理的工作安排的规划
合理评估工期
工期不仅仅是写代码的时间，还要包含业务熟悉的时间、概要设计和详细设计的时间，以及自测、联调的时间等等，当然还要考虑临时性工作的时间，比如处理线上问题等等。在评估工期这件事情上，一定要据理力争，排除任何不合理的工期规划建议，尽可能争取到相对宽裕的时间。因为我发现，很多时候即便争取到自己预期的工期规划，最终还是会因为各种各样意料之外的事情导致工期紧张而不得不加班保进度
前期设计很重要
概要设计、详细设计一定要好好写，程序员多数都不喜欢写文档，但是，用心思考的文档一定是对自己的逻辑的一次全面梳理。另外，设计评审会议上，其他人可以根据设计文档提出不同的建议，帮助开发者完善设计思路，封堵逻辑漏洞，另外也有助于测试工程师有针对性的规划测试用例。这种他好我也好的事情，何乐而不为呢
写了这么多，是为了能牢牢记在心里，避免再次陷入类似窘境。因为。。。这段时间走的弯路，太tm弯了，加班加的太苦了T_T
