1.1.0GA已发布,禅道、jira、itest 一键搬家到Codes及批量式工时填报可用! 查看版本说明
栏目:Codes项目管理研习社

一文讲透项目管理中的管道管理

平台管理员... 2026-01-22 13:55:49.0

一文讲透项目管理中的管道管理


转自  https://mp.weixin.qq.com/s/IjnXONG4abKcWpeZYSOb3Q

目录

1、谈谈项目管理中的管道管理

2、“正确地做事”--项目管道管理,高绩效研发组织的两大必备能力之二

3、IPD落地-项目和管道管理

4、PACE-管道管理



一、谈谈项目管理中的管道管理

(原创 杨学明 共创力研发咨询)


图片

图片


什么是管道管理?



    管道管理(Pipeline Management)管道管理是将产品战略与项目管理和职能管理联系起来(如下图所示),从而更合理地部署企业内与开发相关的资源(不仅包括人,还包括重要设备、辅助设施等等)。它是通过以下三种活动来实现的,这三种活动将重要过程与职能联系起来:

图片

       项目管理的有效性——核心小组、阶段性审核过程、结构化的管理方法——使得企业能迅速有效地将单项产品推向市场。然而,竞争的压力越来越大,迫使企业必须超越项目级的成功管理,而要对研究与开发的投入作整体管理。这就需要在产品开发的投资结构平衡中进行更有效的管理。

       为了达到这种平衡,企业必须设法使其开发管道处于最优性能水平上,必须作出更加完善的资源分配决策,以反映各项目之间的相互关系。企业不但要考虑某一特定产品机会的优势,同时要考虑怎样才能让项目总体结构适应企业的产品战略前瞻。

      因此,对于在多个竞争资源的项目之间进行有效地平衡资源而言,管道管理是必要的:


图片

管道管理的第一个活动:战略平衡




         战略平衡将产品战略与企业的能力和资源紧紧地联系起来,它是一个反复迭代的过程,其结果是选择出有利于企业发展目标的、可行的开发项目。

         战略平衡限定了集成组合管理团队(IPMT)在阶段性审核过程中的决策授权,也限定了职能部门管理者有关资源分配的决策授权。这样,战略平衡没有加入任何官僚成分就对产品战略进行了部署,其中主要使用了三种工具:项目总体进度表、管道载量分布图、职能部门同步预算。

管道管理的第二个活动:管道容量控制




         虽然许多公司都设有阶段性评审,但都未用于优化开发管道,因为每个项目都是独立进行评审,而完全不考虑其它项目,因此就造成了管道的堵塞,市场部只有招架的能力,一方面尽量满足一线的各种紧迫要求,另一方面,还要在其它产品的上市方面下功夫。采购部也正超负荷运转,致力于解决卖方交货问题及尽量减小价格波动。一些研究和开发部门的关键人员常常被召去解决一线出现的问题和产品生产线上的问题。

      由于与其它项目重复,导致在瓶颈区域如进度、人员能力、交付周期等 方面的原因导致延误,尽管核心小组成员多方努力,局面还是难了挽回。高级管理层不得不从其它项目抽调资源以解决项目的问题,因而引起其它管道混乱,很多项目处于”救火”状态。根据共创力咨询专家的分析,影响管道容量的因素主要是三大因素技术稳定性、变更控制力度、项目管理水平。

        只有收集了必要的跨项目的数据和资料,阶段性评审工作才得以加强,IPMT团队才能够优化整个管道的运作,优化的原则如下:

