关于“团队建设”的反思

　　本文，是我对过去某个项目进行团队建设的实践总结，旨在为读者分享个人经验教训。接手项目组时，项目组的软件开发能力处于无序状态，没有任何管控措施，甚至连最基本的团队规则和编码规范都没有制定。团队没有造成有效的合做，没有明确分工，代码质量低下。

一 通过半年的尝试

事件	描述	好的方面	未解决的问题	经验教训
尝试让领导了解软件研发的复杂与软件构建的那些事情。	经过文档，会议上的发言，电话的沟通但愿能影响领导对软件开发是认识。在领导的决策中，大胆提出本身的建议，并分享本身的项目经验，	领导对软件项目与通常工程项目间的差距有所了解。可以逐渐接受项目组提出的进度要求。 领导对软件项目风险有了新的认识，不在盲目立项。 领导了解了项目团队的基本组成和岗位分工，可以倾听PM的意见进行人员招聘。	领导对程序员职业定位和程序员的价值观并不理解，对开发人员不够尊重。 领导不理解软件项目的管理原则，对项目插手过多，并时常做出破坏团队建设的活动。 领导对质量不够重视。	不要对“培训”领导有过高的但愿。工做之中的合理建议是必须的，但当领导不在倾听你的声音时，大家间的任何沟通都是无效的，那时即便你有满腔抱负也无济于事。
拟定编码规范。	个人第一步就是拟定编码规范，强调命名规则的重要性，命名的隐喻，并力求获得项目组的认同。	理解了命名规则的隐喻，并能更好地解读代码。 经过讨论达成了一致的命名规则，并开始执行。	没有绩效考核机制，没有代码审查，程序员任然会践踏规范。	在没有代码审查、团队规范和绩效考核的状况下，难以让编码规范获得强制实施。若是管理者被赋予的权力太低，连让开发人员返工的权力都没有的话，编码规范形同废纸。
制定进度计划并进行进度控制。	使用Project作进度计划，并进行跟进。	因为采用自底向上的方式安排进度，参考开发人员的主张调整，开发人员的责任感明显上升，进度滞后现象有所收敛。	开发人员会为应付进度而缩减功能。	进度当然重要，可是质量不能忽视。必须结合质量来考虑进度状况，而非单方面地认为任务已经完成。
文档标准化。	强调文档的重要性，在项目实施中，有意识地申请编写文档的时间，并一马当先撰写的大量的技术文档，帮助团队理解需求、技术架构，提升开发效率。	开发人员已经造成文档意识，并能撰写部分文档。	文档内容风格没法统一，文档规范难以在项目中推行。撰写文档的优劣程度不一。	必须有团队规则和绩效考核保证，自上而下的贯彻执行才能推行标准化。
推行SCM。	搭建SVN环境，培训SVN使用，大力倡导版本控制的好处。	团队成员基本掌握SVN的使用方法。	没有按照指导规范使用SVN，版本控制杂乱无章。	没有考核的培训，效果不佳。
明确分工和职责。	经过内部讨论明确成员分工，力求责任到人。	分工基本明确。	互相推卸责任。	在没有追溯和绩效考核的状况下，难以作到责任到人。
倡导技术学习。	向公司申请资料费购买技术图书，提倡团队成员在工做以外进行技术学习和实践。	初期，团队成员热情高涨，看书并撰写博客，	后期，大多数成员再也不看书或撰写博客。	虽然本意是实现公司与团队成员的共赢，但多数成员更看中的是工资待遇，而不是技术知识。
明确技术方向。	尝试创建愿景并明确技术方向。	通过漫长的讨论，明确了技术路线。	技术方向，没法被贯彻实施。	没有必定的执行力，我的作再多的努力也无济于事。

二 “演化”仍是“革命”

　　通常，我更倾向于经过“演化”来缓慢地，进行变革。虽然，“演化”的周期更长，效果不那么容易凸显，可是其可以减轻团队的震荡，并可以获得高层的支持。我也在思考“革命”的作法是否会有更好的效果。当团队成员已经造成一个个工做模式和习惯时，就很难让接受不一样的东西。我想，若是以前进行的是完全的“革命”，从公司制度角度来强势推行某些措施是否会获得不一样的效果。

三 “人”仍是“过程”

　　敏捷与CMM之争已经持续好久，在我看来就如同魔兽世界没有最出色的职业，只有最优秀的玩家同样，这种争论永无心义。

　　我一直在观察，现实与理想。我发现，不少错误的东西正在成为主流，但错误的价值观不该该影响到咱们。

　　　　应付进度 不如 保证质量

　　　　溜须拍马 不如 求真务实

　　　　推卸责任 不如 认可错误

　　　　加班赶工 不如 按时完工

　　虽然左侧的人不少，但我认为右侧的才是正确的。