时间过得很快，转眼在产品中心已经半年时间，记录一下自己的体会。

关于部门定位

公司从去年开始明确了新的战略，基于新的战略定位又在今年进行了部门调整，成立了2大产品中心。我所在的智能情报产品部，是直接面向公司战略的新立部门，对标Palantir、水晶球，集中团队的技术优势和市场积累，打造领先的智能情报分析产品。

一开始部门的唯一目标就是将实验室初创的GoIN系统进行产品化，按照产品管理标准流程进行立项、研发、发布、推广，后来随着前场部门反馈了很多知识图谱项目需求，考虑到GoIN的核心就是知识图谱，因此领导又赋予我们孵化知识图谱产品的责任。

作为产品部门，主要工作和核心目标都是围绕做好产品。然而在公司领导层制定考核制度之时，因为担心产品部门闭门造车，不了解实际需求，因此又要求产品部门要对相关项目提供支撑，把营收目标作为考核的关键要素，季度考核中占20%，年终考核甚至占比达50%。

这样一来，理论上是更加全面地进行产品管理和考核，但实际上作为新立产品部门，就背负了太多的责任：既要过程规范，又要技术先进，既要做好主线产品，又要做好项目交付。而按照公司制度，商机和项目是从行业部门来的，产品部门没有自己的销售售前，甚至也没有项目经理岗位，产品部门要做营收，必须依托行业部门，因此跟行业部门达成合作共识、明确项目职责、做好边界划分就非常重要。

然而，对于我们承担的GoIN产品，因为理念超前、市场接受度不高，甚至公司各部门、公司高层领导对产品的认识都存在相当大的分歧。尽可能早地弥合分歧，形成对产品相对一致的定位认识这是我们部门的一个重要任务，因为只有这样才能够争取更多的支持。

另外还有一个区别于其他产品部门的特殊之处在于，基于多种考虑，我们需要跟实验室一起共同推进产品研发。然而毕竟是两个部门，部门定位、工作制度、考核方法都存在较大的区别，因此如何跟实验室研发团队进行分工合作，达成共同目标，也是我们需要探索实践的。

关于产品

GoIN产品是目前天玑团队最先进的产品，没有之一，这个是从领导到各部门员工都认可的。GoIN的目标就是打造一款具有强可视化和交互体验的、提供多种维度和视角的分析工具的、可自由组装的大数据智能分析工具箱。对标的产品就是美国的Palantir、Tabular、IBM i2以及国内的水晶球。当然我们不是完全照抄，这主要体现在天玑团队多年来在2G领域的行业积累，以及基于中科院计算所的技术优势。

从我自己的体会来说，一开始接触到这个产品，确实被先进的分析理念、酷炫的可视化效果所吸引和折服。若年年前，我在实验室参与了当时的一个重要系统ADA的建设，那个系统也曾一度是实验室的明星产品，几乎每次客户交流都会演示，但是限于当时团队对产品的认识、大数据分析理念还有对UI可视化的认识都比较浅，对比来说，GoIN给人的感觉就是比ADA进步了一个时代。

去年我自己还在行业部门的时候，就开始了解和对接GoIN产品，还根据领导安排，参与早期的GoIN产品化，不过当时因为还有部门的交付任务，没有放太多心思在产品上，公司的资源投入也很有限，因此总体对GoIN的认识比较肤浅。

今年调整部门后，开始真正熟悉这个产品以及研发团队（实验室的研发团队），认识上出现了一些起伏变化。我从前端着手，亲自负责了统计分析模块的设计开发。经过一些时间了解，发现前端代码非常混乱，经常出现各种BUG，包括在设计上、代码编写上都有很大的问题。对于后台和数据接入部分，也发现缺少设计：除了接口文档，几乎就没有其他设计文档；接口部分缺乏模块划分；代码组织混乱；数据接入更是完全靠手工写代码，没有形成规范的格式和工具，以致于5月份的时候做一个案例，需要花两三周的时间反反复复地修改数据格式上。

所以这个时候原本很高的期望一下子就掉下来了，有点受打击，完全没有之前吹嘘的那种灵活性、先进性。但是产品版本规划、发版都得要做，不能推延，这是公司要求。最后确定二季度一定要发布1.0版本，经过不懈努力，在7.17日完成1.0版本结项，7月底发布。

当时我就想，虽然GoIN面子上看着很先进，其实里子里还不如ADA系统。在系统架构方面，是非常欠考虑的，包括各个数据库的选型，数据结构设计也很不灵活，前后端都没有模块化的设计。但是从产品上讲，确实理念先进，加上郭老师本身特别注重界面和功能细节的打磨，以及他对产品的宏大愿景规划、他自己的热情投入，让我觉得这个事情是靠谱的。

