技术部门如何对业务、客户的新需求进行取舍,做到优雅相处?
2017-07-04 11:28
746 查看
对技术领导者来说,技术之外,更是有着广袤的世界亟待探索。2017年,第二届全球技术领导力峰会(GTLC)以“探索圆外的世界”为主题,邀请互联网及传统行业权威技术领袖,分享他们关于技术、关于行业、关于商业、关于投资、关于领导力的实践与见解。
云片CTO林佳齐出席峰会并带来他的思考与总结。
云片CTO(左三)与众技术领导人合影
一、整体战略层面,各个角色对技术要有统一的认知
首先,技术是驱动业务增长和公司长远发展的核心竞争力。
很多嘉实分享的领导之道已经提过,一个公司的CEO、管理层、业务方如何看待技术,会决定一个公司能走多远做多大。比如有嘉宾提到:技术人应该主动做出角色变化,成为驱动业务增长的引擎,甚至要引领业务的创新和变革。而更为激进的观点认为,CEO不能对技术不关心不重视,也不能神化技术认为技术无所不能,需要沟通理解技术的价值。因为技术才是引领公司走向未来的核心,才是业务10X、100X增长的决定因素。
在公司战略意识层面,各个角色需要对技术有统一的认识,需要依靠大家的互动沟通去理解技术的战略地位。
其次,技术必须要服务于业务,业务驱动技术往前发展。
当今企业之间的竞争,对技术人特别是技术的管理者提出了新要求,需要学会从客户、业务、商业的角度去看问题。认识到业务增长会带动技术的革新,技术存在价值依赖于它为业务创造的价值。
从大的层面上讲,技术和业务不是对立,而是统一的。我们通常把需求方或业务方和产品研发割裂的思想需要统一,公司的目标需要统一,包括资源投入、考核管理上统一。
二、项目管理层面实践方向的经验分享
经过来自各行业,不同规模的公司,负责不同角色的队员讨论,产出了非常具有实用价值的项目管理层面的实践经验。包括:
需求调研:项目组中的多个角色可以一起参与,包括业务方、实现方,大家对需求的重要性理解在前期就可以共同决策;对不合理的需求,在前期就由产品经理跟客户进行沟通过滤筛选。
需求的风险评估:是一句话需求(这种需求最害人,一句话研发可能就要加班一个晚上)?有没有MRD/PRD?经过流程评审?不同部门需求冲突时有没有合理的PK。
需求优先级如何评定:排期能否跟业务方一起评审达到共识?
研发节奏:能不能借用现代的迭代模式,类似scrum等工具,把需求管理做得透明,提升沟通效率。
结果跟进、反馈和复盘:对业务方提的需求是否合理,对研发交付的效率和质量定期有反馈和复盘,让大家关注结果。比如有多少需求实现之后其实是没有带来价值的,从而督促双方能更谨慎的思考。
同时,不同公司规模、行业、人员特点和管理模式,需要结合自身的特点选择自己合适的模式。一个Sale/Marketing驱动的公司和一个产品研发驱动为主的公司,大家的协作模式肯定是不一样的。没有好坏之分,适合自己的就好。
三、专业度:一个容易被忽略的问题
有一个容易被很多团队忽略的问题:团队之间,互相的抱怨或扯皮,其实很可能是大家在专业能力上是不够的。
一群不专业的人,协作上其实比较难取得高效的结果。比如,需求方能否比较清晰的描述你的客户需求,需求价值如何判断,如果经验和能力不足,是很可能把研发带坑里的;研发上如果需求的交付不能保证按时保质交付,业务方也很容易形成研发不给力的印象,或者沟通理解上的不到位也会带来一些不必要的误解。久之,双方都会互相不信任。
因此,专业是信任和协作的基础。在此基础上,才是协作磨合和方法论和技巧的应用。
云片CTO林佳齐出席峰会并带来他的思考与总结。
云片CTO(左三)与众技术领导人合影
一、整体战略层面,各个角色对技术要有统一的认知
首先,技术是驱动业务增长和公司长远发展的核心竞争力。
很多嘉实分享的领导之道已经提过,一个公司的CEO、管理层、业务方如何看待技术,会决定一个公司能走多远做多大。比如有嘉宾提到:技术人应该主动做出角色变化,成为驱动业务增长的引擎,甚至要引领业务的创新和变革。而更为激进的观点认为,CEO不能对技术不关心不重视,也不能神化技术认为技术无所不能,需要沟通理解技术的价值。因为技术才是引领公司走向未来的核心,才是业务10X、100X增长的决定因素。
在公司战略意识层面,各个角色需要对技术有统一的认识,需要依靠大家的互动沟通去理解技术的战略地位。
其次,技术必须要服务于业务,业务驱动技术往前发展。
当今企业之间的竞争,对技术人特别是技术的管理者提出了新要求,需要学会从客户、业务、商业的角度去看问题。认识到业务增长会带动技术的革新,技术存在价值依赖于它为业务创造的价值。
从大的层面上讲,技术和业务不是对立,而是统一的。我们通常把需求方或业务方和产品研发割裂的思想需要统一,公司的目标需要统一,包括资源投入、考核管理上统一。
二、项目管理层面实践方向的经验分享
经过来自各行业,不同规模的公司,负责不同角色的队员讨论,产出了非常具有实用价值的项目管理层面的实践经验。包括:
需求调研:项目组中的多个角色可以一起参与,包括业务方、实现方,大家对需求的重要性理解在前期就可以共同决策;对不合理的需求,在前期就由产品经理跟客户进行沟通过滤筛选。
需求的风险评估:是一句话需求(这种需求最害人,一句话研发可能就要加班一个晚上)?有没有MRD/PRD?经过流程评审?不同部门需求冲突时有没有合理的PK。
需求优先级如何评定:排期能否跟业务方一起评审达到共识?
研发节奏:能不能借用现代的迭代模式,类似scrum等工具,把需求管理做得透明,提升沟通效率。
结果跟进、反馈和复盘:对业务方提的需求是否合理,对研发交付的效率和质量定期有反馈和复盘,让大家关注结果。比如有多少需求实现之后其实是没有带来价值的,从而督促双方能更谨慎的思考。
同时,不同公司规模、行业、人员特点和管理模式,需要结合自身的特点选择自己合适的模式。一个Sale/Marketing驱动的公司和一个产品研发驱动为主的公司,大家的协作模式肯定是不一样的。没有好坏之分,适合自己的就好。
三、专业度:一个容易被忽略的问题
有一个容易被很多团队忽略的问题:团队之间,互相的抱怨或扯皮,其实很可能是大家在专业能力上是不够的。
一群不专业的人,协作上其实比较难取得高效的结果。比如,需求方能否比较清晰的描述你的客户需求,需求价值如何判断,如果经验和能力不足,是很可能把研发带坑里的;研发上如果需求的交付不能保证按时保质交付,业务方也很容易形成研发不给力的印象,或者沟通理解上的不到位也会带来一些不必要的误解。久之,双方都会互相不信任。
因此,专业是信任和协作的基础。在此基础上,才是协作磨合和方法论和技巧的应用。
相关文章推荐
- 在需求采集时,如何对客户的需求进行分类
- [转载]给IT人员支招:如何跟业务部门谈需求分析?
- 思路,如何快速应对客户提出的业务需求
- CTO如何避免决策失控(四)——通盘考虑 做到技术业务不分家
- [技术管理]如何做到业务迭代和技术积累的平衡?
- 给IT人员支招:如何跟业务部门谈需求分析?(上)
- 如何理解客户需求、市场需求、产品需求、业务需求、特性、功能需求 ?(转)
- 业务、客户、数据:创新动态技术如何保障科技金融的安全未来
- 如何根据客户需求做到DSP投放广告,精准广告投放?
- 自第N次改需求后,如何权衡业务需求与技术交付?业务方策划了一个宏伟的蓝图,只给你和你的团队一个改BUG的时间开发。阿里效能平台技术专家之岳邀你有奖来聊。
- 需求管理之如何对客户的需求进行分类
- 如何理解客户需求,市场需求,业务需求,功能需求,产品需求,设计需求?
- 给IT人员支招:如何跟业务部门谈需求分析?(上)
- 如何鉴别业务部门表达的需求与真实的需求?(温州传奇13)
- 需求:没有技术做不了的,只是时间问题,我们是服务部门,客户说怎么样那就怎么样了.
- 基于网格技术的计算能力提供—对GridASP有效业务处理进行概念证明实验的开端
- 国内ERP开发模式――如何看待客户的需求
- 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更
- 如何进行界面和业务逻辑分开的原型化开发