谈谈团队文化

今年团队来了几个新人，新人初入职场，除了专业技能的学习，职场基本素养的培养也很重要。但是很多时候，我们忽视了这一点。职业素养一方面需要自己领悟总结，一方面优秀的团队文化也有很重要的引导作用。这也是今天为什么谈谈我们的团队文化的一个出发点。

一个有执行力、高效的团队，团队成员间一般都存在某种默契，这种默契就是团队文化。有了团队文化，才能凝聚一群志同道合的同学一起工作，有了一群志同道合的同学我们的工作效率才会非常高。

往往这种默契一般都靠心领神会，说了反而矫情。对于这种可说可不说的东西，我倾向还是说一说，因为沟通就是信息同步，保证大家在一个频道上交流，减少信息传递损耗。

公司文化是团队文化的基石，公司在各个层面推进敏捷转型，所以敏捷肯定是我们团队文化的一部分，这包括敏捷纪律、任务看板、持续集成看板、代码评审纪律、计划会、每日例会、展示会、反思会，每周分享会等等，这一块就不多说。

除此以外，我们的团队文化还应该包含如下行为准则：

 

开放公开

• 日常开发公开；
• 故障定位公开；
• 代码全体所有；
• 技术共享；
• 文档随手归档svn文档库；
• 积极主动分享；

有效沟通

• 用数据说话。代码评审时，先提供你的自测结果日志数据，而不是仅仅的一句“自测通过”；讨论故障时，先提供你采集的故障信息数据；讨论方案时，先提供支持你方案的数据；讨论问题时，先提供相关的背景数据，比如邮件、文档； 
• 保持简单。Don't make me think。测试接口要有使用帮助，不要让用户思考；打印信息要简练，不要干扰用户，软件界面要傻瓜，避免歧义困扰用户；
• 邮件沟通。要做到标题清晰，不乱改邮件标题，不破坏mail thread，邮件正文信息充分，讨论时不要带有个人情绪；
• 开发需求讨论。先讨论原始需求，再讨论解决方案；避免把某个解决方案作为需求来讨论；
• 集体讨论时，善于运用头脑风暴、SMART、鱼骨图、思维脑图等工具；
• 用户故事清晰。用AIS结构描述，每个用户故事给出验收用例和完成定义；

 

快速响应

• 邮件要有响应，比如询问的问题要有答复；指派的任务要有进展汇报。邮件不能到你这里，就“石沉大海”，烂在自己的手里；
• Review Board代码评审的意见要及时处理，不管是否合理，都需要认真对待并一一回复。不能敷衍了事，伤害团队代码评审的积极性；
• 任务按重要性和紧急度划分成4类，分类处理。一般原则，重要紧急的任务用马上处理，并日报汇报跟踪；紧急不重要的任务马上处理；重要不紧急的任务作为高优先级任务放入敏捷backlog list；不重要不紧急的任务作为低优先级任务放入敏捷backlog list。
• 阻塞一天的问题，需在每日例会上发出求助；如得不到反馈，逐步升级；
• 做事要有始有终，要有输出，要闭环，要善于运用PDCA工作法；

 

注重承诺

• 注重承诺是职业的基石，这对任何职业都是如此，软件开发也不例外。注重承诺，赢取客户的信任是职场成功的第一步。
• 迭代领取的敏捷任务是一种承诺，承诺在展示会前要完成；
• 开发某个功能是一种承诺，承诺保证这个软件功能的内部质量和外部质量；
• 答应的deadline是一种承诺，承诺全力以赴完成；
• 如果无法完成，要勇敢的说不，不要盲目承诺，破坏我们的信任基础。

-- EOF --