推脱项目

最近组里出了个小插曲。

上周末，头头脑脑门在一起开会计划未来2年和W整合需要的具体工作。当中涉及到产品X的选择。可以选择W已有的产品，或者重新做一个来替代原来的。采取前者需要整合W的产品到现有的系统。但貌似有些人有很大的pride，总是希望用自己的产品，随意非常支持重写。重写的好处还不明显，但明显的是开发成本很大。如果我有足够的能力和资源，我愿意重写来改善现有的产品。但实际上，我还不到重写一个产品的能力，而且先有的也足够好。

这些产品的取舍应该是上层领导的选择，但我也被牵扯进来。

之前我曾经帮我们组的architect写了些prototype（称为A）。曾被领导们基于了很大的希望，认为这个终将替代现有的很多产品。这个prototype被overload的很厉害，衍生成为几个方向。有一个最终release出去。后来发现overload一个产品的功能是很triky的决定。如果产品的功能上没有足够的overlap，这种overload只会使程序越来越复杂。一个版本里会嵌套着其它没用的code，最后很难维护。而overload的本意：low maintaince cost, more efficient performance, 就会被完全淹没。

回到刚才的话题，我们组的architect认为A和我们现在需要做的产品最为接近。他极力认为只要稍稍改动A就可以实现X的功能。所以希望我来站出来说话，希望我来支持他的观点并帮他实现。但却发现，除了architect个人以外，其它lead都不同意这个决定。我个人也不同意。后来就看领导们如何推脱这个project：

- 全组的方向不够统一。这个project的方向并不是最主要的方向，可能会事倍功半。
- 高人力资源。我们现在需要N个人，不但人手不够，而且已有的人都有其它的工作。
- 其它资源。做这个产品还需要其他组的支持。
- 长开发时间。想做到更原来的一样或更好的需要N个月。现在时间很紧。
- 具体项目复杂。列出具体work item，一一解释其复杂性。
- 提供折中妥协方案。对方提出这个要求，就需要得到一个答案。完全的推脱让对方也下不了台。

更具听到的，我总结了一下，写了这个sample dialog：

"This project is a very challenging project. If we want to do this, we would need to implement X, Y, Z. The feasbility of implementing these is still up in the air. We probably we need X amount time to determine if they are doable. Even if these problems have been solved, We do not have enough human resource to pull this off. Considering that many people has already been working on X work item, which is team's main focus by September. We would need 3-5 additional full time staffs to work on this project. And this would very likely to take about a year to implement a minimal set of what they already have. In addition, we would need to get X's commitment on providing corresponding support during the development. ... So what we can say now, given X we are able to deliver Y by time W. We would call this an Alpha release, which would demo the functionalities of the system, and provide a basis for further analysis on cost estimation."

 推脱project其实不是我这种小兵需要做的，什么活都是做，但是在避免得罪人的情况下要尽量避免做没有什么前景的活。小兵就是一个棋子，摆好了被人铭记的战士，摆不好了就是一滩炮灰，由不得自己。不管是战士还是炮灰都不能白搭，在有限的影响力下，做对自己的career最有帮助的决定。