前言
有幸参与和负责过国内百强企业的Saas产品项目，一直想找个时间把项目全历程总结并分享出来。产品经理是如何从0到1接触并完成整个产品项目的，中间会经过什么环节、什么流程，需要具备什么技能，输出什么内容，取得什么成果……这一切的一切，我都将呈现于笔下。
如有雷同，不甚荣幸。
项目通知
我没想到，身为产品经理的我也需要写SOW项目计划书。
自上次驻场产品需求调研回来，一直在整理客户用户场景和业务规则的梳理，内容繁多且杂，而且还需要一边维护系统的正常迭代，着实有点压力。
就在我在疯狂敲击键盘的时候，领导突然出现在我的背后，吓了我一跳。
领导说：上次调研整理得怎么样了？
我平复了下惊吓的情绪道：内容有点多，还在整理，差不多这周能输出一份完整的内容。
领导欣慰地笑了笑：那就好，项目准备签订了，到时候要出一份SOW出来给到客户确定。
我说：SOW？
领导解释道：就是项目计划书，等下我给份之前其他项目的计划书给你，你按照上面的流程先做一份，然后找我核对。
我说：有标准模版就好，这样我写起来也比较快，什么时候需要写完？
领导抬头估摸了一下：下周三吧，刚好可以把你这周整理好的内容贴进去，里面有遇到什么问题可以直接问我。
我回答道：好。
SOW？项目计划书？作为产品经理写过很多文档，倒是第一次接触项目计划书，不错，又可以学到一个新东西。
框架梳理
在微信收到领导发来的文件后，我打开看了看，这是一份国内某头部运动品牌Saas产品项目的项目计划书。
看着足足有60页的内容，我深吸了一口气，不过随后又放松了下来。
在之前驻场产品需求调研时已经收集和整理了10几份调研记录了，SOW项目计划书无非就是按照框架将内容梳理在一起罢了。
通过阅读和思考，脑海里渐渐有了一些框架：
1、文档封面
引入眼帘的是SOW的文档封面，标准的项目计划书格式，包含项目名称、解决方案提供商名称、日期、版权声明、文档基础信息、版本修订信息。
2、项目概述
项目概述的内容需要以简洁精练的语言，归纳出整个项目的核心内容。
项目概述主要分为项目名称、项目背景、项目需求、项目目标、项目范围。
- 项目名称：需要提供完整的项目全称，以及在后续文档中提及到项目时所使用的简称；
- 项目背景：主要描述客户方的概括、现状，以及基于现状对于解决现状的需求；
- 项目需求：在上一次驻场需求调研时的业务场景需求概括；
- 项目目标：希望通过Saas产品达成什么样的业务目标、管理目标等；
- 项目范围：Saas产品的项目范围包含标准工作、定制开发功能、系统对接等；
- 产品模式：Saas模式还是本地部署模式，涵盖内容包含系统对接、定制开发等；
- 超出项目范围的内容：脱离工作说明书的功能、模块需求，本项目使用范围只包括中国大陆地区；
- 假定及约束：假定和约束主要为本文档的假定条件，示例：合作。则约束为进行合作时双方应该遵循的准则。
3、项目内容
项目内容是整个SOW的核心，项目内容涵盖了客户所有的业务场景和需求，以及解决方案的思路和逻辑。
对于这块可能每个公司都有自己的标准，这里基于产品经理的“惯性”，我们还是将整个项目内容当作一个单独的部分来梳理，体现出结构化思维和逻辑性，在呈现专业性的同时，也能让客户读得懂。
项目内容大体结构按“分点答题”的方式，对于客户的核心的业务场景和流程，自上而下拆解：业务需求说明、业务分析、解决方案、业务规则。
- 业务需求说明：以描述的方式说明整个业务场景的概括；
- 业务分析：针对于业务场景，设计哪些需求要点，以及这些需求点在业务场景中所实现的目标；
- 解决方案：根据业务场景及分析的需求点，Saas产品提供什么样的解决方案；
- 业务规则：在解决方案中涉及哪些业务规则，计算方式是什么；
这一部分的内容，可以根据在前期驻场产品需求调研的内容或者远程沟通的内容进行归纳总结。
值得注意的是，业务场景本身是有一个顺序的，而不是单独将几个业务场景罗列进去。业务场景可以存在时间线的先后顺序，项目内容则按照这个时间先后顺序进行一个场景一个场景的梳理。
4、技术需求
除了业务需求外，Saas产品项目还涉及到客户部署系统所需的技术方面的需求，其中包含软硬件等维度的需求。
这一块的内容刚接触时也是头大，毕竟身为产品经理从来没有考虑过这一块的内容。
但询问后才知道，其实SOW项目计划书不一定全部是产品经理写的，分的几块内容可以交由其他同时进行协作，而技术需求这一块很大一部分是系统架构部门梳理的，产品经理只需要提供客户当前的情况数据，系统架构部门的同事就可以基于客户实际情况输出一份技术需求表。
技术需求包含：总体需求、硬件架构（正式、测试环境资源要求，硬件拓扑架构、软件架构）、业务灾难恢复（业务灾难假设、系统灾难恢复要求、备份与恢复解决方案要求）、其他硬件要求、性能要求、压力测试要求等等。
5、项目实施计划
有了上面的准备，下一阶段将对于客户Saas产品项目的上线进度罗列出一份计划清单，告知用户我们将如何进行项目推进，每一个环节时间节点是怎样的，输出交付什么内容。
这一部分基本是有客户双方的项目经理制定并整理的内容，主要包含项目阶段与交付物、项目工作方法、项目实施交付件、项目验收标准等。
项目实施计划的核心在于各个阶段的时间进度把控，包括与产品经理、技术经理、系统架构等同事沟通每一个阶段预计需要的时间和安排。
一旦时间有所变动，则需要立即拉起会议与客户方沟通时间变动情况，及其变动的原因，确保双方对于进度推荐和彼此的情况有所了解和准备。
6、其他内容
其他内容不是真的是“其他内容”，而是一些通用的SOW内容的合集，这里就不一一展开，只做简单的罗列和说明。
标准的SOW项目计划书需要遵循市场上合作的标准规范，则有些内容是可以直接使用的。主要内容包含：工作期限、项目风险、变更管理、双方对接人、项目组组织成员和职责等。
7、SOW项目计划书签订
最后的最后，整份项目计划书整理完成并与客户方沟通确认后，由双方代表人员进行签字确定，并存档。
这样，SOW项目计划书阶段才算是真正完成。
小结
通过梳理SOW项目计划书，不知不觉就输出了一个模版。
难得的一次总结，也顺便将之前的项目又重新“复习”了一遍，对一些场景和内容的理解也更加深刻了些。
果真，坚持写作和深入思考同样重要。
未完待续
经过这一次的SOW项目计划书的编写事项，我以为事情应该告一段路了。
接下来，就回归到产品经理日常工作流程，开始着手写需求方案了。
未完待续……
如果本专栏对你有帮助，不妨点赞、评论、关注～
