蜗牛派最近和朋友探讨如何规划供应链系统及财务系统，从业务架构到技术实现，从具体的功能及设计到数据的流转，涉及方方面面，基于此个人也进行了思考，虽然前期整理了很多FMS、SCM的业务流程，但回顾一下，总觉得还欠缺一些东西，最近刚好在看产品方法论和一些关于思维的书，本篇就试着写下对于系统规划的一点思考，希望与关注的朋友共同交流！
思考问题模式的转换
作为产品或研发人员，我们都是接收需求（业务或产品），创造或改善产品的人（新产品或老产品），这些都是我们习惯的也是一直在做的工作，当有新需求时你首先想到的是什么？
以我个人来讲一般先是将新需求简单理解一下，然后在自己接触的产品、系统中去搜寻与之有关联的内容，然后去想要改造的点有哪些，应该如何去实现，实现时会涉及哪些困难点，不知大家是否也是如此，这种应该属于功能性思考模式，即习惯于针对将需求转换或拆分为多个系统功能，然后结合相关的业务或系统进行扩散式的设计。
目前看这是一种初级的方式，但是对于公司业务、系统比较稳定的场景下的一些小需求是最简单、有效、直接的方式；需求尽快评审，任务会快速分解，项目会及时上线。
但对于一些较大的需求或项目，此种思考方式需要转换，我这里将其定义为系统思考模式即不以单个功能独立的去思考，而是站在系统的角度去讨论、设计。
做电商后端的产品或研发、或做ERP、供应链等软件规划，每个人可能负责其中一个或几个子模块，分工越细，涉及的范围越窄，所以应该增加思考的宽度，站在系统的角度去考虑，将各个模块能够串起来，起码要知道上下游模块的关联影响，这样有助于复杂问题简单化，从系统上也会避免烟囱式设计和重复造车的问题。
功能性、系统性的思考方式没有错，随着业务的熟悉程度、技术能力的不断提升，此时应该用平台思维方式去考虑项目需求。日常应该去多了解多个系统，在平台的角度将多个系统组织起来，形成一个平台架构，此时要考虑的就不是简单的实现，而应该是合理性、稳定性、扩展性。
功能、系统、平台这些还仅是从简单产品设计和系统的方面去思考，技术研发在日常工作中更多的是这种，所以还需要再度升级即产品思维，这也是N多人说的。要时刻牢记我们设计、规划、开发的一个产品，而且它不是孤立的。
一直都说产品思维，什么是产品思维？知乎上有很多讨论，也有很多种答案，「产品思维一种从用户、场景、触达等转化链路出发，完成目标的思考方式。」这个我是比较赞同的，它包括用户思维、价值转换，也隐含了交易模型的信息。
如何规划设计产品
产品可以是一个硬件，也可以是一个软件，也可以是一项服务，我们接触的产品就是软件、系统或一个接口等。
产品无论大或小需要知道为什么要做（Why)
更多的时候要想一下现有的产品是否可以满足，如果不满足存在什么问题。如果是一个从0到1的产品，那么就要了解，实现它能解决什么问题，有没有竞品或类似的产品。
这个通常会在MRD中详细阐述或在prd中更多以项目背景体现，对于为什么去做，一定需要考虑清楚的，不能形式化或程式化。
譬如公司要开发一个财务系统，它和用友、金碟等有什么不同，如果它是一个业务系统，那么它又和现在的一些系统有什么区别呢？
可以按照SWOT（优势、劣势、机会、威胁）去进行拆解，每项都清楚了，大家也就会理解了。
确定业务边界、范围即做什么(What)
要有个概况，我认为此部分可以采用产品架构图的方式呈现出来，它包括哪些功能、模块、上下游系统的接口等。通过它将可视化的具象产品功能，抽象成信息化、模块化、层次清晰的架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路。
产品架构图适用于较大的项目，对于一般的需求就不适合了，此时可以使用最常见的一种方式，即思维导图。
思维导图中有多种模板，最常用的有单向导图、鱼骨图、水平或垂直时间图等多种，在项目讨论、需求评审过程中它还可以作为会记记录的工具。通过思维导图可以清晰展示出相关业务模块，涉及的功能点等。
无论采用可用方式或工具，只要让相关人知道我们即将要做的内容，方向、策略等就可以。
确定目标（Object)
在项目产品实现过程中，经常会设定一期、二期分阶段的完成，尤其采用敏捷的项目管理方式「快速迭代、快速上线、快速试错，快速调整」，这非常适合互联网电商项目。
以目标为导向，来引导项目产品的执行，这就是现在各公司在推崇的OKR工作法，OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法。
产品可能要经历多个项目来实现，项目又可以拆分成多个小项目，所以目标分为终极目标、大目标、小目标等。
对于目标可以按照时间来设定即近期目标、中期目标和长期目标。
选对负责人和团队（Who)
这个非常重要，因为不同的人负责同一个项目会有不同的执行结果，大家可以共同回顾一下我们所经历的项目，有成功有失败，有方向上错误，这和目标(Object)有关，有范围上的错误，这和做什么(What)有关，也有和人(Who)有关的。
不同的人做，产品或项目的质量会不同，这也会影响到项目目标，这里有一个不值得定律，可以参考。
不值得定律，就是如果你觉得一件事不值得做，你就不会把它做好。细细品味好像确实如此，如果项目负责人是公司指派的，但他（她）对这个项目并不感冒，那么他（她）投入的精力就有限，讨论时就不会深入，那么即使最终完成，此项目也只是阶段性的，最后可能会不了了之。
在上家公司曾参与过公司级的信息化系统项目，即利用NC来替代目前所有的系统如SCM、销售系统、门店工具、报表等，经过了解当时技术、产品、业务等都觉得这个项目是耗费资源（人和物），并不能满足我们的业务需求和目标，但是碍于当时CEO要求，只能配合，从项目启动到执行，也就两个月的时间，项目宣告结束，这应该是不值得定律的一个体现。
经常参与一些小需求评审或研发任务讨论会，发现有的人并未全心的投入，多一点工作也不想做，以致于后续要花费很多时间去沟通，严重影响团队氛围和项目测试、上线等，此时他（她）内心就似乎有一种不值得做的态度。
选对人、选对团队成员，是重要的，有时候态度比能力更重要，能力可以在项目执行过程中通过积极学习去提升，但态度有时很难转变。
如何去做，怎么做（How)
这个是设计的过程，也是分解的过程，明确了目标，知道做什么，由谁去做，那么这些资源如何调配，根据短、中、长期目标按照什么样的路径去实现是关键。
对于产品或项目，可以采用产品路径图(RoadMap)或WBS工作分解法，将任务、资源、目标按时间周期有规律的整理出来，后续按此进行跟踪管理；站会和看板是简单有效的方式，提高沟通效率及时了解项目进展，这些都应该在项目真正开始前明确。
这些都是敏捷项目管理的实践，在此阶段确定了必要的方式方法，最重要的还是技术上如何去完成这个产品或项目，所以个人觉得在此时要进行技术选型、各开发团队间如何协作、不同的技术组（研发、测试、运维、数据等）如何配合等；面对业务产品的需求变更如何响应和应对，虽然敏捷强调的是拥抱变化，但是这应该是在不影响目标的前提下的一种变化。
这些有些还是属于大的规划，涉及很多细节还是要在具体实现过程中才能进行，在整个过程中我们还应该让自己始终以满足用户为目标，站在用户的角度进行不同场景的切换，这应该是用户思维的一种方式。
用户不单指个人或一些人的群体，它是一些在某个场景下，某些特征的人或团体的组合，对于用户思维可以去看看俞军方法论这本书，会有更深刻的理解。
风险及应对方案（Risk)
在不同阶段会有不同的风险，产品有营销推广风险，技术实现过程中有技术选型、架构设计等不同的风险，执行过程中有延期的风险等。
对于风险识别与管控是需要提前考虑和规划的，这在项目管理课程中都有针对性的讲解。
在实际工作中，风险一般都是提前根据经验而提出来的，但是在后续实施过程中往往会忽略这些风险，随着时间的推移很多风险都会让大家习惯，而且有些人也会刻意的规避一些风险，这对最终的结果有时会产生很大的影响。
在团队中有时会遇到一种善于迎上的负责人，对于上级领导安排的工作或任务总是拍着胸脯做保证，于风险基本避而不谈，对下则采用强压或推脱的方式，这种情况应该在（Who)阶段识别出来，这也是一种风险。
风险识别要客观的去识别，不夸大也不要规避，主要是针对风险要提出应对方案，这是才是关键。
资源规划(Resource)
人（产品、研发、测试、运维相关资源）只是资源的一种，在产品或项目实现过程中会涉及很多资源，技术方面有服务器资源、网络资源；此外还需要管理层的支持等隐性资源，如充分的授权。
资源就是我们在完成这个项目或产品的过程中，所应用的所有的有形或无形的各种需求的总和，在规划时要充分考虑到这些，以避免项目、产品超支或延期风险。
产出方式及衡量(Evaluate)
用户价值=新体验-旧体验-迁移成本，这个公式很有名，一个项目或产品的成功如何去考核，上线成功就是成功吗？应该不是的。
譬如，之前我们在做财务共享集成项目时，上线时需要完成不同业务线的应收、应付等与SAP的CCP、Brim集成；审核过程中要应用影像、审批流完成在线审核；支付时要与集团的电子支付完成对接；数据通过ESB进行同步等等，这些都是一些产品功能，对于财务部在完成集成后，要有工作效率的提升、人员成本的降低等。
这些是与目标相关联的，对于一个系统，还要考核其相关技术指标，如QPS、TPS等。
规划如何汇报
以上是针对实现产品或项目的整体规划，是借鉴了以前同事的工作方法结合5W2H进行了一点扩展，简化下来就是为什么做，做什么，谁来做（3W)，目标是什么，如何做（1O1H),风险及资源规划和产出价值（2R1E）。
形成一个标准模式，对于大家对产品的认识，在汇报过程中避免无头绪、无方向、无效率的讨论。对于汇报人要依据规划准确的讲解给相关人员，这也是需要方法的。
理论与方法
金字塔原理：这是由芭芭拉.明托提出来的，她毕业于哈佛大学，是麦肯锡公司第一位女咨询顾问。
简单的理解就是在汇报过程中，要先表达中心思想或结论，然后自下而下表达，自下而上的思考，纵向疑问回答、总结概括，横向归类分组、演绎归纳。
具体的原理也是刚刚了解，在汇报过程时对于问题回答时，要先说论点再说论据，对于论据建议3条即可(别超过5条），多了可能就啰嗦了（第一、第二、第三；首先、其次、最后…)。
在组织这些内容时，可以按照时间顺序「如：目前、现在、未来或第一、二、三步的执行过程」、空间顺序「如：地域、部门或属性等分类」、重要性顺序「如：会员、核心用户、普通用户」、逻辑演译顺序「推理的过程」。
还有很多分析方法我们可以学习训练并应用，这里汇总下这些名词，有兴趣的可以去百度详细了解。
标杆分析法、SWOT方法、波特五力分析、麦肯锡7步分析法、5W2H分析法、6W2H分析法、5M1E分析、8D分析、SMART原则、360度评估、甘特图、乌龟图分析法。
用户思维与交易模型
这两个是在读俞军产品方法论时提到最多的，用户思维说的个人的简单理解，对于交易模型我的理解是在产品设计和系统设计时都要牢记，它不是指以买或卖过程的货币转移，任何有价值的内容都应该属于交易，它就是利来利往即创造利益、分配利益的过程。
书中原文是：交易模型是指产品经理发现和设计的合理机制，它能促成用户做出某种行为（即交易），且可持续（生态是平衡的）。
此外，要有同理心，开过很多会，经历过多次争吵，应该以实现目标为导向，站在对方的角度去思考、看待问题，还是以前看心学的六字直言：聆听、欣赏、接纳。
总结
本篇从思考问题的方式（功能、系统、平台、产品）开始，到运用「Why,What,Object,Who,How,Resource,Risk,Evaluate」,再到汇报时可以运用的方法理论，是自己最近学习了解的一点认识，分享给大家，刻意的去训练运用这些理论，应该会使自己思考问题更准确、更专业、更合理吧！
