国内交付项目新手PM生存指南

长期以来一直做国外的交付项目,对于国内的项目总是很怵,因为总觉得做国内项目就需要像电视剧中一样边谈项目边喝酒应酬,而且还天天加班,所以一直以来没有机会也没有勇气接近国内项目。

但是,机缘巧合,最近在国内项目上摸爬滚打了一段时间,感觉可以把自己的经历和经验记录下来,跟大家分享一下。

也许大家接触的都是国内客户,但是不同的客户会有自己独特的风格,在下文中我会按照交付项目开展的时间顺序为大家介绍它们通用的和特有的问题及经历。

#售前阶段

在正式开始项目前,我们需要对项目管理的“金三角”(时间、范围和成本)有明确的认识。但是在售前阶段这些问题的答案都很模糊,需要我们逐步分析和确认。

一般会通过以下三个步骤来解决。

###第一步:了解背景

我们首先需要做的是找到这个项目机会的来源,也就向销售的同事获取尽可能多的信息,例如这个机会是哪个客户给的,他/她在客户组织架构中的位置是什么样的,他/她对我们有什么样的建议和想法,这个机会所在部门的背景情况和重视程度,这个项目现在遇到的问题和以后有可能遇到的问题,我们去谈需求时需要联系谁,联系方式是什么。

拿到了这些消息后,我们还可以利用现有的信息,在公司内部找和客户同一部门或者类似部门打过交道的同事了解更多的背景和技术知识,尽可能找一个在同一客户下工作过,最好是客户熟知并且对客户有影响力的同事,在洽谈需求时能一起参加,这不仅会让我们更有底气,能更准确地了解客户需求,也会让客户增加更加信任。

这些信息我们最好能够记录并保存下来,而且需要系统性地整理这些信息及注意事项。

在这一阶段我们了解的更多都是全局的内容,而在项目中我们往往忽视了从全局观出发,如何能更好地解决问题。

###第二步:拜访客户

有了这些信息,下一步就是和客户约好时间,进行拜访

第一次进行客户拜访,通常双方需要先进行相互介绍,我们一般也会派出项目的PM和Tech Lead参与拜访,拜访的内容主要是了解需求。但是第一次谈需求,我们需要注意更多从业务和价值角度切入,而不要陷入技术细节。这时我们往往会发现自己之前设想的和客户描述出来的差别很大。但是我们要注意,不要过于坚持自己的想法,而需要根据客户的描述,通过自己的问题一步一步地引导客户说出他们的痛点和期望,从而能使项目的目标清晰。

在这一阶段通常我们也要向客户展示我们的技术实力,让客户坚定选择我们的决策是正确的。采取的方式可以有针对项目相关技术的演讲或者演示。总的来说,最好把第一次拜访控制在一个小时左右,这样我们一方面得到了相关的项目知识,另一方面,为下一次会面向客户展示具体的项目相关技术实力提供了机会。

在有了项目业务需求和痛点之后,我们需要修正自己之前的想法和设计,根据最新的情况进行总结,并且最好得到客户的确认。

接着,根据这些信息,我们就可以着手进行技术架构的设计以及风险的评估,为后续的拜访明确目标,使会议更高效。之后的拜访或者会议都是一步一步的细化过程,包括确定是用什么技术栈,什么架构,客户如何与我们交付团队合作等等。不过我们需要控制每次会议以及为项目准备时间的投入,以及这一阶段持续的时间。因为持续时间长不仅会让客户感觉我们不专业,也会暗示我们不理解项目。再说,如果项目最后没有谈成,也是对于公司资源的浪费。

###第三步:合同形式

上面我们说的都是技术方面的,售前阶段有很重要的一点是需要了解客户想以什么样的方式和我们签合同。因为咨询和交付项目的工作方式以及交付物都是不一样的,如果我们以交付项目的形式签订合同,而以咨询的形式工作,那在项目结束时,我们会面临如何验收,如何提供交付物的问题。这也很有可能让客户在工作验收和领导汇报时陷入被动,因为实际完成的和合同上签署的内容是不一致的。