同时我也在不断思考自己以及我们部门在其中的角色。我觉得我们的优势有几个：一是我自己在ADA、魔镜等系统中积累的架构经验，能够帮助提升系统架构设计；二是我们是按照公司的产品研发管理流程来推动产品化，会给实验室带来一些规范化管理支撑，包括需求收集、功能规划设计、技术设计、测试以及日常沟通机制等等；三是我们代表公司，能够将公司各个行业前场的需求快速收集传递过来，使得产品能够更加实用、更接地气。

实验室团队在二季度期间，基本上以重点案例和演示为驱动，基本上每次演示客户反馈都挺不错，但是客户总会问一个问题：系统如何给他们的实际业务发挥作用。所以基本上还是产品的需求问题，实验室相对来说没有太多项目的压力，接触一线客户比较少，因此很多需求其实是自己设想出来的。

7月下旬，在产品1.0结项和1.0发布会的间隙，公司召开了年中总结交流会。我当时给领导汇报上半年的主要成果是：1.0结项实现产品从0到1；明确产品2大定位；支撑多个行业项目；探索与其他部门合作模式。比较虚，因为确实没有收入和实际项目落地。在下半年规划中，我提出要“做实”和“做强”，做实就是更多考虑行业和客户实际需求，做强就是把系统本身功能加强、性能加强。

从三季度情况，尤其是8月份和9月份的实际情况上看，我们确实是在不断做实做强。其中有几个主要成绩：一是我们在规划1.1的过程中，与实验室团队、公司多个行业部门进行了充分沟通，最终形成了1.1的需求并通过评审，这其实也是我们产品理念的体现，充分征求行业的意见，形成产品共识；二是在8月和9月，我们投入大量的资源和精力为安全行业的分析案例提供支撑，从一开始地数据对接、业务功能流程设计，到后来直接邀请分析师跟我们产品经理和工程师一起来做数据分析和案例设计，最后形成了一篇非常饱满有价值的分析报告，获得了客户的高度认可，后续很有可能达成服务项目合作；三是在支撑另一个项目（代号gab）中，我们与客户进行了充分交流沟通，面向客户最需要的业务需求进行功能定制设计，并安排2名算法工程师在现场进行支持，做到实实在在地提供服务，同时参考Palantir的工作理念，产品组成员都会尝试理解需求、熟悉系统；四是按照1.1的规划，在核心能力组件方面进行开发，逐步对系统进行技术重构，增加架构灵活性。

接下来，我们要通过更多实际案例（来自真实需求而不是自己设想）来驱动产品做实的进程。在知识管理、知识抽取、知识融合、知识计算等能力组件方面不断完善，推进产品做强。

当然，现在仍然还有一些问题，就是公司领导和各个部门对GoIN产品的定位认识以及GoIN与知识图谱之间的关系，还有知识图谱产品形态以及是否要独立出来，这些都是需要进一步探索和讨论的。

关于技术

GoIN的核心技术是知识图谱，看起来很明显。但其实有一段时间，我跟实验室团队郭老师、范老师讨论这个问题，他们是不太认可的。可能从学术上讲，“知识图谱”这个术语有一点烂大街了，为了不让人觉得太low，所以他们不太愿意说GoIN是一个知识图谱系统。他们给出的说法是：多元异构的广谱关联网络。额，说实话，这个词给客户讲，他们肯定是听不懂的，还不如就说知识图谱。

一开始领导们规划，在GoIN中孵化知识图谱，将系统一些功能模块屏蔽掉，就是一个知识图谱系统。业界普遍认为，知识图谱是一个知识的全流程管理系统，包括知识建模（知识如何表示）、从数据源到知识的转换过程（一般称为知识抽取）、知识存储查询、知识计算和应用等环节。很明显，GoIN的主要目标不是这个，GoIN主要是面向分析，与知识图谱的联系应该在于分析的承载平台是知识图谱。GoIN的主流程是将数据接入后，构建知识图谱，同时还会提取一些其他标签，最后形成一个综合的知识网络，基于这个网络进行图谱的、时空的、统计的分析，最终形成分析结果和报告。

目前从公司行业部门反馈过来的需求，直接对应GoIN的其实非常少，所以我们现在打算主动进攻，前移工作台，走到客户那边去，了解数据分析业务的需求，看能发挥什么作用。另一方面，知识图谱的相关商机、项目机会却很多，尽管这些项目里面多少都有一些应用层的功能要求，但是以GoIN来交付就太重了，以及很多需求无法满足。

我们在1.1的产品规划中，基于我们自己提出的“知识图谱能力平台”定位，决定提供一些知识图谱组件，供行业和项目进行集成调用。

