项目管理

图片来源：link 摘要：当我们要考虑如何让项目不延期时，我们是否做到让每个员工都满负荷了？我们追求的是不延期，还是追求更卓越的产品？ 这一两个星期和同事讨论如何使用看板进行项目管理时，总的来说，我遇到最频繁的问题有： 如何能看出项目是否延期？ 如何拆任务？ 其实，我遇到的问题是：如何能看出项目是否延期？然后经我将问题深挖，才发现他们更本质的问题是：拿到需求，如何拆任务，拆到什么粒度。 讨论这类问题，最好举个例子，否则整个讨论过程会很虚。 比如我们的项目经理从产品经理那里拿到一个需求：改版APP。这款APP有12个界面，所有的界面都需要改。而你手下有6个人。 这时，可以以两种粒度来拆分： 以界面为粒度 拆分成更可以量化的粒度。 关于什么是可以量化的粒度，下文会阐述。 按界面粒度来拆分 可以看出，以界面粒度来拆分，简单粗暴：24人天的任务，我们有6个人，所以，理论上我们只需要4天完成“改版APP”。我们可以很容易看出这个项目是否延期，只要每个界面都没有延期。 放到看板上，理所当然，每个界面一张卡。 现实中，我们的项目经理可能还会这样分到人头上： 为什么一定要分到人头上？除了方便KPI（表面上），背后还有一定的文化因素：因为当项目延期时，我们就可以找出那个相应的人进行问责。这种问责的机制导致的后果：人们更愿意推卸责任，而不是共同协作。 放大一些这个问题，公司内部多个技术部门也会因为这种问责的文化，导致部门之间更趋向责怪对方不按期，而不是共同协作完成一件事情。 再再放大一些这个问题：在人们的意识里往往认为，问责后，坏的事情就可以避免问题再发生。放到我们本篇文章讨论的上下文里，也就是问责可以避免延期。但是，可能吗？因为延期已经发生，我们应该在延期发生前进行协调资源来解决延期。 我们举个例子：在项目进行的过程中，人员B在做界面3，4时，在第3天时被一个问题卡住了。而人员C其实在第3天时就已经完成了，第4天开始优化。其他人准时完成了自己的任务。最后人员B的延期导致项目延期了2天。这时，如果你问责人员B，那么，这次的延期能倒退吗？也许你会说，问责后，这个人下次就不会延期了。 我想说： 延期不延期和你问责没有任何关系。如果有关系，你在项目开始时，就每个人问责一下，这样项目就不会延期了？ 我们应该追求的是每个项目都不延期，而不是下一个项目不延期 我们追求的是不延期，还是追求更卓越的产品？ 回头看这次延期，也许我们是可以避免的，比如在第3天的站会上，人员C说出自己被某个问题卡住了。这时，可能其他人员一句话就点通人员C的问题了。还有可能是人员C遇到的问题是需要其它部门来协助才能根本解决，这时项目经理就需要与其它部门沟通了。 回到问题“按界面粒度来拆分任务”这个问题本身。 将界面再拆分成可量化的粒度 这种方式要我们的项目经理拿到需求后，让最熟悉这个APP的人或团队对需求再进行拆分成一系列工作单元，然后再分别估算这些工作单元在现有的人员基础上需要多少天。最后估算出一个总的交付时间点。我们假设完成这个需求，我们同样需要4天完成。 至于拆分到什么程度，就是我们上文提到的可量化的程度。 什么叫可量化？ 上面我们看到将需求拆分成一系列工作单元后，我们可以更灵活的安排优先级。同时，这样也帮助我们发现界面1和界面2有一个工作单元3是有交集的。有交集的工作单元，我们应该让同一个人来完成以避免其中的沟通成本。总的来说，拆分成一系列可量化的工作单元后，我们可以： 更灵活的优先级调控 发现有交集的工作单元，也就能发现可减少沟通成本的空间。 但是，什么样的工作单元叫可量化？ 代码行数是最简单的，估计完成APP改版需要写10万行代码。一个工作单元，我们定1万行？这种工作单元是可以量化，但是写完那么多行代码，你就是完成APP改版这个任务了？ 我们举个例子来说明什么样的工作单元叫可量化，比如对于界面1，我们需要： 把“完成”按钮的颜色从绿色改成蓝色 当完成值为100时，不显示100，显示成“恭喜，已完成” 缓存从服务器获得的任务完成值，对于多次操作，只向服务器请求一次，以提升用户操作的流畅感 从这个例子，我们可以看出，每个工作单元都应该是： 准确的：将绿色改成蓝色，而不是红色 不可分割的：不显示100，显示成“恭喜，已完成”，这个工作单元，你不能再分割了 体现了业务含义：代码行数并不能体现业务含义，但是提升用户操作的流畅感有业务含义的。 可量化的工作单元、站会与看板 有了可量化的工作单元后，再结合站会和看板，这样，我们每天都可以知道（可视化）团队的工作状态了。延不延期，大家都可以看得到，大家都是成年人了： 谁做得快，谁捡更多的卡来做的。而且可以捡优先更高的卡先做，也降低延期的风险。我们可以从这个过程中识别人才。 站会的第3天，人员B还在做_#3_卡，我们其他成员可以加快速度做其它卡以弥补人员B的慢速度，同时项目经理也可以更早的介入这个可能延期的卡中帮助人员B 当出现质量问题时，人员D的卡会被打回Todo多次，因为有站会，我们所有人都很感觉到_#5_这张卡可能存在一定难度或者人员D在协作方式存在问题，这时，我们其他人就会主动帮助人员D解决问题，而不是责怪他。 慢慢地，团队的协作方式变得以解决问题为导向，而不是以问责为导向。 拆分成可量化的工作单元，一样会延期 但是，我个人的经验看来即使我们将需求拆分成可量化的工作单元，项目一样可能会延期。 看板只能帮助我们更可视化，更容易地了解到项目当前的状态，对于这个状态，我们的项目经理要如何反应，完成是个人问题了。 同时，看板也能帮助我们找到延期的根本原因，比如是某个人的卡在In Progress上拖了很长时间、某个人请假了、其它部门中间改需求了、项目人员在某项技术的能力问题…… 所以，要延期的项目一定会延期，我们应该正确面对，找到原因并根本解决。我们要做的只是保证每个人每个工作日都是满负荷的。 这里，留给大家一个思考题：如果其它外部条件不变，每个人每个工作日都是满负荷了？如何不延期？ 拆成可量化的工作单元会增加项目经理的工作量？ 然而，又会有人说了，这么多项目，我每个项目都要拆分成可量化的，我们项目经理会增加很多工作量。 其实，如果真的有作用了，这些工作量是值得的，只要你真的理解可量化工作单元的作用。同时，当出现多个项目时，你忙不过来时，说明现在是你培养另一个项目经理的时机了。你可以尝试将一些项目管理的工作交给团队成员来完成。但前提是项目经理本身也是超负荷工作，影响正常工作了。 小结 想让项目不延期，我们首先关注的是如何将需求拆分成可量化的工作单元，然后想办法保证这些工作单元真正被有效的执行。办法通常可以有： 使用看板可视化所有的工作单元 通过站会了解工作单元执行过程可能的风险 通过协作来取长补短 通过优先级来降低延期时的风险 通过打包有交集的工作单元减少沟通成本 通过以上方法可以将团队“调”到可能的最优状态。但是如果还是延期，原因可能就不在团队了。 ...

