【TL软件开发公司概况及其项目运营现状分析案例6200字】

TL软件开发公司概况及其项目运营现状分析案例目录TOC\o"1-3"\h\u27972TL软件开发公司概况及其项目运营现状分析案例 112500第一节TL公司概况 118139第二节TL公司的项目交付进度统计 7第一节TL公司概况本文重点针对一家初创型的软件企业TL公司进行案例研究，研究的范围是该公司成立之后至第34个月（含）之前的企业管理与项目交付情况。在本章节中，研究内容主要包括介绍案例公司的基本特征，人员与组织结构情况，创业之初所制定的发展战略，以及当前运营的软件开发项目情况等出于保护商业秘密的目的，文中可能在一些细节的论据之处未能给出充分的信息资料，例如有关该公司的项目金额、员工薪资等，但是经过仔细检查，这些信息和细节情况不是本文研究围绕的主题或内容主线，因此不会影响本文的论证分析以及最终结论的得出。。出于保护商业秘密的目的，文中可能在一些细节的论据之处未能给出充分的信息资料，例如有关该公司的项目金额、员工薪资等，但是经过仔细检查，这些信息和细节情况不是本文研究围绕的主题或内容主线，因此不会影响本文的论证分析以及最终结论的得出。与此同时，为了突出现实中该公司阶段性的发展特征，为了本章内容的表述清晰，文中将对案例公司成立以来34个月的时间段进行划分：第1自然月至第12自然月属于公司成立后的“首年”，第13自然月至第24自然月为“第二年度”，第25自然月至第34自然月为“第三年度”。其中第二和第三年度是TL公司实际有项目运营的时间阶段。这些表述在所有文字说明和统计图表中将是统一的。一、TL公司的基本情况TL公司由43名正式员工组成，依照国家统计局颁布的企业规模划分标准根据国家统计局《统计上大中小微型企业划分办法（2017）》，软件和信息技术服务业行业的企业划分标准为：（1）大型企业：从业人员≥300人，营业收入≥10000万元；（2）中型企业：从业人员100≤X＜300人，营业收入1000≤Y＜10000万元；（3）小型企业：从业人员10≤X＜100人，营业收入50≤Y＜1000万元；（4）微型企业：从业人员＜10人，营业收入＜50万元。，该公司在软件行业中符合小型企业的规模认定；截止到本次研究结束时和文字工作开始前，公司成立时间为34个月整，该公司的注册资本全部来自于创业人员的个人筹集。以上特征决定了TL公司符合初创企业的属性范围。根据国家统计局《统计上大中小微型企业划分办法（2017）》，软件和信息技术服务业行业的企业划分标准为：（1）大型企业：从业人员≥300人，营业收入≥10000万元；（2）中型企业：从业人员100≤X＜300人，营业收入1000≤Y＜10000万元；（3）小型企业：从业人员10≤X＜100人，营业收入50≤Y＜1000万元；（4）微型企业：从业人员＜10人，营业收入＜50万元。关于TL公司的员工构成方面。TL公司以计算机专业的技术人员为主要组成，员工的年轻化程度较高。管理层主要由公司的初创团队担任，包括总经理1人、副总经理2人（分管商务和技术）和部门主管4人。技术人员包括三种分工，人员数量和工作职能分别如下：（1）开发工程师约20人，工作职能是代码编写，根据代码类别具体分为java开发、安卓开发、IOS开发和前端开发等；（2）实施工程师约10人，负责产品建设、产品运维和客户服务；（3）测试工程师约3人。另外职能部门包括财务和人事两方面工作。关于TL公司的商务和产品特征方面。TL公司以开发和销售软件产品与相关服务为主营业务，所对接的客户范围是国内的企事业单位，业务性质属于对公，客户数量相对有限，具体的客户对象也相对特定。该公司对市场机会的抓取是通过创业团队的自身积累即非正式管理来实现的，这一特征也非常符合软件行业初创型公司的普遍特点。该公司的产品类别属于办公应用软件，这类软件旨在为客户的实际工作场景实现信息化建设，也就是说，通过一套办公应用软件，某单位线下的工作业务流程可以全部转移到线上进行，从而实现无纸化办公。由于不同客户单位的从事专业和业务内容各不相同，因此向每家客户销售的软件都具有不同的功能组合与后台逻辑，TL公司为客户提供软件产品的定制化业务。二、TL公司的组织结构在业务拓展过程中，TL公司逐渐形成了围绕项目管理和软件交付而运作的部门结构。截至本文在第三年度调研时，该公司的组织结构如图3.1所示。图3.1TL公司组织结构示意图公司的最高管理者是总经理，负责公司经营的全面工作，包括项目审批、融资关系、对公司全体员工的调配及考核、对各项目进度和质量的最高监督等。两名副总经理分管商务立项和研发技术工作，同其他四个部门一起直接向总经理负责。商务副总是大客户A部的部门主管，部门经理就是项目经理负责向其汇报；技术副总是研发中心和技术服务中心两个部门的主管。除职能部门外，大客户B部、直销部和分销部这三个部门在组织设计中也应当由副总分管，但由于企业在初创阶段需要熟悉新业务，逐渐培养主持跨部门业务的成熟干部，因此暂由总经理代管。负责公司定制软件产品项目工作的部门，涉及研发中心、大客户A部、大客户B部和技术服务中心（仅测试工程师），这四个部门的工作流程与合作关系是本文所围绕讨论的重点。直销部和分销部尚未系统地开展业务，人员结构不齐全，技术服务中心的实施工程师主要负责支持这两部门的未来业务，因此本次研究暂不涉及这些机构和人员。三、TL公司的战略设计创业之初，TL公司充分发挥其技术能力，并且秉持理想主义的创业精神，制定了一项战略方案，规划了如何开展其软件定制业务的愿景。公司成立后，首年没有签订商务项目，而是集中由创业团队中的技术专家自主研发出了一款整合有云计算等先进技术的底层技术平台D（本文或简称为“D平台”），与此同时逐渐完成各专业员工的配齐。这套D平台就是TL公司的发展战略的集中体现。在这款D平台软件成熟完善的前提下，TL公司可以在统一的技术平台D上，完全由实施工程师直接操作，配置出各项定制的软件产品，从而不触及代码地完成软件的开发建设。如果这项战略完美实现，在D平台开发完成后，TL公司就实现了消除在软件开发项目中编写代码的工作，极大地提高项目交付效率，为公司带来可以持续增长业绩。同时，在该战略的规划之下，该公司的开发人员不用接触项目定制产品的相关工作，开发工程师的主要任务即为D平台研发新的技术功能，以拓展提升该平台对商务项目的支撑能力。然而，这项D平台的开发工作尚未完成时，公司因为首年的启动资金耗竭，提前进入了合同项目签约和软件产品建设的运营阶段。应对资金短缺的迫切困境，TL公司的管理层将初始的战略规划进行了调整，即将D平台的代码可编辑性开放，通过一边做项目交付产品，一边完善该平台的代码，从而在应对复杂的市场需求的同时，提高D平台对不同需求的支撑性和适应能力。战略上实行的调整，反映了TL公司战略理想的触地，其底层技术平台D的不完善性将决定公司在其产品开发的过程将涉及繁重的代码工作，这为该公司理想中的项目顺利交付造成了阻碍之一。四、TL公司业务模式及工作流程自第二年度，TL公司进入到了以项目管理为核心的发展阶段，从该公司大客户项目A部和B部的两项部门设置中可以看出。大客户项目A、B部重点围绕项目而运作，同时研发中心的开发人员和技术服务中心的测试人员为A、B两个项目部门的工作提供支持。首先，“大客户”的含义具有以下几个层面：（1）项目对接的客户性质较为官方，与公司有重要的信赖关系，倾向于建立长期持续的合作；（2）这类客户需求的软件产品规模较大，项目的周期较长，建设周期往往按年计算；（3）项目的金额较高，因此这类项目的顺利交付以及阶段性的按时回款，是关乎公司的生存发展的首要任务。其次，大客户A、B两部门的合同履行和项目工作的方式基本一致，具有以下特点：（1）大客户部门的员工长期在客户单位的现场办公；（2）每个部门在同一时间基本只与一家客户签订合同，每份合同对应一套软件即一个项目，但应客户实际需求往往同时签订或者陆续叠加多个项目（多套软件），因此部门与项目的对应关系是一对多的。产品建设完成、软件上线验收后项目结束，完工的项目部门再与下一家客户签约，部门人员相应地转移办公地点。再次，在人员配置上，两个大客户部门均是只有项目经理和实施工程师的项目团队，项目经理由部门主管担任，每位主管兼任多个项目的负责人。涉及底层平台D的调试工作，由研发中心的开发工程师在公司远程支持。由于大客户项目部同时为一家客户建设多个软件，因此相应地，研发中心的每位开发人员都需要同时支持多个项目工作。研发中心的主管根据每名开发人员的能力级别、代码语言类别或者偏好特长，随机分配人员到不同编码要求的项目组。开发人员按能力级别与部分项目任务的对应关系如图3.2所示。图3.2TL公司开发人员（部分）与项目任务（部分）对应关系示意图上述示意图中，项目和部门之间的连线较为密集，这显示了产品项目与开发人员之间一对多、多对一和多对多的关系的混沌状态。这比较鲜明地反映了当前研发中心对人员实行组织管理和随机分配制度的效果。开发工程师在上述安排下，一部分工作任务是修改D平台的代码，完善其对项目上产品建设的支撑能力，另一部分更多的工作则是出于D平台的技术能力尚浅，加上D平台的核心技术并不为多数人掌握，因此开发人员普遍尽量绕开D平台直接制作软件补丁包，以实现短期内追赶项目交付进度的目的。这就造成项目上的开发任务依然很艰巨，开发人员甚至需要放弃休息时间加班完成项目工作。由此可见，研究TL公司的开发流程和开发人员的工作方法，是十分重要的。在D平台编码完善、最终关闭其可编辑性之前，开发任务都是TL公司围绕运转的核心工作，尤其是鉴于D平台的成熟过程可能相当漫长。尽管一些中小型软件企业会选择借鉴互联网公司常用的敏捷开发模式，但TL公司的软件开发流程遵循传统的瀑布式开发方法，这是由于该公司的主创人员基本都来自大型软件企业，过往背景中的工作习惯和熟练技能使该公司决定沿用这些人员曾在原来企业应用的瀑布模型来组织软件项目管理。由于该公司拥有自主研发的底层技术平台D，因此具体的瀑布式开发过程有别于标准模型，直观地表现为瀑布中间的设计和编码阶段被简化了一些。基于在D平台进行操作，软件的开发过程主要由实施工程师完成，需要修改D平台代码或者解决平台bug的情形由开发工程师协助。表现在项目流程上，实施工作代替了瀑布中的编码环节，只有涉及到D平台的编码和维护才需动用开发人员。该公司的主要工作流程如图3.3所示。图3.3TL公司基于软件开发瀑布模型的项目流程图通过上述项目流程，客户定制的软件被从无到有地建设出来。围绕产品生产交付的项目工作，除了技术上的实现之外，项目上的各专业人员需要在密切的合作中充分交流。在第二年度的初期，每个项目在需求分析阶段完成之后，会统一组织召开项目例会，参与到项目组的全体成员均出席该例会。会上，由项目组的商务人员与技术人员（开发、实施和测试）相互正式沟通项目情况，内容针对客户需求如何设计产品，涉及哪些技术要求，项目工作的时间安排和其他规定等，完会后项目正式启动开始工作。然而，随着时间的推移，公司承接的软件项目数量逐渐增加，每个项目启动时难以分别组织会议，同时，每名员工都身处多个项目组当中，开会将严重挤压项目上紧张的工作时间，因此召开例会的习惯逐渐被取消了，项目工作在无正式沟通的前提下随着合同签订的时间开始。关于项目情况等的沟通事宜，转移到日常在需要时进行非正式交流。此外，根据瀑布式开发过程的要求，需求分析阶段和测试阶段分别需要产出需求分析报告和测试报告的文档，由实施工程师和测试工程师负责编写。瀑布模型中的文档是十分重要的，是下一阶段和后续阶段所有工作的前提依据。然而，在TL公司发展到第三年度时，出于赶工交付的目的以及文字写作本身具有复杂性等多种原因，文档工作逐渐被大家认为是不必要的程序，便基本被全部取消了。以上两种情形持续时间已久，然而TL公司逐渐发现，这些表面上精简了项目工作的做法，造成的结果却是公司的项目进程不仅没有缩短，反而让项目成员感觉手上的工作量越来越增加，工作压力也没有符合期望地得到减小。伴随着业务的逐渐拓展，TL公司的软件项目上开始频繁出现一些问题，最直观地表现为，绝大部分项目都出现了上线交付时间延期的现象。项目延期交付直接关系到商务合同的回款进度，项目未按约定时间完成阶段性交付任务，相应地客户方面只能延迟支付该阶段所对应的款项。项目延期情况最严重的时期，公司仅能依靠新签项目合同的首付款维持生产和运转。第二节TL公司的项目交付进度统计为从定量的角度详细了解TL公司项目交付的现状，本文收集了TL公司自第二年度到调研统计期间的项目资料信息，分别包括有：（1）项目经理编写的项目进度报告，从中提取项目经理定义的项目进度百分比数据；（2）实际项目进度比约定里程碑日期延期的天数，以及回款的进度百分比数据；（3）各项目对应的合同文件，从中查询到双方立项时约定的里程碑（里程碑的含义是项目各阶段工作完成的最后期限，或者客户支付款项的日期）。本文将以上数据信息进行了汇总，形成了项目进度的甘特图，方便查看和对比各方面数据。经过统计，该公司大客户项目部的项目运行情况如下表3.4所示。表3.4TL公司的大客户项目回款及交付进度统计（统计日：第三年度1月6日）图表的横纵表头是所有项目的名称、合同约定的里程碑期限以及交付后运维期限的约定情况，其中，“项目期限”事项之下的总计一列统计了合同约定的从双方签约后项目启动到项目交付、产品验收之间的过程时长，根据项目规模从一个月到七个月不等；首付款是在合同签订之后的5、10或15个工作日内付讫的款项，具体时间由双方在合同中书面约定。表身的内容主体首先是各项目在当前阶段的交付进度和回款进度，并与合同约定的里程碑进行比较。其中，项目期限和回款比例这两行数据为合同中的约定信息；回款比例中加粗的百分比是由项目经理确认的已达成的回款进度，交付进度一行的百分比是由项目经理所评估确认的数据。以项目A01为例，截止到统计日期第三年度1月6日该项目应当达成的里程碑是第二年度12月2日已完成项目交付、达成终验款收讫，该项目的实际进展是在回款方面公司收到了50%的首付款和40%初验款，共计达成全部回款的90%，但项目方面产品的交付进度仅为20%，项目依然处于启动阶段。在交付进度的左侧一列中，各负数的含义是项目延期于里程碑的具体天数，其中大客户A部的所有项目均发生了交付延期，不考虑客户暂停项目的情形下，统计平均延期天数为69.33天，已发生的最长延期时间达到136天。比较全部项目的交付进度与合同约定的交付期限可以总结出，只有项目C01按时达成了当前里程碑并提前实现了项目交付，项目A02、A04、B03已超过约定期限未达成里程碑，项目A01、A03、B01和B02已超过约定期限未达成里程碑且已超