技术部门如何对业务、客户的新需求进行取舍，做到优雅相处？

[yunpian2017]

对技术领导者来说，技术之外，更是有着广袤的世界亟待探索。2017 年，第二届全球技术领导力峰会（ GTLC ）以“探索圆外的世界”为主题，邀请互联网及传统行业权威技术领袖，分享他们关于技术、关于行业、关于商业、关于投资、关于领导力的实践与见解。

云片 CTO 林佳齐出席峰会并带来他的思考与总结。

https://www.v2ex.com/i/or8CoSYS.jpeg

云片 CTO （左三）与众技术领导人合影

https://www.v2ex.com/i/iWkMMpo1.jpeg

一、整体战略层面，各个角色对技术要有统一的认知

首先，技术是驱动业务增长和公司长远发展的核心竞争力。

很多嘉实分享的领导之道已经提过，一个公司的 CEO、管理层、业务方如何看待技术，会决定一个公司能走多远做多大。比如有嘉宾提到：技术人应该主动做出角色变化，成为驱动业务增长的引擎，甚至要引领业务的创新和变革。而更为激进的观点认为，CEO 不能对技术不关心不重视，也不能神化技术认为技术无所不能，需要沟通理解技术的价值。因为技术才是引领公司走向未来的核心，才是业务 10X、100X 增长的决定因素。

在公司战略意识层面，各个角色需要对技术有统一的认识，需要依靠大家的互动沟通去理解技术的战略地位。

其次，技术必须要服务于业务，业务驱动技术往前发展。

当今企业之间的竞争，对技术人特别是技术的管理者提出了新要求，需要学会从客户、业务、商业的角度去看问题。认识到业务增长会带动技术的革新，技术存在价值依赖于它为业务创造的价值。

从大的层面上讲，技术和业务不是对立，而是统一的。我们通常把需求方或业务方和产品研发割裂的思想，需要统一，公司的目标需要统一，包括资源投入、考核管理上统一。

二、项目管理层面实践方向的经验分享

经过来自各行业，不同规模的公司，负责不同角色的队员讨论，产出了非常具有实用价值的项目管理层面的实践经验。包括：

• 需求调研：项目组中的多个角色可以一起参与，包括业务方、实现方，大家对需求的重要性理解在前期就可以共同决策；对不合理的需求，在前期就由产品经理跟客户进行沟通过滤筛选。

• 需求的风险评估：是一句话需求（这种需求最害人，一句话研发可能就要加班一个晚上）？有没有 MRD/PRD ？经过流程评审？不同部门需求冲突时有没有合理的 PK。

• 需求优先级如何评定：排期能否跟业务方一起评审达到共识？

• 研发节奏：能不能借用现代的迭代模式，类似 scrum 等工具，把需求管理做得透明，提升沟通效率。

• 结果跟进、反馈和复盘：对业务方提的需求是否合理，对研发交付的效率和质量定期有反馈和复盘，让大家关注结果。比如有多少需求实现之后其实是没有带来价值的，从而督促双方能更谨慎的思考。

同时，不同公司规模、行业、人员特点和管理模式，需要结合自身的特点选择自己合适的模式。一个 Sale/Marketing 驱动的公司和一个产品研发驱动为主的公司，大家的协作模式肯定是不一样的。没有好坏之分，适合自己的就好。

三、专业度：一个容易被忽略的问题

有一个容易被很多团队忽略的问题：团队之间，互相的抱怨或扯皮，其实很可能是大家在专业能力上是不够的。

一群不专业的人，协作上其实比较难取得高效的结果。比如，需求方能否比较清晰的描述你的客户需求，需求价值如何判断，如果经验和能力不足，是很可能把研发带坑里的；研发上如果需求的交付不能保证按时保质交付，业务方也很容易形成研发不给力的印象，或者沟通理解上的不到位也会带来一些不必要的误解。久之，双方都会互相不信任。

因此，专业是信任和协作的基础。在此基础上，才是协作磨合和方法论以及技巧的应用。

[honeycomb]

广告发错地方了