产品实施过程中为什么会复现各种问题？

在产品需求文档中，写得很详细、很到位，但是这依旧不能完全100%的避免问题的出现，也就是大家常说的“问题常有，不然就见鬼了！”

今天一大早起来，冲了个凉。爽，爽，爽… 在过去的一周，着实很忙碌，一方面是产品版本迭代更新；另一方面是产品进入实施阶段。记得之前和大家分享过“需求文档”，说到文档中应该尽可能描述清楚需求，以免相关实施方存在疑惑。确实，在产品需求文档中，写得很详细、很到位，但是这依旧不能完全100%的避免问题的出现，也就是大家常说的“问题常有，不然就见鬼了！”

产品实施过程中究竟为什么会复现各种问题？

产品实施过程

文档问题：不是说文档已经写完全、详细了吗？怎么还有问题呢？

是的文档是可以根据既定的规则将问题描述清楚，可你不能控制的是人的因素，这个最核心因素：

a.因为不同人的理解事物的角度和方法存在差异，对于文档中既有描述，理解上难免有误差；直接沟通是最好的解决方案；

b.需求方，比如：市场部、客服等等，临时修改/增加需求必然导致先前撰写好的文档造成修改；如果再加上信息传播不及时，造成各方信息不对称，那必然会导致实施过程中理想与现实的冲突；可能有人会问，都进入研发阶段了，需求不是早就定了吗？是的，理论上是需求都冻结了，可又有谁能保证需求百分百的一点都不被修改/增加呢？反正，小编能力有限、智商捉急、Too young Too Naive ,暂时还没那个能力100%管控。

c.由于需求方需求的增加，相应的需求文档也要做调整，那么调整的过程必然会有些许的遗漏。又有人，会问：能不能仔细点，将问题都扼杀在文档里？小编说一句，可以！这对产品人本身也是极高的要求，在时间的保证下，还是应该保证文档的每一处的无死角。当问题出现的时候，直面交流还是最佳的解决办法。

d.需求评审时，技术评估误差。在需求评审会议上，技术研发的老大哥都会对现有产品逻辑的合理性及其技术实现方案做技术评估。过多认为因素及经验参与的过程，存在偏差同样是合乎情理的。在产品/项目的问题的实际解决过程中，出现技术难点或实现上的复杂点，有时候也需要适当的调整需求，以便于快速的解决问题。

e.全员产品，技术大牛们在实现产品时，提出了一些更好的产品优化方案并且易于解决/实现。在一家全员产品型的创新型公司，必然是不可能视而不见的，对合理的需求，也会做出相应的调整，体现在文档和产品之中。

产品设计流程

有这么多的问题究竟该如何去规避？或者说在遇到这些问题的时候，如何更好的解决呢？项目/产品进入研发实施阶段，更多涉及到的实现，而不是逻辑上的问题；而这些逻辑上的细节也都在文档中一一做了详细说明。需求文档（PRD）也自然成为产品与研发测试纸质化交流的唯一事实依据，实施过程中文档的及时维护是重中之重，这真的就够了吗？一起往下看：

a.研发大牛们心有疑惑，产品应该如何？随传随到，即刻解答！是的，在产品/项目实施过程，产品应该时刻准备着，准备冲到研发部为研发大哥们消除心中以后。此谓“开心消消乐”！搭建良好的沟通机制及问题相应机制，是很有实用性的。

b.需求方增加/修改需求，应该及时更新到文档，并且文档中应标识与上一版本不一样的地方，以便开发大哥们整闷了！同时，也有必要在文档最前面文档修订记录中，记录每次修改的内容，以便后期查询，需求变动的记录。

c.文档更新了，不算完；还需要及时地通过各种渠道通知项目有关成员文档（PRD）变更的情况，依据实际情况而言，还是那句话：面对面的交流时最好的方式！一般，小编是QQ吼2句，最关键的是会亲自去说一声…研发哥哥很忙的，说不定的QQ已被屏蔽…

产品实施过程，不仅仅是围绕文档而展开的，还有很多其他关键点需要留意：时间节点、项目进度、产品还原度，这些也是很关键的。