如果是一位IT产品经理，应该少不了要写产品相关的工作方案。之前有分享过如何写IT产品规划，那是从全局角度对产品做的整体规划；具体落地的话，则是以项目为单位来开展，以达成一项项里程碑。那么，对于某个具体项目的建设方案或工作方案，是如何写的呢？

项目是整体产品规划的一个里程碑，因此项目建设方案要表达的范围和产品规划类似，只不过范围缩小了，主要聚焦当前要达成的里程碑目标上。方案的5W1H，可以从背景目标、技术方案（方案设计/工作方案）、实施策略、计划安排、风险及应对几个方面来表述，这几个方面也可以直接作为方案材料的章节。

这部分主要对两个W——WHY & WHERE 进行说明，描述该项目应对的需求或问题，以及预期达成的目标。需要强调的是务必把预期的输出成果和目标效果说清楚，其中有两个关键词：用户和场景。

用户：好的产品是找准用户的，所以满足的是谁的需求、或解决的是谁的问题，这点必须很明确。用户如果不明确的话，项目做完之后就不知道该向谁去推广了。

场景：具体的需求或问题一定离不开场景的，场景说明的就是项目的输出成果会在什么时候按照什么流被使用。这一点如果不明确的话，用户拿到产品可能也不知道这些新功能或新特性有什么用。

这部分主要对WHAT & HOW 进行说明，即说明为达成目标，具体进行怎样的产品设计以及采用怎样的技术方案，包括产品的UI设计、交互设计、架构设计、技术选型、流程设计等等，总之就是把具体怎么做说清楚。这个关键的关键词是：逻辑性。

方案与目标的映射逻辑

Dieter Rams的设计十大原则中提到过：Good design is as little design as possible. 至纯至简，好的设计直击目标，不做额外无关的设计。常见表述不清的问题，往往是看不出方案和目标有什么关系。

自上而下的表述逻辑

对于具体方案的表述一般先来张总图，说明方案涉及到的几个方面，然后再每个方面分别阐述，并说明各方面之间的关联关系。

涉及到架构设计的可以参考如下：

这部分是对HOW的补充，也就是项目在具体操作过程中需要考虑的点。

举几个例子，例如”平滑演进“，说明的是新开发的功能，需要和老功能有个过渡的阶段，会引出相关过渡措施；又或者”XX团队联动“，意思是需要跨团队合作，为后面的组织保障提前打个招呼等。

这部分偏软技能一些，实际汇报时可以单独一章节，也可以按需和第二章节技术方案合并。

这部分主要对另外两个W——WHEN & WHO 进行说明，明确组织保障和时间计划。

划定项目团队层次结构图：明确参与项目的团队及各方职责，如果是一个团队那也会分组，如果连分组也不用，那么这部分可以需要。

任务分解与分配：基于技术方案，在实施策略的指引进行任务分解和优先级编排，明确任务的输出成果、依赖关系以及计划完成时间，形成一个完整的任务清单；之后根据职责划分，为每一项任务排定负责人。

资源申请：根据各项任务所需，梳理汇总所需的人力、服务器、费用等相关资源，用于评估项目成本和项目启动准备。

其他涉及到计划安排的事宜也都可以在这个环节进行说明。

这部分是进一步对HOW的补充说明，也就是对实施过程中可能会出现的风险进行预判，并提前设计好应对措施和流程。

这个风险可能是项目实施过程中的技术风险，例如对产品稳定性产生了影响；也可能是项目管理上的风险，例如进度延期、成本超标等。总之，能想到的风险都提前打个预防针是不会错的。

IT产品规划的实际落地有赖于一个个项目能够稳步推进，通过从目标、设计、资源、风险等全方面提前规划，是一个项目成功的开始。磨刀不误砍柴工，大家千万不要忽视了有章法地进行项目方案规划的重要性哦。

题图：Photo by Octavian Dan on Unsplash