对于软件价值管理的思考--《PMO论文集2019》（电子版）

原创：PMO评论 特约作者：胡乔治
摘要：传统项目管理，无论是典型的软件销售服务公司，还是互联网软件公司，在过程管理中，通常是从需求输入开始。这当中造成的误判范围、过度承诺、信息传递变形甚至信息黑洞的情况屡见不鲜。即使企业中有诸如PMO或是项目管理委员会这样的组织，大多数都忽视了需求并非凭空而来。而这些需求是否具有价值，如果从组织和成本的角度上去考虑，则会发现不论创新类公司还是拥有成熟市场的公司，都应当把需求从售前（需求产生）之时进行度量和梳理，明确需求是否可以假设的方式来验证。有一句老话“假设（需求）什么都不是，只有当它能够被证伪或证实，才有价值”，有了价值假设的需求，才会有去实现的必要。
关键词：价值 需求 CMMI
1. 价值和需求
传统的敏捷宣言，只关注了在项目过程中，团队如何保证需求价值的实现，如何交付价值。即敏捷首先假设的是这个项目（需求）的价值是存在的，依据这个价值依据，在项目过程中持续交付可评估的产品，以达到接近用户真实需求价值的目标。
我们不妨追问一下敏捷的本质是什么，敏捷宣言的核心价值告诉大家如下四条核心价值：
•个体和互动 高于 流程和工具
•工作的软件 高于 详尽的文档
•客户合作 高于 合同谈判
•响应变化 高于 遵循计划
就这四条核心价值来讲，更加贴近于软件开发中的过程管理。从真实世界的项目全生命周期来看，敏捷忽视了项目启动之前的价值假设过程，如果这个需求的价值假设在商业模式、成本预期或客户（运营）期望功能出来之前，是稀里糊涂构思出来的，你再怎么努力，敏捷也不过是多走几步还是少走几步看到项目结束的结局罢了。大家扪心自问一下，你所从事的敏捷项目，有多少是从开始就将商业价值和企业目标与敏捷项目结合起来进行管理的。
软件开发团队通常重视的是项目的成功交付和验收，而非项目是否真正为企业（用户）创造了商业价值。无论是项目型公司还是互联网公司，开发团队通常在短期内对项目交付最重视，而从长期看，交付一堆没有达到预期价值甚至毫无价值的产品（功能）时，对企业和团队造成的成本损失，要远远超过尽早识别不具备价值的需求而延迟开发的成本。
那么如何将敏捷扩展到项目启动之前，进行项目全生命周期的敏捷管理呢？在我们集团研发中心所管理的内、外部IT项目的度量结果看，没有进行清晰的商业价值管理的需求，即使最终上线，在一年内被关闭和下线的比率也达到了83.5%。而相对有商业价值管理的需求，在一年内被关闭或下线的只有不到37%。而第一类需求，通过我们PMO部门的内部审计，浪费的研发成本近千万元。可以想象，如果浪费的研发成本转到有清晰商业价值输入的需求上，不仅是节约了成本，而且带来的收益也是远远超过成本的。
通过迭代以及项目的复盘，和成本、进度、质量、商业价值各类指标的持续跟踪，我们总结了在敏捷团队中，贯彻商业价值假设的五个原则。分别描述如下：
1.1 敢于质疑
互联网企业的命脉来源于创新，经验永远是过去时。企业需要相信创新来自于人的主动性，而非机器。即使是在精益的发源地丰田，这个流水线的工厂内，也奉行人的主观创造力是第一生产力的观点。反观国内的互联网公司和创新工场，管理层和创业团队很少去主动将需求的商业价值传递到研发团队。很多研发团队也是接到需求就开始评估怎么做，不问为什么做，也从来不问价值。就算有人问了，也只是要求排个优先级而已。这种对企业价值和商业本质的漠视，也导致了技术团队缺乏大局观。而研发团队最多只是站在技术立场上，反过来要求产品做出一个不靠谱的年度规划，由研发团队来预估系统架构上的合理性。放眼目前的商业环境，都是在不停变化的市场契机中发现商业机会，如果靠产品经理或是公司决策者就能正确地判断公司未来一年的产品路线，那为什么整个中国成功的创新型公司还是少数者？在企业的成本（预算）有限的前提下，做正确的事，永远比正确地做事更重要。创新型企业必须以尽可能小的成本和时间，完成同等数量经证实的认知【1】。
同样，从软件开发这一脑力密集型活动中需要尊重人并发挥人的主观能动性的角度出发，公司的管理层更要首先放低姿态，承认自己也会犯错，并将商业目标和价值要求，通畅地传达到研发团队。而研发团队在面对需求时，需要多问几个为什么要做，敢于质疑价值不明确的需求为什么要付出成本来研发。
目前在我所在的企业，推行的是对于不超过两个迭代的中、小型需求，需要提供《商业画布》，从而由PMO推导出《价值时分表》，通过这两个文档的讨论，明确需求的价值、价值产生的预期日和实现的急迫性，并从中提取需求实现后的上线跟踪指标。
而对于横跨两个迭代以上的大型需求，PMO要求运营和产品团队共同提供BRD。在早期实践中，我们只要求运营团队提供BRD，但发现这样容易出现运营和产品团队之间推诿的现象，双方都不认为这个需求最终是由自己负责来落地：运营会认为要靠产品线上化，产品认为运营的设想并不严谨，两边会陷入无止境讨论商业价值和目标落地的拉锯讨论中。后期我们改进了BRD的提供方为运营和产品共同出具，双方共同对需求的商业价值和指标负责，这样各方在同一个目标的前提下，能快速达成一致和可行的意见，并迅速转化为兼具商业和产品描述语言的BRD文档。
1.2 成本优先
在我们做一项商业决策时，往往是凭借过去的经验和有限的试验及数据做出的假设。这本身没有错，而往往人们容易忽略的重点是：忽视了验证这个假设能够承受多大的成本。合适的时间，用合适的成本去做合适的事，这也是“风口上的猪也能飞”那句话原本的意思。
下面来举个例子。
我所在集团的某公司，曾经在B2B快消品市场上，投入过一个快消地推业务员使用的APP产品。当时这个产品是给公司内部业务员使用的，用于实现：安排拜访路径和计划、代客下单、定点给终端店推销优惠活动等地推功能。在开拓外区市场时，根据市场人员的调研和相关领导的从业经验，一致觉得市场上其它快消厂商和经销商是需要这个产品的。所以二话不说，为了抢占先机，为了做那个风口上的猪，产品率先将业务员端做了改造，适配了外部经销商和厂家业务员的模式，还没等投入到市场，这个项目就因为种种原因而收缩，取消了与外部的合作。还好只做了个简单的适配，但也耗费了两个迭代（四周）的成本。从敏捷来看，项目本身一点没有问题，但从商业价值来看，成本的浪费不言而喻。
可能大家看到这里，会有很多疑问：商业价值又不是研发说了算的，领导决策了，由运营做规划，产品来设计，研发团队只负责实现。但回想一下，如果敏捷不能创造价值，那研发团队的价值又从何体现？
因此，当我们在假设一个价值目标时，要遵循的是成本优先和决策推迟原则。譬如就这个案例而言，如果先使用线下先行的小规模验证，由运营方安排三至五名实习生每天收集数据在excel里进行统计分析后，发在厂家和经销商的业务员的微信群里，来呈现这些用户需要的订单统计分析和拜访率也能达到先期验证的目的。这样浪费的成本孰高孰低，一目了然，行不通再止损也快。也不用后面我们又要考虑把这一套代码下线，来避免后续还要付出不必要的维护成本要划算。
1.3 推迟决策
推迟决策并非那种“做决定时在思考，遇到困难就授权”的官僚思维，也不是将责任推诿至他人的做法。而是因为太多拍脑袋所做的商业决定所带来的高昂实现成本，造成了大量的企业资金的浪费。而提前决策恰恰违反了第1.2条的“成本优先”的原则。

