本文作者为大家梳理了系统产品规划时需要考虑的一些因素：人货场的关系、成本中心和利润中心，以及企业的架构建模。

2020年已经过去1/12了，这段时间每天都在关注着疫情战役，我们所做的就是尽量做好自我保护，还应该思索未来，勿忘初心，阳光总在风雨后，相信困难终将过去！

作为产品、研发如何规划这一年的个人工作，站在团队、公司的角度是否也该做预算及战略规划了呢？

这两天在朋友圈看到这样一句话“很多职能部门正在由成本中心转变为利润中心，但很少考虑变成投资中心的”；在今日头条上看过一个”北漂二人行“的小视频，大概意思是说“程序员干个十几年才发现，技术是互联网行业中最容易被替代的”，扎心不，我还想补充一句，其实现在互联网电商圈里的产品也是最容易复制的：）。

否则就不会有这个团，哪个选，这个鲜生，那个蜂了，仔细想想无论年轻还是中年，如果仍然在从事产品研发工作，都应该正视下自己，规划下系统产品。

如果你从事的是产品设计或技术研发相关工作，应该会接触很多的系统，涉及很多的业务，作为参与者如何去构建一套好的平台系统，如何去设计产品，我们可以共同去想一想。

人、货、场的关系

• 人：一方面是货的提供方，即我们的公司组织结构，各部门的协作关系，部门内的团队协作过程；另一方面是指货的购买方或使用方，即用户。两方面的人通过货有了联系，才会形成经济活动，从而为双方提供服务，并产生利润。
• 货：是指你提供给用户的实物商品或虚拟服务等，在供应链的体系中，一直在传递的就是货，它的流转效率是供应链能力的体验，也是信息系统能力的考验，更是产品设计的应用软件价值体现。
• 场：场也有几方面，即实际的场所，如仓库、门店等这些为了货的中转而建设的固定场所，也有为了商品呈现而搭建系统平台，各系统间进行数据传输的各网络节点、存取数据的网络中心、IDC或云服务器；当然这个场还包括人从事工作的地点。

以上是我对人、货、场的理解，所以设计规划产品或系统时，我们要从这三方面去考虑，去设计。

用正确的人在正确的地点做正确的事，提供正确的服务，这也可以说是目标。

所以，我们在规划时要理清楚人、货、场的关系。

对于个人而言，由于我们不会涉及过多的系统，虽然涉及跨团队的协作，但我们只是整个组织的一个点，所以我们需要将自己承担的工作任务先理出来，然后确定其边界范围，再去回顾下负责的系统或产品目前的优势、劣势；结合现状梳理一张关系图，去判断其合理性以及改进的点，这样后续的一部分工作就整理出来。

第二步，在团队内进行交流，将个人的规划放在团队中，看看有哪些重复的，有哪些需要其他人协作的，有哪些可以产品化或服务化的，以此为目标也应该可以梳理出一部分新的工作任务，确定基本的目标。

其实这就类似于OKR，寻找目标，然后分析其实现的可能性，最终确定其短期或长期的目标。

OKR好像讲的是自上向下来确定公司目标，宣讲给各部门负责人，确定后由部门以公司目标为目标制定部门目标，再由部门中的各个小团队来以部门目标为目标制定团队目标，最后才到人。

虽然如此，对于个人来讲，如果有一个主方向，那么对于规划会更好。

所有的这些，都离不开人（团队）、货（产品）、场（依托点），剪不乱，理还乱，不理会更乱。

成本中心到利润中心

开始就提到了，公司大部分的团队都属于职能部门，说白了就是花钱的，所以在财务上就称之为成本中心。

作为技术产品部，花钱不输于市场部，云服务器，网络带宽，IDC机房建设，加之人员规模和薪资可能是公司最大的成本中心。

所以你看网上宣布裁员的互联网电商公司，最先裁的人就是技术人员，因为你平均薪资比业务高，人员比其它部门多，最主要还没见到你弄出来啥东西，这个行业目前是最苦逼的了。

部门的预算和团队建设此时应该已经提报给公司了，要清楚这一年你的年花到哪里了，哪些可以省略，哪些需要投入要一目了然。

作为部门负责人或团队领导，这时在考虑降成本的同时更应该考虑如何去赚钱，这样才能体现出你的价值。

如何从成本中心升级为利润中心呢？

说实话我也不知道，但是我考虑可以能过以下几个方面来规划。

1. 与业务部门谈判，尤其是销售、市场部

这样的部门是为公司的创造业绩的盈利部门，而技术产品部是为其服务的。我们为之开发各种应用系统、营销工具如app，小程序，数据分析工具等等。

在保证其业务功能实现的同时，研发部可以与产品部共同针对各个产品进行深入挖掘，进行创新功能的实现，帮助业务部门去产生GMV，从而分得其一部分业绩，不是为了做产品而设计产品、开发功能。

要强调下，这个是要保证业务正常的合理的需求实现前提下才可以谈判，否则你连基本的保障都做不到，你就是找喷；其次要防止吹牛逼，要量力而行，不要套路业务部门。

敏捷项目管理中讲究客户合作胜于合同谈判，在此时可以利用合作而间接的商谈一些可以为之带来利润的项目，实现共盈。

2. 发挥产品技术优势，寻找外部合作项目

