半年TeamLeader总结(转) -半年工作总结

时间：2022-04-25 20:27:01 半年工作总结我要投稿

相关推荐

成为一个小团队的TeamLeader半年多了，有成功的喜悦，也有失败的苦闷，无论如何，是该总结一下了。 *关于计划作为一个小团队的Leader，项目的计划分成两个部分，项目计划和进度控制，事实上在我经历过的或者我观察过的（我的或者他人的）多个项目当中，往往最常犯的毛病就是有计划没控制，甚至是没计划更没控制。事实上两部分相互相成，一个糟糕的项目计划必然导致糟糕的进度控制，但有好的计划而糟糕的进度控制则会导致一切努力化为泡影，领导不满意，团队成员多怨言，上下不讨好里外不是人。自己曾经也多次地经历过这种郁闷，甚至一度想放弃，最终还是坚持了过来。 1)项目特点总结：一般目前处理的都是一些短时间迭代的任务（周迭代），每个迭代相对比较简单 2)时间评估：良好的开端是成功的一半，在项目的开始时，首先仔细地进行时间评估，尽量地细化任务以获得更好的时间控制。此阶段非常地重要，评估的失误往往导致进度过紧，而人在疲倦的时候更是往往错误不断，最终导致整个计划失去控制。我的经验是，在一切任务开始之前，一定要跟相关人员将业务沟通地非常清晰，此阶段的一个小错误，将导致后面的全面被动，在沟通完毕之后，由开发人员评估时间，之后根据经验得到一个正常的评估结果。这个过程中最容易犯的错误就是,一是开发人员对时间评估往往非常地乐观，因为他只看到了开发的这个过程，关于这个问题，我把评估时间段分为：沟通时间、设计和开发时间（包括自测）、联调时间（跨团队甚至是跨公司）、发布Beta测试时间，跟开发人员强调每个过程可能会发生的时间，在这些时间的基础上，再乘一个缓冲基数，得到最终的评估时间，尽管如此，在不少情况下，还是出现了需要加班才能够完成的情况，这个确实是需要继续总结思考的地方；二是对一些任务，往往领导规定了时间，这种情况下都是非常地被动，只能根据时间来定计划，往往这种情况下更需要保持清醒地头脑，更细致地进行计划，而一旦发现偏差太大，则必须强烈拒绝，否则最终的结果也不会是领导期望看到的，在这个问题上可以说是犯了非常多地错误，对困难估计不足，过于乐观，屈服于领导的意愿，看来这方面还是得继续加强。 3)与第三方合作：多次与第三方进行了合作，也总结出了下面的经验；在开始阶段双方定义好业务流程图，并指定每一步骤由哪方完成，并形成文档; 在开始阶段根据业务流程图定义好所有的接口，包括接口参数和返回结果，并形成文档; 在定义完业务流程图之后，出原型（包括界面原型、邮件原型等）; 定义好双方各个时间点，包括Stub测试程序发布时间、接口文档提交时间、某业务点发布、出原型时间、联调时间等等; 控制变更。其实在与第三方合作最困难的一点就在于，对方看不到如上这些控制的好处，思维不在一块，往往会导致在后期还在不断地调整，一整个就搞地非常地郁闷。 4)过程控制：控制整个过程，我的经验是从控制各个时间点，必须把各个重要的时间点和产物定义地非常地清晰。目前主要定义的时间点和产物包括：需求确认完成阶段--最终确认无误的需求文档（包括原型和相关的模板之类的），提交测试用例--评审后的测试用例，设计时间点--设计沟通（比较简单）或设计文档（比较复杂），开发、自测时间点--代码、自测的结果Excel列表（根据项目的特点而定）、版本和变更说明，Beta测试--测试报告，发布。此外，目前的做法是每天花二十分钟了解一下项目的进展情况，并一再跟项目团队成员强调，一旦发现进度偏离，必须马上反映。 5)变更控制：无止境的需求变更往往就是项目进度控制的掘墓人，刚开始最容易范的毛病就是，往往不加以评估就随意地答应业务人员的需求变更。现在的做法就是，发生需求变更时，进行仔细评估，是否会影响项目的进度，往往对一些无伤大雅的需求变更则大方答应，乐地做好人，但一旦发现对进度会产生影响，一般的做法就是，向业务人员建议，要么下个迭代处理，要么砍去目前已有的功能。经过这些沟通，往往

