# IPD预研（Charter）流程的关键点
写这篇文章的时候，我正在回想自己第一次接触IPD Charter时的困惑——那是一份厚得像个枕头一样的文档，密密麻麻的文字让人望而生畏。后来做多了才发现，Charter其实没有那么可怕，关键是抓住几个核心要点。今天我就把这些年摸索出来的经验分享出来，希望能帮你少走点弯路。
先弄清楚：什么是IPD预研Charter
在展开讲关键点之前，我觉得有必要先说清楚Charter到底是什么。简单来说，Charter是一份"立项说明书"，它是产品开发项目正式获批之前的那道门槛。你可以把Charter理解成一张"路线草图"——它不追求面面俱到，但必须把"要去哪里、为什么去、怎么去、需要什么资源"这几件事说清楚。
IPD体系里有个核心理念叫"做正确的事，再正确地做事"。Charter存在的意义，就是帮助团队在"做正确的事"这个阶段把好关。很多项目做到一半发现走不下去，往往就是因为Charter阶段没有把问题想透。我见过太多团队急匆匆地启动开发，等到快交付了才发现市场根本不需要这个功能——这种教训太深刻了。
关键点一：问题定义必须精准，不能模糊
这个点我放在第一位，是因为它太重要了，又太容易被忽视。
我见过不少Charter文档，开头就是"我们的产品要解决用户的XX需求"。这种写法猛一看没问题，但仔细一读，你会发现"用户是谁"没讲清楚，"XX需求"到底是怎么回事也没说明白。这种模糊的问题定义，后面的分析再漂亮也是白搭。
那什么样的问题定义才叫精准呢？我给你举个例子。假设你要做一个企业管理软件，不要一上来就写"提高企业运营效率"，而要具体到"帮助年产值在5000万到2亿之间的中型制造企业，将采购审批周期从平均7天缩短到3天以内"。你看，这样问题就变得可衡量、可验证了。
问题定义精准的好处是什么？它能让你在后续的论证中始终保持聚焦。我个人的经验是，Charter评审的时候，评委最喜欢问的问题就是"你说的这个'痛点'，到底有多痛？"如果你能用具体的数据、真实的案例来回答这个问题，基本上就成功了一半。相反，如果你只能给出一些模棱两可的描述，评委心里的疑虑就会越来越大。
还有一个实用的技巧：在写问题定义之前，先做一个小范围的调研。不用太复杂，找三五个目标用户聊一聊，听听他们到底怎么看待这个问题。这个过程可能会花你几天时间，但它能帮你避免很多方向性的错误。薄云在服务客户的过程中也发现，那些前期调研做得扎实的项目，后面的Charter评审通过率明显要高很多。
关键点二：商业论证要经得起追问
商业论证这块，很多Charter写得云山雾罩，要么是一堆漂亮的财务模型，要么是过于乐观的市场预测。我来说说我认为比较扎实的商业论证应该是什么样子的。
首先是市场规模和增长趋势的估算。这里有个常见的误区，就是把"整个市场规模"和"可触达市场规模"混为一谈。你不能说"中国有10亿网民，所以我们的市场是10亿"，而要说明白："根据我们的调研，有XX%比例的网民存在YY需求，对应的大约是ZZW的市场容量"。这种细致的拆分，能让你的论证更有说服力。
然后是盈利模式的可行性分析。我见过一些Charter，盈利模式写得非常笼统，比如说"通过订阅收费和增值服务获得收入"。这种写法不行，你得说清楚"订阅定价准备定在多少钱一年""目标用户中有多少比例愿意付费""第一年的预期付费用户数是多少"这些问题。不用保证完全准确，但要有清晰的逻辑链条。
最后是投资回报的测算。IPD体系对这一块有比较成熟的方法论，我就不再赘述了。我只想提醒一点：测算的时候最好做三版——乐观版、基准版和悲观版。很多Charter只写乐观版，看起来前景一片大好，但实际上评委心里很清楚：现实往往不会按照乐观版发展。你主动呈现悲观版的风险，反而能体现出你对项目的深度思考。
关键点三：团队配置和角色分工要清晰
这部分我想说一个观察：你很难通过Charter本身来判断一个项目能不能成功，但你可以通过看团队配置来获得很多信息。
一个好的Charter，应该清晰地列出核心团队成员的背景和能力，而且这些能力要和项目需求相匹配。比如你要做一个AI驱动的产品，团队里却没有在机器学习领域有深厚积累的人，那评委自然会问："这个技术难点怎么解决？"你不能说"我们打算招人"或者"外包出去"——在Charter阶段，团队能力就是项目能力的一部分。
另外就是角色分工要明确。我见过一些Charter，团队成员列了一长串，但每个人负责什么、汇报关系是怎样的，统统没写。这种情况会让评委觉得团队根本没有想清楚怎么协作。薄云的项目经验表明，把"谁负责什么、决策谁来拍板"这些问题写清楚，不仅是为了应付评审，更是为了让团队自己在后续执行中有章可循。
还有一点经常被忽视，就是要识别项目所需的关键能力缺口。诚实地面对这个问题，比假装什么都没问题要好得多。你可以在Charter里写："目前团队在XX领域经验不足，计划通过外部顾问或合作的方式来补足。"这种坦诚的态度，往往比掩盖问题更容易获得认可。
关键点四：资源和时间规划要切合实际
很多Charter在这块会走两个极端：要么是极度乐观，把时间压得很紧，好像项目能一路绿灯、毫不费力地完成；要么是过于保守，把各种风险都放大，导致资源需求膨胀到不切实际的程度。
我想说的是：资源规划的核心是"够用就好"。不要为了显得项目规模大，就把各种资源都往里塞；也不要为了讨好领导，就把时间压缩到根本不可能完成。IPD体系提倡" Stage-Gate "的阶段评审机制，Charter阶段不需要把每一步都规划得清清楚楚，但关键里程碑和对应的资源需求必须想明白。
具体来说，你需要回答这几个问题：项目大约需要多长时间、分为几个阶段、每个阶段需要多少人、预算大概是多少、有没有依赖外部资源（如采购、第三方服务等）。把这些写清楚，评委就能对项目的整体节奏有个数。
我个人的经验是，在时间规划上要留出合理的缓冲。不是说故意把时间写长，而是要把"需求澄清""技术预研"这些容易被忽视的环节考虑进去。很多项目Charter阶段定的时间表，到了执行阶段才发现有几个关键环节没算进去，最后不得不一改再改，反而更耽误进度。
关键点五：风险识别不能走过场
风险识别这块，我发现很多团队的Charter写得像是"标准模板"——随便列几个风险，然后配几句不痛不痒的应对措施。这种走过场的做法，评委一眼就能看穿。
真正有价值的风险识别，应该是团队认真思考过的"我们这个项目可能会在哪里翻车"。不同类型的项目，风险点完全不一样。比如技术研发类项目，最大的风险可能是关键技术路线选错；市场导向类项目，最大的风险可能是需求判断失误；资源密集型项目，最大的风险可能是关键资源获取不到。
写风险的时候，不要只写"技术风险""市场风险"这种大类，而要具体到"如果我们采用的XX算法在真实数据上表现不及预期，有没有备选方案""如果目标市场的政策发生变化，我们的应对策略是什么"。
薄云在协助客户做Charter评审的时候，发现一个规律：那些能把风险识别写到点子上的团队，通常也是执行力比较强的团队。因为这说明团队真的有在认真思考项目可能遇到的困难，而不是在应付文档要求。
关键点六：Charter评审本身也需要方法
说了这么多Charter的关键点，我最后想说说Charter评审这个环节。很多团队把Charter写完就万事大吉了，其实评审也是流程的重要组成部分。
首先要选对评审人选。理想的评审团队应该包括技术专家、业务专家和财务专家，他们能从不同角度来审视Charter的质量。如果评审团队太单一，有些问题可能就发现不了。
其次是评审前的准备工作。团队不要直接把Charter丢给评委就完事了，最好能做个简短的背景介绍，让评委快速理解项目的来龙去脉。评审时间通常有限，把时间花在刀刃上很关键。
最后是对待评审意见的态度。我见过一些团队，评委提了意见就急着解释或反驳，好像被质疑是件丢脸的事。其实完全没必要。评委提意见，说明他们在认真看你的Charter，这些意见往往能帮你发现盲点。即使有些意见你不同意，也可以留在后续讨论，Charter本身就是在迭代中完善的。
写着写着就扯了这么多，希望能对你有点帮助。IPD Charter这个流程，看起来繁琐，但如果你真的静下心来把每个关键点都做到位，后面的执行阶段会轻松很多。项目失败的原因有很多，但Charter阶段没把基础打牢，绝对是最可惜的那一种。
如果你正在准备做Charter，不妨把这几个关键点再过一遍：问题定义够不够精准、商业论证经不经得起追问、团队配置是不是合理、资源规划是不是切合实际、风险识别有没有走过场、评审工作有没有做到位。把这些问题都回答好了，你的Charter质量应该差不了。
