半年TeamLeader总结

成为一个小团队的TeamLeader半年多了，有成功的喜悦，也有失败的苦闷，无论如何，是该总结一下了。

      *关于计划

      作为一个小团队的Leader，项目的计划分成两个部分，项目计划和进度控制，事实上在我经历过的或者我观察过的（我的或者他人的）多个项目当中，往往最常犯的毛病就是有计划没控制，甚至是没计划更没控制。事实上两部分相互相成，一个糟糕的项目计划必然导致糟糕的进度控制，但有好的计划而糟糕的进度控制则会导致一切努力化为泡影，领导不满意，团队成员多怨言，上下不讨好里外不是人。自己曾经也多次地经历过这种郁闷，甚至一度想放弃，最终还是坚持了过来。

      1)项目特点总结：一般目前处理的都是一些短时间迭代的任务（周迭代），每个迭代相对比较简单

      2)时间评估：良好的开端是成功的一半， 在项目的开始时，首先仔细地进行时间评估，尽量地细化任务以获得更好的时间控制。此阶段非常地重要，评估的失误往往导致进度过紧，而人在疲倦的时候更是往往错误不断，最终导致整个计划失去控制。我的经验是，在一切任务开始之前，一定要跟相关人员将业务沟通地非常清晰，此阶段的一个小错误，将导致后面的全面被动，在沟通完毕之后，由开发人员评估时间，之后根据经验得到一个正常的评估结果。这个过程中最容易犯的错误就是,一是开发人员对时间评估往往非常地乐观，因为他只看到了开发的这个过程，关于这个问题，我把评估时间段分为：沟通时间、设计和开发时间（包括自测）、联调时间（跨团队甚至是跨公司）、发布Beta测试时间，跟开发人员强调每个过程可能会发生的时间，在这些时间的基础上，再乘一个缓冲基数，得到最终的评估时间，尽管如此，在不少情况下，还是出现了需要加班才能够完成的情况，这个确实是需要继续总结思考的地方；二是对一些任务，往往领导规定了时间，这种情况下都是非常地被动，只能根据时间来定计划，往往这种情况下更需要保持清醒地头脑，更细致地进行计划，而一旦发现偏差太大，则必须强烈拒绝，否则最终的结果也不会是领导期望看到的，在这个问题上可以说是犯了非常多地错误，对困难估计不足，过于乐观，屈服于领导的意愿，看来这方面还是得继续加强。

      3)与第三方合作：多次与第三方进行了合作，也总结出了下面的经验；在开始阶段双方定义好业务流程图，并指定每一步骤由哪方完成，并形成文档; 在开始阶段根据业务流程图定义好所有的接口，包括接口参数和返回结果，并形成文档; 在定义完业务流程图之后，出原型（包括界面原型、邮件原型等）; 定义好双方各个时间点，包括Stub测试程序发布时间、接口文档提交时间、某业务点发布、出原型时间、 联调时间等等; 控制变更。其实在与第三方合作最困难的一点就在于，对方看不到如上这些控制的好处，思维不在一块，往往会导致在后期还在不断地调整，一整个就搞地非常地郁闷。

      4)过程控制：控制整个过程，我的经验是从控制各个时间点，必须把各个重要的时间点和产物定义地非常地清晰。目前主要定义的时间点和产物包括：需求确认完成阶段--最终确认无误的需求文档（包括原型和相关的模板之类的），提交测试用例--评审后的测试用例，设计时间点--设计沟通（比较简单）或设计文档（比较复杂），开发、自测时间点--代码、自测的结果Excel列表（根据项目的特点而定）、版本和变更说明，Beta测试--测试报告，发布。此外，目前的做法是每天花二十分钟了解一下项目的进展情况，并一再跟项目团队成员强调，一旦发现进度偏离，必须马上反映。

      5)变更控制：无止境的需求变更往往就是项目进度控制的掘墓人，刚开始最容易范的毛病就是，往往不加以评估就随意地答应业务人员的需求变更。现在的做法就是，发生需求变更时，进行仔细评估，是否会影响项目的进度，往往对一些无伤大雅的需求变更则大方答应，乐地做好人，但一旦发现对进度会产生影响，一般的做法就是，向业务人员建议，要么下个迭代处理，要么砍去目前已有的功能。经过这些沟通，往往业务人员之后对业务的变更会更谨慎。

  6)持续迭代：对于有些任务，会使用短周期、多次迭代的方式进行，在这种项目中，我碰到的最常见的问题就是，往往到下一个迭代开始之后，才开始下个迭代的准备工作（需求了解、设计及相关工作），而往往每个迭代周期的时间又非常地短暂，导致开发和测试时间不足而引发其他的问题。最近总结的结果就是，对这种短周期多次迭代的项目，开发测试和下个迭代的准备工作同步进行，确保在每个迭代开始之后，相关的工作已经就绪，当然，这是比较理想的情况，在迭代准备工作需要涉及外部配合的情况下，会有一定的障碍，不过，尽快地推动开始，相当于拉长了每个迭代的开发和测试周期，能最终为计划腾出更多的缓冲的时间，同时也能更好地保证开发质量。

      *关于质量

      项目最终产物的质量将决定了整个项目的成败的结果，因此，如果在项目的过程当中去保证质量致关重要，我的经验总结是，

      1)流程中的质量控制：控制各个点的质量，以保证最终的质量：一是需求质量--我一般都会跟相关参与沟通的人员一再地强调，谋定而后动，必须想清楚想明白点滴确认好，不要匆匆忙忙地动手，现在一般都会非常仔细地去了解需求，对不明确地需求要求业务人员确认，通过此轮准备，重要的失误不会在最后才被发现；二是测试用例--要求所有的相关人员参与测试用例的评审；三是设计--设计完成之后必须进行沟通，不允许在没有经过相关人员地确认就匆忙开始；四是开发和自测--尽量地提交测试Excel报告、TeamLeader对代码进行CodeReview；五是Beta测试--提交测试报告。

      2)人为因素的质量控制：首先，质量控制是基于准确的时间评估，因此必须在开始阶段保证了时间评估的准确性，过紧的开发进度容易导致人的疲劳，人的疲劳又常常导致过多的错误，导致质量失控；其次，在团队成员上，不断灌输质量的理念，让他们了解到质量的重要性，并积极参与质量保障措施（譬如测试Excel报告）；最后，灌输分清主次的观念，要求他们在时间紧迫地情况下，保障重要功能重要问题的质量。

      事实上说的这个过程会过于理想，在实际操作中往往有非常多的意外情况发生，这也是需要不断地去提高这方面的技巧。

      *团队建设

      如上的说明更多地是在规范和流程上去控制好整个团队的工作，事实上，人的因素非常地重要，个人的主观积极性和能力，往往能够能大大提交团队地开发效率，目前在团队的建设上，我主要采用如下的措施：

      1)培训：工欲善其事,必先利其器，只有整个项目团队成员能力的提高，最终才能推动整个团队的素质的提高，因此在培训上的投入可以说是非常地重要，在后续中，也必须继续加强这方面的安排。

      2)构建团队和谐地气氛：这一点感觉做地还是非常地不错，整个团队的气氛比较轻松和活跃，基本上每个成员之间都能够彼此相互帮助，并感受到在这个团队中的快乐，积极做事，快乐工作。当然，该放松时放松，但该严肃时必须严肃，特别是在项目进度上，是绝对不能讨价还价，实在不行就得加班，当然，在兄弟们加班时，一般都会与大家一起奋战到最后。

      3)鼓励：每周例会，现在一般强调地最多的就是两点，一是总结，要求团队成员总结本周工作情况、提出个人想法，其实一般这种并非是需要了解他们的工作，而是锻炼总结能力和口头表达能力；二是自由发言，鼓励他们提出自己的想法。目前这个方面做地还是远远不够的，看来还得继续加强啊。

      关于团队建设方面，现在能做的还是太少，看来接下来得多花点时间多思考这方面事情。

 

      半年的时间是非常短暂，总结出来的东西还是很浅薄，路还很长，希望之后能够更多地学好这方面的知识，以期做地更好

   

     MySpace的地址：http://blog.myspace.cn/index.cfm?fuseaction=blog.view&friendID=1306090849&blogID=402533140

You are right
Team Leader，不光是技术是Leader，更能沟通协调，让人服你

我什么时候能做到呢？
或者个人达到什么水平、标志可以开始做team leader呢？
我做了3年的开发了。

我们领导说过：
  你有意识要当项目经理的时候，才有可能当，就算你能力还有所欠缺，他也会来个“拔苗助长”式的培养

呵呵，当然也要有适当的基础及机会

同意你们领导的说法。

楼主分析得很精辟！本人也TL半年了，感同身受，彻底摆脱之前的“好好人”角色！

楼主总结的不错，确实是经验

跟水平没关系，看你BOSS给你机会不