[项目管理]工业工程理论在软件项目中的实践

摘要：结合工业工程理论，对公司现有软件项目开发流程进行总结分析，优化项目管理流程、提升项目作业效率。

关键词：工作研究；流程分析；降低成本

引言

本人在IT行业从事软件开发工作，经过本学期工业工程伦理和实践课程的学习，对工业工程理论的在工作中的应用有了一些理解和收获。本文内容分为三大部分，第一部分是我对本门课程的理解总结和体会，第二部分是对所在公司软件项目流程的工作研究，第三部分是工业工程理论在具体编程作业中应用。

1 理解工业工程

1.1 工业工程的目标

工业工程作为一门综合学科，通过管理技术和信息技术的结合，从自然科学、社会科学、人体工程学、经济学等角度，对企业生产的流程进行记录、分析，对人力、材料、设备、能源和信息进行合理规划和优化，最终达到提高整体工作效率、简化工作流程、减低经济成本、提高企业效益的目标。

1.2 工业工程的发展

工业工程理论与时俱进。随着生产技术的升级换代，工业工程的研究范围也在不断变化和扩展。

第一次工业革命后，由于机器的出现，生产力大幅度提升，大规模的工厂生产逐步取代小规模的个体作坊生产，提高生产效率的研究开始展露头角，为工业工程的诞生奠定了基础，与此同时劳资方的矛盾也逐渐产生，催生了工会、铁路管理局等组织来平衡双方矛盾。

第二次工业革命后，电气技术的发明，生产力再次产生质的飞跃，工业管理理念百家争鸣，最终出现了以泰勒为首的科学管理理论，标志着工业工程理论体系的初步建立。科学管理对作业过程中的工作和时间进行记录分析，然后进行改进和简化，使生产过程标准化、规范化，极大地提高了生产效率。与此同时，由于过分强调“经济人”，人因对生产的影响也更加明显，工人阶级和工业资产阶级的矛盾逐步显现和升级，但并未从根本上化解提高生产力与压榨劳动力之间的矛盾。

第三次工业(科技)革命后，电子计算机技术、新能源技术的出现，科学技术对于生产的影响越来越重要，催生了一大批新的产业，工业工程的研究范围也随之扩展，重点从最初的对人力作业研究扩展到对机器的研究，如何使人机更和谐地协作，使生产自动化、劳动脑力化成为了工业工程研究的新方向。

第四次工业革命后，互联网的出现，打破了以往的地域、物理限制，将人力、机器、物料、能源联通在一张全球性的巨大网络中，工业工程的研究范围彻底从对动作研究、时间研究和流程分析，演化扩展成为了一门跨人力、机器、物料、信息技术、法律、社会、环境等学科的综合研究体系，其研究目标也从单一地提升生产效率转变为提高企业的产品质量、服务质量、创新能力等综合竞争力。互联网带来的信息大爆炸，使得工业工程理论不再是象牙塔里的不可得之物，他的理念被广泛传播，其精髓也从传统的工业生产被运用到更广泛的领域和服务中去。

1.3 工业工程的未来猜想

在未来人工智能、超级计算机、新能源等技术成熟普及后，相信生产力将提高到一个前所未有发达水平，人类可能极大地解放双手，工业工程的中对人类作业动作的分析研究也势会向智能机器作业的方向倾斜。与此同时，人类对产品的品质和可靠性的要求也将越来越高，人因在工程中的分量也越来越重要。

2 工业工程在软件项目中的应用

软件项目的作业地点、作业过程、作业工具相对集中，其生产过程主要为脑力劳动，其生产效率和产品质量受人因影响较大，其产品形态也呈现数字化、虚拟化。在系统层面，工业工程理论可用来优化项目流程，改善各岗位间的协作方式。在元素层面，工业工程理论中较微观的流程分析、工艺分析等方法，则更适用于在制造业、建筑业、物料业等可视化、标准化流程的现场作业场景，对于软件项目则可研究改善的对象相对抽象，如优化作业环境、流程、动作，升级落后技术，减少瓶颈节点工作时间等。

结合工作研究的方法，我分别对公司的项目流程和人员结构进行了分析优化。

2.1 项目流程的工作研究

2.1.1 挖掘问题,确定工作研究项目

从经济因素、技术因素、人力因素进行考虑，选定公司的软件项目开发流程为研究对象，结合5W1H和ECRS方法理论，对流程进行分析优化改进，希望能提高整体工作效率、简化工作流程、减低经济成本。

2.1.2 观察现行方法

由于软件项目流程的作业时间具有难以估算的特点，故耗时仅记录大致范围。

