Login Now 2020年刚开年，十二分之一的日子已经悄然溜走。这段时间，大家的注意力几乎都被疫情牵着走，每天除了做好防护，剩下的心思多半都在琢磨未来要怎么走。那句老话怎么说来着，"不忘初心"——等风雨过去，太阳总会出来的。
不过今天想聊点具体的。作为产品人，今年该怎么规划自己的工作？是不是也该跳出个人视角，从团队甚至公司层面去做些战略层面的盘算？
前两天刷朋友圈，看到一句话挺有意思：很多职能部门都在忙着从成本中心往利润中心转，却很少有人想过要成为投资中心。又在头条上看到一个北漂程序员拍的视频，大意是干了十多年才发现，技术这行在互联网圈里其实最容易被替代。
我想补一刀：互联网电商圈的产品岗，其实也好不到哪儿去。要不然怎么会有"这个团、那个选、这个鲜、那个蜂"的扎堆现象？所以不管年轻还是人到中年，只要还在做产品、搞研发，都得认真想想——系统产品这件事，到底该怎么规划。
人、货、场，一个绕不开的三角关系
做产品久了，"人货场"三个字耳朵都听出茧子了，但真往深了想，每个字都有不少门道。
"人"不只是用户。往上游说，是公司内部的组织架构、部门协作、团队流程；往下游走，才是掏钱买东西的那位。两边的人通过"货"发生联系，经济活动才能转起来，服务和利润才有落脚处。
"货"既可以是实物商品，也能是虚拟服务。在供应链系统里，货始终处于流动状态。它的流通效率，一方面体现供应链本身的硬实力，另一方面也是信息系统能力的试金石——你设计的那套软件，到底能不能打，看的就是这个。
"场"的含义更广。实体层面有仓库、门店这些固定场所；虚拟层面则包括系统平台、网络节点、数据中心，甚至员工干活的工位。做产品规划时，这三个维度都得覆盖到，在正确的地方做正确的事，提供对的服务，目标才算清晰。
对个人而言，我们往往只是庞大组织里的一个点，涉及的面没那么广。所以第一步得先把自己的任务理清楚，划定边界，再回头看现有系统的长短处。画出关系图，判断哪里合理、哪里还能优化，后续的工作方向才能出来。
接下来要放到团队里去看：个人计划跟别人有没有重叠？哪些地方需要协作？哪些东西能产品化、服务化？这个过程有点像OKR——先找目标，再分析可行性，最后拆成短期和长期任务。公司目标层层分解到部门、到小组、再到个人，道理大家都懂。但即便没有自上而下的强约束，个人心里有个大方向，规划起来也会顺很多。
说到底，人（团队）、货（产品）、场（支撑点），这三样是绕不开的。剪不断、理还乱，不理更乱。
从"花钱的"变成"赚钱的"
前面提到职能部门大多是成本中心，说白了就是花钱的。技术产品部尤其典型——IDC机房、云服务器、网络带宽，再加上人头和工资，很可能是公司最大的成本项。所以每到裁员季，技术往往首当其冲：平均工资高、人数多，而且"看不见产出"。
眼下正是报预算、做团队规划的时候。作为负责人，得清楚今年钱花在哪、哪里能省、哪里必须投。更关键的命题是：能不能在控制成本的同时，也给公司挣点钱？
怎么从成本中心升级为利润中心？说实话，我也没有标准答案，但有几个方向值得试试。
第一，跟业务部门谈合作，尤其是销售和市场。
这些部门直接创造业绩，技术产品部则是做支撑的。我们开发的App、小程序、数据分析工具，本质都是为业务赋能。在保证基础功能的前提下，能不能跟产品一起挖掘创新点，帮业务部门把GMV做起来？这里要把握好分寸：基本盘得守住，否则就是找骂；但也不要大包大揽，有多大能力办多大事。敏捷开发强调"客户合作高于合同谈判"，借着这种合作姿态，完全可以聊聊有没有能共同做大的利润项目。
第二，把技术优势变成对外合作的机会。
技术产品最大的资产是什么？我觉得是那些已经打磨成熟的内部系统和解决方案——当然，涉密内容要排除在外。行业里有多少电商公司的研发是外包的、多少是自研的，大家心里都有数。如果内部工程做得扎实，包装一下就能给同行或更小的公司用。
这就要求我们在设计系统时，脑子里要有"用户"和"产品"两个概念，不能局限于"项目上线就完事"。哪怕暂时形不成通用产品，先在内部慢慢孵化也是好的。
具体怎么做？比如搭建对外开放平台，把部分能力开源或API化，既服务内部也打响品牌，还能收点费用——快递100的模式就是例子。再比如主动给第三方做方案输出，把成熟的项目经验复制出去。阿里中台实践成功后，不就协助几家大型央企做了中台架构落地？团队再小，也总有比自己更小的，研发、运维、数据、测试，总有一块能对外输出。
一旦能从成本中心转成利润中心，话语权自然不一样——你不只会花钱，还能赚钱。
要有企业架构的视角
井底之蛙只能看到巴掌大的天。做系统规划做久了，经验越来越多，真正的创新反而少了。得把思路打开，别被眼前的业务、现有的系统、当下的人给困住。
前面说的用户思维和产品思维，我觉得越来越重要。
用户思维，就是回到人货场的实际场景里，想想设计的功能、开发的系统，是不是用户真正想要的，能不能满足企业里不同层级的人。跳出自己的视角，结合业务人员的真实想法，做出来的东西会大不相同。
产品思维则是把格局撑大。我们做的不是一个功能、一个模块，而是一整张鸟瞰图。有时候不得不承认，那些"大牛"看问题的角度就是不一样，本质上是高度差了一截。
系统产品既然是服务于企业的，企业架构自然有其方法论。它通常分四层：业务架构、应用架构、数据架构、技术架构。
业务架构谈的是流程、角色、协作与变化，跟人货场的逻辑一脉相承。年度规划要以它为牵引，否则其他架构都成了无源之水——跟业务对不上，怎么满足业务？
应用架构关注系统、服务、功能的划分。这是日常工作中最常接触的，系统怎么拆、边界怎么定、耦合怎么控，想清楚这些，用户用起来才顺手，角色权限才好划分。好的架构师，既能吃透业务，又能在技术上做取舍。
数据架构规划的是数据、业务对象、交换格式，以及安全隐私。中台概念火起来之后，数据架构被提到了前所未有的高度。说到底，公司最值钱的不是人，是有效的数据。好的数据架构不仅能让存储更安全、流转更高效，还能通过数据赋能，给企业创造额外价值。
技术架构则是落地层面的——硬件、网络、服务器、操作系统，用什么开源软件、什么自研工具，网络怎么跳转、图片怎么缓存。规划时得从企业全局出发，技术负责人的成色，从这里最能看出深浅。不懂技术或产品的人做管理，无异于裸泳，但"皇帝的新衣"在很多公司照样演得热闹。
作为研发产品的一线人员，这个阶段正好想想未来的路往哪走。路在脚下，更在脑子里。
最后说几句
系统规划要考虑的维度很多。规划是计划、是预算，更是指导未来干活的基准。但互联网行业的残酷在于，变化太快，今天刚定好的方案，明天公司可能都没了——这两年这种事还少见吗？
回到开头那个话题，为什么说技术最容易被替代？我的理解是，会写代码的人越来越多，如果做出来的东西发挥不出价值，那确实没什么护城河。所以得往深了想、往广了做，为企业搭好架构、做出有价值的产品，真正把人、货、场串起来。
最后，祝大家平安健康。