如果我们能够顺利解决上面所说的问题,我们就可以等着进行投标等工作了。下面我们就来看看神秘的投标阶段都会有什么意想不到的问题吧。

#投标阶段

首先我们需要根据标书的要求,完成相关系统的设计。这些设计并不只是技术架构,还需要包含对于客户的理解,对于项目现状的理解,对于项目远景的理解,以及由此而产生的技术架构和实施计划。同时,我们还需要展现我们对于同一类型项目的经验和成功案例。

编写标书的技术方案看起来简单,只要写命题作文就可以了。

标书的大致目录

图 1.1 - 标书的大致目录

但是,标书需要我们协同配合,尤其是需要售前同事和交付团队进行密切沟通,确保交付团队在得到客户真实意图,准确把握客户的期望和优先级的情况下,出具架构合理、充分考虑到客户需求和成本的方案。如果在投标前期给客户做过Inception,我们还需要和Inception团队全力合作,进行知识的有效传递(最好能让Inception团队来编写标书)。如果能从Inception的团队中获得例如线框图(如图1.4),用户画像,用户旅程,推荐的技术架构甚至Epic Story,对于确定项目范围和编写技术方案来说会助力很多。

线框图和用户旅程

图 1.2 - 线框图和用户旅程

###关键点一:技术栈和技术架构

在编写标书时的关键之一在于技术栈和技术架构。在我们根据客户的需求确定这两项之后,我们还需要进行架构评审,以便集思广益,减少架构设计时引入交付风险,同时也可以更好的权衡交付压力和技术卓越。我们不仅需要考虑使用什么技术来满足客户的需求,还需要考虑客户运行项目的成本,甚至客户是否需要付出很多成本招聘到合适的运维人员等。

技术架构

图 1.3 - 技术架构

###关键点二:估算工作量

确定了技术栈和技术框架之后就需要对工作量进行估算了。在进行估算时我们不能按照特定的人员能力进行估算,而需要按照平均开发水平估算交付项目的人天,因为我们不能确定谁来进行开发。由于和客户签订合同通常是以人天为单位进行计算的,所以按照我们通常使用的以难易程度为点数进行估算也是可以的,不过最后也需要转换成人天。在估算出工作量之后还需要和售前同事权衡架构设计的精密性和交付周期。此外,对于有些客户,我们评估了工作量后,还需要和他们针对每一个功能的工作量进行PK,确定我们的工作量没有水分,因为我们更需要对项目业务和技术都有深入的了解。

###关键点三:确定人员计划

编写标书的另一个关键是确定人员计划,但是这一点依赖于前面两项。在确定了技术方案后,我们需要根据具体的技术需求,确定需要什么样的角色,例如使用什么技术的前后端开发,是否需要iOS/Android的开发,是否需要UX等;以及根据对于交付项目的工作量估算,确定这些人员上项目和下项目的时间,并且最好能留一点buffer,以应对需求变化和请假等不确定因素,同时还需要考虑到项目交付后一段时间的维护计划。项目的利润也是PM需要重点关注的,这也会影响到选什么样的人加入项目。由于我们通常并不会获得完全适合项目技术的人员参加项目,所以作为PM也得负责人员的培养,以达到项目的要求。

人员计划

图 1.4 - 人员计划

此外,我们不仅需要充分考虑以上三个方面,还需要突出我们的亮点,使客户能更直观地了解我们的价值所在。

在编写标书前我们就得设定好心理预期,编写标书,尤其是第一次编写标书时,通常都会有很多地方都要修改很多遍。虽然修改很累很繁琐,但是只有做好了这一步,才能让后续工作更顺利。

##讲标阶段

投标不仅包含编写标书,还包括讲标的环节。两者中间实际上还有“投标”这一活动,但是一般是由特定的同事去投标的,所以作为PM和技术人员,通常在这一阶段更关注于投标之后的讲标。

顾名思义,讲标就是在客户现场把投递的标书讲一遍。但实际上前后的准备工作都很多。