管道管理的第三个活动:协调项目与职能部门的交接



    

       职能经理对通过他们各自部门的项目工作量负责,实际上,他们管理着开发管道的一个部分。协调职能交接的目的是不断优化管道以达到最大可能的流通量。在这种环境下,职能部门和项目是整合在一起进行考虑的,没有完全区分开来。各职能经理共同努力,争取有更多的项目通过整个管道。他们不再仅仅关心各自的部门,而是积极地配合上游和下游职能部门迅速解决各种各样的问题。

      协调职能交接要考虑到涉及所有开发相关部门资源需要的执行行为,包括产品开发、技术开发和常常为人们所低估的产品辅助活动等(例如:市场支持、生产故障排除和持续的监理等)。此外,也应考虑一些重大的举措,如实施新的技术体制和改进开发过程等。上述各种活动,只有产品开发活动由核心小组和阶段性审核小组负责完成,其它的活动将完全依赖于各职能经理根据具体情况通过战略平衡来完成。

      为各项目安排人员常常是很困难的,因为每个核心小组通常都希望得到最好的人手,而且希望得到的数目也比实际上真正需要的多。这样,在保证职能部门目标的前提下,与各项目的核心小组成员共同努力,合理地分配有限的资源就成为职能经理的职责。与相关核心小组成员的密切合作,使部门经理能够确保每个项目计划都是高效的并且是可以实现的。如果他们能运用过去的经验(如对以往项目周期的认识等)着手制订切合实际的计划,那么,他们的工作便简单多了。同时,职能经理还必须为非产品开发行为配备人力资源。这类活动有些是非做个可的,如产品支持等。而其它的活动则应集中在建设本职能部门长期的能力上,以便当许多项目同时涌入管道时,能应付自如;

    仅仅要求人们努力工作、延长工作时间是个短期手段,对应付暂时的超负荷或许有效。但要保证职能部门对长期计划的及时交接,部门经理必须积极地预计未来的要求,并以下列方式主动地面对部门的有限性:

    在许多开发过程得到较大改善的公司里,职能部门管理者发现自己所起的”辅助核心小组成员”的作用已逐渐减弱。事实上,目前竞争激烈的环境日益要求部门管理者们的管理水平来一次质的飞跃。而关键在于明确他们在管道管理过程中他们的新角色是什么。

为什么企业在管理产品开发管道时会遇到问题?



 




       虽然大多数公司认识到他们未能有效地管理产品开发管道,但往往不明白问题的症结所在。我们认为以下可能是造成上述状况的原因:

二、“正确地做事”--项目管道管理,高绩效研发组织的两大必备能力之二

(原创 潘霄 dss 顶世智汇)

化工行业的新产品开发周期长,投资大,且成功的不确定性比较高。据DSS的观察,很多企业在研发项目管理上遇到诸多挑战:

  • 产品推向市场速度太慢——达不到公司的预期,落后于竞争对手,失去首发优势

  • 丧失宝贵的市场机遇——缺乏创新性、突破性的产品或新市场的进入

  • 新产品营收不达预期——客户上量缓慢,产品定价市场接受度低

  • 研发投入和成本超计划——开发成本超支,产品成本过高


究其原因:可能是缺乏对市场、竞争对手和客户的了解;可能是缺乏紧迫感,跟不上市场节奏;可能是决策机制僵化不畅;也可能是缺乏成本一致性和有效性管控……根本问题是对研发项目的执行没有建立有效的管理,没有掌握“正确地做事”的方法。

DSS认为,要解决上述问题,企业需要建立有效的项目管道管理机制,其核心是建立门径式管理流程。


门径式管理流程

门径式管理的出发点,是把新产品开发整个过程切分成数个环节,用门径(stage-gate)把关的方式通过及时的、早期的、严格的决策管理研发项目的进程,提高速度与质量,降低风险。

以DSS PCF (Product Commercialization Framework,即产品商业化框架) 门径式管理流程为例,其标准端到端流程包括六个阶段和五个门径评审。每个阶段有具体的工作任务、流程与工具方法,每个门径评审有问题清单和评审机制。PCF以产品商业化为终极目的,以终为始,管理“不确定性”。

图片

图1:DSS产品商业化门径式管理流程(PCF)


门径式管理的关键成功要素

国内已有许多化工企业开始采用门径式管理流程进行研发项目管理。门径式管理知易行难, DSS认为有以下关键成功要素尤为值得注意:

一、新产品开发是整个公司而非某一部门的责任,跨职能部门合作是产品商业化成功的关键。因此,每一阶段项目团队的骨干成员组成、权责划分、协同配合均对项目的完成质量至关重要。

图片

图2:项目团队由跨职能组成


二、清晰界定门径式管理流程与其它管理流程之间的关系。一方面,门径式管理流程不是一个孤立的流程,必须与企业的战略管理、市场管理、工程管理、业务运营等流程紧密衔接;另一方面,要避免将不同层面、不同领域的流程混杂在门径式管理流程中,导致管理逻辑不明、责任落实不清等问题,严重影响门径式管理的实际效果。企业需要完善流程体系,建立流程之间的联系,让门径式管理流程更纯粹、产品商业化的目标更聚焦。

图片

图3:建立新产品开发流程与其它管理流程之间的联系


