我们是一个研发部门，面临与其它组成员共同协作完成共同目标的情况，在此过程中遇到了一些问题，本次记录一次跨部门合作当中出现问题的思考。简化的问题是，张三让李四今天拧好这些螺丝，下午下班前李四拧好螺丝并且下班，张三发现拧的螺丝还是有点松，问李四啥时候能拧紧，李四说明天吧，张三同意。第二天张三领导问为什么螺丝还没拧好，怀疑李四消极怠工，并上报李四领导，导致李四心情不好。
本次对个人对问题进行相应的反思和总结，以便之后进行改正。
问题发现
敏捷开发Scrum规定，出现问题那都是团队的问题，人的问题80%都是组织和制度的问题。复盘仅为了未来更好的协作，犯错也从来都是团队的错。
问题1：目标不清晰
团队每个人都是独立的个体，身份不同的情况下思考方式都是多种多样的，所以在整体性目标和局部性目标要达成高度一致，才能有效形成合力。
从上述问题当中我们发现目标是不够清晰的，拧螺丝的目标是啥？是单纯的拧紧还是为了临时固定桌子使桌子不晃，还是为了火箭升空的时候防止高温防护层不脱落。目标不一样执行的动作是不一样的，多人协作项目中更是如此，有的人往东用力有的人往西用力，看似大家都在努力工作其实都是白白浪费体力。
那么如何确定明确目标呢？
- 整体目标
按照上面的案例，个人理解交代任务是：我们拧螺丝的目标为了防止火箭升空时，高温隔离层不脱落，如果脱落整个火箭就会爆炸，人员伤亡、经济损失不可计量。这个时候首先工作人员往往能力体会到工作的巨大价值，工作的积极性会相应的调度起来。再次会考虑为了达成这样的目标需要谁拧多少螺丝，需要拧什么材料的螺丝，具体拧到哪，什么时间完成，5W1H这些信息都需要量化。 - 验证手段
根据整体目标我们准备出具体量化指标后，需要定义测试用例。目前的开发项目经常的手段是研发完成后，再准备测试用例来验证功能的完整性，这种情况必然导致开发完成后与预计结果不符必然导致多次返工。正确的方法我理解应该是先定义出需要测试验证的点，然后在开发过程中把这些点考虑到，然后在开发完成后再次进行验证。必要的情况下引入专业测试人员来承担用例书写和验证工作。
问题2：沟通不顺畅
跨部门沟通不能有先入为主的概念，不能先假定自己是正确的，更不能对谁有偏见。事情是事情，情绪是情绪，想法是想法，解决事情就只谈事情，不能将所有的一切混为一谈。一切问题的解决以组织、制度为准绳，如果没有制度就以协商的结果或者由上级领导决策的结果为准，但决策未必是最佳的，也未必是正确的，但一旦形成决策就要执行，这件事结束了下一次就可以完善，避免再犯同样的错误或者遇到同样的问题。解决问题，越贴近通过组织、制度方式来思考团队才会获益更大，也会得到更大的支持，而不是频繁的与对方领导上报工作。
产品/项目经理、研发、测试是三个不可或缺的三个角色，三个角色各司其职才能保证整体性效率的提升。
目前的从组织、制度上的问题是？
- 接需求和测试验证的人员集中在少数一两个人，必然导致需求对接缓慢、验证延迟、沟通不畅。
- 研发人员不了解整体业务需求
- 研发模块工作划分机制有待优化
推测解决方式
- 划分更合力的组织结果，对产品、测试、开发各角色由不同的人来担任，做到边界内外分明，排除
- 是研发人员与测试人员都要了解整体的业务需求，理解整体的目标，测试人员提前准备好测试用例便于研发人员自测，规定好目标完成的标准是哪写测试用例通过；
- 模块内采用一人延期，全体受罚的方式；单一模块内所有人对所有内容都需要了解，当某人个人原因出现紧急情况时，有其它同事能够直接接替工作，不能存在由于一个人的个人问题影响进度的情况；
- 组织和制度的优化需要一个过程，逐步在团队可接受的范围内优化调整，且必须要有一个监督员的角色时刻提醒来保证整体不偏离轨迹；
问题3：缺少定期复盘
任务重，排期紧张等原因导致缺少定期复盘机制，但是复盘不可或缺，是一个团队提高效率的必然手段。
一次研发周期后需要对整体过程整体进行记录，复盘整体过程中哪个环节出现延迟、哪个环节提前完成。团队各自表达遇到的问题以及相应的解决方案，制定统一的优化方案。只有不断的优化，才能形成有战斗力的团队，个人也会更加感受到个人的价值。
小节
- 团队有明确的方向才能使团队具备合力效应
- 北京十一中校长李希贵提到：“能用结构解决的问题，就不用制度。能用制度解决的问题，就不靠开会”就像美国管理大师戴明所说：“一个组织中的员工问题，80%都是组织和系统自身的问题”。只要能成功地建立结构良好、机制健康的组织，领导者的用力会很轻。
- 优秀的团队和优秀的个人都是在不断的犯错、反思、优化当中不断前进的
相关阅读
- 需求研发/开发流程管理
- 敏捷开发Scrum是什么？
- 学校是如何运转的
|