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