产品经理如何利用敏捷开发而不加班

前言：朋友吐槽他们公司效率低，经常加班呀，一天忙成狗，作为一个反对加班的人，对于他们这种行为我很鄙视，我从来不认为工作需要加班，需要的是流程化和高效率，那些天天忙成狗的人加班疯的人需要思考的是自己是不是那个流程有问题，朋友吐槽火力来自老板，就是那些整天只会指点江山不会做事的那些自以为掌握世界老板，对于他们我们尊重，听他说找出重点，任何事情都是可以沟通解决的。

我们经常遇到老板有一个想法，但并不能很好的描述需求，所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成，后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成，资深工程师进行把关，再到测试人员测试，最后再交付用户验收、技术维护。看起来很好的模式，开发了几个产品最终有的延时有的产品离用户的期望差距甚远，参与项目团队的人信心受挫。

为什么会失败呢？思考了这些问题：

1、技术总监不是产品经理，不能够承担产品设计的责任。老板是信任技术总监能做好产品，就交给他做。但这里搞混了一个概念，产品经理和项目经理，技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好，责任所在。说到底，就是机制没有把产品设计和项目经理区分开，不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

2、需求不稳定，变化后改动代价大。由于创业，需求为了适应市场会经常调整，但是一但调整，很多开发计划就会受到相应的调整。如果部分功能已经正在开发，调整需求后很多工作要重新开始，严重影响了技术同事积极性。业务不调整需求是不可能的，他们是为了满足用户的要求，用户满意了才能给企业带来价值。不过如果调整，代价太大，很多代码要重写，大家就会责怪技术总监或者项目负责人没有把握好需求。

3、同事技术学习，而新同事技能暂时还没有发挥出来干活效率低，任务经常延期，没有成就感。核心团队事情很多，没有时间整理项目文档，新员工没有文档上手慢。大家每天很多事情，需要加班才能完成，比较疲惫。每个人除了工作还有很多事情需要做，比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作，他能同意，他家人也不一定同意。让大家愉悦的开发，比疲惫的上班效率要高很多。

4、交付软件质量差，离用户期望差距大。创业时大家的想法都是好的，大干一番，做一个所有人都爱使用的产品。现实是残酷的，大家辛辛苦苦做出来的东西，老板不满意、用户不埋单，付出的努力没有人认可。交付的软件没时间自测试，或者自测试不充分，交给测试又是一大堆问题。有些公司还没有测试，直接出去给用户，相当危险。这样交出去的公司不仅仅影响了用户的使用，还影响了整个公司的口碑。

体制解放生产力

敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。

敏捷开发的主旨：（主要就是提升效率，加班真的很讨厌）

一：个体及交互比流程与工具更具价值

二：可用的软件比冗长的文档更有价值

三：与客户的协作比合同谈判更有价值

四：对变化的响应比遵循计划更有价值

而我们之前的问题，交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试，先看一张敏捷开发的流程图。

敏捷开发敏捷流程化

敏捷开发简单流程：

1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。（backlog可以理解为需求或者要做的事情）

2、召开产品backlog计划会议，预估每个backlog的时间，确定哪些backlog是需要在第一个sprint中完成的，即sprint的backlog。（sprint可以理解为一个团队一起开发的一个任务集合）

3、把sprint的backlog写在纸条上贴在任务墙，让大家认领分配。（任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上，这样大家都可以看得到任务的状态 ）

4、举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务。（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内）

5、绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了）

6、sprint评审会议是在sprint完成时举行，要向客户演示自己完成的软件产品

7、最后是sprint总结会议，以轮流发言方式进行，每个人都要发言，总结上一次sprint中遇到的问题、改进和大家分享讨论。

敏捷开发解决问题

怎么结合敏捷开发解决现有项目的问题，要记得任何措施都是为了保证按时按质按量把软件交付给用户，不要为了敏捷而教条实施敏捷，公司不能产生商业价值，任何先进的理念或者技术都是无意义的。

1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的，才能被认可。

首先培养测试小妹学习敏捷开发，后续让她承担部分产品责任人和敏捷指导者的角色，原因有：

a、测试要验收功能，必须理解业务需求。

b、测试也是QA质量体系的一块，学习好了对于软件质量有个更深的认识。

c、团队大部分是男生，女生推广更有亲和力一些。

