本文整理自 58 同城技术委员会主席沈剑在 QCon 2017 北京站上的演讲，原题为：《业务端技术团队真的痛？》本文将为你详细分析业务端技术团队的各种常见痛点。

技术团队的痛处

团队是指一种为了实现某一目标而由相互协作的个体所组成的正式群体。是由员工和管理层组成的一个共同体，它合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。团队建设是企业在管理中有计划、有目的地组织团队，并对其团队成员进行训练、总结、提高的活动。

在本次演讲中，我将讲述的主题是业务端技术团队所存在的痛处，我将介绍其业务团队在带队过程中可能遇到的一系列问题，之后结合自身经验与大家分享。问题如下：1、和 PM 为何不能愉快的玩耍？2、和 QA 为何不能愉快的玩耍？3、压力大、项目做不完、永远加班做业务怎么办？4、Bug 多、质量低、永远加班该 bug 怎么办？5、人员流动率高，真的是因为没有技术含量吗？

1、PM 相处篇

1 目标一致

与产品经理相处存在的最普遍问题在于目标不一致，最典型的例子是 KPI 的制定、产品团队 KPI 指标的考核。产品团队、运维团队等 PM 的绩效指标在于 PV 的增长量、UV 的增长量。公司业务团队 KPI 如何考核？技术团队的 KPI 一般标准如何确定？技术团队负责质量，产品团队负责业务指标，假设当时产品团队提出一个功能需求，完成此功能可提升其 PV 和订单量，技术团队对其进行评估发现，由于其高复杂性会对已有信息造成大的冲击，并且这一更改会导致系统的不稳定性，或者说需要较长的时间更改它。那么怎么办，为何会出现这种情况？

其主要原因在于目标不一致。如何协调两者之间的关系？举个例子，产品经理和技术经理在讨论问题，产品经理觉得技术经理的团队技术并不支持他们的产品，导致他们不能达到目标；而技术经理却认为，如果他们的技术支持了产品会导致他们自己的目标达不到。为了防止此类现象的经常性发生，他们应该在业务开展开始前便达成一致目标，因为这是一个自上而下的过程。一个团队组织架构是业务团队的闭环，内部有产品技术部、测试部。而有些团队组织架构内部包含的是产品部、技术部、质量部，若其以业务单元为组织架构可能不会存在目标不一致的问题，但若其以职能为组织架构却可能发生该类问题。

但是，即使是这样的组织架构，在目标上仍然需保持一致，在创业阶段更需要保持业务优先原则。因此，一定要确保产品团队与技术团队达成目标一致性。一损俱损，一荣俱荣。对于目标不一致的解决方案，以业务指标为第一目标，然后统一目标，统一 KPI。为达成一致目标需要 PM 负责人以及业务团队达成共同意识，否则各自完成各自目标，结果终究是对立的，他们不仅需要实现业务，还需要对系统的稳定性和质量负责。

初期的快速迭代可能因此不会考虑太多设计层面的问题，或者说初期的架构设计适应了当期数据量、并发量和业务迭代速度。但随着时间的推移，业务发生变化，并发量、数据量持续上涨，系统架构不再能够支撑，而这时便需要技术团队进行技术改进的项目，尽管这可能与业务功能实现无关。

举个例子，APP 重构，58 到家有多家 APP 商家、用户端以及司机端等，一开始为了追求速度，招聘 3-5 人形成一个团队进行开发，后来发现我们可以进行分层抽象和沉淀公共组件，以此提高开发效率。数据层也是同理，后端做服务端，web 端访问数据库，加入缓存，使得架构结构更加合理。我们最初采用 AM 线和 CM 线各自账号体系的登入方式，后来业务方向发生变化，因此开始改做平台方向，但我们存在跨业务线登录的需求，即 SSO 的需求，统一进行技术优化的项目。

然而当我们拿着技术改进项目与产品团队沟通时，沟通结束之后双方都可以达到自己的期望与预期吗？举个例子，技术同学花费两个星期时间进行技术优化，产品同学却说这个月我有非常重要的运营项目，我需要运营 PV 和 UV 来完成自己的业务指标，由此得出，产品同学并不理解技术改进、技术优化。那么如何达成一致性？第一为达成一致目标，为指标负责。作为一名技术人，都想要达到 PV 高、技术好、流量涨的目标。如果产品经理与我的总目标一致，那么当我说服产品同学为我做这些事情时会更简单，因为总目标一样，产品同学理解起来会更加容易。

2 数据说话、以理服人

目标一致、数据说话、以理服人。该采纳的建议是什么？