三、对新产品开发项目施行差异化管理。DSS观察到,有的企业只用一个管理流程原封不动地应对所有类型的项目,管理僵化、不灵活。根据DSS的经验,不同的产业公司应依据自身行业和产品/服务的特点定制适合的流程。可以从标准流程衍生出简版或特殊版流程,应用于不同类型的项目。例如,以某国际一流化工公司为例,其电子材料部门有标准的6步法流程,有适用于应用开发的3步法敏捷流程,也有适用于新兴技术的探索流程。

图片

图4:DSS主张对新产品开发项目施行差异化管理


四、聚焦阶段评审的核心决策问题。有些企业推行门径式管理的时候比较追求流程图和问题清单设计的尽善尽美,但是没有把每个阶段评审的核心问题是什么想清楚。研发工作的“不确定性”这一与生俱来的特点已然注定:产品商业化流程必不同于业务审批流程。项目组瞄准下一阶段评审的核心决策问题开展工作,不必拘泥于一定按什么顺序做、谁来做、谁来批。阶段评审工作聚焦每一阶段的核心决策问题是否得到满意回答,以此来给出判定结果。

图片

图5:PCF明确各阶段评审的核心决策问题


五、构建创新组织文化,树立正确的理念与行为。一亚洲领先化工公司在与DSS合作引入PCF之前,也有一套门径式管理流程在运行,但几乎所有项目都倒在上市前的最后一刻。究其原因,平时的项目阶段评审都是“一路绿灯”,极少有人愿在大庭广众下明确地说“No”。因此,DSS辅导该公司专门成立了创新文化工作组,帮助重塑创新文化氛围,树立正确的理念与行为,形成统一认知:终止一个项目的决策和推进一个项目的决策,在价值上是等同的。从终止项目上抽出来的资源、节省下来的资金,可以投入到其它更有潜力的项目上。唯如此,企业的研发投资回报才能改善。

图片

图6:创新组织文化、正确的理念与行为是项目管道管理的基础


建立一个健康的项目管道

企业的研发项目在门径式管理流程中流动,会形成一个项目管道。一个健康的项目管道呈现前宽后窄的“喇叭形”的项目分布形态。想要形成这一形态,领先的企业会着重做好以下三点。

一、强化前端加载,让初期想法或概念既有数量,又有质量。在想法产生阶段采用“四面棱镜变焦法”(挑战传统、驾驭趋势、理解需求和整合资源),在反复思维发散与收敛过程后,最终聚焦于高质量的创意。这“四面棱镜”的准备工作颇费心思,需要企业悉心收集、准备材料,形成真正的洞察力。


二、注重想法的储备、评估与升级。想法是任何部门、任何人、在任何时间都可以提出来的。把想法储备起来,进行初步执行风险评估就可升级为概念;概念经过快速市场评估并达到标准(有吸引力的价值主张)可以成为项目。原则上“宽进严出”,从想法到概念、从概念到项目的管理思路既鼓励前端的参与,又确保后端结果问责清晰。


三、建立逐步严格的阶段评审制度。评审委员会成员的组成应该随着项目进阶,逐步提升高层领导的参与度。属于下一阶段的问题,在当前评审阶段就不必问;在不同阶段评审的同一类问题,对回答的颗粒度要求也是不一样的。

图片

图7:一个健康的项目管道呈现“喇叭形”的项目分布形态


一个健康的项目管道呈现“流水不腐,户枢不蠹”的运动状态。领先的企业通常采用以下几个关键指标(KPI)衡量项目管道的状态:

一是项目管道增长率


二是因市场反馈而终止的项目占所有终止项目的百分比


三是成功通过原型产品验证的项目数量


四是项目从立项到新产品投放市场的时间


DSS的建议

谈管道管理,切不可管中窥豹,还是要结合体系,从整体上看清楚。三个层面,从上到下,依次为战略、管理和执行。业务目标由战略层输入,通过管理层、在执行层输出结果。组合管理向上承接战略,对“做正确的事”负责;管道管理向下统筹项目执行,对“正确地做事”负责。

图片

图8:在整个研发管理体系中看组合与管道管理

在战略层面,集团高层领导听取各业务主管汇报战略意图项目分布和财务回报,审查和批准各业务的投资组合以平衡集团的发展战略,对投资组合的转型性调整负责,做出破除发展约束的重要决策。

