两个棘手的项目

两个棘手的项目

这半年做过两个比较棘手些的项目，棘手的项目最大的特点是跨团队，业务边界其实不清晰。同一个功能好几个团队都在做，到扯边界的时候就比较难搞了，其实挺不容易。

其中一个项目是多重业务方，业务方之间的目标也不一样，怎样整合达成一致，确实也是一门学问。该项目旨在不同终端推出销售数据信息，现有的移动App端的埋点方案其实比较成熟，用了好多年才趋于稳定，也是公司各个团队依赖的关键，因为移动互联网的发展直接决定了App的销量远超PC之流，最近两三年比较火的小程序用的埋点方案相对智能化，人工埋点的工作量相对比较少，应该成为一种趋势。

旧的东西不那么好，新的东西取而代之也不容易，针对埋点的事情，有用即可，对公司长期来说统一且合理的方案更好。但谁愿意在现有普遍比较成熟的原技术栈动刀呢？这对各方各不容易，不能影响现有的每日数据需求，灰度的时候怎样逐步替换，各数据系统需要重新清洗并展示到数据产品上，这都需要时间，况且业绩压力比较大的业务方来说，数据需求是必须的，能满足诉求即可，这么大的重构买单，自然不一定是他们需要的。

最终在二选一的时候，只能领导拍板了，找高层，推进高层决策，目前项目组其实做得并不好，其实可以试着跟高层接触，一般情况下找到高层的都是扯皮的事情，有事无事也不找，所以怎样逐步介入，让高层支持，这个自己也做得不太好，其实主要是怎样跟他们交流，做到更进一步。看看我领导怎么做的，找高层说明关注点，约主要相关方先对齐观点，而后约会听大领导决策。大部分情况下，大领导的观点都比较独到，不存在扯皮的情况，格局也大，主要是解决问题，给下属增加资源也比较方便。

另一个项目则在自动化和手工之间团队之间争吵，原则上所有事情在不同技术团队都可以实现，团队之间有分工，也有合作才是正道。但对于大的团队来说，重复建设似乎没有必要，除非是那种内部竞争产品，几个团队都在搞，有强势有想法业务方支持的最容易成功。做出来的东西有人用才是王道，否则研发团队会挑战，一个投入了巨大工作量的团队，肯定希望自己亲手做成的产品可以尽早投入线上，这个产品和业务方也要尽早沟通，达成一致，要做哪些事情，一条一条列出来，要仔细盘点，有时候细节会决定成败，这一点对项目成功也是非常重要的。当然，最后也是通过升级到高层领导得以顺利解决，这自然花了不少时间。

这两个项目最终都是通过升级到大领导解决的，在下面其实讨论蛮久的。公司级别的项目管理办公室，进而到项目治理委员会，有助于高效解决这类型的问题，虽然时间不一定非常快。这在之前的外企其实做得蛮不错的，当时的公司环境也简单很多，有问题不可怕，几大高级领导建立透明的治理机制，关注有问题的项目状态，领导也是为项目而生，充分利用项目负责人的职能，这是项目经理需要多多考虑的。