1、项目背景

18年，我在一个创业初期的小微公司工作，公司最初规划对接交管路政部门需求，提供车联网信息化相关服务。我加入这家公司一是想在创业公司工作，可以跳过一些限制获取到团队创业成长的经验，二是因为这家公司研发的车联网是我十分看好的领域，且有最高水平高校的技术支撑，也能获取到一流的技术成长。

我是以产品经理的职位加入的小微（公司代称），但因为上级期望，转回了项目经理，不过因为是创业公司，其实是兼任双职且带团队。

因为小股东承接过交管局的项目，小微想借此关系继续为交管局提供车联网服务，但因创业公司要养活自己，同时也会接交管局其它的信息化项目。

我入职一个月被授命担当二手车过户公共服务平台项目的项目经理。该项目是小微和若干关联企业一起承接开展工作，甲方是某二手车交易市场，同时项目受市车管所监管。

项目交付产品技术难度不大，但因为小微一切刚刚开始，遇到了一些其它的困难。

2、项目前期方案确定

因为公司战略是车联网，我在项目前期就“公共服务项目”与公司战略匹配性与和分管研发的直接上级进行沟通，我的上级又与公司其它高层交流，初步意向接下项目。在确认资源有保证后，我开始推进项目工作，与客户接触，获取初步的产品客户需求资料，明确客户期望产品服务提供的形式。

总结下来，客户对产品的初步要求是：

1）交付安卓与iOS版App，供二手车经销商与一般用户使用，对公共服务。

2）交付微信小程序，供二手车购买方使用，对公共服务。

3）交付BS应用，供二手车市场管理过户使用，对监管方服务。

4）一切在3个月内交付客户使用。

这里面除时间风险大外，有一个更迫在眉睫的问题，当时已招聘人员不具备某些研发技能，比如没有人有iOS开发经验。我拿这点和领导交流，期望领导有犹豫后，我就提议与客户延长交付的时间点。领导听取汇报后，要求现有安卓人员在项目中使用混合开发技术。

项目前期的方案就这样大体确认了，而混合开发这个问题在后面爆发开来。

3、客户需求管理

在经过关键干系人识别后，我慢慢捋清了二手车过户公共服务平台项目的客户。这个项目首先是小微股东的参股公司甲，接到甲的参股公司乙的项目，乙接到的是二手车交易市场的单子，而二手车交易市场是在市车管所监管下开展工作，这样一梳理，大体包括：

1）甲，乙公司代表直接甲方，日常沟通交流以获取主要的项目需求。

2）二手车交易市场客户作为平台最终部署的使用方，监管过户工作，所有需求也会经过其确认。

3）市车管所代表整个项目方案的监管方。方案流程，细到数据字段的内容属性需要经其审核。

4）二手车交易市场业主，会在使用产品后，给出意见。

外部客户这么多，需求出现问题是难免的，这个倒不是项目的瓶颈。多年项目管理经验，我对客户需求梳理，分析，管理已十分熟悉，在之前项目中一年多几百条story来回折腾也搞得定。项目管理工具方面，对客户沟通是通过维护需求跟踪矩阵文档来进行；内部是我自己在网上找的禅道免费版安装部署来进行项目管理，分解登录客户需求，配置产品模块，分配研发任务。后期因为我还兼任了测试工作，所以bug登记与跟踪也都是我一力完成。

说回需求的问题，无非是甲客户认为乙客户的方案要改，或是交易市场认为乙客户的需求要改，有时甚至是甲客户认为市车管所的方案要改，当然也有客户自己提的重要功能方案来回改四次的情况。

比起需求调研的困难，我倒觉得变更没有实质性的难度。我已经将所有需求进行了管控，变更分析就像探案一样，慢慢找出原先的需求来源是哪里，是否有什么不足，变更要解决什么问题，是否可有其它代价更小的方案。影响小的变更我自己就可以负责排版，影响大的变更，像是临近发版本或是改架构等，交由项目管理委员会决定。