在管理层面,各业务PMO月度性更新各项目的进展。研发主管季度性召集项目经理,综合考量各校准因素,共同商讨项目优先排序的更新和资源的调配。以类似的节奏,研发主管向业务管理层(例如,营销总监,运营总监,产品经理等)汇报项目组合与管道管理的成果。对应业务战略,研发资金水平的调整、关键人才的扩充、新技术平台的搭建、产品迭代的规划等均是讨论重点。

在执行层面,项目经理致力于推进项目进展,最大化新产品竞争力、推进速度、可预测性和成本效益。针对每个项目,把价值链分析、市场细分、客户需求理解与转化、价值主张设计、技术评估、方案开发、实验设计与实施等具体工作做扎实。做为一线管理人员,项目经理向上反馈的“情报“越及时、准确,索要资源的理由越充分,越可能获得管理层更大的支持。

三、IPD落地-项目和管道管理

(原创 系统邪修 IT系统邪修)

一句话表达,其实就是多项目管理,希望系统能够提供精准的决策信息,用以处理多个项目并发时的资源冲突。通过管理决策达到资源的合理利用。
多项目管理,实际工作任务大家其实都在进行,有的用表格进行共享数据进行人为填报,有的团队用其他的软件进行各自填报信息。
咱们一如既往,通用的公共的说法、做法、讲法,咱今天就不在这个地方进行赘述,因为这方面的专家会讲得更好、更有感染力。
因此笔者在这里不会有看起来特别高大上的图案,也不会有特别宏大的叙事。
因为在讲项目管理很多会讲的直接拿出甘特图,燃尽图等进行常规讲解。笔者看来这就是系统基础。
大致表达了一些内容就是“基础理论要折腾,要创新”
在这一点上笔者持有不同的态度:基础理论上面其实并不需要创新,目前市面上讲的创新,其实是换一种词汇,强制拔高。在基础理论上来回创新,就是将明白事儿说糊涂,然后再重新说,比如什么“工业化、信息化、市场化、城镇化、国际化”等其实说好听点就多元化,用这个来概括了。
说不好听点就是“碎片化”,外边的东西太多了给干割裂了,越割裂越焦虑,越焦虑越割裂。然后强迫所有的人都必须这样这样。
所以,静下心来,去除噪音,来寻找内心的那种安定,然后慢慢去挖掘本质。换句话说就是一定要静下心来研究事物的本质,掌握他的规律。
于是此片开始了,怎么引入这个话题呢。常规的PLM项目管理中很多系统的确包含了很多功能要素,也能直接使用甘特图、燃尽图等。但是怎么用着就非常奇怪呢。
拆分一下:在很多企业其实把项目、多项目当做是订单、多订单。问今年项目多吗?今年单多吗? 其实就问的一件事活儿多吗?
既然在某个程度上说订单是简化的项目、项目是复杂的订单。我们合并同类项干脆起名为订单制。
有了这个基本认识以后。我们再来看如何落地多项目管理。
多项目管理 = 多订单管理
1、顶层思路:落地多项目管理就是要像做订单管理一样,把跨部门的节点都拉在一条线上。所以多个订单你能进行管理,多个项目同样可以进行。只不过开发前期的WBS需要横向拉通到后端所有节点。
2、系统顶层:OA平台向连续的作业平台转型
3、结构化延伸:一条线延伸至横向后端。不再是一个单独的节点,通过“关连”来点选任务,或点选项。没错就是“关连”的“连”。不是我们以为的关联。
为什么现在的都是“关连”呢 因为不能直接像电子表格那样生成即时的全过程的可视化。需要二开炫技。再二开炫技。根本原因就是没有在一张大表上。这个也在我的另一篇文章中有迹可循:国产PLM敢问路在何方?国产系统基本就是这个开发路径。换句话说,关联信息需要人工再进行加工形成报表。
4、项目WBS=项目BOM=订单BOM:在项目WBS向其他部门节点延伸时,需要一致性传递,一些敏感信息可以进行隐藏。
稍微注意一点就是项目的WBS包含物料与非物料的BOM,即机电软以外的BOM条目。比如检测检验服务费。检测报告费等。同样原封不动地一致性传递,延伸到后端协同部门。
项目子任务即项目的条目递增,渐增式。这样在显示后端完成百分比时可以直接动态抓取数据。无论渐增式、递增式,其实都表达了项目的复杂性,确定了的审批过发布过的都可以进行锁单。部分锁单,锁单后就是后端不能随意修改。保证一致性流转。
5、大表即系统工程基座:这个大表就是将纵横各节点进行串接,这样可横向纵向监控的数据就有了。何愁不能图形化呢?
资源CBB,包括人员,组,权限,日历CBB统一在这张表上,何愁不能显示交叉项目 人员占用,加班情况。任务完成情况呢。何愁不能提供决策报表呢?何必苦苦二开再二开呢
综上,从IT系统上来表达可实操落地的多项目管理。请看完完整的合集后,进行批评指正。最终祝愿大家多项目管理开发落地成功。
对于产品这个项目本身的管理,例如产品开发方向,功能场景设定不在本文进行探讨,这属于产品力本身的课题。这个不在笔者能力范围内。也请见谅。
一句话说:本文不提供产品开发项目管理本身的见解