推迟决策的时间点是指：决策的最佳响应时间点应为做出决策的成本跟推迟决策造成的损失大致相当的时间点。【2】
推迟决策的实践：在精益管理中，有一个推迟决策的最佳实践：真实期权【3】。听起来挺拗口，下面简单解释下。
期权大家都知道，而真实期权可以拆成“真实”和“期权”两部分来看，即针对项目在分阶段投入成本的情况下，我们需要有在特定条件下为了探索真实场景而对各阶段所拥有的三种投资成本评估（期权）的方式：一是放弃投资（即条件不成熟）；二是继续投资（即达到此阶段的约定条件）；三是重新评估未达到的条件，决定是否变更条件或减少投资规模。
这些实践，有部分来自于金融期权的数学模型，有部分来源于决策心理学。归根结底，是指在决策时，需要满足事先约定的条件并了解决策所需要的原因后，再做决策。真实期权的终止日是条件性的而非契约性，你可以延后期权的终止日，直到发现最优解，从概率上来看，推迟决策要比提前决策更能提供价值。
举个例子：某公司即将开始一个全新的平台引流项目，我们有一个商业目标，希望通过产品来实现日均50万的PV和大于等于10%的订单转化率，公司以前没有类似的经验可以借鉴，即使有人有相应的经验，在这个平台上也从未实践过。
传统意义上的项目，应该是开始商业计划书，然后PRD，然后项目实现并上线验证。在这里，就埋下了决策陷阱：一开始的目标推导出来的商业计划书中，由经验评估出成本，继而产生的ROI，这个ROI顶多是个估算，谁来为估算的决策推导出的成本来埋单?我相信没有一个人是有100%的信心和承诺去做这个决策的。即使是计划做得再好，凭经验做出来的计划，也满足不了随时变化的市场和社会环境的变化。那些商业大V给的无非是天花乱坠的计划如何做出详细分解，而这并非投资的最佳路径和最优化探索。
真实的世界里，我们要将决策带来的成本付出减到最少。因此，好的做法，是在面对一个不可知的目标时，将目标拆分成不同的阶段。而回到案例中，这个项目因为未知因素太多，但又需要快速推进的话，应该是在商业计划成型之前，做一次小规模的验证，这个验证应该是针对特定的极少部分种子用户，并利用现成的最小化成本（H5工具生成的落地页、现有平台产品的简单对接）去实现，观察预定的指标，总结是否需要调整变现路径和方法，再形成完整的可推论的商业计划（BRD），并划分阶段和成本，然后才是分阶段实施的PRD和上线后的商业验证指标。有了这样一个先验过程，并将阶段验证条件作为下一阶段的决策依据，才能更好地迎接在过程中不断变化的问题，并最终以最合理化的成本和收益达到项目目标（虽然项目目标可能会调整，但也是基于真实验证下的调整，而且成本并未浪费）。
因此，推迟决策并非不做决策，而是在有先决条件下分阶段去实现项目目标，决定是继续按计划做，还是终止，或是变更条件后适当投入再看看。
任何一本软件工程教材都会告诉你：假设在分析阶段找到并解决一个错误的成本为1，在设计阶段解决同一个错误的成本就变成10，在实现阶段就变成100，在维护阶段就变成1000。敏捷软件开发中的真实期权实践，正是为了避免不正确决策所带来的成本浪费。
1.4 风险预测
海恩法则告诉我们：任何不安全的事故都是可以预测的。而事故的征兆往往在迭代过程中是非常相似的。PMO则需要在迭代的各个节点中，关注迭代的量化指标和团队反馈，来不断总结风险并归纳到风险知识库中，并在后续的迭代中应用风险库中的风险点进行检查。
从我们PMO部门的实践过程中，风险库中检查点的完善和归纳并非难事，在短短半年时间内，我们依据前期50多个迭代活动中的迭代总结和事故分析，梳理了6大类15个小类共200多条涵盖全部研发活动的风险。同时，我们根据需求或项目类型的不同，裁剪了不同迭代和项目规模下的风险点检查模板，以避免投入不必要的精力过分检查风险较小的项目而增加无谓的研发管理成本。但我们在后期发现了一个有趣的现象，即在团队能力稳定和成熟的情况下，迭代中最容易暴发的风险并非技术能力、资源这类研发过程中的风险检查点，而是迭代开始之前的商业需求是否真正依托以上“敢于质疑、成本优先、推迟决策”的原则来开展商业价值的假设验证活动。凡是仓促上马，靠拍脑袋决策的需求，必然会导致迭代活动中需求范围的蔓延，需要PMO和所有干系人回过头再对需求的价值进行明确，并重新梳理得出需求中价值高低的业务期望指标，再来对应出功能的优先级，从而调整研发活动。这中间的混乱、模糊、不明确的氛围，一定会让团队无所适从，只有通过加班、增加资源来解决，而需求最终的落地，也往往会面临普遍的延期困境。
从PMO的角度看，商业价值的假设验证，需要早于BRD、商业画布、价值时分表。企业在开展商业价值的假设分析前，最好是有一个可控成本下的“投石问路”的动作，这类的动作往往并不需要做什么研发活动，利用现有的大量移动社交软件和轻应用的H5工具平台，就能很轻易地在种子用户或是初期使用者中间获得反馈，从而为后一步的商业价值假设提供更准确的输入依据。
但比较尴尬的是，并非每次需求的输入都能完全按照这些原则来执行。原因各种各样，但首先是商业决策者是否能抛开公司估值、市场荣誉、融资活动这些虚荣指标，真正从长远考虑商业的本质，创造一个可持续发展和盈利的商业模式。
1.5 全局优化
最后落脚到PMO这个部门在软件企业中，工作的内容到底有哪些。在很多企业中，PMO实质上是作为一个传统的项目管理中心，承担了项目综合管理的工作，其职责和权力往往是通过高层的临时授权而获得，往往对项目和迭代只有监察、指导、协助和审计的职权，这样常常会让PMO部门有无法落实工作的无力感。从我们PMO部门的长期实践来看，迭代和项目活动过程中的标准化、流程化、工具化、体系化只是PMO工作内容的一部分。PMO首先是要了解组织内要实现的商业价值的使命和战略。只有明确方向了，才能进一步做后面的事，而不要只做一些头痛医头、脚痛医脚的项目管理工作。
因此，我们认为PMO的工作方向，有如下几个重点：
1.透彻理解（而不仅只是了解）组织的战略目标、瓶颈和部门协调陷阱，在此基础上做出标准化、简单化的流程，协调部门间的信息流通和标准化；
2.在整个组织层面，实施敏捷，而不仅仅是研发部门。需要将市场、运营、产品、研发、客服、财务、法委、风控等组织，清晰地串入整个敏捷流程中，保障不要出现信息黑洞；
3.由上至下，向各个部门的商业价值假设的场景进行分析，找到问题并加以改进；
4.和基础运维部门配合，提供平台级的信息分享工具，并进行知识管理；
5.协调重大项目中的进度、质量和资源，进行跨部门协调，督促审核关键交付物。
2. CMMI的陷阱
CMM的成熟度模型，更加偏重于项目的执行过程。与敏捷类似，都是假设有一个已立项、清晰的项目目标的前提下，如何按最佳实践去实现项目目标。
CMM也好，CMMI也罢。对售前的过程域，比较匹配的还是需求管理的过程域，这个过程域中，强调的是需求理解的一致性。而这个需求是否匹配用户的商业价值，从CMMI的过程管理活动中，鲜少有提及。
限于篇幅，我只举一些CMM中在售前活动中遇到局限的案例。
实际项目中，我们承接过一个大型集团的协同平台。在售前阶段，甲方提出了一个很宏大的规划，如果用敏捷的快速交付原型方式显然不合适了，估计要画几百页原型才能满足。这个时候，首先澄清用户的目标和项目范围后，才能为接下来的有价值交付铺平道路。因此，接下来的一周，我们并没有提交方案，而是按照初次访谈得到的规划信息，和技术负责人一起，对甲方信息中心的关键人员做了一轮访谈，并邀请甲方参观了一些类似的客户项目。取得信任后，我们在甲方的支持和协助下，对业务部门的核心人员做了另一轮访谈，再根据这些信息和访谈纪要，输出了一份长达98页，装订成两册（一册为项目建设方案建议，一册为方案图集）的文件，影印了10份交给甲方信息中心和各部门查阅，我们分别约时间在会前收集意见并反馈和修订，并在接下来的会议中通过讨论，明确了目标的范围和优先级，确定了各个阶段的里程碑和输入条件后，以第一阶段为重点，才开始制作demo和原型。
这个项目最终招标的技术部分，实际上就是按我们提供的项目建议方案书来写的，甲方也非常信任我们前期做的详细分析确实能落地，并且也看到了部分核心功能的原型，感觉我们的方案很靠谱。在投标评审中，倾向性给我们打了最高分（没有任何猫腻），其它公司倒不是不努力，不过大多是凭过往经验，某有名的软件公司甚至复制了一份在其它集团投标的技术标文件，很多地方完全不符合甲方的实际业务场景。从这个故事中，不难看出，我们即使在售前阶段，对需求的澄清也是相当慎重的，通过合理的成本付出（方案建议->原型）给用户不断提供分阶段的价值输出，明确项目范围，落实项目的可行性，从而为后续项目的开展提供了良好的可落地基础。退一万步说，如果在前期调研过程中，我们就发现在这个项目上，甲方的商业初衷与实际落地偏差太大，而且甲方不愿调整，那我们只是付出了两轮调研，以及顶多一个方案建议书的成本。这个成本也只涉及到一个售前经理和一个技术总监，要比糊里糊涂投入7、8个人的团队进行投标，摸着石头过河做方案和标书的成本要低得多。
在这个项目中，方案建议其实是项目中关键技术论证的报告，阅读对象是客户的IT和业务部门，其目的是告诉对方：1）请你们放心，从项目目标、实施范围、典型场景、关键技术、实施计划的方方面面我都考虑到了，让客户有明确的方向感和落地感；2）告诉客户，这个项目的边界在哪儿，项目中的实施范围的优先级、顺序、技术实现方式是什么；3）给客户指出项目接下来的实施模式是什么样的。
因此，这个报告的形式以文档方式最好，而且这个报告最好是由公司内专业的销售、售前和技术经理来一起写。花这点力气是值得的，因为：1）此时技术骨干的介入，会直接给出技术实现最可行的方式；2）此时技术人员的介入，会在一定程度上了解项目的背景、风险和目标，因此在这个阶段由技术经理和销售一起引导客户的技术思路是最有效的；3）最重要的，防止销售画大饼。
那么这个方案如何写呢？一个好的方案建议书，是给IT和业务部门看的。因此开篇的时候要从业务角度去写，即“凤头”，通常的章节如“前言、项目目标、项目范围、实施内容、技术原则”这些。开篇就是要让人有眼前一亮的感觉，觉得你是懂我的，你是懂我这个行业的，你说的是我听得懂的话，你说的把我想的都总结了。
接下来的中间章节，一般称之为“猪肚”，通常有“系统开发平台、系统逻辑架构、系统物理架构、系统运行环境、关键技术实现”等内容，通常这部分业务部门会一眼带过，但IT部门会认真看，特别是架构部分的图，千万别马虎画，要经得起推敲。另外就是关键技术实现，实际上就是解答IT部门内心关于技术难点如何解决的疑问，同时给后来的项目组成员一个指导和参考。
最后的章节，就是怎么落地了，因此叫“豹尾”，意思是有力干脆。一般有“项目进度规划、项目管理保障、项目费用概算”，当然概算你事先要和客户达成一致。这个阶段可以稍稍高点。
3. PMO如何进行价值管理
基于以上论述，在我们集团的软件研发活动进行前，我们会尽量贯彻商业价值假设验证先行的原则。如果遇到阻碍，一般情况下我们会对高层以备忘录的形式进行说明，并清楚地指出可能的风险点和后续风控措施，及预期的止损点。通常我们会在以下几个节点的交付物上进行审计：BRD/商业画布、PRD、ERD、UAT、Deploy、预期指标达成前的指标验证。遇到重大项目，我们会组成专班，直接与产品经理和运营方成立商业假设验证组。通过以下几个步骤完成商业价值的实现落地或放弃的活动。
3.1 商业命题
往往一个商业目标的提出，从组织层面提出时，比较难以明确地落地。需要各相关部门进行几轮讨论，明确这个商业目标是要重新创造一种场景，还是要解决问题恢复原有状态，还是改良目前的现状【4】。从而得出这个商业命题是属于哪一类问题，后面就可以通过传统的5W1H、6W【5】、鱼骨图的方法来分析问题的解决场景。这一阶段，通常需要大量的沟通和讨论来定义，通常最后的结论我们会通过一张思维导图来清晰地描述5W1H和6W的命题。
3.2 小成本验证
有了商业命题的输入，多数运营和产品会根据自己以往的经验或是公开资料推论出一个甚至多个解决方案。此时可以根据头脑风暴，选择一个解决思路，并通过搭建一个线下小规模场景来验证，再来收集这个场景下的反馈数据，从而明确这个解决思路是否可行。如果不可行，就总结是否这个解决方案有改进的余地，或是采用另一个解决方案来验证。如果所有解决方案的小场景验证都无法通过，此时应该召开各方人员再聚焦4.1的内容，重新讨论商业命题并推理解决思路。
3.3 清晰商业假设
如前述1.1节中所述，根据需求规模的大小。PMO会要求运营和产品共同编写商业画布或是BRD，并绘制价值时分表。通过对商业画布和BRD的评审，确认后续商业价值的验证指标，并根据价值时分表来明确需求的优先级。哪个需求在越短的时间内能假设获取更高的商业价值，那么这个需求的优先级就会更高，而并非出于领导意志或是臆测。
下面是我们在清晰商业假设活动中的商业画布（见表1）和BRD的模板截图（见图2）。

