站会

图截自：http://agilemanifesto.org/iso/zhchs/manifesto.html 最近，项目上遇到了以前我从来没有遇到的事情：10多个人一个团队（概念上的），要应对9个外部需求提出方；要维护超过10个子系统，这个“大系统”还是从另一个不愿意配合的团队接手过来的；项目管理者中，有倾向于敏捷的，也有倾向于瀑布的；最可怕的是这支团队完成组建才1个多月，只有3个人有站会经验，平均工作经验在7年以上😱。 所有的这些条件混合在一起，管理就变得异常复杂，困难。面对这样复杂的乱麻，谁都很难有勇气一刀切。 然而，事情还要做。比如站会。上周我自荐主持一次站会。说实在，那次站会是失败的，因为期间还是有两个人拿手机来刷。 有人拿手机出来刷，说明站会上的内容和他们无关，进一步说明站会是无效的。 但是，为什么呢？我会后一直都在思考这个问题。 我想起自己一年多前，也是带团队从零开始实践敏捷开发。为什么不会出现这样的情况？ 突然，一个词蹦出来：共同语言！ 站会成为形式的根本原因，就是整个团队没有共同语言！。没有共同语言使站会沦为形式。 好，现在我必须解释两个问题： 为什么整个团队没有共同语言导致站会成为形式？ 为什么整个团队没有共同语言？ 我先解释为什么整个团队没有共同语言，再解释为什么没有共同语言的团队站会是形式。 为什么整个团队没有共同语言 团队的沟通模型 第一个使整个团队没有共同语言的因素是：团队的沟通模型。 为了方便讨论，我们假设团队的沟通模型为： 项目管理A，对接需求方1、2、3，然后再将任务拆分给Q、W、E。项目管理B、C依此类推。 这样的沟通模型下，为什么团队成员会没有共同语言？ 在这样的沟通模型下，开发人员Q平时只与A沟通需求，尽管可能私底下与其他开发人员沟通一下实现，可以说，开发人员Q与项目管理A才会有共同语言。依此类推，每个开发人员只与他的直接上级有共同语言。 我的结论是：趋向于单向沟通的团队沟通模型决定团队成员之间没有共同语言。而且这种单向沟通的结构时间越长，团队成员之间共同语言就越少！现象是，同处一个团队，你不知道你隔壁坐的同学到底在做什么。 没有统一业务术语 第二个整个团队没有共同语言的因素是：团队内部没有统一业务术语。 我们假设站会时，移动团队里的iOS、Anroid、H5三个小组一起参加同一个站会。而在站会时，iOS针对功能A使用了“激活”业务术语，而Android的同学对同一功能A却使用“上线”业务术语。 不统一业务术语不仅导致成员之间没有共同语言，导致更严重的问题是：沟通效率低下。 为什么整个团队没有共同语言导致站会成为形式 其实道理很简单，你问问自己，你喜欢与自己有更多共同语言的人交谈，还是反之？这是人性！ 站会时，我们更倾向于听我们关心的，和我们听得懂的。但是因为没有共同语言，所以，我们即不关心，也听不懂！ 站会当然也就是形式而已。 怎么破？ 这下肯定会有人问，那为什么要站会？取消不就可以了。问这样的人是因为不了解站会的本质：站会一种团队快速反馈的机制。 至于为什么需要快速反馈，很简单：（真正有效的）每日站会的团队可以每天根据站会内容（反馈）来对人员、需求、发布时间进行调整，调整的时间是以天计。而如果只有周会的团队，那么，这个团队调整的时间是以周计，那你觉得哪种团队面对变化时更敏捷，迅速？ 说回来，如何让站会更有效，而不至于成为一种形式呢？ 至少可以肯定的是这不是一个主持人就能解决的。 剩下的先留给大家思考，我们下篇文章再讨论。 你也可以先读读我之前写过的文章： 每日站会、代码审查、结对编程 之开源中国实践 反馈机制在企业中的作用？ 如何防止程序员上班迟到？