前年，接触到了《丰田生产方式》，就对大野耐一这个人十分感兴趣，就专门找他的书来看。 同时，我一直都有一种“感觉”：我们软件工程的管理方式都是从传统工业借鉴的。比如被吹上天的“精益”概念及“看板”概念。然而，这些概念里，少有人说明这样地借鉴的理由及借鉴了哪些，放弃了哪些。想回答这个问题就必须分别弄清楚传统工业和软件工程的本质。 我尝试在这本书了解一些关于传统工业的管理概念。以下是书摘： ####“精益”的概念的产生 1990年，美国麻省理工学院的詹姆斯 沃麦克等多位教授，在《改变世界的机器》一书中，首次以“精益生产”（learn production）为核心介绍丰田生产方式，自此，欧美的一些企业才开始把丰田生产方式作为全球化以及提高生产率的标准和尺度。 领导说服力：坦诚即代表强劲的说服力 要想说服别人或是得到理解，若没有什么根据或道理是行不通的。 不要总是认为自己的言行没有错误，意识到错之后就应该爽快地说出来。如果有了这种胸怀，指挥现场以及下属不就变得轻而易举了吗？ 犯了错误之后，应该不吝于向他人甚至的下属道歉，怀着这样坦诚的态度，怎么会没有说服力呢？ 为了形成强劲的说服力，重要条件之一就是管理者自身应该怀着谦虚的胸襟。 现实生活中，人们似乎随着知识越来越丰富，产生错觉的可能性反而越大。 传统工业也会遇到我们软件工程一样的问题：面对同样一份工作，存在不同的意见。传统工业时里的体现可能是组装配件有两种方式，哪个效率更高；软件工程里的体现是实现某个功能，怎么实现更快（不要忘了，我们还要考虑可维护性，可读性）。当存在不同的意见时，双方容易在无用的争论上浪费时间，大野耐一是这么处理的： 在产生两种意见的情况下，各给双方一个工作日的时间，让他们按照自己的意见试着做一做，最后比较结果，直到让大家彻底理解、赞同为止。 其实，这样处理的最大好处是将**“实践出真理”**的文化慢慢带入企业。 ####要提高生产效率，“意识革命”是首要问题 从上层管理者到中层管理者甚至工作在生产一线的作业员们，由于大家都是普通人，所以都有可能被禁锢在错觉之中，认为现行的做法是最科学的；或者说即使不认为是最好的，也觉得别无选择，这就是被常识化了。 我们软件行业更是如此，特别是一毕业就只在一家公司待很久的人。很容易被“常识化”，认为软件开发就只有一种方式：手工将jar包下载回来，导入到IDE中，然后写代码；部署软件也就是ssh上服务器，然后stop,start。 大野耐一说： 若是不改变从管理顶层到一线作业员以及工会的意识、观念和想法，那么怎么可能探索出做好工作的新方法呢？组织上的改革或许相对容易，但是“意识革命”应该会更加困难一些吧。 再比如很多人认为写单元测试会导致进度被拖慢。其实，关于单元测试是否加快进度，需要更多的数据支撑。所以，需要软件项目管理工具为我们提供更全面的统计工具，来收集这些数据。这也说明了软件行业和传统工业的一个很大的不同。传统工业中很多工作是重复的（产品通常是批量生产），可以快速实验，快速看效果。而软件行业中，根本没有批量生产某一软件的说法。 ####无效率的动作不是工作 身为生产现场的管理者和主管，必须具有分辨“动”和“働”的慧眼，也就是说，必须能够分辨清楚哪些动作是无效率的，哪些动作与工作是无关的。 这里，对于这个“无效率”的定义会有争议。我是这样认为的，如果不能帮助我写出可读、可维护、用户可用的软件的动作都是无效率的。比如手动去管理软件依赖、手动部署、需求沟通需要等上一个星期、新加入团队的成员需要花两天的时间搭建开发环境、重复手工测试、单元测试写在main方法里、写代码过程分心看微博，动弹…… 作为leader，发现这些无效率动作，然后找到改善办法是一项重中重的工作。 ####改善应该按顺序进行 所谓作业改善，就是能够让现有的设备更好地发挥作用。在改善过程中，首先需要考虑的不是购买设备，而是最佳的工作方法。 我认为首先需要进行的是作业改善，之后才依次为设备改善、工序改善，也就是改善应该有先后顺序。 软件行业中，顺序应该是软件开发流程改善，之后依次是实现技术改善、软件开发工具改善。原因是软件开发流程的成本收益率比实现技术改善、软件开发工具改善更高。这只是我的片面之词。希望有数据的同学能帮我证实。 ####产品质量问题 如果某个零件比较容易在前几道工序的时候出现问题，是不是应该考虑将检验工作提前呢？提前发现并剔除不良品，总比让它们一直往下走要好得好多。 品质融于生产过程中，因此，如果能在必要的地方做好检验工作，那么就不必等到工程的最后才发现不良品，或者说到工序的最后阶段只需要重点检验某些部分即可。 产品质量融于软件开发过程中，将风险高的软件模块提前开发。QA在功能开发前就参与需求的讨论，并提出验收条件AC。 ####降低成本 如果有人问我，为什么要拼命减少库存、降低成本，我会告诉他，是为了让资金周转更加轻松。 然而，只要提到降低成本，大家就会觉得这是财务人员的责任，其实不然，财务人员根本无法促使成本降低，这只能通过集体的努力实现。 因此，所谓的降低成本，唯有依靠生产现场来进行，现场的降低成本的意识要做到比鬼还要精才行啊。 减少浪费也可以降低成本。关键是我们如何看待浪费。在《丰田生产方式》中定义的浪费： 1.过量生产的无效劳动：软件行业中指在不合适的时候开发多余的功能 2.窝工的时间浪费 3.搬运的无效劳动：需求沟通不完整，导致重复沟通 4.加工本身的无效劳动和浪费 5.库存的浪费 6.动作上的无效劳动：花费过多的时候搭建开发环境 7.制造次品的无效劳动和浪费：品质没有融于生产过程中 从这里就可以看出光靠架构师是不能彻底杜绝浪费，更不可能靠财务了。 ####小结 这本书给我最大的启发是：高高在上不接地气的技术管理是无法管理好团队的。高高在上意味着他无法或很难及时、准确得知开发现场的情况的。如果你连“施工现场”的情况都不了解，谈何改善？ 同时，我也发现软件行业的代码审查、每日站会就很好的体现了大野耐一的现场管理思想。通过这两个实践，我们的leader才有更多机会靠近“现场”。这才是代码审查、每日站会背后更深层的原因。 半年后再次重读这本小书，又知新。 老翟书摘说明 书摘内容完全来自原书，如果原书的作者或出版商觉得我侵权了。请联系我。 老翟书摘旨在通过一种书摘的方式让大家花最少的时间了解一本书，从而决定要不要继续读下去。书摘的每一本书都是本人亲自读过并理解的。