之前犬校里讨论了一类“难度不大但复杂度很高”的项目，我最近正在跟进的事情正好比之前我分享的案例更为典型。

项目是展车模式，车在上市前，一般会参加一些车展，这个时候完整的功能还不一定做好，所以展车模式需要包含以下几类需求：
1.在展车场景下确保用户看到的、用到的是相对正式的内容，例如非正式的logo、无版权的占位素材图的替换等
2.在展车场景下，不适合开启的功能，例如禁用喇叭等
3.本来放在后面版本才实现，需要提前到展车对应的版本实现的功能

简单吧，如果我们定义问题的难易度对应的是任何一个人得出合理解的概率，那么这个问题的难度很低，正常职场人（任何职能）几乎都能把这个问题的解决方案描述清楚。
但这个问题的复杂度极高，主要体现在组织协作和项目计划上。

先说组织。
第一点是涉及到甲乙方。
我们的组织比较特殊，存在甲乙方的关系，我们作为乙方实现功能，上游有甲方提需求，所以我们的需求需要跟甲方确认之后才能实现。
同时，涉及到品牌相关的，例如图片素材、名称等等，统统需要甲方提供。
第二点是我们内部的涉及的组织也比较多。
例如禁用喇叭属于车控团队，展车模式一些进入退出的方式属于营销团队，状态灯属于OS团队，具体的功能项还会涉及到智驾、语音、音乐、三方等多个团队。
我数了一下，这一批需求里面涉及到的负责执行的产品经理一共13个人，得保证他们都能同步确认需求、评审落地。
这两个点耦合到一起，麻烦的就来了，例如把一类图片素材更换成占位素材，需要这样做：
（1）乙方梳理目前有哪些位置用了非正式的占位素材
（2）甲方根据素材表，整理正式版的素材，交给乙方
（3）乙方研发替换素材
听起来好像也不复杂？但推进起来各种漏球，原因有：
（1）乙方至少涉及三个研发团队、四个产品团队的工作，并且他们之间并非一一对应的，有的研发团队承接两方产品的需求，有的产品输出给多个研发团队需求。所以这类素材没有统一的owner，且有比较复杂的协作模式。之前我没跟进过这个模块，有一个产品leader起了张表头，大家填了一下都有哪些素材，我误以为这个leader就是这一类素材的负责人，所以只跟这个产品leader和他对应的研发leader确认进度，导致他们的素材甲方及时提供了，另外有两个方向甲方并没有提供素材，乙方的产品参与度也不高，还在那里等着，直到ddl临近才发现这个问题。
（2）甲方设计新素材依赖乙方提供原始设计稿，乙方曾经统一批量提供了原始设计稿，但是过去一段时间了，所以甲方内部负责执行的同学不知道应该找谁要材料，要到了材料发现格式也不合适，例如一个动效到底是视频还是连续帧。又得掰扯。

再说项目计划。
其实要提到组织的第一点，就是我们很多素材依赖甲方，需求也需要跟甲方评审。
所以上面提到的13个干活的产品经理，不是一上来就知道这里跟他们有关系，我是这么推进的：
（1）跟甲方确认原始需求，我大体识别会有哪些相关方
(2)把所有相关方（包含乙方负责执行的专业同学和甲方提出需求的专业同学）一起拉会，逐条确认原始需求
（3）各专业同学拆分、调研需求，这个过程中可能会发现一些新需求，也可能会发现一些需求不用做
（4）形成最终的feature list，并确认需求owner
听起来好像也挺简单的？我遇到的问题主要有：
（1）上面第三步各自的进度不统一，有些内部评估就行，有些要拉上商务跟供应商评估，有些内部跨团队，有些又反向依赖甲方。
（2）虽然单个需求都不复杂，但是合到一起，一个版本做不完，所以我们拆了三个版本：展车必须有的，展车没有但量产车有的，量产以后OTA的。乙方内部怎么排这三个版本，排完了版本怎么说服甲方接受有些需求后置，又得拉扯。
当然我们有一些量化的沟通手段，就不展开了，但这个拉扯过程毫无疑问是充满着多方参与、边界不清晰、来回反复、不断上升的。

一般这种项目都是pmo跟进，但目前我们资源捉襟见肘，我顶缸来兼任一部分pmo的职能。
之前做产品的时候，有时团队里也没有pmo，产品负责项目管理，但是相比之下，过去那些移动互联网的项目管理实在太简单了，无非是追个排期的事。
如果说解难题像一次又一次挑战身躯庞大的boss，解复杂题就像黑魂速通的跑图，你得关注漫长路线上每一个小怪会不会削减自己的血量，再长的血条也经不住慢慢磨。

汇总起来复盘一下，当然从我的表述中能看出来一些团队存在的问题：
例如实际上有些专业的产品和tpm参与度不高的，上面的所有任务我都会拉会沟通，有纪要有任务，关键点也会在群里艾特，但有的人确实因为各种原因对任务不敏感，遇到问题也不喜欢上报，而是憋着。
例如组织分工上确实是混乱的，例如上面那个图片素材的问题，我下意识地觉得这么重要的模块肯定会有个产品leader，但没有，各个方向各自为战。
但如果把这些都当成客观条件，条件就是这么个条件，负责这个项目的局中人应该怎么做呢？

我总结就是：胆大心细、六亲不认。
胆大指的是不要有任何心理包袱，要侵犯性地向所有人确认进度。语音方向我之前合作不多，担心自己搞不清楚，所以他们每个需求我都跟他们的产品leader确认进度、确认卡点，果然这块几乎没出岔子。
心细指的是要深入各专业的业务细节，甚至要带着项目整体视角的决策参与讨论。如我上面所说，整个项目的难度不高，所以尽管我对某些专业不够了解，但是决策这些需求所需要的信息量肯定是够的。例如一些需求做与不做，如果识别到各专业与甲方掰扯了，我需要站出来参与讨论，引导决策成更容易共识的结论。
六亲不认则是给上面加个程度的描述，不要以为谁谁谁过去是专业的，所以他这儿可能没风险。要把所有执行的人当成傻子，像跟傻子说一样去说明项目背景和节奏，像跟傻子合作一样去检查他们的进度和卡点，像帮傻子一样去帮他们推动解决问题。

闲聊下来，有个同事说心疼我被pmo虐的不行，这个项目确实推动起来挺头疼的，但我觉得这确实是一次有意思且宝贵的体验。
我一直不认为项目管理只是pmo的事情，哪怕自己去分配自己的时间、自己去管理自己的情绪，也会是项目管理技能的一部分。据说造车是上下游协作最复杂的消费类产品，真的挺有意思的。