在敏捷项目管理情景下，如何做多项目管理？这是一个好问题，基本上快速增长中的创业团队都会遇到这样的问题。
作为这样一个公司（嘿店）的产品经理，我也曾经在网上寻找过这个问题的答案。但是每个团队的实际情况都非常不同，想找到一个对口的解决方案基本上是不可能的。大部分人都是摸石头过河，在收集了一些零散的建议和想法之后，结合自身的条件和经验去做一些直觉上的尝试。
拿我们公司的实例来说，我刚进入公司的时候，产品团队毫不含糊的说是一片混乱。没有人为产品负责，CEO、运营、技术团队都会对产品提出需求，基本上就是会上或平时讨论一下，然后记录在一个任务板里。记录和执行都没有任何规则可循，最后需求基本很难落地，逐渐被遗忘。到下次提出者想起来的时候，就会再对所有人问一句，“这个需求什么时候能做好？”，然后没人做答。
总结有3个问题：
没有人为需求打包、筛选并把相关的需求排一起，开发成本高；
没有人为需求排序，开发者不知道先做什么，商业价值回报低；
没有统一的开发流程，任务卡片用技术语言描述，沟通成本高；
我入职的时候技术团队有5人，设计师3人。我们的技术能力很强，产品线比较多，当时主要有小程序、新模版、新Dashboard、新建站工具、新Checkout、bug修复、营销工具这么几条可以归纳出的产品类别，都是这8个人在执行。按照技术类别，这些工作又可以被划分为设计、前端、后端、bug、文档、测试等工种类别。
一个产品都很难去做好开发流程，何况这么多产品混在一起？我们不是大公司，可以分出不同的独立团队去分别完成不同的产品。我们只有一个团队，我们不仅要做所有的事情，还要做的快！这个难度是相当大的，也是为什么创业公司，尤其是技术团队，会很自然的去以敏捷的方式做开发，并且以用Scrum这个框架最为流行。
作为产品经理，我所面临的第一个问题，自然就是，用一个看板还是多个看板？
我花了快一个星期的时间去学习和了解团队现有的流程。我们的团队一开始是用Trello做简单的任务管理的，然后转移到了Tower上。如下图，我们有12个任务看板，设计和开发相关的一共有4个看板，既不是按产品类别来划分，也不是按工种类别来划分，对于一个新人来说，肯定是有一定的learning curve的。
我又看了一下3个看板的timeline，发现其实只有一个是active的，第二active的看板中的最近一个任务已经是3个月以前完成的了。再看一下“产品研发”看板里面的任务内容，基本上全部是技术语言，或者非常具体的action，任务有一些标签，但是没有排序，也没有任何方式的量化（时间或分数）。总之开发团队之外的人是不可能读懂的，这被运营多次反映过，CEO从中看不出大局，更别提预测某个具体产品的交付日期。CEO或运营或任何人，想得到任何产品计划或交付信息，基本靠问，而问又没有人可以准确回答，所以基本大家是在迷雾中前行，把眼前的问题放在脑后，坚信迷雾迟早会散开。
可以看出，我们团队在正确使用看板这一问题上，消耗着巨大的沟通成本。
面临怎么做多项目管理这个问题，我心里有3个目标：产品任务要可读，开发速度要可视，交付日期要可估。而所有一切的底线是：成本要低。
我们团队此刻必须要开始有一套固定并且高效的开发流程，团队越来越大，流程债越欠越多，迟早是要还的。我之前在澳洲和美国做科技公司用过多年的Scrum，也接受过培训。Scrum很看团队，我们的团队个人能力强、主动、团结，很适合用Scrum，大家也很拥护。在这里我就先不介绍Scrum了，大家可以另行搜索。
经过评估，我决定让开发团队用回Trello。因为Trello免费、简单、又足够强大，刚刚好。并且我决定，开发只用一个看板！不同的产品线怎么区分？用标签。
用一个看板而不是毎个产品一个看板的考虑有两点：
思考使用哪个看板，观看、查找、切换，全部都是成本，而且很容易让人头疼，产生厌恶心理；
由于每个人都参与了每一个产品，想要对全局或某一个产品进行统计和预估，多看板很难操作，牵扯到各种数据导出、过滤、整合，全部都是成本。
怎么给产品开发做统计和预估？很简单的道理，时间=路程／速度。你需要且仅需要两个数字：团队的开发速度和产品的分数总和。统计出这两个数字，就能预估项目所需时间。这些的前提是给卡片量化，即记分。
使用Chrome插件：Trello for Scrum可帮我们达到这个目的，如下图。Scrum大家都有各自的用法，记分是我认为Scrum最核心的一个步骤，有了它，我们才能计算出团队的速度，才能预估出项目的交付日期。没有分数的卡片，就像一只没有血条、没有经验值的怪兽，不知道怎么就打死了。那遇到Boss怎么打？需要打多久？
上图是我们其中一个卡片。数字0.5是团队通过讨论（或执行人员独裁）给卡片打的分数，这个分数可以是一个难度x未知度x时间的一个复杂指数。但对我们来说，我们就简单的用执行时长来作为分数。0.5即半个小时，属于非常简单的任务。打分一般使用斐波那契数，即0, 0.5, 1, 2, 3, 5, 8, 13, 21...这样的数列，越往后越表示任务的复杂和难以预测程度。
除了量化卡片以外，仍然是出于降低沟通成本的考虑，我们的卡片以故事的形式描述，而不是以action的形式描述。即每一个卡片都要回答：谁？想达成什么目的？为什么？这三个问题。这样做的目的是让所有人，即不光是开发团队的人，都能看清楚每个人在做什么，会带来什么样的商业价值，需要做多久。那么具体的执行action，或验收指标怎么描述？答案是在卡片里设Checklist，如下图：
需要重点提出的是，我们在这里对卡片的分数（时间）估算，绝对不是为了考核毎个执行人员的工作时间和效率，我们不会去看某个人做了什么事情做了多久。实际上，每个卡片基本都是由多个人共同完成的：设计、开发、测试，只有整个卡片（故事）被进行了记分，并不是每一项具体的action或人。给卡片记分的目的上文已经提过，仅仅是为了进行团队速度的计算，和对项目交付日期的预估。我们只关心团队的速度，不关心个人的投入，因为之前提过Scrum是很挑团队的，只有个人能力强并且能动性高的团队才适合做Scrum，既然做了，就要相信彼此，不要搞考核。考核也是成本，一切分心的事物都是成本，都是产品的敌人。
我们的Scrum sprint周期为一周。作为Product Owner，我负责根据各方提出的需求（Requests）将其贴上不同的产品标签，再根据开发成本和商业价值进行排序（Product Backlog）。而团队仅需要根据现成的排序，在周一例会上，计划本周可以执行的卡片（Sprint Backlog），一个一个认领和执行（Doing），执行完成的卡片所有人在周五例会上进行测试（Test），测试通过的卡片（Done）必须具有可以在任何时间都可以上线的质量，由我决定在某一个时间结点是否把Done的卡片上线。这样如果我们的产品按时完成，我们就可以上线100%的功能，如果不能，我们也可以选择只上线已经完成的功能，不会出现什么都上不了的情况。
Scrum for Trello插件会提供给我们一个图表，叫做Burndown Chart，在含有"Done"关键字的列表里的卡片和被加上"Consumed Points"的卡片都会被认定为“完成”。这个图表可以基于此给我们计算出上文提到的几个重要数字：一个是团队的速度，这这个例子中，我们的平均速度是每天20.45分；二是剩余分数，在这个例子中我们一共剩余118分。我们一周的工作时间设定为5天，基于此，图表估算出我们要想完成手头所有卡片（全部产品线），大概在4月18号，今天是4月10号。由于敏捷开发的原因，我们会不断的整理和添加新的卡片进去，所以这个日期会一直变动。
知道了团队的速度，也就是执行力，就方便了我们预估某一个产品线的100%功能交付日期。比如如果我们集中精力攻克前端任务，我们可以选择过滤显示所有前端相关的卡片。如下图所示，我们得出一共有25分的前端卡片未完成，那么除以团队平均速度20.45分每天，我们大概需要1天多的时间即可完成。当然更准确的做法是，过滤出所有前端相关人员的日均速度，25分除以这个速度，就是所有前端任务需要完成的大概需时。
我们第一周开始用Scrum的时候，团队并不是很恪守Scrum的规则，导致一些卡片虽然做差不多了，但是到周五review的时候，并没有达到一个可以测试的阶段。不能测试，就不能保证这个卡片可以随时上线，那我们就不能把它算作Done，这样以来我们第一周的速度就非常缓慢，一周才拿到10分。没有做完的任务放在第二个周期继续，那么第二周就很容易完成了一些高分的卡片，导致第二周我们一下子拿到了40多分。前几周波动大属于正常现象，卡片也经常会出现由于团队高估自己的执行力，而出现计划多做的少的情况。慢慢的，团队会趋于接近一个平稳的开发速度，而每个周期开始的计划也大致可以在周期结束的时候刚好完成，这样我们就可以更好的进行产品计划，有条而不紊了。
打造一个好产品固然重要，但是更有价值的是打造出一个能够持续打造好产品的团队。好的团队需要的不是经理而是流程，而好的流程说到底，就是一个字：降低成本。
