Home
>
娄底项目管理协会
>
娄底项目管理技巧
娄底项目管理技巧

time:2020-07-12 11:29:04

author:重庆佰鼎科技有限公司

【Font size: big medium smail

本文由重庆佰鼎科技有限公司提供,重点介绍了项目管理技巧相关内容。重庆佰鼎科技有限公司专业提供项目管理协会,翻译项目管理,项目资金管理情况等多项产品服务。公司产品内容市场占有率逐年提升,深受赞扬,虏获了一大批忠实客户。

项目管理技巧在敏捷项目管理情景下,如何做多项目管理?这是一个好问题,基本上快速增长中的创业团队都会遇到这样的问题。

作为这样一个公司(嘿店,一种更好的电商方式)的产品经理,我也曾经在网上寻找过这个问题的答案。但是每个团队的实际情况都非常不同,想找到一个对口的解决方案基本上是不可能的。大部分人都是摸石头过河,在收集了一些零散的建议和想法之后,结合自身的条件和经验去做一些直觉上的尝试。

拿我们公司的实例来说,我刚进入公司的时候,产品团队毫不含糊的说是一片混乱。没有人为产品负责,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多分。前几周波动大属于正常现象,卡片也经常会出现由于团队高估自己的执行力,而出现计划多做的少的情况。慢慢的,团队会趋于接近一个平稳的开发速度,而每个周期开始的计划也大致可以在周期结束的时候刚好完成,这样我们就可以更好的进行产品计划,有条而不紊了。

打造一个好产品固然重要,但是更有价值的是打造出一个能够持续打造好产品的团队。好的团队需要的不是经理而是流程,而好的流程说到底,就是一个字:降低成本。

Reprint please indicate:http://trna.cnsoftweb.com/xmgl-2545.html