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

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

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

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

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

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

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

产品设计体会(3002)封闭开发

2007年底,又给封闭了好几周了,和外包的项目团队在一起。

iamsujie补:2009年春节后又将封闭搞一个项目。)

算起来到公司有超过一半的时间出于项目封闭状态,也算幸运吧,因为封闭的项目通常是比较重要和神秘的(好吧,或者是因为办公区域没地方坐了,=,=bbb)。

《人件》里很强调办公环境对人的影响,不过那是对正轨成熟的大公司而言的,从我们经常搞封闭就可以看出,确实还是一家创业型(至少是有创业气氛)的小公司。

封闭的好处比较明显,大家都挤在一间房里,围着一张会议桌办公,交流非常方便,有什么问题,吼一声就通知到所有人了;而且封闭通常是为了“赶工”,所以争论会比较多,小空间可以使得争论更容易产生,而且参与者会更加投入,不用担心激烈的争论会打搅到外人,因为屋里没有外人;封闭还会让人丧失时间概念,早上会到得比较晚,但晚上经常也在工作,这样通常快速、高效,会不自觉的加班,而且互相之间的影响比较大。

另一面,封闭的缺点也是显而易见的,环境较差,比较挤,当大家对项目有激情,或者经常有团队激励(包括物质的如出去聚餐,精神的如又跨过了一个milestone)的时候,高昂的战斗气氛可以保持,但难免的长时间会心理疲惫、压抑,个人感觉通常上限是23个月。想到一个特例,阿里的秘密基地湖畔花园的封闭通常会很久,但那里的团队战斗力可以一直保持,这也许就是团队激励的作用。

从上面的特点可以看出,封闭比较适合创业型团队的敏捷开发,追求速度的同时必然牺牲流程、规范、文档等东西,而这次封闭正好又是和超级正规军在一起,他们做起事来完全就是《软件工程》教科书式的,项目启动、……、需求分析、概要设计、详细设计,每样的文档空白模板一拿出来就已经几十页了,每周的周报、会议记录都有极其华丽的模板,讨论都是口说无凭要邮件出来双方回复确认的,这段时间可以感受到两种文化的剧烈碰撞,学到了很多,这种新模式作出的产品如何,2个月后揭晓。

iamsujie补:但这个项目并不顺利,后文有关敏捷、外包等话题中有描述。)