四、PACE-管道管理

(原创 IPD解读 IPD解读)

前面章节提到的不论是战略管理,决策评审、结构化开发、核心小组、技术开发,都是从做什么产品,怎么做产品上提出的一系列方法论,但很多中大型企业会出现产品战略与实际的企业能力和资源脱节、职能部门的预算与项目计划不一致、出现始终延误项目进展的组织瓶颈、缺乏按计划补充项目所需的人力资源、长期的“救火”现象,每个职能部门和项目组都只顾及自身的最佳表现而忽略了产品开发的全盘,致使后者只能得到次佳的表现。而如何将产品战略与项目管理和职能部门联系起来,从而更合理地部署企业内与开发相关的资源,让各项目都能得到完善的资源分配,平衡产品开发的投资结构,则需要对研发进行整体的管道管理。

图片


管道管理是通过以下三种执行行为来实现的,这三种执行行为将重要过程与职能部门联系起来:

战略平衡:对众多机会制定优先顺序,对企业能力进行调整,以期拿出新产品。

管道载量:通过增加阶段性评审过程中的决策透明度来实现资源分配的微调。

协调部门之间的交接:确保无论是短期内还是长期内,职能部门的管理人员都能使项目在企业里得到最大程度的流动。

战略平衡

战略平衡是根据不同要素来平衡开发项目及相关的执行行为来实现的,如专一性与多样性之间的平衡,短期目标与长期目标的平衡,高风险与低风险之间的平衡,扩展现有的产品平台与开发新的产品平台之间的平衡。

战略平衡将产品战略与企业的能力和资源紧紧地联系起来,它限定了在阶段性审核过程中的决策授权,也限定了职能部门管理者有关资源分配的决策授权。产品战略的决策部署主要有以下三种工具。

1、项目总体进度表----是一个优化的开发主导计划。这一按时间排序、关于所选项目的暂行进度表是产品战略的具体化,因而在阶段性审核中它被用作各核心小组分配和特许资源的依据。根据核心小组阶段性审核材料、管道载量分布情况及战略方向的调整等,进度表会不断地得到更新。

2、管道载量分布图----用于控制和维持管道的平衡,以便在最大限度上增加产品开发的输出。在战略平衡过程中,该分布图用于制订项目总体进度表,使之与企业所拥有的与开发有关的资源和技术容量相吻合。在开发的全过程中,该分布图一直作为控制和管理开发管道及职能部门管道的依据。总体管道载量分布图作为总体管道载量的上限,用以保证项目和各职能部门的需求不会超出公司的资源容量,而为重要职能部门进行监控的各职能部门管道载量分布图会定期修正,以确保职能部门和技术技能之间保持平衡,避免产生“瓶颈现象”而降低整个管道的速度。

3、职能部门同步预算----与传统的职能部门预算的形成方式不同。它不是将各项目、各职能部门分散、单独地看待,而是通过战略平衡,把各项目和各职能部门的需求(如维修保养、追加投入、主要设备、过程改进等等)作为输入项目,在企业有限的资源和资金内进行调配。项目之间、职能部门与项目之间不再为争取企业的有限资源而竞争,相反,鼓励它们互相合作,争取在整体战略上,以有限的资源创造出最大的效益。但是这些同步预算必须具有一定的灵活性,使资源可以顺利地从一个职能部门转到另一个职能部门,以应付不可预计的项目差错。

管道载量

这里面有个问题,在进行决策评审时,决策委员会可能么没有掌握跨项目之间的资源、计划的相关信息,尽管可以使单个项目计划更合理,如果没有合理的管道载量,整个管道会始终处于超负荷状态或次佳状态中。