图片来源：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上拖了很长时间、某个人请假了、其它部门中间改需求了、项目人员在某项技术的能力问题…… 所以，要延期的项目一定会延期，我们应该正确面对，找到原因并根本解决。我们要做的只是保证每个人每个工作日都是满负荷的。 这里，留给大家一个思考题：如果其它外部条件不变，每个人每个工作日都是满负荷了？如何不延期？ 拆成可量化的工作单元会增加项目经理的工作量？ 然而，又会有人说了，这么多项目，我每个项目都要拆分成可量化的，我们项目经理会增加很多工作量。 其实，如果真的有作用了，这些工作量是值得的，只要你真的理解可量化工作单元的作用。同时，当出现多个项目时，你忙不过来时，说明现在是你培养另一个项目经理的时机了。你可以尝试将一些项目管理的工作交给团队成员来完成。但前提是项目经理本身也是超负荷工作，影响正常工作了。 小结 想让项目不延期，我们首先关注的是如何将需求拆分成可量化的工作单元，然后想办法保证这些工作单元真正被有效的执行。办法通常可以有： 使用看板可视化所有的工作单元 通过站会了解工作单元执行过程可能的风险 通过协作来取长补短 通过优先级来降低延期时的风险 通过打包有交集的工作单元减少沟通成本 通过以上方法可以将团队“调”到可能的最优状态。但是如果还是延期，原因可能就不在团队了。 ...

P.S. 这里的“迟到”指的是故意迟到。 看看满大街的招聘信息上都写着： 弹性上班，不打卡 我们还有必要思考如何防止程序员上班迟到吗？我不讨论有没有必要，因为肯定有不少公司存在员工上班迟到的同时，没把事情做好的。 也许你又会问了：如果是这样，上KPI不就好了，给他一个活，规定好时间不就可以了？ 这个问题，我觉得不在本文讨论范围内。我只想讨论：如何防止程序员上班迟到。 了解我的人，都知道，当我遇到问题时，我往往先想的是为什么，然后再想怎么。只有知道为什么，才能根治。 那么他们为什么要迟到呢？这个问题似乎是无解的。就似常常迟到的小学生，被老师问起原因一样，每个小学生，每一天都有自己的理由。 好吧，对于似乎无解的问题，我们暂且放一放。 回到问题本身：怎么“防”？ 一提这个问题，绝大数人就想到了：上打卡机呗。 以前，我也是这绝大数人的其中一个。可是最近，另一个疑问进入到我的大脑： 为什么去年我带团队时，没有迟到现象？ 晨会——这个词突然击中我。是的，因为团队每天早上上班时间点过20分钟都会准时进行晨会。 晨会就是指所有团队成员站着过任务卡，晨会一般都会很短。好处什么的，具体可以看我的另一篇博客：每日站会、代码审查、结对编程 之开源中国实践 晨会是如何“防止”程序员上班迟到的呢？ 因为我们团队达成一致：上班时间点过20分钟进行晨会。假如10点上班，你一个人10点20了还没来到，你好意思吗？ 不知道有人想到其中的腻味？人是会不好意思的，在团队这个交际圈里，除非你不想在这个团队待了。换句话说，这样的晨会在一定程度上利用了人性对交际的焦虑来实现“防迟到”。 但是，我要申明，我要申明，我要申明：晨会的真正目的不是为了防止程序员上班迟到！晨会达到自己的目的的同时，恰好解决了“迟到”这个企业难题。 有人会问，为什么10点上班，10点20才开始晨会？因为我们需要给团队成员一点时间进入工作状态，给团队成员一些空间融合。 小结 做水利工程时，与其围堵，不如疏导。这样的战略方针，在企业管理中同样有用。我们在思考如何“防”时，不应该只想着如何围堵，疏导可能是更好的解决方案。而晨会就是一种疏导方案。 题外话，员工为什么会故意迟到？这是另一个有更有深度的问题，留给大家。:)