技术产品最大的优势是什么？

我觉得我们可以利用为公司提供服务的产品给第三方公司提供服务或解决方案，当然要避免涉及公司机密的内容。

为什么这样说呢？可以了解下，目前互联网电商公司的研发有多少是外包人员，有多少是自招人员。

如果我们内部的项目产品设计的好，可以包装成产品，提供给与我们行业类似或小的公司使用。

所以我们在规划产品，设计系统时要有用户思维，有产品思维，不局限于为了项目上线而工作，如果每个人都有这样的想法，在具体工作中相信会有所帮助，即便不能形成通用的产品，那么在内部也可以慢慢孵化。

如何实现？

（1）开发对外开放平台，开放一些可以开源的项目给第三方使用，既满足公司业务的使用，又能提升公司知名度，同时也可以收取一些费用（如快递100，就是提供相关的查询服务赚取费用的）

（2）帮助第三方进行方案设计与实施，其实这就是让我们的研发产品走出去，在与公司相关客户对接的同时，为其提供必要的解决方案（利用我们成熟的较好的项目去拓展）。

记得在看阿里企业中台实践的书中提到，他们在中台实践成功后协助几个大的央企进行了中台架构设计与实施，虽然我们团队可能比较少，但是比我们小的团队也是有的，无论是研发还是运维或数据组、测试，都可以进行这样的尝试。

我们在系统规划时有这方面的考虑，无论能走多远，终究是有益的，如果转变为利润中心，那么在公司就有其话语权了，因为你不仅会花钱，也会赚钱了。

要有企业架构建模的思想

大家都知道井底之蛙，只会看到那么大一块天空；其实我们在系统规划或产品设计时更多的是经验，所谓的创新少之又少。

应该转变思想，不局限于目前的业务，目前的系统，目前的人。

前面提到了用户思维与产品思维，这也是我最近一直感觉比较重要的两部分。

首先说用户思维，即我们要根据人、货、场中的人所处的点去分析、比较，站在实际的场景去思考我们设计的功能，开发的系统是不是用户想要的，是不是满足企业从上到下相关人的不同需求。

跳出自己的思维，结合实际业务人员的想法会有所改变，变与不变还是不一样的。

其次是产品思维，我们要时刻在心里牢记，我们开发设计的一款产品，而不是一个功能，不是一个小的模块。格局应该大一点，看问题的高度提升了，我们看到的就是一个鸟瞰图，而非局部。

有的时候一直在琢磨，为什么那些牛逼的人看问题和理解问题就是与我不一样，应该就是高度不同。

系统产品是为企业规划，所以企业级建模也是有其方法论的。

企业架构也是分层的，有业务架构、应用架构、数据架构和技术架构几个过程。

业务架构是指业务流程、角色的变更，业务变更与协作，这和前面提到的人、货、场有类似的内容，每年的系统产品规划都应该以业务架构为指导来进行，离开了业务架构，其它的架构都将一无事处，因为与业务不符，如何去满足业务呢。

系统架构是指系统、服务与功能。这个也是我们在网上经常看到的系统组成图，系统是根据业务范围设计的，在规划时要考虑业务边界和系统的耦合度及合理性，多个业务可以划在一个子系统中。

系统结构清晰了，人（用户）使用起来就会方便，角色也容易划分，系统架构师在我眼里一直都是很牛逼的，因为他(她)有业务整合的能力，而且还有技术选型、实现的能力。

数据架构就是对数据、业务对象、交换格式、安全和隐私的规划与部署，目前数据中台各大公司都在建设实践，公司最重的是什么？不是人而是有效的数据, 这里说的是有效，并非什么数据都有用的。

数据架构不仅是业务流和系统间数据流，还应该是各业务对象的交互、协作；个人觉得好的数据架构不仅使系统数据更好的、更安全的存储，更应该是可以通过数据进行赋能，来为企业提供更好的服务。

技术架构是通过硬件、网络、服务器或操作系统等实现其数据、系统的部署实现。如系统发布平台是通过什么实现的，需要哪些开源的软件和自开发工具，网络的跳转如何，前端的图片是如何缓存的等等。

在规划时，要站在企业的层面去考虑，可见一个技术负责人要多么的牛，不懂技术或产品的人我觉得就是在裸泳，不过在现在好多公司中这种状况与“皇帝的新装”中的场景特别像。

作为研发产品人员，未来何去何从，趁此阶段可以规划一下，路在何方，路在脚下。

总结

系统规划时考虑的因素很多，规划就是计划是预算，它是指导未来工作的一个基准，应该沿着规划的目标去逐步实现。

但互联网行业来变化太尼玛快了，你今天刚计划好明天可能公司就没有了，这种情况在这一两年已经见怪不怪了，再回到”北漂二人行”所说的，”技术是互联网行业中最容易被替代的”，我的理解是编码的人越来越多了，而且如果我们开发的产品没有发挥其价值，那么它真的是一文不值。

我们应该考虑各种因素影响，为企业搭建出好的架构体系，开发出有价值的应用产品，将人、货、场真正的结合起来。

最后感谢您的阅读，愿所有的人都平安健康，加油！

作者：倔强的大萝卜；公众号：倔强的大萝卜

本文由 @倔强的大萝卜 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议