表1商业画布模板

图2BRD模板
3.4 产品实现跟踪
在此阶段，主要分为两部分。一部分是产品实现过程中的研发活动的跟踪，另一部分是产品上线后前期4.3节假设的商业指标的实现情况。
对于研发活动的跟踪，不同的阶段我们有不同的考量。在研发团队的早期磨合时，我们主要是度量PRD评审质量和进度、代码质量。在团队进入稳定期后，我们更关注的是整个开发流程中，需求在制品是否有稳定的输入和输出，这非常依赖PMO对企业商业价值的整体把控，一方面要帮助运营和产品源源不断地根据商业命题输入高质量的商业假设文档（商业画布、BRD），并协助团队根据价值时分表排定优先级。另一方面，要跟踪研发团队的产出是否饱和，是否有技术债。我们使用的工具是一张《迭代度量模板》，这个模板中清晰地绘制了需求在各个节点中进入的时间，从而很容易度量出需求的成本及节奏是否正常。下面图3、图4和图5分别是截图部分内容（数据均有处理，不是真实情况）

图3需求交付记录

图4需求累积流图

图5需求周期控制图
4. 对价值管理的思考
在我管理PMO部门的一段时间内，曾听到过两种截然不同的上级观念：一种是不惜代价和成本，所有商业活动都是基于产品先行；另一种是顾虑研发成本过高，所有活动都要求线下验证通畅再研发并上线产品。
这两种方式没有对错之分，要看在什么环境下运用。如果企业拿了一笔巨额融资，投资人又有明确的市场体量要求，不惜代价也要抢占红海，自然第一种也没问题。而第二种适合在一个成熟稳定的市场里稳扎稳打。而在另一种手快打手慢的市场里，还没等你把商业环节全验证完，也许已经有人推出了一个不那么完美的线上产品抢占了用户份额和市场机会。
其实，回到本质，这两种都是对远期利益的预期，只不过适用的范围有其特定约束，前一种是资本洪水希望能淹没市场，后一种适用于成熟市场下的稳妥创新。
在有了一些项目经历后，我仍然相信，互联网企业的商业本质仍然会落脚到盈利能力，一个无法盈利的企业，总有一天会被市场所抛弃。因此，PMO在迭代、项目管理中，需要向前再跨一步，回到商业的原点，厘清每个需求、每个项目的商业价值假设，通过分阶段的验证活动，用最小成本来证明或证伪假设是否成立，从而为高层实现决策提供清晰的依据。
参考文献
[1]埃里克.莱斯.精益创业.北京：中信出版社，2012：126.
[2]艾伦.沙洛维，盖伊.比弗，詹姆斯.R.特罗特.精益创业第2版.北京：电子工业出版社.2016.5:21.
[3]埃里克.莱斯.精益创业.北京：中信出版社.2012：112.
[4]高彬尚孝.麦肯锡问题解决与分析技巧.北京：北京时代华文书局.2014：9.
[5]丹.罗姆.一页纸工作整理术.北京：中信出版社.2017：144.

