|
今天是12月1号，今年的最后一个月了，昨天我刚写完公司的年终报告。回顾这一年的岗位工作，其中有一个关于软件开发进度管理，值得拿出来分享、分享。 作为一名用户、产品经理、项目经理，你是否经常遇到方案确定完后，然后2周过去，1个月过去，半年过去，我啥也没看到，我好焦虑啊！那群敲代码的哥哥到底在干啥，做到哪了？ 对，今天就是来帮你解决这个问题，避免焦虑的。 一个软件项目的方案书，常常是一本皇皇巨著，几十上百页的文档。作为用户、产品经理的你，自己都看不下去，你觉得那帮程序猿哥哥看得下去吗（除非它有玄幻小说的精彩）？ 我告诉你，文档的本质作用有2个： 1、白纸黑字存档，关键时刻可以有理有据地撕逼，让对方哑口无言 2、工作的程序需要，为了符合公司制度、上级监管。 如果你有共识，我们再来看，实际要做事，应该什么样子的方案才是有效的？ 答案也无非2个： 1、清晰、易懂 2、有层次，具体做的时候，可以只看对应的内容。 假设你也有共识，那么什么样的形式、如何呈现可以达到这两个目标，应该一下子就清晰了吧？ 原型化！！！ 方案是啥？程序猿哥哥就做成啥样。开发人员在产品层可以0思考，只专注于开发层次考虑。 原型化要求你在方案里，有清晰的层次结构：那些是讲项目背景介绍？哪些是具体产品方案？ 在读你的方案时，要可以原子化呈现每个功能、页面。程序猿哥哥开发啥，就看对应内容就可以了，做到不遗不漏。 关于方案如何原型化，不在本次分享范围内，有兴趣，可以看看我之前写过的这篇产品设计的文章：2015年之前的2B产品都值得重新再做一遍（从用户体验上） 注意：一切非人为因素的开发问题，本质上都是方案书的质量问题。 1、按MVP原则，制定发版计划 上面产品经理做好方案后，下一步就是排出开发的版本计划。 一般来说对已有业务建设系统，除非明确是互相独立、互不影响的模块，否则方案应该尽量是完整的。但我们的实际开发不是简单地按方案书从头到尾开发，而应该考虑再对这份方案书进一步拆解。 这里会用到一个叫MVP的原则。我再一次拿出有趣的造车图，让你理解什么是MVP  上图是一般人理解的造车顺序，下图是产品人理解的如何拥有一辆车。 我们接着说说B端产品在MVP原则中的例子。以电商为例，我们购物的主线流程是：登录-看商品概要-看商品详情-点击购买-确认购买信息（地址、商品型号）-完成支付。 认真看看，这里没有分支流程：加入购物车。 也没有提到逆向流程：退款、退货 是它们不重要吗？ 不是的，但如果你想快速上线，就应该考虑优先顺序。比如可以先没有购物车，可以当遇到退货、退款的情况，留个操作入口就行（只要你的商品不是高退货、用户还不多，最简单的做法是：做个客服对话框）！ 如何理解MVP（最小可用产品）？就是指只要它能用就够了，用得舒不舒服是后面再考虑的事。很多非业内人士都想一步到位，一上线就要各种完美。换个角度想想，公司是靠软件赚钱？还是实际的业务？软件可能是一个新的销售渠道，或者是一套内部管理系统。所以你应该优先考虑投入产出比。 你想想早期的B端产品，哪个不是这么粗糙？ 有人说B端产品，一上线就要全流程闭环。你千万不要被这句话给误导。 B端产品确实有很强的业务属性，但是没有系统之前，人家业务也照样开展，你要做的是逐步替代一些人工的工作，不要神化系统的威力。 还以上面的电商为例，用户的流程闭环就是可下单、退单。你的MVP产品可以主要先做下单，然后为退单留个入口就行。 2、以敏捷开发的发版要求，2-3周发版1次 根据MVP选择排出方案功能的优先顺序后，就要基于排序来进行开发排期。 哪怕是上面说的最精简的下单主线流程，实际开发也可能要分多次完成。 注意：这里说的完成不是指上线，而是指内部开发发版与测试。 我们继续做一轮拆解：登录-看商品概要-看商品详情-点击购买-确认购买信息（地址、商品型号）-完成支付。 这个流程中，从登录到看商品详情页可以分为一段，从点击购买到完成支付可以分为一段。 开发评估工时时，需要有经验的开发工程师参与给出实际的时间，开发负责人还需要考虑人员、时间等资源，非常务实地、留有冗余地做出具体计划。 作为产品经理，你可以不需要了解开发每个功能为什么是这么多时间，但你要能看出整个计划表是否具备可解释性？比如行内对开发设计、前端开发、后端开发、测试的时间占比有个大致的标准，这份计划表有没明显偏差？ 再比如，同一类开发，为什么有的功能的时间特别长，工作量区别在哪？ 重要阶段是否有产出物作为衡量成功的标准？计划里是否考虑了这些？ 希望你认真看看我举的3项内容，这里没有一项干预开发人员的具体工作，但是它们合起来又对整个开发计划的实现至关重要。对，这里面有很深的底层逻辑：抓重点、有边界、看逻辑。 业内目前的敏捷开发模式（至于实际开发是瀑布或者其他方式不重要），一般按2-3周发版一次。我个人认为你的调研、设计是不是敏捷不重要，但开发发版应该满足敏捷。作为聪明人，你要善于吸取业内最佳实践的精华（开发是整个软件工程成本最高的环节，在这个环采用敏捷发版的价值最高）。 3、用开发方提供的每个发版计划，督促它完成。 每个版本的开发计划，在甲乙双方获得共识后，就应该严格按计划执行。 产品经理/项目经理要按照计划表里的细项具体跟进对应负责人，如有必要可采用每日站立会等方式（一般紧急项目的做法），或者每隔2-3天了解一次最新进度（应根据每个开发人员的尿性来考虑跟进频率）。 有个发版计划这把尚封宝剑，产品经理/项目经理就能名正言顺地跟进开发进度，因为计划前充分讨论，计划后充分执行，所以大家更愿意各司其职。 注意：按发版计划来正常开发，才是高级的做法。让那些不做提前计划，临时想插入的任务都往一边靠，久了之后，大家就习惯了如果新任务只能待下次安排，这才是真的践行PDCA管理思想。 注意：如果天天有紧急任务要插入，说明团队的规划、计划能力太需要加强了。 项目团队最好的状态是：一直在做重要不紧急的事。希望这句话没有戳中你的痛 |
|
|
