产品设计体会(3008)项目Kick Off

说一下项目Kick Off会议(简称KO)的作用,会有人觉得这很形式化,但我认为很重要,其实KO只需要15min左右的时间,我通常会安排在需求评审(参加人与KO基本重合)之前,成本很低。

在这15min内,需要传达的信息有如下几点。

Ø    项目的背景与意义

我们在哪里?说过去,做项目之前的情况,为什么要做这个项目(以让听众痛心疾首为终极目标)。

Ø    项目的目的与目标

我们去哪里?说将来,做项目之后的情况,解决什么问题就算项目成功了(以让听众面带桃花为终极目标)。

Ø    做法、需求、功能点概述

我们怎么去?说现在,具体用什么方法促使“过去”到“将来”的转变(以让听众跃跃欲试为终极目标)。

Ø 项目组织架构

目的是让到场的、相关的人员了解有什么事情应该找谁,注意不要遗漏跟开发关系不大的成员(小型项目的大多数活动是开发及相关过程):服务部门、配合部门的接口人,因为项目的事情如果他们不知道的话,那么即使项目本身顺利发布,之后也会带来很多配合上的问题。

特别提一下,我会组织一个“项目督导委员会”,必须的,他们的任务很简单——背黑锅(权力越大,责任越大)。当项目因为种种原因出现重大变更的时候,比如成本、工期、需求等,我会向他们提出申请,获得批准后才动,这也是对PM自己和项目成员的保护。

Ø    项目计划

让所有人了解两个关键点:1.时间点与里程碑,2.各个时段需要的资源。

这点就不多说了,太深奥的还不懂,按老板的话,其实做好项目很简单,一是计划好,二是控制好,各种手段都是为了这两点服务的。

Ø 沟通计划

我觉得和项目全体成员明确这点非常重要,因为太多事情的不顺利都是沟通的问题,大家都做不到一直主动、彻底的沟通,所以有个规矩来逼着做一些沟通的工作,可以免去很多麻烦。一般来说,我常带的号称“敏捷”的项目,方法有:项目日报、每日晨会、评审会、产品试用会、发布预告/公告……

产品设计体会(3004)项目外包不适合“敏捷”

2008春,前几个月尝试做了PM(这次是Project不是Product了),亲身经历了一个项目是怎样一步步不顺下去的。先说明一点:这里的“敏捷”是指甲乙双方配合的“敏捷”,而不是说外包项目本身内部的开发过程不合适“敏捷”。

先说一下背景,项目时间太紧,工期是由商业谈判决定的,没有及时评估工作量,做着做着产生delay,先试图简单的用加班的方法赶上进度,后来被迫注入“敏捷”项目方法,但事后发现“项目外包”模式不适合敏捷。

首先,项目外包使得甲方不愿意砍需求。为了敏捷灵活,公司内部的项目需求在很大程度上是可以砍的,是“保质不保量”,这是符合敏捷的原则的。但是项目外包,甲方在提需求的时候不愿把任何一个功能像平时那样推到2期做,因为项目结束后2期在哪里都不知道,所以“保质保量”变成了“不保质保量”。

其次,敏捷必然导致文档工作不细致,使甲方游离于项目之外的“验收测试”模式难以适应。敏捷从模式上会导致提交测试的产品和最初的需求之间必然有很多变化,并且文档很难跟上,而这种敏捷在公司内部之所以运行的很好,是因为PD、开发、测试在项目过程中可以充分交流,测试在TCTest Case)评审的时候会叫上PD和开发,有些属于详细设计的细节是在评审的时候与开发直接确认,在测试执行过程中也会协助确认需求细节并迭代测试。而项目外包的时候,甲方会从一份颗粒度过粗的需求文档上派生出“验收测试”的TC,又因为验收有“考试”的性质,所以不允许乙方的开发参加甲方的TC评审,导致只能和甲方需求人员确认细节,而需求人员对如此细节又没有要求,无奈之下只能按照自己的想法说,必然导致两边对需求的理解有鸿沟。另一方面,验收测试是一次性的,只有passfalse的结论,没有迭代的过程,不符合敏捷的思想。

最后,国内的乙方通常没有“敏捷”的经验和意识。一般甲方没有独立软件研发能力才选择项目外包(否则多用开发外包),职业性质/国内的项目管理现状决定了外包工程师的习惯是按照详细的设计文档开发/测试,抗拒需求改变,所以强行“敏捷”会导致失控。因为没有一份完整的详细设计文档,开发人员会按照自己的想法编码,测试人员也照自己的想法测试,没有做TC评审的意识,加之没有和需求人员即时沟通反馈的习惯,没有一个迭代的过程,再为了工期的死命令削减测试强度,结果就是发现做的与需求不符的时候已经晚了。

很多原因共同造成不好的结果,还有些没说,总结下来就是不能再这么做了,对敏捷的理解很粗浅,欢迎指正。

产品设计体会(3003)项目外包 != 开发外包

项目外包和开发外包的模式有明显区别,手头经历了一个概念不清的项目,结果一路坎坷,体会如下。

合作模式、权责利划分一定要在开始的时候明确。这次的项目外包,乙方又把开发外包,谁对谁负责,什么事情谁做一直没有明确界定。乙方会本能的倾向于开发外包,导致甲方投入越来越多,产生分歧。

既然项目外包了,项目管理方法应该乙方定。当时间紧的时候,乙方或投入资源或和甲方重新商业谈判来解决,甲方强行改变项目管理模式是风险极大的。比如这次双方对“需求设计编码”环节的理解有差别,乙方是教科书里的软件工程,而甲方的“需求”包含了很多“设计”的内容,“编码”也包含了部分“设计”,“需求”完了直接进入“编码”。说法不同,实质一样,不过后来采用甲方的模式,导致乙方真的跳过了“设计”阶段,没有产出相应的文档。

项目外包的需求如何配合?乙方应该push,向甲方收集需求,并维护《需求说明书》等文档,当然甲方要积极配合并即时告知最新变动并走乙方的流程进行评估,而开发外包就是甲方push更合适,走甲方的需求流程,不断给外包的工程师更新需求。

项目外包的测试如何配合?甲方肯定会有验收测试,但是乙方一定要在项目范围内安排比验收测试更详细的测试,前外不能把“找bug”的测试部分寄托在甲方的验收测试上,而这次到项目提交的时候,项目组内部做过的测试还远不如验收测试详细,这和验收的原则显然是不一致的。

另外外包的项目会有甲方乙方两个PM,这次也听乙方的中年PM谈了很多两种PM的不同,受益很多。