半年TeamLeader总结(转) -半年工作总结

业务人员之后对业务的变更会更谨慎。 6)持续迭代：对于有些任务，会使用短周期、多次迭代的方式进行，在这种项目中，我碰到的最常见的问题就是，往往到下一个迭代开始之后，才开始下个迭代的准备工作（需求了解、设计及相关工作），而往往每个迭代周期的时间又非常地短暂，导致开发和测试时间不足而引发其他的问题。最近总结的结果就是，对这种短周期多次迭代的项目，开发测试和下个迭代的准备工作同步进行，确保在每个迭代开始之后，相关的工作已经就绪，当然，这是比较理想的情况，在迭代准备工作需要涉及外部配合的情况下，会有一定的障碍，不过，尽快地推动开始，相当于拉长了每个迭代的开发和测试周期，能最终为计划腾出更多的缓冲的时间，同时也能更好地保证开发质量。 *关于质量项目最终产物的质量将决定了整个项目的成败的结果，因此，如果在项目的过程当中去保证质量致关重要，我的经验总结是， 1)流程中的质量控制：控制各个点的质量，以保证最终的质量：一是需求质量--我一般都会跟相关参与沟通的人员一再地强调，谋定而后动，必须想清楚想明白点滴确认好，不要匆匆忙忙地动手，现在一般都会非常仔细地去了解需求，对不明确地需求要求业务人员确认，通过此轮准备，重要的失误不会在最后才被发现；二是测试用例--要求所有的相关人员参与测试用例的评审；三是设计--设计完成之后必须进行沟通，不允许在没有经过相关人员地确认就匆忙开始；四是开发和自测--尽量地提交测试Excel报告、TeamLeader对代码进行CodeReview；五是Beta测试--提交测试报告。 2)人为因素的质量控制：首先，质量控制是基于准确的时间评估，因此必须在开始阶段保证了时间评估的准确性，过紧的开发进度容易导致人的疲劳，人的疲劳又常常导致过多的错误，导致质量失控；其次，在团队成员上，不断灌输质量的理念，让他们了解到质量的重要性，并积极参与质量保障措施（譬如测试Excel报告）；最后，灌输分清主次的观念，要求他们在时间紧迫地情况下，保障重要功能重要问题的质量。事实上说的这个过程会过于理想，在实际操作中往往有非常多的意外情况发生，这也是需要不断地去提高这方面的技巧。 *团队建设如上的说明更多地是在规范和流程上去控制好整个团队的工作，事实上，人的因素非常地重要，个人的主观积极性和能力，往往能够能大大提交团队地开发效率，目前在团队的建设上，我主要采用如下的措施： 1)培训：工欲善其事,必先利其器，只有整个项目团队成员能力的提高，最终才能推动整个团队的素质的提高，因此在培训上的投入可以说是非常地重要，在后续中，也必须继续加强这方面的安排。 2)构建团队和谐地气氛：这一点感觉做地还是非常地不错，整个团队的气氛比较轻松和活跃，基本上每个成员之间都能够彼此相互帮助，并感受到在这个团队中的快乐，积极做事，快乐工作。当然，该放松时放松，但该严肃时必须严肃，特别是在项目进度上，是绝对不能讨价还价，实在不行就得加班，当然，在兄弟们加班时，一般都会与大家一起奋战到最后。 3)鼓励：每周例会，现在一般强调地最多的就是两点，一是总结，要求团队成员总结本周工作情况、提出个人想法，其实一般这种并非是需要了解他们的工作，而是锻炼总结能力和口头表达能力；二是自由发言，鼓励他们提出自己的想法。目前这个方面做地还是远远不够的，看来还得继续加强啊。关于团队建设方面，现在能做的还是太少，看来接下来得多花点时间多思考这方面事情。半年的时间是非常短暂，总结出来的东西还是很浅薄，路还很长，希望之后能够更多地学好这方面的知识，以期做地更好来源:http://blog.myspace.cn/index.cfm?fuseaction=blog.view&friendID=1306090849&blogID=402533140

【半年TeamLeader总结(转) -半年工作总结】相关文章：

半年工作总结02-22