项目管理圆桌会专栏开张啦！

项目管理圆桌会目前已经进行到第四期，这个专栏会脱敏后发布一些我们的访谈记录。希望能对公众号的读者也有一些启发。今天发布的是第三期，主题为：相爱相杀的产品和技术。

产品需要懂技术吗？技术需要懂产品吗？

—

产品需要懂一些技术常识，技术也需要懂一些产品常识，这样能够带来三个方面的好处。

1、产品和技术之间能够换位思考，站在对方的角度去思考问题，容易拉近产研团队之间的距离，更顺畅的进行沟通和协作。

2、技术和和产品可以相互补充对应的方案，确保方案的完整性。产品更懂技术的时候，我的产品方案的落地性会更强。

3、避免当工具人。作为技术来说了解产品的价值更容易反向倒逼产品，让自己所做的功能产生更大的价值。

总结来说，技术和产品相互掌握对应的知识，能够反哺，相互学习，促进整体价值最优。

作为产品经理和技术开发，如何避免成为工具人？

—

产品经理夹在业务和技术当中，很容易变成一个需求分析的机器。如何体现出产品经理的价值，可以在这几个方面进行有效学习：

1、对接业务的时候了解清楚背景、目标，以及业务方的初步方案是什么？这个时候你可以基于自己的经验帮助业务方找到更好的解决方案，也可以在这个过程中学习到更多的业务知识。

2、如果业务方还没想清楚，逻辑不是特别清晰，那这个时候也是砍需求的好时机。

作为技术而言，不要把自己当做一个编码机器，要主动思考。如果这个项目是我自己的创业项目我会怎么办？对结果负责的情况下，我还需要做哪些事情？把自己当做一个owner，会让你更有成就感，能收获到更多。

提交测试之后产品和技术总是因为bug的归属问题，大打出手怎么办？

—

首先我们要允许每个人都有自己的情绪，但是大局观不能缺失。我们需要引导相关人员关注的是更快的去解决bug，不影响业务的交付。

先解决问题，如果有一些流程问题或者其他方面的问题，我们可以事后去复盘去找到更好的解决问题方法。

什么样的产品PRD能把事情说清楚。

—

一个好的PRD要写清楚：为什么做这件事情、我们的解决方案是什么、做了之后如何去验证这三部分。

为什么要做这件事情？
这一部分你要告诉大家这个需求的背景是什么，能带来的价值是什么？

我们的解决方案是什么？
你要告诉清楚这个需求的细节，业务流是什么样子？系统的逻辑是什么样子？有哪些功能涉及到有哪些改动点、以及正常/异常的流程都是什么样子的？

除此之外，还有一些非功能性的需求也要考虑。例如兼容性，合规性，安全性等等。最后在团队协作上，我们还需要关注有哪些跨团队的需求，需要提前去和对方沟通做好排期。

价值如何去验证？

这个时候我们需要关注是不是要埋点，是不是需要要做灰度测试等。

如何有效的传递需求，避免信息传递损耗。

—

1、一图胜千言，能够用图表示的部分，尽量少写文字。线框图流程图都是受欢迎的实践。

2、做好准备工作。在PRD评审之前多读读PRD，带着问题去参加评审。

3、让开发反讲需求。通过开发讲解需求的方式判断开发是否真正理解的需求。