首先,我们要准备讲标标书。大家会觉得奇怪,刚才不是写好标书都投了吗?还写什么讲标标书啊?其实一般投标的纸质版标书会有150~200页的内容,而讲标时间通常都是半小时,再加上15分钟左右的问答,所以在30分钟内不可能讲完标书上的所有内容,因此我们需要对标书进行精简,并且多以图表和图片的形式进行展示。这一过程也会和编写标书一样会修改很多次。

其次,还需要进行讲标的演练。需要有人模仿客户,提出各种问题和挑战,让讲标的同学尽可能做好应对各种不同的听众和情况,随机应变,使整个讲标过程在控制中。同样演练也会进行多次,以使演讲技巧和临场能力得到锻炼。

再次,在正式讲标前,我们需要准备好电脑电源,翻页笔,显示器转接头,装有讲标文件的优盘,各种格式的讲标文件(Keynote、PPT、PDF等)等设备和资料,避免任何出错的可能。并且我们需要提前到场,如果离客户远一定要留好充足的时间,避免迟到而影响讲标效果。

最后,在讲标时,我们只要控制好节奏,把握好时间,按照演练的内容正常发挥就可以了。

在投标和讲标之后是商务谈判和签订合同等活动,由于一般大家都不会接触(其实是本人并没有接触到),所以就略过啦。

等前期准备都完成了,就可以开始正式的交付阶段了。

#交付阶段

在交付阶段作为PM关注的点很多,所以分为几个方面来说。

###在这一阶段,我们还需要和客户沟通了解以下方面:

  1. 了解客户项目的上线流程:比如上线是否需要申请域名,是否有上线前的测试和安全检查等,内部工作流程和规范(需要使用的各种工具,以及是否每次会议结束后都需要发送会议纪要等),文档和报告(日报,周报以及项目交付时需要提供的诸如用户手册、维护指南等文档)。

  2. 了解客户如何定义项目成功:因为对于客户的业务部门、技术部门和我们交付团队,成功的定义并不一样,但是需要我们了解这些不一致,然后相互协调相互妥协,尽量让各方都满意,使项目在交付后每一方都认为项目成功了。

  3. 为客户提供统一的接口人:这并不是说交付团队只有PM和客户沟通而是说不同类型的事物至少客户可以找同一个人解决问题,而不是每次遇到问题,都是需要通过询问才能找到合适的人解决,甚至没有人负责解决问题。例如对于项目管理和人员安排,客户可以找PM;而对于技术架构和实现方面的问题,可以找Tech Lead。

除了了解上述方面,对于客户,尤其是业务部门,通常来说对于交付团队来说都很不放心,担心进度和实现效果。特别是对于第一次合作的团队来说更是如此。那我们能怎么样改变这种情况呢?

  • 首先我们可以通过每天的站会让客户了解我们工作的内容,也便于我们快速解决问题。不过我们需要控制站会的形式,不能把站会变成向汇报或者进行提问的方式。

  • 其次我们可以通过故事墙(物理和电子的)让客户实时看到项目的进展和项目的状态,让他们觉得项目可控。

  • 再次是需要适时而且适度向客户寻求解决问题。这样可以让客户更有参与感和成就感,不过需要控制好度。尽量避免交付团队自己开小会,让客户觉得自己被排除在团队之外。

其实,最关键的还是我们开发的软件。不仅是客户,交付团队也是看到了实际的产品之后,才会对项目进度和质量更有信心。

