第三，软件开发技术人员对工程化理论的实践有抵触心理，认为增加了劳动量。
一些软件企业在项目完成后给用户进行培训讲课时，往往会以“用户文档滞后”来解释“产品说明、用户手册”之类文档的不健全。这似乎没有什么不妥，但如果将项目叫做“工程”的话，就可将其与建筑工程相比较，那我们也就可以说：大楼有了，图纸滞后。这是很可笑的。
作坊式开发过程中的技术负责人员一般是个“英雄”，应用系统的“设计”是在其脑子里完成的，在其意识里工作结果就只是一堆可执行的程序，既然能直接敲得出来，自然没必要再做写文档的“重复工作”。
这样做的结果是，由于设计思路和实现细节在项目组内的交流困难，大部分的系统开发过程由于大量尝试性、重复性工作而变得缓慢，后期调试会出现许多意想不到的大大小小的问题，狼烟四起之时大多数技术人员特别是技术负责人主要工作是“救火”。这样的项目，工程延期往往是普遍现象，“火势太大”情况下的人力再投入常常被“情非得己”地采用，工程越大越是如此。软件开发的特殊性决定了其工程效率与编程人员的数量并不成正比，没有过程文档支持下的项目到了后期，人员的投入反而有可能使工程进度减慢。工程进度失控将直接导致项目亏损，这是显而易见的。
所以也就不难理解，在作坊式的软件企业里，会“救火”的技术人员为企业所推崇和依赖，他就是掌握企业命运的英雄。可想而知，如果这样一个英雄半途离开，那没有任何文档支持的项目的中间结果对其他人来说基本上就是“一堆垃圾”而已，也就是说，企业前期投入的资金只是造了“一堆垃圾”。这时候，主管的脸色才真会不好看了。
先设计后施工。大楼在未动工时就在图纸上进行，可能发生的修改都在图纸上实现，可能造成的不利状况在图纸上被杜绝，在没有一砖一瓦的损失下做到各方面的满意。工程本身就是大家参预的，是共同智慧的结晶。这就叫工程！
如果有人告诉你：“有个国际飞机制造公司没有下属的飞机制造厂”，你信吗？如果相信，那你可能对“软件工程”有一些理解了。如果你不相信，那我说：建筑设计院无需组建自己的建筑公司，你同意吗？如果整个环境支持，我们何不只保留一个“设计院”来轻松攫取高端巨额利润呢？
软件企业在若干项目过程中逐步形成了自己的过程模式，其极致就是形成一种流水线式的规范模式，但如果流水线的某个环节存在问题，那开发新产品的过程会一样重蹈覆辙。正因如此，目前被大力提倡的CMM正是指导我们解决这类问题的。
第四，技术人员没有实现分层，对工程化开发不能很好支持
在一些软件企业里，技术人员疲于奔命，似乎有做不完的工作、有学不完的知识，但有一天他却失落地喟叹：没学到什么技术啊！多年前就讲知识爆炸，而IT实际上才是天天在知识爆炸，新技术，新工具层出不穷，一个比一个复杂，一个比一个玄妙。一个人能有多少精力、多少时间去应付这种爆炸过来的知识呢？
作坊式开发的实现，要求主要的项目实施人员得从各个方面来说都得是非常出色的，不仅要全面地掌握系统架构知识、具有业务分析和系统设计能力，而且还得是多种流行开发工具的专家、数据库的专家、网络配置的专家等等等等，这对于一个人来说是不大可能的，在这里，“英雄”的塑造之难可见一斑。所以也就不难理解我们都将程序员称作“Programmer”，而绝对不能学印度人叫做什么“Coder”。作坊模式下不切实际的实际技术需求就为工程的失败埋下了伏笔。
事实上，软件业在逐步趋向规范化之路的今天，软件企业内部逐步对技术进行细分，自然地对技术人员也就从所（需）掌握知识上进行划分，这就保证了技术人才的专业化和技术队伍的专业化。
从企业管理和工程技术角度来讲，整个软件企业的技术结构可以大体上分为四层，即技术方向决策层、技术研究组织层、项目管理实施层和程序代码编制层。
技术方向决策层是对于公司市场方向、产品方向和技术方向进行定位，以及组织技术队伍、规划实施策略等的一类宏观综合技术层。
技术研究组织层是对于项目工程进行规模确定、计划制订、方案设计、技术难点攻关和技术力量配置等的项目综合支持技术层。
项目管理实施层是对工程项目按计划按方案进行实施和过程管理的综合实施技术层。
程序代码编制层是指功能程序代码编制技术层。
系统分析员、需求分析师、高级程序员、程序员等，在对其知识、经验和能力的要求上从高到低，在项目中担当相应的角色、完成相应的任务。在具体项目实施中相应人员的工作内容和担当角色，依据项目规模大小和现有人员配置情况，可以逐级拔高使用，这也是人才培养所必须的。这里强调技术结构分层和技术人员划分，更多的是技术责任的明细，而非具体个人的技术定位，将技术任务和相应的责任划分到具体的岗位、将岗位落实到具体的人，这与具体技术人员身兼数职是不矛盾的。
对于高级程序员、程序员等人员，从技术方向、开发工具的分类上根据具体需要进行进一步的细分，这样会更趋合理和可靠。企业须有计划地进行技术队伍构建和人才吸收、培养工作，在规范化工程管理模式下这种工作才有实施的可能。
第五，软件高端人才真实含意被曲解，规范化管理人才的普遍缺乏直接阻碍工程的规范化实施
从大环境上来讲，制约软件业发展的瓶颈很多：资金不足，人才匮乏，没有核心技术等等。单从人才角度做个比较：在印度，软件企业约有1000家，拥有28万软件工程师，平均每个企业280人；然而中国仅仅有大约15万软件开发人员，分布在5000多家软件企业，绝大多数企业员工在50人以下。由此，专家们认为：在世界软件业进入工业化生产的今天，中国却依然在进行小作坊式生产。
专家们一方面唉叹资金不足，一方面埋怨人力的分散，但面对应用软件需求市场操作的不规范和经济规模的萎缩，软件企业如果盲目地扩充规模，将背起沉重的负担，这对无异于自掘坟墓。软件开发方式并非由人力规模一方面因素决定，工业革命来自生产技术的变革，而非人力的巨增，工业化大生产是流水线操作，而非人海战术。软件开发方式的变革同样的关键在于技术的变革，这种技术并非所谓的“核心技术”，而是指导工程化过程和管理规范化生产的技术。
规范的工程化开发方式没有被软件业广泛采用，除了前面所讲的一些原因外，最主要的还是掌握规范化管理技术的高端人才的缺乏！
作坊式开发的软件企业里，一提到人才，马上想到的是会用什么工具、用过什么系统平台、掌握的“技术”是不是“主流”？最主要的看是不是“全才”、能不能“救火”？而讲到技术管理人才的时候，就看是不是能以其技术“镇住”麾下的技术人员了，所以往往在找不到这样的技术能人时，只好拿不沾边的高学历来吓唬人。这样的企业的管理者很少会想到人才对开发方式的理解、认识以及相应的生产实践经历。
对落后生产方式的坚持，决定了规范化生产的不被认可；对规范化管理的淡漠，抑制了相应人才的成长，甚至扼杀了其生命。在这样一种恶性循环状态下，高端的技术管理人才严重匮乏也就是自然的了。
在软件开发企业里，高端技术管理人才的职责是什么？我们大可以列出许多许多，但在国外软件业资深专家的著作里只是一句话：以最小代价为公司赢得最大收益。奇怪，这不是总经理的职责吗？但试想想，如果一个总经理360天围着一帮程序员，琢磨他们为什么要用一年的时间才做完了本应三个月完成的工作，他能搞明白吗？他能忙得过来吗？
作为一个企业，说穿了，其根本目的还就是两个字――盈利，企业做什么行业只是一种盈利手段而已。既然要做软件开发这个有其自身特殊性的行业，就得遵从其运营的基本规律和本质要求，采用相应的科学的生产方式和管理方法。
软件企业在谋求发展的同时也要考虑如何生存，面对软件业生存竞争和风险危机，软件企业的管理者需要有足够的规范意识和创新精神。
