非软件行业公司自建软件开发部门能力不强的原因分析
最近有一个长期客户，汽车行业排名前列的，开始进行自建软件开发部门，逐步代替原有的每个项目挑选软件供应商、谈合同的合作方式。此客户是我们公司的主要客户，对我们的影响也很大。作为乙方，我们只能尝试逐步向外开拓其它业务，同时观望其后续结果。
一年多下来，据了解，其成绩并不理想：项目完成周期长、质量也堪忧，交付的软件，都要多次修改，才能逐步向能接受的质量靠拢。
当然，我个人来说，我从一开始就不看好"非软件行业公司自建软件开发部门"。
作为 1996 年大学毕业的 IT 业资深人士，耳闻此类事情不少，也亲身经历过一次。之前在某美资500强 IT 公司工作，其建立了一个软件中心，用于对公司内、外提供开发软件服务。对外的软件项目，限于软件行业合同的规定(大多是先完成软件、后付款，能争取的最有利的不过是分阶段付款)，不得不争取做好，以便获得客户的认可，期待客户及时进行确认收料(收货)，按计划收款。对内部服务的软件项目，则质量只能说是凑合，勉强能用罢了。
为什么会有这种差异呢？为什么企业内部的软件开发部门，做不好为本企业开发的软件呢？
本文尝试分析其中的奥秘。
首先，现代工商业的发展，导致行业工作细化，其结果，则是很强烈的“学习、模仿、创新、超越”模式。
举例来说，开饭店的老板，一般都是原来在其他饭店里做厨师、经理、招待员或学徒，有了一些工作经验，加上自己平时学习、琢磨所得，在合适的机会，然后自己出来开饭店。这样比较容易成功。
原本做司机、泥瓦匠工作的，智力与上述差不多的人，直接转行开饭店，比较容易失败。
究其根源，在于“从无到有”是很难的一件事，需要非常聪明的头脑、加上大量的时间，才能琢磨出一个陌生新行业的可能正确运营模式。相比较而言，单纯的"学习/模仿"则是比较省时间的。
新创业的，如果花大量时间去想厨师和切菜是否要两个人的问题，则可能来不及开张赚钱，已经在不停支出各种费用情况下破产了。
"地球绕太阳转"，这个道理从无到有，历经了很长时间(很多年)。而学习这个知识，只需要很短一点时间(几天)。
结合本文的问题来说，一个非软件行业公司的管理人员，想从头建立一个软件开发部门，从零摸索，跳过"学习/模仿"阶段，凭空想出一些规则，是不管用的。见过电视上高级厨师炒菜，并不等于能直接学到、直接拿来用。这里面包含的学习、练习，时间、精力、成本是省不掉的。
且外行的总管人员，所设想的规章制度，是否有效，需要时间来验证(这里面如有浪费，浪费的是公司的钱。但非软件行业公司自建软件开发部门，本就难以考虑自负盈亏之类的事情)。
当然，如果是一个全新的行业，若干竞争公司，都从零摸索，则没有问题。
其次，不同的工作模式及要求，会导致最终做事方式及质量的很大差异。
软件公司有盈利的生存压力，需要在满足客户质量要求、时间要求、成本投入等方面进行管理与平衡，而企业内部软件开发部门则相对压力小。这会导致两者做事方式千差万别。
软件公司一般分软件产品研发、软件项目合同开发、特定技术的年度支持/服务等，撇开冠冕堂皇的说辞，时间管理、成本管理是优先考虑的，质量管理则因人而已，看各公司的重视程度与能力；企业内部软件开发部门，以项目、变更类居多，"避免弄出大事情"是首要考虑的，时间要求相对宽松，成本方面如果无特别管控则会很夸张的失控。相对而言，纯软件公司在成本费用控制上，很少导致"很夸张的失控"这种程度。
企业内部软件开发部门以"避免弄出大事情"的原则与心态去工作，各方面人员遵守公司规章与纪律，看上去没什么问题，实际上导致"人人负责、无人真正负责"的状态。
家庭主妇做菜很少有餐饮行业那样”哆哆哆．．．”快速切菜的，家用炒锅、汤锅等工具的选择，与餐饮行业差别很大；两者人员分工、操作流程之类的，完全不同。这也导致最后的成品质量差别很大。之所以有这么大的差异，在于其要求不同：家庭即便炒菜不好吃，只要不太难吃，一般不会要求换人做。有时即使想换也因各种因素换不了(老妈炒菜难吃就要求换成老爸炒菜？你一个娃有多少说话的权利？)。"企业内部软件开发部门"也会有类似的情况。
基本要求不同，导致工作方式及相关规定都不同，项目中采用的软件技术也很可能不同。随时间的推移，非软件行业公司自建软件开发部门与纯软件公司，能力与效率的差距越拉越大。
第三，"企业内部软件开发部门"往往以企业原有人员，作为核心人员，组建软件开发部门。
这些人员，未经历在“纯软件公司”以乙方人员身份参与市场竞争，很难以了解软件公司／行业是如何运行的。基于"领导英明、领导赏识我、让我负责我就负责”的简单逻辑，不顾自己的能力与经验，也容易导致失败的结局。
至于为何以企业原有人员作为软件部门核心人员，而不是从已有运行良好的软件公司，挖项目经理、架构师、高级软件工程师、软件工程师、测试经理、测试人员等有经验者，一方面非软件行业公司薪资上未必有吸引力，只能去招聘新毕业人员，另一方面，负责招聘人员未必有足够的能力，去挑选这些技术或管理人员中的优秀者。国内有名的某度公司还招聘到一个极不靠谱的设计什么总监。
除招聘之外，正常企业运行过程中，提拔优秀的软件项目管理、技术人员，在非软件行业公司，是一个难以完成的事情。
第四，奖惩制度上，非软件行业公司的灵活性相对差一点。
"奖功罚过"(奖励有功的，处罚有过错的)，纯软件公司容易实现，非软件行业公司很难实现。
软件公司对外做软件项目，如果客户提出要求换项目经理、技术架构师，对软件公司来说，如果有人可换，并不是一件很为难的事情。项目里的角色，本就是临时性的。这个项目的某个乙方成员，与甲方吵了，换到另一个客户合作的软件项目，对乙方软件公司来说毫无压力。
非软件行业公司做类似事情，难度大很多。组织架构/部门组成，期望相对稳定，不能随意变动。业务方不满意，就换项目经理或架构师？好难操作啊。
第五，软件开发行业，关键人员的差异性非常大。
软件公司往往能很快意识到这一点，而非软件行业公司，往往意识不到这一点，或者需要很多年、吃过很多教训后才稍微了解一点。
非软件行业公司很容易把它们已有的行业经验"招聘新手、培训两周、发员工规章手册/注意事项，开工！"套到软件部门。这种思维是如此的根深蒂固，即使他们发现有的项目做失败，只更换少数几个关键角色，就可大幅改进，他们还是很快就会回到原有的思维模式上。这也许就是企业的基因吧。
第六，项目中使用"资源池"的做法早已被证明是低效的。
早些年，IBM 等大公司，凭借自身的名气，在国内承接各种大的软件项目，然后召集与其合作的小型软件公司，以“全包”(IBM不出项目经理及架构师) 或者“半包” (IBM出项目经理及架构师，合作软件公司出低级别角色的人员)的形式，进行软件开发。这些参与合作的小型软件公司，对于IBM 来说，也就是“资源池”。
事实证明，此做法往往不如将软件项目交给一个中小型软件公司以全部自有人员进行开发。
究其原因，在于其中的角色分工，导致责任分离，一旦出现故障，难以区分问题在哪一方。谁来调查问题？IBM 来调查？它很有可能都把问题推到合作的小型公司身上。甲方来调查？甲方未必原有投入足够的人力资源去调查，且未必有足够的能力去区分IBM及其合作伙伴各负担多少责任。
非软件行业公司自建软件开发部门成立"资源池"，也会有类似的问题。
这种事实上是转包的方式，往往存在层层转包，费用逐步大幅下降、工期逐级压缩，最后真正干活的公司，拿到的钱非常少，难以派出高水平的人员，只能以低水平的人员勉强完成项目。
不仅是很多企业，相关法律也在竭力避免这种转包方式。
我很奇怪的是，此汽车公司，以前对于乙方软件公司，承接项目后引入外部人力资源公司的程序员/测试人员，非常反感，极力要求乙方以自有人员来完成项目，减少不可控因素。现在轮到自己的软件开发部门来承接软件项目，却主动规划使用“资源池”的方式，来提高整体灵活性。如果甲方自己的软件开发部门使用“资源池”的方式可提供整体灵活性，为何以前要反对乙方软件公司使用“资源池”的方式承接项目？
使用"资源池"的合作方式，有一个管理上的假设前提：资源池里，人与人的差异可忽略，只看每个项目借用的人天数，折算成相应的费用金额。现在的技术发展导致技术多，技术人员在经验上往往有所偏重，比如某人连续几个项目都做报表模块，下个项目中，换一个从未做过报表模块的新手，可能工作效率不如此人的一半。只看人天数不看具体人员是不妥当的。唯一看上去理论上可行的是，对“资源池”里的每个人，进行逐个项目打分，进行打分，不同打分对应不同单价，对后续主持项目的负责人可见，其在挑选“资源池”里的人时，可借此打分/单价来选定人员。这个做法的实际可操作性太小。
甲方管理人员所不知道的是，写软件，如同作家写文章。也许小学毕业以上的，人人都会写文章，但不同的人，最后的完成质量与效率，差异很大。乙方纯软件公司，往往以“能者多劳”的方式，让最能干的人，多干一些活，实现其项目时间计划，不偏离太多。其背后的激励机制，在于奖惩制度的灵活性。甲方“资源池”方式，想以“能者多劳”的方式，借以掩盖管理人员的技术外行及计划的不合理，因甲方激励机制的局限，难度大很多。
第七，期望以传统行业的流水线分工位的方式来进行软件开发，则更是不可行。
传统行业的流水性方式，分工位，在于其一旦发现缺陷，可向上追溯问题根源在哪一个环节，且其追溯具有快捷、内部局部范围内公开的特性。软件分步骤开发，计划是A队，需求调研是B队，设计是C队，开发是D队，测试是E队，部署是F队，这样一旦系统运行出故障，能很快追溯到哪个环节么？追溯很费力，难以局部范围内公开。且一旦发现某个环节频频出问题，甲方自建软件开发部门、“资源池”，能否及时进行人员调整，也很难说。乙方纯软件公司里，项目角色是临时性的；甲方自建软件开发部门，项目角色与其行政级别/部门是强关联的，基本无法做到“某人这个项目里做项目经理，业绩差劲，下个项目转为测试人员”。这种差异是致命的。
问题一旦没有追溯追究的习惯，则后续难以提高各队人员的责任心。“有错不罚”，还想带好队伍？哪有那么容易的事情。
另外，使用外部纯软件公司进行项目合作，可以很轻易地把那些极不合格的乙方公司，排除在未来的采购供应商名单中。对于非软件行业公司自建软件开发部门，如何处理类似事情？把水平很差的人开除？或列入黑名单？都有为难之处。