流程	目的	耗时
1.立项会议	1.组建项目团队 2.明确项目目标	0.5h
2.收集需求	收集需求	0.5-1.5h
3.绘制需求原型	将客户非结构化的需求具象化，引导客户确认和完善需求	8-16h
3.评审需求原型	1.与客户确认需求 2.开发人员了解需求细节，评估复杂度，初步确定技术方案	1-2h
4.设计UI界面	以原型图为基础设计人机交互界面	8-24h
5.搭建开发环境	搭建开发环境	8-16h
6.沟通API	前后端人员沟通技术细节。	0.5-1h
7.开发前端界面	开发前端界面	根据工作量变化
8.开发后端	开发后端程序和API	根据工作量变化
9.测试和修复	测试产品寻找缺陷并修复
10.验收		8-16h
11.发布测试环境	发布产品到测试环境	30min
12.发布验收环境	发布产品至客户验收环境	1-2h
13.发布生产环境	发布产品至正式环境	1-2h

2.1.3 提出改善方案

改善方案遵循先5W1H方法进行分析，然后通过ECRS方法进行优化的原则，从流程上发现项目流程中存在的不经济、不合理、不科学现象，从工序上确保操作工序是否合理顺畅，从作业上确保各类作业必要、简化、最优。具体表现在为：

在需求治理方面，通过对需求目进行3次提问有效规避非必要需求、减少工作量，同时发掘出客户最深层的需求。

在项目流程方面，通过对流程必要性、最终目的进行提问，消除不必要工序和作业，合并不饱和、多人操作为饱和的担任操作，对于无法消除或合并的流程，调整流程顺序，安排并行流程，减少等待时间。对于复杂的、重复的、不经济的手工操作，考虑用自动化工具进行简化，以结果为导向，避免为追求技术而使用高级复杂技术，反复进行5W1H进行评价，使用最适合、最经济的方法。改进方法如下：

流程	问题	改进
1.立项会议	无	无
2.收集需求	1.会议时间过长 2.客户思维发散，经常无法系统性描述需求	根据5W1H法制作标准化的需求收集模板，首次与需求方接触前，请需求方根据模板填写关键要素，并提供市场竞品。明确需求收集的关键要素，为需求讨论划定框架边界。
3.绘制需求原型	无	无
3.评审需求原型	会议流程不确定，会前各方无准备、不了解需求，评审过程发散，提问的问题不着边际，各说各话。会议纪要较难整理、耗时多。	1.标准化会议流程。 2.讨论前15min全员默读需求，了解需求细节，列出问题清单。 3.会议过程主持人统一讲解，然后提问和回答。复杂问题会后先考虑再专项讨论。 4.简化会议记录：会议过程录音，会议纪要部分要点一句话概括，当场确认完成公布至工作群。
4.设计UI界面	设计完UI界面后未向需求方确认直接开发或未向需求方主要决策人确认。导致需求方后期会推翻设计稿，造成开发工作浪费。	设计图完成后，第一时间召集需求方，请主要决策人进行确认，将需求改动提前到设计阶段，减少无用功。
5.搭建开发环境		可将开发框架、数据库、服务器配置模板化。
6.沟通API	未做书面准备，仅口头沟通，各方理解有偏差。	沟通前准备书面文档，定义好请求体和返回体格式，沟通过程依照文档进行。
7.开发前端界面	无
8.开发后端	无
9.测试和修复	无
10.验收	无
11.发布测试环境	发布时间长	引入了Jenkins等持续集成工具，将手动构建部署应用升级为全自动部署
12.发布验收环境	发布时间长	对于小型项目，可直接删除此步骤；对于中大型项目：参考全自动的测试环境，将手工发布升级为半自动发布
13.发布生产环境	发布时间长	参考全自动的测试环境，将手工发布升级为半自动发布

2.1.4改善方案的实施和评价

改善方案涉及到部门内(开发人员)和部门外(需求方)，采取先内部试行再外部推广的方式。对于部门内人员组织集中培训，项目经理跟进被优化流程相关人员；对于部门外人员，项目经理向主管、分管领导汇报，分管领导召集相关部门主管进行讨论、评价，得到确认后由项目经理组织需求方人员进行专门培训和实验运行，使具体执行人员和相关人员真正掌握新方案的操作。（预期）效果如下：

