V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yunpian2017
V2EX  ›  推广

如何对业务、客户的新需求进行取舍?

  •  
  •   yunpian2017 · 2017-07-05 17:26:56 +08:00 · 1939 次点击
    这是一个创建于 2681 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    以上内容来自云片 CTO 林佳齐第二届全球技术领导力峰会林佳齐出席峰会的思考与总结。

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3432 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 11:29 · PVG 19:29 · LAX 03:29 · JFK 06:29
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.