对技术领导者来说,技术之外,更是有着广袤的世界亟待探索。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 驱动的公司和一个产品研发驱动为主的公司,大家的协作模式肯定是不一样的。没有好坏之分,适合自己的就好。
三、专业度:一个容易被忽略的问题
有一个容易被很多团队忽略的问题:团队之间,互相的抱怨或扯皮,其实很可能是大家在专业能力上是不够的。
一群不专业的人,协作上其实比较难取得高效的结果。比如,需求方能否比较清晰的描述你的客户需求,需求价值如何判断,如果经验和能力不足,是很可能把研发带坑里的;研发上如果需求的交付不能保证按时保质交付,业务方也很容易形成研发不给力的印象,或者沟通理解上的不到位也会带来一些不必要的误解。久之,双方都会互相不信任。
因此,专业是信任和协作的基础。在此基础上,才是协作磨合和方法论以及技巧的应用。
1
honeycomb 2017-07-04 11:14:31 +08:00 via Android
广告发错地方了
|