流程	效果
1.立项会议	未改动
2.收集需求	会议时间控制在了1h以内，产品经理会后的整理工作量也明显减轻
3.绘制需求原型	未改动
3.评审需求原型	1.会议时间控制在了1h以内 2.与会者对需求背景有全盘了解，减少了基础问题提问，增加了关键问题提问 3.减少无效会议信息记录，节省记录人时间，累计每月节省8h以上
4.设计UI界面	增加了确认UI界面的环节（8-16h），但明显减少了开发过程中的误差、改动。整体上缩短工期，提高质量
5.搭建开发环境	时间缩短为4h
6.沟通API	增加了各参与人的设计准备工作，减少了开发过程中的理解偏差，总体缩短了工期，提高质量。
7.开发前端界面	未改动
8.开发后端	未改动
9.测试和修复	未改动
10.验收	未改动
11.发布测试环境	时间缩短为5min
12.发布验收环境	时间缩短为0-0.5h
13.发布生产环境	时间缩短为0.5h

2.1.5 改善方案的标准化

方案的标准化在IT行业非常重要，其目的是把新的方案和经验通过书面形式进行固化，避免重复造轮子，防止因为人员的岗位变动、离职造成经验和技术的流失，使新员工到岗即可快速上手操作，确保均匀的生产效率和品质。本次的改善方案分三步走：首先对改善流程形成书面指南，包括改善目的、负责人、操作细节、相关文件表格；其次组织相关人员培训，按照由部门内到部门外的顺序实施；最后由项目经理定期检查收集反馈，并进行修订改善。最终形成简洁标准的工作流程。

制作本次改善方案正值公司战略转型期，切实应用到了公司的真实工作中，实施过程前期会遇到部分人员的不适应和磨合，但整体效果显著，规范和标准化了项目流程。

2.2 人员结构的工作研究

前期公司新开发项目已基本成型，有较多岗位人员工作不饱和，本次公司的转型过程中也对人员架构进行了优化，作为团队骨干，我参照5W1H和ECRS法对人员优化提出了相关意见，最终结果如下：

岗位	数量	工作情况	优化
产品经理	1	各项目共享，工作量饱和，但质量欠佳，无法深入规划产品需求	新增1名，分担工作量，增加需求研究时间，提高产品质量
设计师	3	各项目共享，工作量不饱和，设计成果存在重复造轮子	减少1名，空闲时间整理过往作品，提取公用元素，形成作品模板库，提高作品复用率
前端H5工程师	1	各项目共享，工作量机器饱和	未动
前端Android工程师	1	只维护一个不常用项目，工作量极其不饱和	培训前端H5技能，兼职H5分担工作量
前端IOS工程师	1	只维护一个不常用项目，工作量极其不饱和	培训项目管理技能，兼职项目经理
后端Java工程师	5	大部分项目均已进入维护期，工作量极其不饱和	减少2名，培训1名兼职项目经理，培训1名兼职运维工程师
测试工程师	3	大部分项目均已进入维护期，工作不饱和	减少1名，根据测试人员清楚项目流程的优势，转岗1名为运营
运维工程师	1	工作量不饱和	减少1名
网络工程师	1	工作量不饱和	减少1名
桌面工程师	1	工作量饱和	培训网络管理技能，合并网络、桌面硬件类工作
合计	18

岗位	数量	工作情况
产品经理	2	工作量适中，产品质量显著提高
设计师	2	工作量适中，质量不变，出图速度显著提高
前端H5工程师	1	工作量饱和，效率提高
前端H5/Android工程师	1	工作量饱和
项目经理/前端IOS工程师	1	工作量适中，任务多时参与开发
后端Java工程师	1	工作量饱和
后端Java工程师/运维工程师	1	工作量适中，任务多时参与开发
项目经理/后端Java工程师	1	工作量适中，任务多时参与开发
测试工程师	1	工作量饱和
运营/测试工程师	1	工作量适中，任务多时参与测试
桌面/网络工程师	1	工作量饱和
合计	12

本次共精简6人，合并1岗位，新增5岗位。降低了总成本，增加了闲置人员的工作量，减轻了提高了工作积极人员工作量并提高了薪酬，整体提高了IT团队的激情和活力。后续会根据公司的发展情况和团队协作情况的反馈，动态调整优化团队。

3 工业工程理论在编程作业中的应用

3.1防呆法的应用

防呆法的关键是让最呆笨的人也不会做错事，可归纳为三见：见文知意、见图标知意、见流程图可操作。防呆法可应用于产品设计，对于提升中老年等计算机知识较薄弱的群体的用户体验非常重要。在设计人机交互界面时尽可能简化操作界面、减少操作步骤、使用通俗常见的操作指示图标、设置醒目的求助功能，力求减少人工培训、人工客服。同时，在软件产品应道具备用户行为收集（在遵循工程伦理原则下）和用户意见反馈功能，对于用户的使用行为进行分析，不断优化迭代产品方案，提升产品质量。

3.2 改动法的应用

改动法的原理是通过改善作业的动作、工作场所的布置、工具设备的设计来减少作业动作、降低作业者的疲劳度从而提高作业效率。就编程的过程而言：