之前有人问我管理团队时，如果变更频繁，团队成员不愿意怎么办？我理解研发同事，包括UI，都是害怕自己的劳动成果得不到尊重才会有抵触，我印象中好像没有遇到这种情况，首先作为项目经理，要做好需求分析梳理，争取一次性确认，可以通过DEMO版本与客户确认，避免频繁需求变更；即使客户仍然频繁变更，也要界定好变更的原因，不是开发人员工作没有做好导致，不打乱战。

项目经理心中要有一本帐，一听到有人提起功能，要条件反射似的判断这属于哪个需求，当前研发的状态，是否涉及变更...

4、产品设计

二手车过户公共服务平台项目中的客户需求沟通交流，比起我听他人做过的政务项目、军工项目要顺畅的多。我听说有的项目中需求难确认、产品难设计，客户本身工作繁忙没时间配合是一个原因，还有一个很重要的原因是客户认为自己是耗费巨大心力才掌握了业务能力，根本就不相信来做需求调研的小朋友问几个问题就能掌握。我理解这是对自我存在意义的维护，在任何企业都有这样的现象，谁也不愿承认也不期望自己可以被随便替代。

具我的经验，去做需求调查得先做功课。一般政府单位的工作都是严格听从上级安排，一层层从国家部委，省级机关，地市机关直到最基层单位，部分单位可能有双线管理，但都是按上级文件精神来，再根据地方情况做出方案汇报上级批示。这些政策法规就是大家共同遵循的工作指南，也是需求最全最本源的来源。如果在向客户进行调研前查阅相关指导文件，形成产品功能的大致框架，能在调研时有很大作用。带着框架去调研，我来说，您确认。客户不想被一句话询问“您想要什么样的功能”，这样会吐槽提问的人：我雇你来干嘛的，我自己做不就好了。

二手车过户公共服务平台项目中可能是因为甲方和交管局有多年合作经验，需求获取比较顺畅，也很乐意沟通讨论，所以疑问消除的很快。但在项目中甲方对于产品设计方案管控过于强势了，反倒出现了另一个极端。

我在之前做车载导航项目中，从09年开始就对接客户，将客户需求转换为产品设计供人查看。那时还没有Axure和墨刀，因为公司崇尚日系导航公司做法，Visio也很少用，都是在Excel上画出线框迁移图。

在二手车过户公共服务平台项目中，客户有几个一定要实现的设计：

1）二手车过户双方的操作与二手车经销商的操作一定要在一个App下完成，不能在网页上操作，不能分成两个App；

2）二手车经销商通过App登录车辆所有信息，让App成为其资产销售管理的工具，也可让公众潜在买家通过App查看其待售的车辆。

回看最终交付的产品，初步满足了客户的要求，但是我仍有自己的想法：

1）客户想利用移动手机的“便捷性”，让二手车经销商在何时何地都可以通过App来登录车辆，过户双方也只能通过手机来完成过户。这样却让登记过程苦不堪言。因为按照客户要求，经销商要通过手机填写车辆的配置信息；过户登记的双方要把身份证，手机号相关信息与图片，视频，车辆行驶证、登记证相关信息与图片全部通过手机录入，需要四五页一项项填写，总共信息有二十条左右，后台校验关键项不通过要打回，用户修正后重新提交。虽然按客户要求，App最终交付了身份证，车辆行驶证与登记证的图片文字识别，却其实把过户办证工作人员的工作量转嫁给了只能通过在一个小屏幕上填写信息的买卖双方上。我查看房屋过户登记的相关应用也仅有预约与提示办证流程材料的功能，没有要求所有信息都由公众填写。