###对于我们自己团队来说,需要注意以下几点:

  1. 和很多公司不同,我们开始交付之后,并不是一上来就直接开发功能,而是会有迭代0的环节,包括交付范围的细化,迭代1的故事卡分析,制定发布计划,进行基础设施的搭建,验证技术可行性等任务。这可以让我们在项目伊始就尽量排除、发现和识别架构和框架以及技术可行性上的问题,迅速进行调整。

  2. 我们还需要和客户建立良好的关系,让他们意识到我们是在为同一个目标而努力,需要通力合作才能达到那个目标,所以各方需要相互配合与磨合。

  3. 在坚持底线和原则的基础上适当妥协,尽量保证客户的满意度。但是在无法满足或者对于项目进度、质量、人员、成本以及和客户的关系有影响的方面,需要及时和交付保障的同事进行沟通和商量,尽量在萌芽阶段解决问题。

  4. 关注并管理客户的期望。如果项目开发慢了,要及时向客户解释原因,并提供解决方案以及寻求帮助;如果交付快了,不仅需要介绍我们通过何种努力才能加快进度,同时需要介绍可能存在的问题以及可以改进的内容。

  5. 在开发过程中控制好项目的节奏,不能让团队一直加班或者没有事做,而需要让工作有节奏。对于客户可能提出的996(9点上班,9点下班,每周工作6天)的工作模式,一定要断然拒绝,因为我们希望的是可持续的高效开发,而不是短期的突击。当然这不包括上线前可能会需要加班的突发情况。

  6. 为了更好的合作,我们还需要在项目开始就和所有团队成员达成一致,定义内部工作流程,以及内部沟通机制,例如微信群和邮件群等。不过需要注意使用的频率,减少客户对于进度的担忧。此外对于和客户的沟通,我们也需要制定沟通计划,例如如何与客户确定需求等内容,什么时候给客户进行演示,以及客户有问题该怎么和团队沟通,以保证既能解决问题,又不会影响团队交付进度。

  7. 我们合作的很多客户对于文档都是有不少要求的,所以在开发过程中,由于交付压力,客户有可能允许我们延期提交相应的文档,例如设计文档等,但是我们还需要保留好原始材料,等客户需要这些文档时,我们可以通过这些材料快速生成相应的内容,而不是重新做起。

###对于PM来说还有哪些职责呢?

  1. PM还需要适当屏蔽干扰,让团队能集中精力工作,例如尽量减少不相关会议的打扰,以及回答客户随时提问技术细节等情况;同时需要避免压力过多传递到团队成员,例如客户对于需求或者架构的大改变,从而有可能对项目交付进度产生很大压力,PM需要先过滤这些信息,等改变明确后再告知整个团队,这样可以避免传递不确定的信息,避免造成军心不稳的情况。

  2. PM还需要关注团队成员的精神状态,用积极的方式影响团队,提高团队士气;同时还要负责好后勤工作,例如开发所需要的各种资源的协调,办公用品等,以及Team Building这些活动。

  3. 交付团队还需要不时给客户一定的震撼和影响,以使客户对我们更信任。例如采用客户并没有用过的利用画图的方式展示架构图;

用画图的形式展示架构图

图 1.5 - 用画图的形式展示架构图

以及,可以用美纹胶带来装饰物力墙,而不是在白板上手动画上歪歪扭扭的线;

用美纹胶带来装饰物力墙

图 1.6 - 用美纹胶带来装饰物力墙

也可以是针对技术问题的在白板上边画边讲的讨论等。

  1. 如果在客户现场工作,客户一般会希望通过学习我们的工作方式提高自己员工的能力,所以我们也可以考虑在不影响进度的情况下,传播一些项目实践,例如举行公开的回顾会议等。

  2. 在客户现场工作需要注意客户的网络速度和质量是否会影响到我们的工作效率。如果发现了问题,一定要尽早解决,尤其是安装开发和生产环境的任务对于网络要求会很高。

虽然现在我经历的第一个国内交付项目还正在如火如荼地进行,但是并不妨碍我畅想一下交付之后的情形。

#交付之后

在项目完成以后,我们还会维护一段时间。这段时间只会就现有的代码问题进行修复,并不会进行功能开发。

对于PM来说,

  1. PM需要发送上线邮件,让团队成员有成就感和荣誉感,也让更多人知道自己项目是做什么的。

  2. PM还需要负责项目总结,不仅总结成功的经验,还需要分析出现的问题以及如何避免,让更多的人少走弯路。

  3. 最后少不了的就是团队的庆祝了,无论是买蛋糕庆祝还是别的活动,团队都需要被激励和感谢。

之后,大家又可以准备投入到新的项目中啦:)。

以上的总结更多的是从个人的经验出发,难免会有不足,希望这边文章能使大家在看的时候想到自己遗漏的一些内容,更好更完善地进行项目管理。也欢迎大家的指正。