3.2.1 减少高等级动作

培训程序员习惯纯键盘操作，尽量减少鼠标的使用，减少长位移动作。为程序员配备全尺寸带数字键的键盘，方便数字的输入，减少寻找、思考动作。为程序员配备多个屏幕，减少单一屏幕内因窗口切换引起的思考辨认。注意屏幕的摆放位置，尽量减少眼球或头颈的转动。项目组成员工位要靠近，身体无需长位移即可讨论沟通。

3.2.2 配置适宜的作业环境

为程序员配备复核人体工程学原理的桌椅、键盘、鼠标，降低作业疲劳。

作业环境保持空气清新通畅、保持温度适宜，添置绿植，使程序员保持良好的精神状态，缓解眼部疲劳。

4 总结

课堂中讲了很多现场管理、工艺流程分析的内容，我认为工业工程理论可能更适用于制造加工业和劳动密集型产业，因此，本文开篇之前我深感苦恼如何将工业工程与软件项目结合，对于工业工程在软件项目中的应用抱以鸡肋的想法。

但是，经过近1个月的理论学习和实践应用，我深刻感受到工业工程分析思想的强大，从宏观分析和具体作业分析上都具备重要的指导价值，在各个行业、各类工作中都可以举一反三地应用。软件项目作为一个工作量、时间、成果都较难准确估算的项目类型，如何运用工业工程理论尽可能地将脑力作业和沟通流程规范化、标准化，在未来具有十分重要的意义。

原创，为本人研究生课程学习总结《工业工程理论和实践课程学习报告》，转载请注明出处。

相关阅读

[项目管理]浅谈软件项目WBS任务分解

[项目管理] 需求评审6大灵魂拷问

[管理笔记] 03.如何选择乙方

[项目管理] 浅谈敏捷型生命周期模型

[项目管理]工业工程理论在软件项目中的实践相关推荐

缺陷分析在软件项目中的实践
有人曾说过:人可以犯错,但绝不能再而三.软件开发中,开发人员经常犯错,主要是没找到根因.有效的缺陷分析可以帮助发现问题.制定改善措施,促进项目健康运营.常见的分析方法:帕累托分析.5why.鱼骨图.找 ...
软件项目中如何开展有效的需求评审
1.需求评审的重要性在软件项目中,需求分析是最开始的工作,同时也是最重要的工作.需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话,往往会给项目带来灭绝性的灾难,不重视需求过程的项目团队将 ...
【软件工程】用户在软件项目中承担的工作
终端用户终端用户既指软件的最终操作者,也是软件工程内的一个概念,指终端用户的抽象集合,用于区分单纯使用软件的用户和进行软件开发的开发者.这种抽象主要在设计用户界面时有用,用于代表普通用户的共同特性. ...
浅论WBS分解在软件项目中的应用
WBS分解在软件项目中的应用 [摘要] 本文结合项目管理的WBS方法,对某系统集成公司的管线资源管理项目进行工作分解,旨在说明WBS方法对项目渐近明细和项目的计划方面所能起到的重要作用. [关键词] ...
[周年感悟]看软件项目中的四种角色
工作一年了,这一年没像大学那样拼命的发帖,拼命的写博客.然而毕竟是过了一年了,便以此文纪念我逝去的2011年吧! 2011年3月份到公司实习,实习到5月,然后回学校做毕业设计,7月份正式入职.若是从实 ...
软件项目中的功能风险矩阵
软件项目中的功能风险矩阵黄国强 2011-9-9 仿照美国总统艾森豪威尔的"时间管理优先矩阵",我画了一个项目功能风险矩阵图. 软件开发中,我们最先要做的就是必要而且有风险的事情 ...
软件项目中的决策分析_软件工程中的决策管理
软件项目中的决策分析 Every day we make a lot of decisions. I always wonder why, in so much companies, there is ...
【软件工程】软件项目中的用户
文章目录终端用户用户在软件项目中承担的工作用户体验用户友好以用户为中心的设计利益相关的用户终端用户终端用户既指软件的最终操作者,也是软件工程内的一个概念,指终端用户的抽象集合,用于区分 ...
如何在软件项目中生成物料清单（SBOM）
随着软件合规.断供.漏洞等风险日益受到重视,需求方会要求开发团队提供软件的详细信息. 常用的方法是,研发团队从源码.配置文件.生成交付物等处提取所需信息按需求方要求的格式形成报告.这种手工生成方法,不 ...

[项目管理]工业工程理论在软件项目中的实践

[项目管理]工业工程理论在软件项目中的实践相关推荐

最新文章

热门文章