ASK MO第66期 | 项目经理、产品经理，职权不清如何处理？

我不知道你们的产品形态，所以没法判断这种组织架构是否符合业务发展需求。但是从安迪的描述来看，产品缺乏规划是一个问题，这样出来的产品不会很好，只能是堆砌功能的产品。这个锅还真不是项目经理来背，如果出现这种情况，一般要么就是公司就是交付性产品的公司，要么就是高层领导觉得产品经理团队的能力较弱，也没有办法去牵头领导产品发展。其实锅不在项目经理，而在高层的决策，现在明显领导更相信项目经理的能力。

当务之急是，产品经理要快速地体现出自己的价值，让领导看到我们产品经理的整体能力还是非常强的。如果没有让领导看到这一点，产品团队解散也是有可能的，我曾经经历过这样的案例。

烟雾报警器的原理是：监测室内烟雾的浓度，当达到一定的量时，报警通知相关设备或单位。虽然是一个不起眼的小玩意，但是这个东西关系到消防安全，关系到人民群众的生命及财产安全。

所以这个小东西的可靠性要求是相当高，我觉得不应该接入WIFI的方案，原因主要是WIFI本身的可靠性就不高，接入家庭用电，掉线，信号问题也会有很大影响。你想想，如果你们家是因为电器短路引起的火灾，那么WIFI掉线之后，烟雾报警器也就停止工作了，这个问题就是致命的啦。

而烟雾报警器他本身不需要在上面开发多少的智能化功能，平时没事的时候，最好做到让用户无感知。

所以不仅是烟雾报警器，像一些安防内的器材，最好也是单独线路，保证工作可靠性为前提。

1. 我们在做转型上有没有取得什么正向的收益？

2. 项目复盘会上展示收益并总结。

3. 把做得好的团队和个人进行表彰，让领导站台给予奖励。

4. 加强宣传工作，让更多人知道。

总之，我们总是希望我们在做某些事情上面，会很快地短时间地得出效果。如果这件事情是可以短期有一些效果的，那我们应该尽快地展示出来，并周知其他人，这样会进一步增强我们做事的信心。团队转型这个事情也不例外。

Devops里面反复强调，让运维参加业务当中，不要到发布的时候，才让运维参加。

• 运维可以通过参与，看清团队成员对于服务器的需求，对运维架构的要求。

• 运维团队可以教开发如果写出好的SQL脚本，避免产生性能问题。

• 通过参与业务，运维同学知道哪些服务出了问题，需要重启哪些服务。

总之，没有参与感，没有成就感是导致运维团队工作热情没有办法激发的点，只要解决了这些，就自然解决了工作热情的问题。

感觉已经走到了一个恶性循环里面，士气低落一方面是效果问题，一方面是效益问题。加班的效果不佳，再加上公司效益也没有因为加班明显提升，所以用战术上的勤奋去弥补战略上的懒惰，自然士气就比较低落。

话分两头，一头是公司高层要考虑如何提升公司效益，另一方面，执行层怎么把执行效果提升上来。

在执行层面上，80%的开发都在做业务实现，所以技能提升缓慢，我们可以让有追求的同事，去做一些项目攻坚的事情，用新技术解决一些问题，每个月搞一个技术分享会议，把好的实践分享给其他技术同学，让其成长。

在人员的晋级上，实行双通道，技术的上升通道与管理上升通道并行，让更多人去追求好的技能提升。

公司展开技术文化日，进行技术PK，形成技术的文化，并把他落地到工作当中。