一本很薄的书，之所以引诱我买下是因为它的副标题：领导开发团队，一本目标很明确的书。team work的重要性在工作中已经毋庸置疑了，剩下的就是如何能有效地team work的问题了。软件开发更多地是技术问题，但团队开发却并绝非是技术问题，是一个不折不扣的关于人的问题。因此不会有一个简单、绝对、可按教条执行的答案，但看看在行业内有丰富实践经营的大牛们的经验总结还是很有借鉴意义的，因此决定买下一读。
第一章读完后就暗自庆幸没有花冤枉钱，值得买，值得读。TSP应该是team software process的缩写，因此，作者在这本书里想推广的是一种process，和软件工程中的其他process类似的process，只是这里是关于团队的过程，而非单纯的软件过程。这个process用于指导如何领导“自主型团队”进行软件开发。
由于软件开发的协作性特点和开发人员的知识性工作特点，自主型团队应该是一个很好的选择，然而很多公司和管理者目前还不会意识到这一点，即使是在高科技企业里，民主化很多时候也仅仅是口头语而已，纵向命令链方式依然是主要的组织领导方式，横向协作方式远没有鼓吹的那样流行。总之，管理者们还不相信人们能够自主工作，团队能自主管理。为了追求一个更好的、更有效率的工作环境，“路漫漫其修远兮，吾将上下而求索！”……
什么样的团队可以称作自主型团队呢？作者认为自主型团队有五个特征：
- 成员感和归属感
- 对团队共同目标的承诺
- 过程和计划的自主权
- 制订计划的技能以及遵循计划的纪律性
- 致力卓越
TSP能做什么呢？TSP主要用于：
- 组建一支自主型团队
- 激励团队做工作
- 在整个工作中维持这样的激励和动机
其中TSP团队启动过程可以做到1和2，团队启动过程共有9次会议来建立团队目标、计划及向管理层汇报等。实际中当然不必教条地按条执行，但主要方面还是要做到地，满足构建和激励团队的目标即可。从以前的经验来看，的确需要一周左右的时间来集中地、专心地做这些。否则团队是不会找到感觉的。
在启动以后，需要维持团队的协作，主要要做到：
- 数据收集
- 计划跟踪
- 团队反馈
- 负载平衡
- 重新计划
每周的项目会议是一个很重要的活动，更新项目的状态和计划。这个会议的结果可以作为给管理层汇报的输入。
和管理层打交道是团队领导者的一个职责，需要取得管理层的支持，向管理层汇报，以及在处理请求、频繁变更、人员安置、培训等方面保护团队。
维护团队也是领导者的一个重要方面，包括培养团队、培养团队成员、改进团队绩效等。
书中对以上方面做了很多方法说明，甚至给出了很多操作模板。但这些很具体的做法应该不是重点，重点是抓住其中的精髓，即：如何打造一支自主型团队，如何培养自主型团队的五个特征，为此，作者给了很多方法或忠告，比如让团队认识到项目的意义、让团队参与计划、让团队自主制定过程等等（其实这些和其他组织团队活动的技巧都是相通的，比如号召大家“打土豪，分田地”的革命行动:)），要点无外乎：诚、立信、使民以敬、推己及人等基本做人做事原则。半部《论语》治天下，信哉！
这本书里还有几点比较有意思：
- 对领导和管理的区分
- 管理使用资源达成结果，客观，没有个人感情因素，假定被管理者没有思想和感受，必须被告知要做什么，如果做。适用于无生命的对象或例行公事。管理者强迫人们服从命令。
- 领导激励人们达到目标，带有强烈的个人感情色彩。领导者的地位必须赢得，不是任命即可获得的。
- 角色与任务
- 可以将角色分配给团队成员，负责某些方面，比如：计划经理、质量经理、过程经理、接口经理……
- 团队成员可以在担任角色的同时完成分配的任务
- 任务和角色的划分是“正交”的
- 通过建立团队角色、让团队对角色所有权达成一致来解决团队的内聚和协作精神与所有权的单向排他性之间的冲突。
总之，关于如何构建及领导自主型团队，这本书有了很好的介绍和指导。其中很多地方和我的原有想法和实践很接近，是对以前实践和思考的一个验证，毕竟很多事情做过以后是不会直接有答案显示正确与否的，好的结果和正确的行动很可能没有必然联系的，凭结果是不能验证中间某一过程的（何能以成败论英雄？！），因此，反思往往只能凭感觉和信念来得出一些结论，这些结论往往会带有一些偏见，这些偏见可能会被一次次加强，直至冥顽不化。这本书正好提供了一个参考，确认了大多数的想法，也纠正了一些想法，还启发了一些思考，35RMB，值！
没有评论:
发表评论