2）客户要求很多功能一步到位，强行要求多个使用场景合并，让整个产品显得很“臃肿”。我在初期一直以为这是一个类似瓜子的二手车售卖平台，后来才逐渐发现其实主要是对公众及二手车市场服务的二手车过户平台。当然这也是我和客户一步步推演，去除逻辑漏洞后的较为正常的结果。首先在这个项目中，二手车经销商是与固定的二手车交易市场建立合作，而客户要求按照瓜子等产品形态作为竞品去设计产品。即使产品表现层与资源层勉强达到瓜子的水平，但背后的业务支撑不同，也无法达到最优状态。其次是如果二手车售卖的流量起来了，再去做过户支撑也许更好，但现在二手车交易市场首先的刚需是为即将开始运作的过户大厅提供信息化流程支撑，二手车售卖平台及商户的车辆销售管理是锦上添花的功能噱头。客户强行要求同时提供服务，并且把不同场景杂糅在一个App中，很是考验我的产品设计能力。

整个过程下来，最初以为比较简单的过户功能，也在客户层层加码的想法中增加了各种流程分支，复杂度上了几个台阶。让我再不小瞧类似项目。同时我也更加明确了一个辅助设计的方法，就是抓住数据流这条暗线，谁在什么场景提供什么样的数据，数据在流程运作过程中内容会发生什么变换，应用需要怎样主动干预来确认数据正常。这样产品功能才能正常跑通。

客户期望在二手车过户公共服务信息化中将流程重建，节省公众时间，减少跑窗口的次数，初衷绝对是没有问题。只是过于依赖信息化了。以我的亲身体验，跑窗口办证的普通人员都是偶尔一次需要办证，来到陌生环境下更多感受到的是局促感，在这种情况下，能有专门设置的一对一的真人办证管家才是其最期望的。当然考虑成本与管理因素，暂时无法达成，但至少现在有的政务中心设置了志愿者，就在几个办证窗口之间来回走，主动询问来人需求，指明下步流程。有的地方还专门在叫号机前设置专人预审材料完备性，即使是老年人来也耐心说明，服务到位很多。真人的服务暂时是无法被智能系统取代的。

5、团队管理

项目管理委员会成员包括项目发起人，我的直属上级，以及各客户所在组织的代表。日常就是微信群交流，每日汇报上级项目情况，我也跑过两次市车管所与交易市场进行交流。重大节点时我会在会议上做汇报。

因为产品要调取图片文字识别服务，且系统因并发量与用户规模等因素，部署方案是采购物理机来进行，这一块皆由关联公司甲来完成，日常由我对接。

项目研发团队除我外，包括架构师，后端，前端，UI，九人左右。没有单独招聘测试，运维与产品经理。日常要求早会，研发人员晚上对我汇报进展。

因为是创业公司，团队建设经历了一些事情，我有一些想法：

1）及时与上级对齐人员安排。在这家公司，招聘工作主要由我的上级担当，我需要主动和上级确认新人的项目安排。有时一天来十人左右，根据其岗位职责与项目需求，还有其意愿进行分配，和上级汇报确认。

如果没有配合好，只能是自己和团队来承担了。比如在项目中需要前端开发人员，但最近上级招来的一批人中没有实际商用产品前端开发经验，上级那边又暂时不会招人了，我只能逼着后端人员去开发前端，如果后端有意愿还好，没有意愿也没做好的人，做不出成绩，上级不满意，处境就不妙了，增加不稳定性。

再就是创业公司团队建设可能出现反复。比如上级在一名高级UI入职两个多月后，认为招聘错了，期望留出空缺给产品经理，第一次是平平和和的向我说明，我误以为上级只是考虑，但第二次快到三个月时上级再次提了出来，我确认后只得向UI说明情况，那次裁人是我很不愿看到的。

所以之后我会认真与上级确认最近公司的招聘需求与团队构建想法，避免配合不佳造成的问题。如果仍需要A岗做B岗的事，我也会根据其意愿进行推荐，保证其成长性。

2）团队成员经历过一次被客户“带跑”的情况。因甲方与公司内部的项目发起人在某些需求上有不同想法，一次甲方采用欺骗的手段，把四名项目成员带到其办公场地进行开发，我告知公司项目发起人知晓后，其也只得默认，大概一个月之后四人再返回。

