部门冲突的日常

每个研发团队，或多或少都经历过部门之间的摩擦。比如产品经理认为开发进度太慢，开发人员抱怨需求变动频繁，测试团队又希望更早拿到稳定版本。这些小冲突，久而久之会影响士气和效率。我们团队也曾陷入类似的局面：一个新项目启动三周，会议越来越多，大家在会议室里争论不休，最后连决策都变得模糊。

目标管理法的点滴尝试

有一天，团队主管小李说：“我们是不是该试试目标管理法？”其实大家对这个词并不陌生，但总觉得它离实际工作很远。

小李没有强推什么软件或者模板，而是拿了张白纸，写下了项目的最终目标，然后请产品、研发、测试各自填上他们的关键目标。比如产品写的是“上线后一个月用户留存率达到60%”，开发写的是“后端API响应时间低于200ms”，测试则是“上线前发现的关键性bug数低于5”。

关键词的共识

目标管理法的本质，是让大家围绕共同目标，拆分每个人的子目标和关键结果（KR）。我们没有用OKR软件，也没用复杂的仪表盘，只是每周例会上，把这些目标贴在白板上，逐条讨论进展。

每次发现冲突，比如开发觉得测试提出的用例太多，双方就以目标为准绳：“我们是为了上线前bug数低于5，现在测试用例数量确实需要增加。”这样一来，讨论变得更聚焦，争论也少了很多。

经验与教训

起初，有人觉得目标管理法太理想化，实际推进时还是会有主观分歧。比如产品的目标和开发的目标有时难以量化，或者测试的目标和资源分配冲突。我们一度陷入“目标太多、太细、太分散”的困境。

后来，我们逐步调整：只把最重要的三到五个目标贴在白板，避免目标泛滥。每个目标下，必须有可衡量的关键结果，哪怕是最简单的数字。

此外，我们开始尝试用Trello做目标追踪，把每个目标拆分成任务卡，每周更新进度。虽然没有复杂的管理软件，但用看板视图，大家能直观看到哪些目标在推进，哪些还停滞。

一次小故事

有一次，测试小王发现一个影响核心流程的bug，距离上线只剩三天。照常规流程，开发会认为这属于“太晚发现”，但因为我们的目标明确：关键bug必须低于5。于是大家没有推诿，而是一起加班修复。最终，目标达成了，也没人觉得自己“吃亏”。

小结

这次用目标管理法处理部门冲突，虽不是一套完整的OKR流程，但已经让我们的团队氛围和效率大大提升。最重要的经验是：

• 目标不宜太多，关键结果必须可衡量
• 目标公开透明，争论有据可依
• 工具不需复杂，简单白板或看板就能起效

这些细节上的变化，让我们的小团队在项目推进时少了争吵，多了协作。其实，管理方法不在于多么高大上，关键是能用在实际工作中，解决具体问题。