2022-10-12：做产品的思路

对于 PMI 列出的那些东西，在具体需求调研的时候，并没有什么指导性的东西，不设计到具体业务的东西，都是空谈，理论大于应用，看完之后，觉得并没有什么指导意义，至少在开始的时候，一个孤零零的需求分析，怎么分析？头脑风暴？客户调研？这些都是些框架性的东西。怎么客户调研？只有涉及到指导具体的行动，框架的东西才有它的价值。 PMI 就是如此，给予了相当多的框架，这种框架不指导具体行动，指导的是框架的方向，而且与现实相关的东西更是有相当大的落差。涉及到具体的人：业务、项目内部成员、企业内部领导、企业外部领导，这些东西是更具体的问题。

其也并非是没有意义，至少 PMI 尝试将项目思路框架化，一般化。如果没有这个过程，如果没有这个一般化框架的概念，又是如何能将其规范化、条理化。如果不能规范化、条理化，那项目的执行思路就将紊乱，项目的周期以及工作安排将无法着手。

综合以上的情况，具体的项目安排，在 PMI 给出的一般化规范的基础上，再根据具体情况，进行删减和填充，这种执行项目的思路才具有可行性。更具有可行性的思路上，根据具体情况，列出目前组织可执行的环节、已经思考到的必要环节，然后再根据 PMI 的一般思路，进行一定的框架增加，然后再填充框架，最后罗列出自己组织可做到的最优一般化步骤。

现在能想到的模块：

1. 市场现有相关产品类型
2. 市场利润比例
3. 盈利点罗列

做完这三点之后，然后根据具体利润点，以及自己着重想做的项目类型，来确定要做的具体产品。

在有了具体产品的基础上，再来做竞品分析。根据市场现有的产品，罗列它们的有点以及缺点，还有不足的地方，加上自己的相关创意，产品的需求就可以有一个基本的大方向。

再有了基本需求的基础上，就可以设计基本的 UI，基本的 UI 出来之后，就可以根据 UI 元素进行后端数据库文件的建表，确定接口的规范。这些就是从产品到项目的过渡。

根据实际的项目经验，罗列出来的这些东西暂时不确定是否有遗漏，同时根据 PMI 的一般原则：

• 商业需求分析
• 产品需求分析
• 项目管理
  • 分析阶段
    • 将产品功能对应为技术模块
    • 确定规范
    • 确定接口
    • 罗列技术点，确定技术手段
    • 确定部署的方式以及后期维护的版本升级管理
    • 代码管理以及相关文档的保存维护方式确定（从前期的产品文档到后期的技术知识攻克，以及相关难点的解决思路进行知识管理，对于一个组织来说，知识本身是一种巨大的资产）
  • 执行阶段
    • 采用敏捷管理在看板上罗列功能
    • 建立组织的知识库，将执行过程中的所产生的信息以文档的方式统一保存
    • 根据相关安排进行周期安排，保证项目进度

这些东西是目前已知的项目执行思路，其每一个阶段都是已知必不可少的环节。同时因为许久没有做项目管理以及从来没有做过商业需求分析，只是具有了相关课程的学习经验，以及产品需求分析（产品经理的职责）并没有 PMI 一般化的学习经历，这方面的书籍会在查阅后，以及其他两个环节与 PMI 一般的思路比较后，进行填充。

之所以要做这些事情，是因为一个产品，一个真正具有市场前景，并且符合组织原则的执行思路，是一个项目能否走得长远的关键点。以上是目前所能想到的比较全面的一个思路，对于是否有遗漏的环节，暂时还未能得知。根据以往的项目经验，这已经是一个相对更加全面的项目思路，至于要与一线公司的对比，并没有一线公司的执行经历，所以不能得知。同时里面对项目中知识的保存，并不是从 PMI 中得到的，PMI 中提到要对项目文档保存，以及建立项目管理的知识库，对于过程中的技术知识保存，并没有谈及，这些是从彼德·德鲁克的《知识社会》中领悟到的：知识对于组织而言，是一种巨大的资产，这种资产不能因员工的离职而丧失，必须将其书面化保存。因此，建立组织的知识库，对于一个组织的成长与发展必不可少。