召集所有技术团队开会准备推广。开始和测试小妹好好讨论下，怎么给大家说更有效，更容易接受。她要讲解一定要自己非常清楚敏捷开发，并且准备充分知识点。开会时先指出我们现在问题，让大家看看有什么想法解决问题吗？现在我们做的产品，客户不认可、老板不满意、自己很累没有成就感，有什么办法解决。在大家讨论后，抛出敏捷开发的优势，一般情况下大家都会认可的。大家可能会问到如何执行、落地，可以尝试找一个项目试点，如果实施成功就可以让大家全面推广，不成功也只影响了部分项目。

2、搭建敏捷开发环境。大家要实施敏捷开发，需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件：nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。

3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说，目的是完成这个项目，需要进行这几步：

先根据各自的能力和意向聚集一批完成这个目标的勇士，不管技术和非技术。如果聚集的人不够，技术总监可以根据总体项目的投入机动调整资源以支持，不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试，除去大家做其他事情的时间，总共可以算作4个人。

充分调动客户（老板和业务同事）参与进项目，他们的参与直接决定了项目成功与否。结合之前的经验，如果他们参与不够，最终做出来的东西就不是他们要的，或者离他们要的差距很大。他们刚开始加入的时候，很迷茫有时会表现的比较抗拒，这个时候一定要耐心坚持让大家把第一个sprint开发成功，使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化，如果有需求变化，就添加任务到任务墙，大家可以对所有任务的时间有个全面了解，如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。

技术总监安排和客户沟通，客户这里指老板和业务。测试小妹负责和客户沟通记录，技术总监辅助。多次沟通后，尝试让测试把需求原型用最简单的工具绘制出来，技术总监审核通过后和客户沟通确认，反复迭代，直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行，但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题，过度技术设计产品。

产品设计出来后，召集项目成员分解任务，确定每个任务的时间，可以使用敏捷扑克牌来估计。任务分解尽量控制在1-2天的粒度，这样大家1-2天就可以做出一个能测试的原型，尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周，不能太长，也不能太短。太长会出现疲劳，太短的sprint会让大家觉得工作太多，做完一个又一个。“项目1”估算结果为120人天，总共投入4个人，需要30天4周时间，我们切成了4个sprint，差不多1个月时间完成，满足业务的时间要求。

分阶段实施sprint，绘制任务墙，划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙，贴到未开始的地方。

每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务，统一管理起来。强调的是一个团体，如果有同事请假，其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题，对于当前的任务有什么建议，尽量控制在15分钟内，有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果，而是团队驱动，每天大家做的事情都反映在墙上，谁出现了什么状况，大家都会帮他想办法，保证整个项目能够成功。每一个任务完成，由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。

软件开发过程。认领任务后，怎么保证大家开发有质量的代码？团队有资深点的工程师，不需要太多指导，直接可以参与项目的开发。而学习型工程师，需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务，他负责开发团队的概要设计审核，没有审核通过的设计不能开发，并指导大家分析和设计系统。大家都知道，系统思路有了，剩下就是技术实现的过程，只要技能掌握熟练实现基本难度不大。大家可能会问，敏捷开发不是强调软件开发的产品是软件，而不是文档吗？我们这里也不是像传统开发软件一样为了文档而文档，只是让大家把自己的设计思路写下来，只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论，这样的文档是不欢迎的，受欢迎的文档只需写出用例分析，表设计，复杂的逻辑需要画出流程序列图。

结对编程。之前这个编程模式被无数人调侃过，其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时，会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时，很多时候都会结对，比如指导新同事、讨论设计模块，而之前这些都没有算在我们的开发工作量里。

项目演示和总结会议。在项目结束后，让所有参与项目的成员都参加，一起演示给客户展示，并解答客户的问题，充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享，并为下一个sprint做准备。

经过敏捷实施后，我们的生产力提高了很多，员工的积极性提高了，业务的参与使整体需求把控也很好，大家沟通多了，30天的任务提前了5天完成。我们多出来的时间，让大家每周有一天或者半天研究自己感兴趣的领域，但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术，最后做完需要写个ppt给大家分享下。既能让大家做自己想做的事情，也给大家创造了一个互相学习的氛围。

ps：所有的模式都不应该是教条的模式，先进的模式并不是好的模式，适合自己的才是最好的。套用一句俗话：不管黑猫白猫抓得住耗子的才是好猫。

小哥哥、小姐姐扫码下图二维码加我私人微信，大家一起约个产品聊聊吧，不接受人生指导（比如如何三天成为产品经理）不接受价值观讨论，只聊产品聊生活聊世界。