传统项目管理, 无论是典型的软件销售服务类型还是互联网软件公司在过程管理中, 通常是从需求输入开始这当中造成的误判范围过度承诺信息传递变形甚至黑洞的情况屡见不鲜无论企业中是否有诸如 PMO 或是项目管理委员会这样的组织, 大多数都忽视了需求并非凭空而来, 从组织和成本角度上去, 无论是创新类公司还是拥有成熟市场的公司, 都应当把需求从售前 (需求产生) 之时进行度量和梳理有一句老话假设 (需求) 什么都不是, 只有当它能够被证伪或证实, 才有价值, 有了价值, 才会有去实现的必要
敏捷对售前 (需求价值) 的局限
传统的敏捷宣言, 只关注了在项目过程中, 团队如何保证需求价值的实现, 如何交付价值即敏捷首先假设的是这个项目 (需求) 的价值是存在的, 依据这个价值依据, 在项目过程中持续交付可评估的产品, 以达到接近用户真实需求价值的目标
我们不妨追问一下敏捷的本质是什么, 敏捷宣言的核心价值告诉大家是如下四条
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
就这四条核心价值来讲, 更加贴近于软件开发中的过程管理就真正的项目全生命周期来看, 敏捷忽视了项目启动之前的价值假设过程, 如果这个需求的价值假设在商业模式 or 成本预期 or 客户(运营)YY 之上的, 你再怎么努力敏捷也不过是多走几步还是少走几步掉坑的结局罢了大家扪心自问一下, 你所从事的敏捷项目, 有多少是从开始就将商业价值和企业目标与敏捷项目结合起来进行管理的
软件开发团队通常重视的项目的成功交付和验收, 而非项目是否真正为企业 (用户) 创造了价值无论是项目型公司还是互联网公司, 开发团队通常在短期上对项目交付最重视, 而从长期看, 交付一堆没有达到预期价值甚至毫无价值的产品 (功能) 时, 对团队的损害要远远超过尽早识别不具备价值不需要交付的危害
那么如何将敏捷扩展到项目启动之前, 进行项目全生命周期的敏捷管理呢这个问题, 目前有一个流派, 就是将精益思想与敏捷相结合, 将企业的价值目标与敏捷过程管理相结合, 将商业价值与团队动态管理相结合, 重视产品交付价值本身而非项目成功, 双方共同在价值最大化的目标和框架下协同工作通过精益思想的 7 项原则, 很大程度上避免了敏捷对企业 (用户) 价值层面的假设推论确认过早的问题
这几个原则的重要性依次如下
1 尊重人
这里的尊重人, 来自于精益和敏捷思想中的核心: 相信创新来自于人的主动性, 而非机器即使是在精益的发源地丰田, 这个流水线的工厂内, 也奉行人的主观创造力是第一生产力的观点反观国内的互联网公司和创新工场, 管理层和创业团队很少去主动将价值传递到研发团队很多研发团队也是接到需求就开始评估怎么做, 不问为什么做, 也从来不问价值, 就算问了, 也只是要求排个优先级而已这种对企业价值和商业本质的漠视, 也导致了技术团队缺乏大局观, 而只是反过来要求产品做出一个不靠谱的年度规划来预估架构上的合理性放眼目前的商业环境, 都是在不停的市场契机中发现商机, 如果靠产品经理或是公司老大就能正确的判断公司未来一年的产品路线, 那为什么整个中国成功的公司还就是那么几家? 做正确的事, 永远比正确的做事更重要
从尊重人的角度出发, 公司的管理层首先要放低姿态, 承认自己也会犯错, 并将商业目标和价值要求, 通畅地传达到研发团队而研发团队在面对需求时, 需要多问几个为什么要做, 敢于质疑价值不明确的需求
目前在我所在的公司, 推行的是对于大中型需求, 需要提供商业画布和价值时分表, 通过这两个文档的讨论, 明确需求的价值和实现的急迫性, 并从中提取需求实现后的上线跟踪指标这两个工具来自于精益创业这本书感兴趣的童鞋, 可以去看看这本书, 很经典
2 消除浪费
在我们做一项商业决策时, 往往是凭借过去的经验和有限的试验及数据做出的假设这本身没有错, 而往往人们犯的错误就是: 忽视了验证这个假设能够承受多大的成本合适的时间, 用合适的成本去做合适的事, 这也是风口上的猪也能飞那句话原本的意思
说道理有点枯燥, 举个例子吧:
我所在的公司, 曾经在 B2B 快消品市场上, 投入过一个业务员端的产品当时这个产品是给公司内部业务员用的, 在开拓外区市场时, 根据市场人员的调研和相关领导的从业经验, 一致觉得外部快消厂商和经销商是需要这个产品的所以咯, 二话不说, 为了抢占先机, 为了做那个风口上的猪产品率先将业务员端做了改造, 适配了外部经销商和厂家业务员的模式, 还没等投入到市场, 这个项目就因为种种原因而收缩, 取消了与外部的合作还好当初留了个心眼, 只做了个简单的适配, 但也耗费了一个迭代 (三周) 的成本从敏捷来看, 项目本身一点没有问题, 但从商业价值来看, 成本的浪费不言而喻
可能大家看到这里, 会有很多疑问: 唉, 商业价值又不是研发说了算的, 领导决定的啊, 运营的锅啊, 产品的债啊但回想一下, 如果敏捷不能创造价值, 那团队的价值如何体现?
因此, 当我们在假设一个价值目标时, 要遵循的是成本最小和决策推迟原则譬如, 先来遍线下先行的验证怎么样, 我堆两个实习生天天收集数据在 excel 统计分析后, 发在厂家和经销商的业务员的微信群可不可以这样浪费的成本孰高孰低, 一目了然, 行不通止损也快也不用后面我们又要考虑把这一套代码下线, 避免后续还要付出维护成本要来得划算
3 推迟决策
推迟决策并非官僚, 也不是将责任推诿至他人, 而是因为太多拍脑袋和屁股所做的商业决定所带来的高昂实现成本, 造成了大量的浪费而提前决策恰恰违反了第 2 条的消除浪费
推迟决策的时间点: 决策的最佳响应时间点是指, 做出决策的成本跟推迟决策造成的损失大致相当的时间点
推迟决策的实践: 在敏捷中, 有一个推迟决策的最佳实践: 真实期权听起来挺拗口, 下面简单解释下
期权大家都知道, 而真实期权大家拆成真实和期权两部分来看, 即针对项目在分阶段投入成本的情况下, 我们需要有在特定条件下的对各阶段所拥有的三种投资成本的方式: 一是放弃投资(即条件不成熟); 二是继续投资(即达到此阶段的约定条件); 三是重新评估未达到的条件, 决定是否变更条件或减少投资规模这些实践, 有部分来自于金融期权的数学模型, 有部分来源于决策心理学归根结底, 是指在决策时, 需要满足事先约定的条件并了解决策所需要的原因后, 再做决策真实期权的终止日是条件性的而非契约性, 你可以延后期权的终止日, 直到发现最优解, 从概率上来看, 推迟决策要比提前决策更能提供价值
举个例子: 公司即将开始一个全新的平台引流项目, 我们有一个商业目标, 希望通过产品来实现日均 50 万的 PV 和>=10% 的订单转化率, 公司以前没有类似的经验可以借鉴, 即使有人有相应的经验, 在这个平台上也从未实践过
传统意义上的项目, 应该是开始商业计划书, 然后 PRD, 然后项目实现并上线验证在这里, 就埋下了决策陷阱: 一开始的目标推导出来的商业计划书中的成本产生的 ROI, 顶多是个估算, 谁来为估算的决策埋单? 我相信没有一个人是有 100% 的信心和承诺去做这个决策的, 即使是计划做得再好, 凭经验做出来的也满足不了随时变化的市场和社会环境的变化那些商业大 V 给的无非是天花乱坠的计划如何做得详细分解, 而这并非投资的最佳路径
真实的世界里, 我们要将决策带来的成本损失减到最少因此, 好的做法, 在面对一个不可知的目标时, 是将目标拆分成不同的阶段, 这个项目因为未知因素太多, 但又需要快速推进的话, 应该是在商业计划成型之前, 做一次小规模的验证, 这个验证应该是针对特定的极少部分种子用户, 并利用现成的最小化成本 (H5 工具生成的落地页现有平台产品的简单对接) 去实现, 观察预定的指标, 总结是否需要调整变现路径和方法, 再形成完整的可推论的商业计划 (BRD) 并划分阶段和成本, 然后才是分阶段实施的 PRD 和条件有了这样一个先验过程并将阶段验证条件做为下一阶段的决策依据, 才能更好的迎接在过程中不断变化的问题, 并最终以最合理化的成本和收益达到项目目标(虽然项目目标可能会调整, 但也是基于真实验证下的调整, 而且成本并未浪费)
因此, 推迟决策并非不决策, 而是在有先决条件下分阶段去实现项目目标, 决定是继续按计划做, 还是终止, 或是变更下条件适当投入再看看
任何一本软件工程教材都会告诉你: 假设在分析阶段找到并解决一个错误的成本为 1, 在设计阶段解决同一个错误的成本就变成 10, 在实现阶段就变成 100, 在维护阶段就变成 1000 敏捷软件开发中的真实期权实践正是为了避免不正确决策所带来的浪费
4 创建知识
在敏捷团队中, 传递知识是一项细微并且不会短期内看到收益的工作但是一旦真正建立了一个人人愿意维护的知识库, 哪怕这个知识库是存在于代码的规范性注释之上, 带来的收益和价值往往随着时间的推移而越来越有价值
这里需要说明的是, 团队需要有一些激励机制和自己总结的适用方法, 利用现有的知识构建工具譬如 wiki 规范化代码注释甚至是文件服务器上, 将知识点先沉淀上去, 再进行归纳和分类后, 从而进行提取再加工, 并落实到由这些知识点产生的改良活动中, 并再反馈到知识库中
这需要领导者鼓励并长期关注知识库的质量, 并激励团队做出知识贡献, 打造学习的氛围
而对于进入项目前的售前和需求分析过程, 往往借助的是知识库中的两个类别的知识: 项目度量风险库
在实际知识沉淀过程, 需要特别注意这两个方面知识的总结和归纳, 并交待好事件的前因后果和 Action 的结果项目度量可以帮助分析和市场人员, 大致的评估项目成本和周期 (在乐观和悲观两个维度下) 而风险库, 是在项目启动前一次最好的检验项目风险的实践活动, 并且, 随着知识库中风险点不断的积累和归纳, 检查的清单会越来越详尽, 会尽可能的让你避免拍脑袋决策所带来的失败因子
5 快速交付
一旦决策下达, 团队的快速交付就显得重要了这个阶段其实就是一个核心 "尽早持续交付有价值的软件, 是我们满足客户的最优先考虑" 这个阶段中, 尤为重要的是需求分析成功的项目各有不同, 但失败的项目却总是那么相似这当然是句无限抽象的戏说, 但需求分析的偏差和模糊往往是重要的原因回到本章的重点, 快速交付在敏捷的售前阶段好像没有任何关系, 但如果我们把任何一个项目阶段 (售前立项分析设计实现部署运维) 拆开来看, 每个阶段其实都有交付, 而且仍然可以围绕尽早持续交付有价值的软件这一核心
举个例子:
某大型证券公司, 我们有多个团队为此公司进行项目开发甲方决策人, 通常希望看到有成型的可演示 demo 才决定是否由我们承接, 这个过程在以前, 会由乙方团队赶鸭子上架一样在现有框架和平台下搭一个按甲方领导意思想看的 demo, 往往还涉及到需要走一些简单的设计和测试工作, 等花上一周甚至两周多给领导看时, 还要担心会议上是否时不时报个错, 会不会在会议上又提出新的想法后来, 我们经过讨论, 发现人家根本不关心你这套 demo 后面是否有真实的数据进入系统, 就是看看点击后界面的交互和跳转是否按他的想法来, demo 中有没有更好的亮点或解决思路想通之后就简单了, 改用 axure 上吧, 对于有比较复杂的逻辑和流程要求的, 实在不行就用静态页面整, 也比要构建一套需要持久化数据的系统快, 毕竟客户只看效果才决定接下来是不是交给你做这样我们不仅将演示周期缩短到了平均三天左右, 而且反馈给客户的速度相应的大大提高, 客户的满意度也上来了, 会上有个什么改动, 回来后调整下原型, 也顶多就是半天的时间而已
6 品质为先
敏捷强调通过测试驱动自动化工具建立可持续化日常化的质量检测方法在售前工作中, 我们需要避免的是销售人员为了迎合客户需求, 漫天画饼却给出一个奇低的价格
因此, 在售前阶段, 销售的方案和 demo 必须要和技术团队中的负责人过一下, 并且通过知识库判断大至的成本关于成本判断的方法, 后续章节会有一篇专门介绍
一个有说服力逻辑严密的售前方案, 对客户来说一是意味着有落地的把握, 二是解答了从目标到实现的各个清晰的路径 (目标范围业务逻辑分析模块分析难点分析项目管理分析项目预估算), 三是回答了项目中确实存在的大机率风险如何避免如果不能成, 并不代表你的价格不合适, 只是因为其它非商业原因而落选(你懂的) 相反, 借助这些有质量的方案, 当客户真的想做点有价值的事情时, 一定会考虑你, 所以你在后续还有大量的高价值项目可以介入
7 全局优化
有关于精益管理的介绍, 请点击我的另一篇培训文章精益产品思想同时放上一个参考链接: 精益的智库百科链接
来源: https://www.cnblogs.com/georgehu/p/8299364.html