每次想到这段经历，我都感叹自己之前把创业想的过于美好了，可以绕开在大公司中的条条框框，恣意的向上成长，但仅仅是最初的核心研发团队的构建就摔了这么惨。让我不禁对那些创业成功的人心生敬畏。

6、交付

整个项目在需求慢慢明晰的过程中，我是按周为敏捷开发周期规划的迭代。由我分析各项任务需求之间的关联性，与残存bug的严重性，告知开发人员本周工作的优先级，确保基础的模块、影响他人进展的任务先进行，一切均以禅道为工作导向。总之一直保持以最精细的视角审查最基本可用的版本功能，确认不能倒，迭代新功能根据客户关注度与效果来决定是否发布。

为了保交付时间点，会有安排加班，但基本也只在交付日，其它时间都是七点不到，大家就散了。说到加班，有次团队聚餐时一位同事感谢我会一起加班。我觉得项目经理一起加班是很正常的事，自己最开始做研发那会，大家都走了，就我一人在办公室加班解决问题，如果leader在，会对研发人员起到带头作用。

另外在使用禅道后，我对项目管理工具有了一点新的体会，除了用于大家日常了解项目状态，共享信息，指导工作外，项目管理工具的功能还可以化解矛盾。在没有项目管理工具前，开发人员都是直接与项目经理进行汇报交流，进度不理想或任务繁重时难免有情绪；使用项目管理工具后，一切任务都“物化”了，貌似都是平台给开发人员派发的任务，大家交流也都是以平台为主题，转移了一些项目经理身上的压力。

产品部署交付试运行的节点，我会准备PPT，亲自到二手车交易市场进行宣讲说明，对功能进行讲解，把全流程演示一遍，回答现场甲方及各窗口岗位代表的问题。最终除部署版本及源代码外，还提交了完备的部署文档，设计文档，测试报告，用户手册。

7、技术

因为甲方的偏好，也因为一座城市一天下来二手车过户交易也仅是几千例，所以后端系统是通过自采购一套浪潮服务器进行虚拟化部署来完成。服务器上没有配置集群，仅为了数据备份而做了系统冗余；虚拟机系统配置CentOS；采用 MySQL，Redis 及文件服务器以作图片、视频等过户信息存储；采用 Nginx 及 Spring Boot 技术对外提供接口服务，即使以后要上微服务集群，也可扩展；采用 Vue + Element 作为前端开发框架。

因为有成员对运维部署工作感兴趣，我给了他负责整套系统的部署的实操机会，效果也不错，所以即使公司没有招运维人员，项目也可正常上线。

整套系统最头疼的其实是为了开发iOS版本而采用的混合开发框架，几种框架选择后，项目确定采用领导推荐的ionic。安卓研发同事半路出家学习ionic的typescript开发，上手慢，且还是需要专门的前端同事来辅助，特别是损耗了安卓开发的经验优势，出了一点问题，团队没有专家解答，只能上网查，一个一个方案试，拖慢了整个进度。最关键的是ionic不支持拍摄定制水印的视频功能，也不直接支持云闪付插件，仍需要利用中间件后使用原生开发。且最终的苹果商店上线审核版本也是需要Xcode来编译。最后只好寻找外包来补齐这块，不过提交苹果商店并对应审查意见仍是我们自己做的。

8、回顾

对应最初的目标进行回顾：
1）交付安卓与iOS版App，供二手车经销商与一般用户使用，对公共服务。

基本的过户功能除涉及甲方资源（如银联账号与备案网址的SSL证书等），均已交付。iOS通过苹果商店获取，安卓通过部署服务器获取。不同手机扫一个二维码自动跳转各自平台下载。

车辆行驶证与登记证的图像文字识别均可正常免费使用（之后我只在科大讯飞的付费版服务中才见到此功能）。

2）交付微信小程序，供二手车购买方使用，对公共服务。

因甲方未能提供备案网址的SSL证书，项目选用的前端方案没有交付。