管道载量分析驱使一个企业将精力、财力、物力集中于少数几个影响重大的项目,能够避免资源的短缺,这些项目可望更快地进入市场。资源比例是管道优化的关键,它能保证硬性任务(重要紧急、短期必须要做的任务)和软性任务(重要但有长期规划的任务)在一个合理的比例,左右这一比例的三大因素是技术稳定性、启动弹性和项目管理水平。

进入产品开发之后,技术越不稳定,硬性任务的比例就应该越低,因为无法避免的问题一旦产生,就不得不从软性任务方面抽调资源。

上市弹性受项目进度“锁定”程度的影响。如果上市的时间没任何商量的余地,那么软性任务的比例应上升,这样一旦主要开发项目发生小误差时不致带来灾难性打击。

项目管理水平(包括核心小组、阶段性审核、结构化的管理方法等)对项目是否能如期展开、能否满足它所需要的资源有着至关重要的影响。一个企业的项目管理水平越高,硬性任务的比例可以相对高些,因为,在开发过程中出现预料之外差错的可能性会相对较低。

协调职能部门之间的交接

协调职能部门之间的交接要考虑到涉及所有开发相关部门资源需要的执行行为,包括产品开发、技术开发和常常为人们所低估的产品辅助活动等。职能部门和项目是整合在一起进行考虑的,没有完全区分开来。各职能部门经理共同努力,争取有更多的项目通过整个管道。他们不再仅仅关心各自的部门,而是积极地配合上游和下游职能部门迅速解决各种各样的问题。

职能部门经理还必须为非产品开发行为配备人力资源。这类活动有些是非做不可的,如产品支持等。而其它的活动则应集中在建设本职能部门长期的能力上,以便当许多项目同时涌入管道时,职能部门经理应有主动应对对策。

1、保证人员的弹性,这就要求部门管理者找出其它有类似人才的部门,以便紧急情况下可借用;对部门内部的职员进行交叉培训,使他们能身兼数职;及时开始聘用周期,保证有充分的时间招聘、雇用和培训新进人员;调整部门人员的经验结构,在必要时可以雇请一些临工。

2、为减少产品开发的人力和物力,鼓励重用业已验证的设计,协调不同项目之间的进行对话,使部门内的集体专长能应用于每一个项目。

3、为提高效率而精简开发过程,安装完备的设计工具并努力提高人员的技能。

4、计划向外招请有非核心技能的人员,要预备足够的时间挑选、审核和批准承包商或合作伙伴。

5、为了保证将来开发项目所需的技术就如同“放在货架上”一样,各职能部门应在努力开发新技术的同时,通过与拥有前沿技术的供应商建立的关系最好是专门的关系,以便从外部获取技术。

为什么企业在管理产品开发管道时会遇到问题?

虽然大多数公司认识到他们未能有效地管理产品开发管道,但往往不明白问题的症结所在。我们认为以下可能是造成上述状况的原因:

1、面对众多机会,分不出轻重缓急,因而也无法根据企业的实际情况调整

开发新产品所需的人力和其它资源。

2、开发项目进出管道没有得到积极的管理。

3、产品开发未与各职能部门的管理保持一致。

4、期待某一个系统能神奇般地解决这一问题。


图片



附codes简介

Codes 是国内首款重新定义 SaaS 模式的开源项目管理平台,支持云端认证、本地部署、全部功能开放,并且对 15 人以下团队免费。它通过创新的方式简化研发协同工作,使敏捷开发更易于实施。并提供低成本的敏捷开发解决方案,如事件驱动实现的 “事找人”、自动生成工作周报,多事项闭环迭代,日报与工时填报融合、同步在线离线测试用例、流程化管理缺陷、低代码接口自动化测试和 CI/CD,以及基于迭代的研发管理和测试管理等,践行敏捷开发。主要功能有:需求池、原型管理、工单管理、工作汇报、需求管理、任务管理、测试管理、缺陷管理、自动化测试、项目文档、工时进度管理、风险管理、项目管理(支持多种模式),统计分析等。
Codes 旨在提高各职能部门和人员的协同工作效率,优化软件产品敏捷开发周期,管理员工工作计划和工作负载,便于领导层从全局视角把控各个软件产品的研发进度和风险管控。主要用户有部门领导、产品经理、项目经理、软件研发人员、软件测试人员、项目实施人员和销售人员。