程序员是这样炼成的（8）-1+1<2

 

     今天加班到10点才回家，开始写博客，最近整个项目组闹闹哄哄的，原因是出现了不和谐的声音。原本的安排的是 A,B两组人分别完成两个项目，却因为开始工作任务分配的不合理，终于惹出了麻烦。
  A组的任务是：做一个客户的项目，计划是6月份完成，人员投入工作量60%。
  B组的任务是：开发出一个平台，用来支持一系列A组未来的客户项目，计划是8月份或者更晚完成，开发出来的平台未来给A组使用和维护。人员投入工作量为90%.我们可以理解成，A组的项目算是B组的平台的一个子集。
   但是因为开前一段时候B组的项目经理不够给力，结果A组的项目进度远远跑到前面去了,构思设计都成套的出台了，B组没有一点起色。B组的惰性思想开始作怪，一直followA组的设计和创意。A组开始的时候也很乐意为B组提供支持和帮助，希望自己未来的使用的开发平台软件可以更完善。希望B组在自己开发的已有的功能的基础上完善其它功能，完成一个稳定的平台软件，方便A组以后使用。就这样两个项目组就走到一块，相互之间都还比较融洽。但是好景不长，突然在这个周一矛盾爆发，导火索是：B组决定用另外的编程语言重新沿着A组开辟的道路再实现一次，完成自己的任务。A组共同开发的愿望破灭，之前为B组支持和培训的时间流失。而且A组投诉B组完全是拿公司的资源在浪费。
    公司现在面临的选择有四：
  1.让A、B组继续完成开始计划的已经开发的任务，都不需要多管事。楚河和汉界给两组画清楚。
潜在风险可能是有 (1).公司的程序员开发有重叠，会给公司带来冗余的工作量。
                         (2)A组程序员以后面对同类项目，可能更喜欢在自己原有的项目上修改满足新的需求，B组开发出来的平台可能会脱离需求，可能会没有使用者，开发的平台A组不会接受。
  2.A组停止现有的项目，跟B组一起开发平台，在开发的平台过程中，完成A组的项目，接着两组人一起完成B组的任务。
           潜在的风险是：（1）B组项目经理的坚决反对。B组的地盘B组做主，卧榻之侧岂容他人鼾睡。
                              （2）如果A组和B组谁来统一管理？A组长orB组长。A的积极性是否会受挫？
                              （3） A组的精力会被平台项目花费，如果B组可以发力，迎头赶上双赢的结局是最后，如果A组被B组拖住了后退，项目延期，客户那边就交代不过去了。
   3.A组开发完成现有项目，继续开发平台，反正A组以后自己也要使用。B组人员调离，开始其他的项目。
         潜在风险：（1）本来两个组的任务压到一个组的身上，A组的队员能否承担重任？

                        （2）B组的士气如何恢复？

   4.让 B组的人员回到共同的开发的道路上去，跟着A组继续现在的开发，因为公司不需要两套平台，跟方式2差不多。

     这个问题要是作为一道项目管理的题目应该非常不错，之所以我在这里提及，是因为我觉得我们在日常的项目开发中也会遇到诸多不可调和的矛盾，不可能让所有的同事都按照你的思路去开发。我们应该学会如何面对。聪明的你如何你是：A组或者B组的一员，你会怎么做呢？如果你是项目管理者你又会怎么做呢？

哎~这件事的前因后果大概如此，种什么因得什么果。最开始给A组和B组的任务分派就有问题，现在从一个错误的起点去寻找一个正确的答案真难。

      我的想法和选择，肯定不是最好的，不过还是要和大家分享下， 24小时前，我的观点一直是支持第4种选择，既然A+B度过了一段蜜月期~不然让他们把蜜月进行到底。但是A、B项目经理水火不容，就像两头牛拉不到一个方向去，多次交涉也无果。经过星期一的论战后，现在我的观点变了，将错就错吧，我支持第3种选择的改进版本，A组开发完成现有项目，然后继续A组认为正确的，开发平台，反正A组以后自己也要使用，不如让他们放手去干一场。B组人员暂时不调离，仍然他们自己的开发平台项目。就像革命时期，老毛说要北上抗日，老张说要南下救国，两支革命军走不到一块去，那就各自为战吧，谁最后成功了，谁就是胜利者。对公司而言这样下去的结果是，无论A组最后的平台出不出的来，A,B的项目都按时的完成不了，都是无法找到任何借口和理由的，如果都完成了，那么基本的要求是达到了。如果运气好，A组争气 最后还可能意外的收获了两个软件平台，我们还可以从中选择最好的一个。两个组既然喜欢在技术上比武，我们这些和事老也别劝了~那就让他们是骡子是马都拖出来看看。顺便刺激一下B组的积极性，落后就要挨打，是千古不变的道理，要是B组真的败了，也锻炼了开发队伍，也可以正好找个理由整顿，何乐不为之。A组最后的平台要是落选，他们肯定也是输的心服口服。 从结果来看公司层面是可以接受的，再看看时间方面，A组6月完成计划项目后，继续开发平台所花费的时间是公司额外需要支付的开发成本。但是既然双方都叫上劲了，我觉的A、B两组的实际开发时间要比预计要少一个或者半个月。也就是说从时间上来说，公司的资源浪费也不会大。还有可能会比以前短。
    在我们平日的开发过程中，这样的事情，我相信会经常遇到，我觉得大家有必要多从公司层面去思考问题，做为一名技术人员，不要太多的在乎自己的得失，功劳，项目组长，项目经理，这些挂名的都是虚的。首先要考虑的是，我们能给公司带来什么？能给我们的团队带来什么，我个人有能学到什么。其实今天我遇到的这件真实的事情，从项目计划，到启动，到监控，每个环节都有人在犯错。如何团结队伍，节约资源，让每一位同事在项目有所收获，就是在挽救程序员的青春和生命，如何实现1+1>2是我们在日常工作中，任务分工，为人处事应该懂的道理。