如何在设计产品时避免给开发挖坑

　　在脉脉上参与了如何避免给开发挖坑的主题讨论，结合自己的回复和脉友的回复，重新整理了一下这块的一些想法。
　　要想避免挖坑，首先要明确什么是挖坑？个人浅见，所谓挖坑多数情况下是指：产品经理已经完全确定了需求，甚至写好了需求文档，然后找开发同学碰最终定下来的需求，但是此时才发现时间不够、资源不足、投入产出比太低、当前没有相关专业人员、核心逻辑不够清晰、对现有系统影响太大甚至有消极影响等等一系列问题。如果这时候由于某些原因硬上，就会出现各种问题，也就是会有各种坑。我把这种坑称之为大坑，也是最开发同学最害怕的坑。
　　还有一种是那种细节上的不完善或缺失，我称之为小坑。对于小坑，在碰需求的时候，开发同学多数能够极大化地弥补，而且即使发现不了，对整体的开发也不会有太大的影响。
　　对于避免挖大坑来讲，产品经理的最佳做法是：一开始就将开发同学拉进来讨论各种设计方案的可能性。多数情况下，产品经理在面对一个需求时，满足需求的方案绝对不止一个。有一劳永逸的方案也有暂时性方案，有适应未来的扩展性方案也有当下使用的毫无扩展性方案，有简单的方案也有复杂的方案，有满足核心需求的方案也有满足所有需求的方案而这些方案实施起来肯定大有不同。如果在设计方案之初，在产品经理心中有了一系列备选方案之时，就让开发同学参与进来，开发同学就可以根据这些方案来提出一些建议，产品经理也可以权衡一下得失和难度等。在这种沟通机制下，当大的方向或实施方案确定后，再继续往下走细枝末节的地方，往往也不会出现什么问题。总结成一句话，就是开发前多沟通，开发中就省心。一个功能或一个应用在雏形设计阶段，调整起来是非常快的，一旦开发开始，越到后期越难调整。正如一栋大厦在图纸阶段调整起来是相对容易的，但到封顶时想要调整就很难了。
　　对于避免挖小坑来讲，就要更多地看产品经理对细节的把控程度和精力时间的投入上了。在最终与研发同学讨论需求前，将每一步的细节逐一过一遍，会有很好的效果。画流程图和写需求文档也能够极大地弥补细节上的不足之处。可能有人会说，难道做产品还有不画流程图和写需求文档的吗？当然有。很多情况下，在人力物力紧缺时，产品真的没时间画流程图和写需求文档，往往是只要核心逻辑没问题，就开干了。
　　有没有不怎么沟通，也不怎么挖坑的情况？有。
　　如果产品经理真的懂技术，能够大神般地帮助研发同学想好大部分细节，挖坑的可能性也会比较少。但这种产品经理太少了，不具备普适应。
　　产品经理之前做过类似的功能模块，可以完全套用到现在的产品上，非常确信没问题。这样，坑也会少。