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