近期在读《团队制胜》这本书，感觉非常不错，书中的一些观点很有借鉴意义，我们不怕犯错，但却怕知错不改。读到第四章了，从切身体会来说，感触蛮多的，所以对前几章觉得不错的观点总结一下。
1、在大多数软件项目中，真正缺乏的仍然是对产品的明确并一致的理解，以及在项目的整个周期中对这种理解的管理。关于这一点，我觉得毋庸置疑吧。
2、那些成功的团队中通常拥有丰富的经验、合理的计划，并且团队成员之间的交流也是公开和坦诚的，研究小组很少会认为采用某项技术是成功的关键因素之一。一直觉得技术并不是产品成功的关键，所以也一直对技术的热衷程度相对较低，技术服务于人类的本质在于产品，当然这并不是否认技术这个职位在产品开发中的重要性，但往往技术人员付诸于产品开发中的执行力度，比技术本身对产品的影响更加重要。
3、项目回顾在软件开发过程中是一种有效避免产品缺陷的手段，但最好的方法仍然是努力缩小发生问题与产生结果之间的时间距离。这一点最近感触颇深，一些问题很早就被自己或者团队中的其他成员提出过，但一直没有着手解决，等到相关模块已开发接近完善阶段或者说到了不得不改的时候，才去改，这时必然伤筋动骨，一方面浪费大量的人力资源，另一方面严重打击开发人员的积极性。
4、在实际工作中不存在最优方法。
5、牛仔与无名英雄。成功不仅只依靠少数几个人，个人英雄主义从长远来说不利于产品发展。工作不是读书，读书也许只要一个人默默地努力，必然会有所收获，而产品，却需要汇聚各方力量，从策划人员，技术人员，美术，运营，缺一不可，每一个人都将是为产品负责的英雄。
6、激情是富有感染力的，首先从少数人开始，并最终传播给其他人。一个团队和一支军队一样，总是由少数人的感染，最终决定这个团队的灵魂与对外气质。
7、质量是一种责任，正好看到这一章，对这一点感触颇多。同时可能是受个人追求完美性格的影响，总是希望产品在开发过程中就尽量保证质量，质量保证是贯穿整个开发过程的，不是管理者（产品经理？项目经理？）的责任，更不只是QA部门的责任，而是每一个人的责任。而现实开发中，可能并不是所有人都能将正确地对待质量——我们的任务是正确地完成工作，而不只是完成工作。
所以，一般我在开发过程中，会尽量考虑全面并完成自我测试，我觉得在开发过程中多花些时间思考，并不是一件坏事，工作几年，开发过程中很少用到流程图之类的，这方面的经验非常欠缺，前一阵子试验了一下对一些复杂模块都先做一份流程图，再进行开发，虽然前期时间花得较多一些，但开发却是前所未有的顺利，最终的产出几乎没有逻辑上的bug和缺陷。
同时，一直觉得如果开发过程一味地追求进度，最终产品质量是很难控制的。所以一直比较郁闷的是，因为整个团队的进度计划和个人的计划有所偏差，导致不得不经常通过加班来同时保证质量和进度——人（或许只是我自己）总是不希望自己做的事情，过多地被别人指手划脚，每个人都是有各种各样情绪的。但通过这种方式协调质量和进度，可能不会在意付出了多少，但如果像第三点中提到的那样，人力资源被各种各样的原因而浪费，造成的积极性打击是更加致命的。
在模块提交QA部门之前，自己职责所在也必须尽量保证质量，QA应该更多地扮演质量的把关者，而较少地扮演问题的反馈者。如果一个产品交由QA，不是一些逻辑死角都能发现一堆bug，我觉得开发人员应该汗颜吧。
当这种以责任对待质量的态度成为团队的一种理念，一种默契，那么最终输出的可能未必是商业上成功的产品，却至少也敢说一声“勿以成败论英雄”。
Related Images:
