讨论一下小型开发团队管理经验？

[oio]

我的这方面经验很少，也没有受过专门的项目管理培训（PMBOK还没看完，感觉不实用）。

我觉得程序员无疑都是一批最聪明、最敬业的人（#_#）。大多数人都能够实现自我管理，懂得学习和分享，帮助团队和自身成长。

但不少人也有偏执倾向，从经常遇到的各派激烈争论就可以感受得到。完美偏执倾向有时候是一种好事，对技术追求充满了热情。我自身也有一些这种成分，如果是我做出的产品，一定希望她能很完美，在项目开始前，就会仔细评估比较各项细节，技术方面的，非技术方面的，权衡学习曲线、现有经验、性能、效率、用户体验等各种因素。

但是处于民主型的团队中，有时候这种倾向比较难以协调，比如一些技术的选择，对同一个问题的看法差异，基于同理心，又不得不得考虑各方的感受，感觉挺为难的，大家有什么感悟？ 另外如果是团队转向新的技术，各人员学习进度不一样，除了定期培训，如何协调？如何纠正不严格遵守代码规范的人？....还有一些其他问题，不如大家简单介绍一下呗.......(感觉大多是人与人关系处理的问题)...

[min]

团队里要有人说了算，民主不管用，集中才能办事情

[blackcloak]

坚守目标导向不动摇

[oio]

哈哈

[oio]

@min，这样也对，哈哈

[nameryan]

楼主也是技术出生转管理吧，的却有个通病。
我觉得还是发扬IT精神（自由精神），其实很多员工都会自律，只要给他设定目标结果按时完成，过程可以少参与。

[jianghu52]

我本身也正好处于楼主这个位置，不敢说做的成功，只说一下我经历过的几个leader，然后加上我自己当时在PG的位置上的一些想法，算是给楼主一些借鉴吧。
Leader A：技术牛，业务熟悉。在他手下，基本上就是无脑coder，活来了，直接给你分好，难度适中，有困难直接找他，时间掌握的也好，基本上不会有很多的加班。
Leader B：技术不错，业务渣（他是空降的，业务还没我们熟悉）。业务本身不行，对于我们的水平也不能掌握，倒是无意中切合敏捷的一些方式，活都是我们自己领，deadline我们自己定。剩下的骨头他啃，可惜的问题在于其他人的水平有限，交出去的活质量很差，干了半年，就走了。
Leader C:技术不行，业务更不行。所有的东西都是找我们这些老人，压不住我们，就把骨头扔给新人，然后变着法儿的让新人来找我们这些老人帮忙啃骨头。最后项目延期就说新人怎样怎样，对于客户完全不会say no，各种异想天开的东西，强调流程。
在A手下的时候，那是一团和气，基本上不会有什么问题，因为基本上不存在骨头，之前都啃完了，基本上你只要不遇到无理的客户，就没有问题。这样的Leader我觉得是所有的项目中最理想的。
在B手下，你反倒是可能成长的快一点，因为当你完成自己那份之后，可能还有时间观摩他是怎么啃骨头的，甚至如果他有分享竟然，还可以分享他的调查心得。
在C手下，hmm，只能说运气不好，所谓将熊熊一窝就这样，除非你手下有一群特别牛气的人，而且还愿意被无能的C长期统治，不然，早晚造反。我在C手下，就是造反的头号人物。
作为一个PG。我觉得有这么几种，
1.工作者。coder对于他来说就是一份工作，他就是一个打工仔。所以千万不要给他超过工资的工作，那样他会觉得你是在针对他。而且加班什么的，一定要提前说好，而且说好了就不要再变，因为这样的人一般业余生活也很丰富，你很容易打乱人家的计划。
2.弱者。他跟工作者最大的区别就在于弱者没有能力，不仅仅是没有工作能力，还包括学习能力，沟通能力。这样的人我一般形容就是烂泥。不管你怎么教，怎么引导，他的活永远那么烂，他交出的代码你check4遍了依然觉得不放心。对于这样的家伙，如果你没能力踢出团队，那么尽可能的交代他简单的工作，千万千万不要把一些关键的工作交给他，不然你就等着客户发飙吧。这样的人有的会比较自卑，有的反倒是比较自我感觉良好，总觉得问题是其他人的。遇到这样的极品，最后的结果要么是他走，要么就是你走。
3.程序员。个人觉得我当时在组里就是这么个角色。喜欢摆弄新东西，看不起老东西。脑子好使，但是没什么耐性，对于重复性的工作深恶痛绝，尤其不喜欢“低水平”的工作。遇到这样的人，可以让他啃骨头，但是指望他天天安分守己的干重复性的工作，那么早晚会把他逼走的。
4.伪Leader.这行不好混，有人升职，就有人被裁。所以说不定你会遇到那种水平不次于你，管理经验还比你丰富的家伙。我们之前的一个团队就遇到一个在原来公司做到经理级别的人回来做coder的，于是你发现，组长好多事情还要向他请教。遇到这样的人，大家都很尴尬，如果leader跟PG大家心态调整的好，那自然是你好我好。如果有一个调整不好，Leader想着要显摆权威，PG要想着炫耀经验，那你看着吧，没个好。
以上。

[sivacohan]

我觉得这个我可以说两句。

我们把小团队定义为团队总人数不多于5人的团队。即1个leader加若干coder。


先说一下关于PMBOK的问题：
我在考今年6月份的PMP认证。PMBOK这个缩写实际上已经说的很明白了。这是一个guide。属于纲领性的东西。内容涉及非常之宽泛。而且，国外有一个工作职位就是职业项目经理。这是国情和文化差异造成的一些问题。PMBOK对应的是对大中型公司的项目管理。对小型团队，小公司搞这个，是不合适的。


接下来说管理的事情：
在我看来，管理的意义在于解决两个问题：1、降低沟通成本。2、降低项目的风险。

关于第一点：沟通简单可以分为两个部分，内部沟通，外部沟通（跨部门沟通，跨公司沟通等）。在小团队里面内部沟通成本极低，我们可以尽可能多的进行内部沟通。而外部沟通就比较蛋疼了，因文化、学历、智商等差异，会导致沟通效率低下，甚至双方产生误解。所以，做项目管理的时候，第一步，理清干系人，第二步，反复与干系人沟通，并尝试建立沟通术语。让干系人去改变思维方式通常比较困难，这个地方项目管理人员就在各个干系人中间充当了翻译的工作。

关于第二点：主要就是对风险的预估以及处理能力。在项目开始时，我们就要为项目做出一定的风险预算（包括时间、人力、物力等）。当项目进度出现delay的情况。我们就要采取一定的措施来解决。如果在之前有预估到，那就要动用我们相应的预算。如果我们发生了一件未在预料中的风险，那么我们首先要尝试自己解决。如果超出能力了，或者会直接把我们的风险预算全部吃掉。那我们应该通知上级要求新的资源。


最后说一下关于对上级的方式：
与上级沟通时，不要直接把你收集到的问题直接反馈给上级，一定要对问题进行思考，并提出若干备选方案。


-EOF-

[oio]

@jianghu52
@sivacohan

谢谢两位细心的回复，受益匪浅。发帖时间是春节，现在才看到~ Thanks！

[oio]

@sivacohan , 看来我的风险意识还比较弱，沟通方面倒是深有体会。

[oio]

@jianghu52 我也喜欢尝试新东西，哈哈，跟你类似，适合 3•程序员。但是有了责任的话，重复低水平也得揽啊。