PMO评论特约作者：胡乔治
他从事过金融业、零售业、房地产业、医药销售类、生产制造企业的IT管理和PMO管理工作，在IT类职位上有十余年以上的工作经验。擅长商业智能、MRP、ERP、知识管理、人力资源、互联网金融项目的咨询及实施开发，对项目管理和团队建设有丰富的经验。
最近几年，实施过B2B2C电商、物流电商平台产品的开发管理工作，以及两家传统金融和互联网金融企业的内部协同系统、业务系统、移动金融系统的咨询、调研及开发、运维工作。主持了两家传统制造领域企业的数据挖掘和分析项目的咨询、调研及开发工作。从事过零售企业大型MIS软件开发及实施,从事过大型工业企业ERP软件开发、实施及指导,主持并实施过大型企业人力资源的咨询、实施及系统建设;主持并实施过企业Portal、知识管理的咨询、实施及系统建设。熟悉软件项目管理知识并具有组织管理的能力，能领导开发团队实现企业战略。对企业的IT运维有独到见地，组建了多个运维团队，实施过多家行业10强企业的IT运营规划和运维服务。
他获得了信息系统项目管理师资格、系统集成高级项目经理资质和人力资源管理师二级资质。现任卓尔智联集团研发中心总监，兼任该集团下属两家互联网公司的CTO。