关于“团队建设”的反思

2015-11-16 14:06:36 分类：管理

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

一经过半年的尝试

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

二 “演化”还是“革命”

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

三 “人”还是“过程”

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

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

　　　　应付进度不如保证质量

　　　　溜须拍马不如求真务实

　　　　推卸责任不如承认错误

　　　　加班赶工不如按时完工

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

关于“团队建设”的反思

在线测试

参考手册