但是实验室团队并不想做组件层面的工作，他们虽然有知识图谱的技术积累，但是现在更想重点投入GoIN分析能力。这样就导致了一个很尴尬的局面，真正擅长核心技术的实验室团队不愿意做更加核心的知识图谱核心能力组件，而擅长做应用功能开发的我们部门（作为公司的一个团队）却只能背负压力艰难前行。当然，GoIN主要分析模块，包括算子、可视化组件等，其实都是挺难的，也比较前沿，所以他们愿意去钻研，这本身也没什么问题。但是要做知识图谱能力平台，对于我们部门，甚至对于公司任何一个部门来说，都面临极高的技术挑战。知识图谱里面的知识建模、知识存储、知识抽取、知识融合、知识计算、知识推理、知识关键应用（如智能检索、问答）等，任何一个模块，都够研究人员研究相当一段时间。但公司目前的全部算法工程师，一双手就能数完。何况在知识图谱方面，我们本来就起步晚，如果没有重点投入，是很难做成的。

公司目前的技术点分散本身就是一个大问题，产品研发团队总共才几十人，涉及的技术包括大数据平台、数据采集、数据中台、机器学习、NLP、可视化、权限管理、数据库、知识图谱，还要支持行业部门的几十个项目，以及一些产品管理测试等工作，面临的困难是很明显的。

作为一家具有极强技术背景和技术属性的公司，偏偏没有核心技术，产品看起来倒挺全，但又没几个能够做到行业顶级。这种现象已经持续了多年没有改善。

当然，公司要盈利要生存，技术是不是牛没那么重要。不过对于有技术情怀的人来说，这就是一种失望和打击了。

鉴于目前现状，我认为公司一定要加大对知识图谱研发的投入。具体有两种方式：一是由我们部门成立单独的知识图谱产品组，正式立项，单独增加人员编制和资源配给（不过招聘是一个大问题，很难招到优秀的研发人员）；二是通过联合产品部门、行业部门，成立一个虚拟的产品部门，通过集合各部门的骨干人员，共同进行产品设计和研发攻关（也有问题，包括各部门的投入意愿、组织保障机制、协作机制）。

关于跨部门合作

前面的部门定位中说到，产品部门其实背负了很多责任，要服务好多个甲方。而对于我们部门，公司各行业和实验室都是我们的上帝，而上帝是不能得罪的。行业部门很明显，他们掌握项目商机，他们也有自己的交付研发人员，甚至可以立项做自己的行业产品，说是行业产品，这全靠领导拍板。行业肯定都想自己做大做强，这样他们可能就不带产品部门玩了。虽然有分管技术的领导在协调，但是如果行业就是很强势呢？实验室这边本来就跟公司相对独立，如果没有服务好，就很难合作下去，而核心技术都是他们的。

部门间合作，也许上级领导可以强制要求，但是终究还是看利益。但是我们部门目前市场定位尚不够清晰，产品不够成熟，市场渠道和商机有限，技术优势也没有，这种情况下是很危险的。

自己弱小的时候，就一定要懂得抱大腿，这个算是近期的一个主要体会。看清楚所处环境中谁是大腿很重要，一定要服务好，哪怕只是提供一两个人员的支持也行。

长期来看，还是要找到自己的定位，凸显自身的价值。产品、组件技术、技术方案、数据分析、人力服务，这都可以考虑，不能给自己太多限制。短期来说，那就要能支撑的尽量支撑，实在不能支撑的也要把话说好说圆，让人心里舒服。

半年来，因为2个项目上的分歧，跟某个行业部门关系搞的比较紧张。这个部门目前是公司最大的业绩部门，未来还会扩大，所以这种紧张关系一定不能持续。分析一下两件事情的原因：第一个是因为一开始参与了某个项目，但是后来发现项目需求跟产品主线偏离太远，所以决定不参与，虽然当时也是跟他们进行了沟通，但他们还是觉得我们半途而废不够给力；第二个是近期一个项目，投标的时候来问我们产品不能能不能做，我犯了技术冒进毛病，说可以，并支持他们去投标并顺利中标，但是后来仔细评估发现存在技术风险，主要模块扔需要他们行业部门自己解决，由此产生矛盾。当时开会，领导们都剑拔弩张，我都没敢说话，其实心里有冲动，说这个项目我来扛，但是毕竟资源有限。

因为这些事，也才开始发现，职场还是很复杂的，哪怕在一家创业型小公司。自己又实在是一个太简单的人，不愿意为琢磨人花时间，但是作为部门负责人，自己的形象就代表部门的形象，自己的态度就是部门的态度，自己受点委屈不要紧，但是导致部门业绩受了影响，那结果就是整个部门跟着受委屈。为了团队的利益，自己的面子不算什么。

其实有时候自己知道捅了娄子或者没把事情干好，但是总不好意思主动承认。这个毛病要改。

最重要的就是看清形势，顺应时势，给自己争取发展的时间和空间，尽快形成特色和优势，那样才能无可替代。