拥有这些能力，你将成为一名好的IT项目管理者

在IT圈有三个最主流的项目管理方式：瀑布管理、敏捷管理和精益管理。一般来讲，三种方式都能找到适应的项目类型，比如：

瀑布管理一般使用于需求明确，预算严格的大型IT项目

敏捷管理一般使用于需求和预算变数较大的中小型IT项目

精益管理一般使用于团队、需求、预算都处于变动中的创业项目，或者成熟产品的运维项目。

看起来似乎是一个一片和谐的情况，但在实际 *** 作中，特别是市场需求瞬息万变，竞争良莠不齐的当下，我们所接手的项目往往都无法套用到某一个类型。面对这些一直处于高度混沌和变化状态的项目的时候，单一的管理方式开始慢慢变得有心无力起来。这个时候，我们便需要引入混合管理的方法。

今天小马哥会讲一讲单纯的敏捷和精益开发的痛点，并介绍一种敏捷精益的混合管理模式。

敏捷管理的痛点

敏捷开发是一套具有高适应性的软件开发模式，它通过把单个项目拆分成迭代的持续交付方式，达到渐进明细的管理手段，从而增加自己对于未知的掌控和缓冲能力。但是，敏捷开发也有自身的一些限制和瓶颈，比如：

痛点一：没有在制品限制（WIP）

敏捷开发提倡建立全功能团队 (cross functional team)，也就是说一个标准敏捷团队里需要有完成软件开发所需的开发、测试、业务分析师、服务设计师等所有角色，并且这些角色在某种程度上可以去承担其他角色的职责。 这样一个团队拥有非常大的优势，它可以给予团队更多的灵活度与韧性，也保证了不同职能之间沟通交流的最大效率化。

然而 最大限度的灵活在另一方面也意味着最大可能性的失控 。举个例子，或许大家在平时的工作中都会有这样的经历：迭代刚开始的时候业务分析师准备了一大堆故事卡，开发们迫不及待的捡了很多卡做，测试们通常无事可做。结果在迭代中后期，大量的故事卡都开发完毕，这时候却发现测试根本忙不过来，闲下来的开发只好临时充当起了测试的职责，帮忙测卡。用户故事墙往往会像这样发展：

这样的开发方式往往会有以下一些缺点：

测试在迭代前中期的 资源无法有效利用

将所有测试 压力都集中在了迭代中后期 ，大大增加了交付的风险，减少了应变的空间。

开发承担测试任务往往会同时 降低开发和测试的效率。

而导致这一痛点的原因非常简单，就是缺乏一个在制品限制去控制在每个开发流程中的带宽，导致团队资源在某一个时间段过度的集中在了单一流程上。

痛点二：难以处理单个迭代期间的需求变化

标准的敏捷开发是以迭代作为最小交付单位的，也就意味着在每一个迭代交付中理论上是不允许需求的增加和改变的，任何的需求变更和蔓延都需要在下一个迭代计划会议（IPM）进行讨论。然而在当下的软件市场环境，想要实现这一点是不可能的。通常在做一些持续时间只有数月的项目的时候，客户的需求几乎随时都在改变，“这个新需求明天要上线，怎么实现我不管”的惨案随时都在发生。

迭代式开发是敏捷管理的底线，如果不跳出盒子思考，在满足客户需求的同时处理紧急的需求变更似乎只剩一个解决方案：妥协。

精益管理的痛点

精益开发的核心工具便是 “看板系统”。 看板系统看似和故事墙很像，但却有以下的一些不同点：

有在制品（WIP）限制；

没有制定任何估算方式，任何一张故事卡都被看做一个可以交付的价值流；

没有迭代的概念，采用拉动式的需求管理方式。也就是说需求的拉入取决于市场或者客户的及时需要。

这样的一种开发方式比起敏捷有着更大的机动和灵活性，可以实时实现高优先级需求的持续交付，但同时它也有着非常明显，甚至致命的痛点：

痛点一：难以估算项目预算

因为没有制定任何的估算方式，所以对于精益开发来讲，估算整个项目的预算几乎是一个不可能完成的任务。通常境况下，我们只能通过专家意见的方式给出一个”最晚交付时间“ 或者 ”大约生产周期“ （lead time） ，并在先设立deadline的情况倒逼项目的交付。在绝大多数项目里这样的方式都是不推荐的，只有一些信仰开发的创业型项目和需求相对简单的运维项目能够稍微较好的实施这种估算方式。

痛点二：进度不知道，报告很难写，经理很着急

这个几乎是所有从事精益开发的项目经理都头痛不已的”无解题“。因为看板系统没有使用任何估算方式，同时也没有迭代的概念，所以项目经理通常只能使用累积流图（CFD）这样的相对工具来展示项目进度：

然而，对于当下众多把ROI，NPV等财务数据挂在嘴边的管理层来说，这种 ”我们一共有X张故事卡，已经做完了X张故事卡“ 的报告方式显然是非常不具备说服力的。 当我们尝试着去量化开发进度，并与财务挂钩的时候，又发现精益开发所收集的数据远远达不到我们的期望。

所以，敏捷和精益开发都不是万能的，它们都会遇到自己的限制和痛点。这个时候，一套组合拳天时地利人和的问世了：

敏捷-精益混合管理

顾名思义，敏捷-精益混合管理便是吸取并结合了敏捷和精益管理的特点，尝试去解决各自痛点的混合式管理形式。概念很简单，让我们 以敏捷管理为基准， 来看看精益原则是如何融入其中的吧。

传统的敏捷开发流程大概是这样的：（再一次，请原谅我拙劣的画工）

在加入了精益管理的概念后，流程大概变成了这样：

具体来讲，针对 传统敏捷管理 来讲，敏捷-精益混合管理大概有这么几个大的改变：

改变一：引入在制品限制 （WIP）

如果你有仔细看小马哥上面叨叨了半天的内容的话，便能理解这个改变是一个理所当然的决定。事实上很多项目经理早就在项目中引入了WIP的概念，去平衡团队的开发资源。一般情况下 WIP的数量应该等同于开发的pair数量，等于测试或者业务分析师的数量。 如果你的团队有4对开发，1对测试和1对业务分析师的话，那拥有WIP的故事墙就应该长这样：

在引入了在制品限制之后，我们便可以去限制资源的过度集中，从而在项目的任何阶段都释放出更多的产能去支持整个故事卡生命周期的交付流程，也为持续改进提供了物质基础，从而大大的降低交付风险。

改变二：弱化迭代概念，重视拉动式计划

在这里需要强调的点是，弱化迭代概念并不是抛弃迭代概念，在敏捷-精益混合开发中，迭代依旧是最小的开发管理周期。那如何理解这个”弱化“呢，主要体现在两点：

允许迭代内的需求改变

引入拉动式计划带来的最大改变便是对于客户需求的及时反馈。在敏捷-精益管理模式中，对于高优先级的需求我们允许直接从backlog拉入迭代，并进入优先交付通道 （快速通道）。进入快速通道的故事卡将会被第一时间处理，它大概长这样：

需要提醒的是，虽然我们允许迭代内的需求改变，但是它必须遵守如下原则：

在快速通道里的故事卡依然要受到WIP的限制，通常我们会block住低优先级的卡转而先完成快速通道里的卡

在迭代内加入的需求必须满足如下两个特点中任意一个 ：1 高优先级需求； 2 在当前迭代需求全部提前完成情况下的次优先级需求。

允许一定程度的故事卡滞留（carry over）

很多聪明的小伙伴肯定会问，如果我们允许在迭代内拉入新的需求，那不就造成了需求的蔓延了吗？如何确保团队能够交付本来承诺的故事卡呢？答案便是：我们不强制要求故事卡在每个迭代的交付。这也就意味着，敏捷-精益混合管理允许一定程度的故事卡滞留，通常在20%以下。 当前迭代没有完成的故事卡，在完成基本的记录后，可以滚动到下一个迭代的计划当中。

那聪明的小伙伴又会问了：那这样一来，迭代燃尽图不是就很难看了吗 我们又怎么确保能够按时完成交付呢？关于这个问题，小马哥的答案是：弱化迭代概念，强调项目的整体交付速率和质量。最直接的办法便是使用燃耗图（burn up chart）而不是燃尽图 （burn down chart）:

燃耗图可以通过对于每个迭代的速率收集对比项目整体的故事点数，进行三点估算（PERT），并预测出可能，乐观和悲观的交付时间。通过对交付时间的预测，项目经理可以一目了然的了解项目当前的健康情况，这种方式比燃尽图更加的全面，并且达到了弱化迭代概念的作用。

最后，我们再来总结一下，看敏捷-精益管理方式是否解决了我们之前的痛点：

敏捷管理痛点一：没有在制品限制（WIP）- 通过引入WIP 解决

敏捷管理痛点二：难以处理单个迭代期间的需求变化 - 通过引入拉动式计划解决

精益管理痛点一：难以估算项目预算 - 通过引入敏捷开发的经典估算方式解决

精益管理痛点二：进度不知道，报告很难写，经理很着急 - 通过引入敏捷开发的燃尽图、燃耗图等传统报告方式解决。

总而言之，敏捷-精益的混合管理方式有着更广泛的适用范围，更少的失败成本，并且提供了更大的效率，是大家都值得在自己项目去尝试的管理方式，快去试试吧！

更多有趣的文章，欢迎来小马哥的 个人网站 ：>

从接触了各大行业领域的项目经验嗅觉，以及在项目组中担任了项目管理者（也就是项目经理）的角色经验来看，要做好一名项目管理者实在不容易，如果说要求再严苛点的话，要评上优秀标签，那么想要覆盖所需的能力点就是一种挑战。

在之前没接触项目管理之前，一直有个误区，那就是项目管理可能不需要太多的专业技术能力，懂点行政管理，有点领导力就可以轻轻松松，把一个团队管理地有模有样，把团队里的每个人管得服服帖帖。

后面转向项目管理这块，做个几个项目之后，越发觉得之前的想法设想就是天真得不行，以至于在很多时候项目管理实践上踩过很多“坑”，有过许多地无可奈何，均由于在当时缺乏项目管理者所需的能力，以至于项目管理得连自己都觉得狼狈。

这么说来，要做好一名IT项目管理者究竟需要拥有什么能力呢？在经历过我踩过一些项目管理上的“坑”以及吃过不少的苦头的反思总结下，我觉得需要具备以下的几种能力。

其实不管是哪一行业也好，特别是在IT领域，比如像我是从事IT领域的信息安全方向，在我看来，信息安全技术的能力就是自身能力框架的基石，就像你要盖成摩天大楼，就必须根基牢固，这样的话任何风雨飘摇都无法轻易撼动你，因为会由于基础的夯实而坚挺。

所以基础的能力是取决后面发展的长远，否则“跨越式”的跃进可能会忽略基础成长的机会，造成日后基础松垮，限制了向上堆积的能力。

还有如果你想你的项目团队成员都能心甘情愿听从你的领导和安排的话，你就得有一个让他们“服”你的前提，团队成员他们擅长的是实施的业务能力和专业技术，如果你的专业技术或者业务能力无法优异与他们，那他们又有什么理由一定要服你呢？

这一点其实在项目管理中体现地尤为常见。一位基层员工，由于某些管理的能力特质，被领导赏识，进而提拔为IT项目主管。但是当时被提拔为项目主管时，他的技术能力相对一般，但却面临着要去领导一群大部分技术能力比他好的技术工程师。

一开始他觉得很正常，也没什么压力挑战，因为他自己误以为做好一名管理者，不需要很强的技术能力，因为只需要有好的领导力就可以做好管理了。

后面等到项目实施时，他才发现其实如果本身技专业技术能力不过硬的话，比团队内的人还弱的话，就会面临一种管理的“痛苦”在里面，那他们会有一种心理想法那就是：我根本不会管你管理有多厉害，你的技术都没我厉害牛逼，我凭什么要听你的。

也许，你可能会很无奈：为什么我是作为一个管理者的角色，为什么非用跟你比技术能力呢？但是你也怪不了人家，因为在IT领域里搞技术实施的，人家认的就是第一基础能力，你要我听你的话，可以，只要你技术比我厉害我就承认你。

所以在IT项目管理中，管理能力的基础就是技术能力，技术的晋升拓展就是管理，这种主次之间的逻辑认定，你如果逆反执行，你就会遭遇举步维艰的困境。

其实这种能力在古代军营中的元帅与军将士兵之间的能力差别中体现到很到位。比如大唐薛仁贵，起初作为一个不起眼的火头军，如果没有身怀十八般武艺的能力和过人的胆识，怎么可能屡建丰功伟绩，最后晋升为元帅；在晋升为元帅这种“军营一哥”的角色之后，他同样是一个大的管理者角色，手底下均是武艺高强的武将下属（罗通、秦汉等），从他的武艺在历史电视剧里面的表现来看，更是超越了众人，所以同事及下属没有几个不钦佩赏识以及服从他的。

这也皆因有很大部分是因为极为出色的专业实力在推动了自身的管理，为管理顺水推舟，使得管理的可执行性有了一定的保障性。

估计很多的人都因缺乏良好的沟通表达能力而吃过亏。在论文答辩时，你做出来的论文水平比你的竞争者要高，但人家却因为沟通表达比你好，而得了高分；在求职面试时， 你的专业技术水平比你的竞争者强，但人家却因为回答表现比你好，而被录用了；在项目实施中， 你的其他综合能力都很全面，但如果没有良好的沟通协商能力，那么你的需求永远得不到满足。

所以说，要想成为管理的主导者，你必须学会如何去更好地沟通表达。一个人想做一件事情，这就是他内心的一个真实的需求，但是需求需要实现或者说被满足，它就必须被表达出来，那么如何更好将需求通过语言形式传递表现出来，这就是沟通表达。合适恰当的传递表现形式，就好比优秀良好的沟通表达，更直抵对方的内心，更容易让人听懂接收，以至于让对方去接受并响应你的需求。

在IT项目的实施管理更为重要，对于团队内部，有一件事情需要大家一起来协作共同完成的，这个时候，如果你没有把需求很好地表达出来的话，会有几种情况：第一，你根本表达不清楚，比如没说清这部分的功能要谁去实现，输出报告要谁去整理；人家就不会理解你的需求是什么；第二种是你既说明了事件是什么（事项）、为什么要去做（缘由背景）、谁去做（实施人员）、什么时间点要结果（Deadline）；到这里的话你的需求表达算比较明确了，但还不是最优。

沟通表达的效果差异，在于表达之后，需求如愿实现的差异。什么是好的表达？我觉得就是你把要表达的需求和东西说出来之后，人家不仅仅听懂了，而且按照你的需求反馈了最为积极正确的回应。接着上面的例子，为什么还不算是最优的表达，因为其实还缺少表达一个比较重要的点，那就是目标预期，因为有些时候你把目标预期定出来，对方就会更接近你的真实需求导向输出结果。

但如果没有说出目标预期的话，就有会像是大领导总有天马行空的空洞设想，底下的人听不到目标预期的界限，也许只能无奈地自由发挥，跟着天马行空，实施落地就是痴人说梦。

在将领导的目标预期落地执行方面的话，Google现任CEO皮查伊做得简直太好，这也是他的大boss——拉里·佩奇（Google创始人之一）为什么那么赏识他，最后愿意当一个“甩手掌柜”的原因之一。

因为拉里·佩奇是个不善言辞又喜欢脑洞大开的主，在开高管会议时，总是喜欢说些天马行空的概念，可能由于太过于宏观， 导致高管们一头雾水，不知所云。

但是皮查伊却懂得去主动与老板交谈，简短几分钟便能抓住老板的目标预期是什么，并准确无误地传达给团队成员，以至于可实现落地。

这就是高效沟通表达的艺术，巧妙的沟通不在于冗长而在于精准简洁。

然后对于项目团队外，也就是面对客户或者其他跨部门的沟通的话，除了会沟通，还要懂得协商。不懂得协商的话，自己就会身处被动，客户的配合主动性就会很低，项目开展实施，就难免会陷入“对方都是大爷，我一切都听大爷的安排”的低段位服务姿态。

一般客户方（甲方），服务方（乙方）项目开展合作形式就是：客户方配合服务方开展工作，很多时候会遵循一条原则：“你们主动做事，你们就应该主导，我们只是配合方”，所以谁做事，谁就要去占据做事主导权，因为配合方往往是不着急的。所以在这个时候，当我们是服务方时，我们去把握主动是正确合理的，因为你想把良好的结果导向自己这边的话，主动跟他们说需要怎么配合要比自己不知所措，等着问他们怎么配合；要是后者这种情况的话，会产生两种结果。

第一种，客户方会不满。“事情主要是你们来做，我们是配合的，你们自己都不知道怎么做，那我们怎么知道配合你们呢？”  也许你心里会说自己其实是知道怎么做的，只是咨询下你们的意见而已。但其实，只有当对方把自己代入配合角色， 就会自然而然喜欢别人来引导，而不是来反问他们。

第二种，客户方逆转局势，你陷入被动。当你同样不计划主动告诉对方怎么去做，而去问客户怎么开展工作的时候，而刚好遇到的是不厌其烦且很有想法的客户，那你可能就就要无奈地开启“苦逼模式”。

踏入“不能做主”的泥沼，什么事情，怎么去做，都要听人家的想法来做，自己就失去把握的主动权，这样的话，可能会把自己拉入一个一个隐形的“大坑”，到时候要么你就只能“入坑”或者放弃脱离。

所以，面对近乎苛刻的要求和选择时，必须懂得从自身立场出发，通过与对方的协商，将结果主动导向自身有力的一面，而不是任由使唤，被动去接受本不应该接受的诸般要求。

《驱动力》里面讲到：“企业管理最让人头疼的问题是什么？员工的主动性和创造性。”   其实大到企业管理层面，这是个问题，小到基层项目实施， 驱动力简直关系到每个项目成员能否发挥最大的积极性来推动整个项目的实施，这是个根本性的关键问题；同时，这也决定了项目管理者是否是一名激励人心的驱动者。

也许普遍项目管理者会认为：调动成员积极去帮项目做事情，不外乎就是在多点付出而获得成效后，通过多分几张钞票或者说几番激励赞美的话，这两种方式就可以解决了吗？ 这只是通常的驱动力激励手段，应该是属于“治标不治本”的方法，即使这两种在一定的程度驱动了他们的积极，而无法深层通过在项目过程中，激励出他们应该有的“成就感” ，那只是一种短暂的驱动，时间一久就会疲乏，驱动就会变得迟缓。

所以管理者在通过物质需求和言语激励的方式之外，还应该懂得将员工的“成就感”当成创造力和执行力的源泉，并费些心思，将驱动力的力量从自身散发出来，感染到每个人，使得获得成就感，而成为自愿自觉去创造的“个体”。

在我看来有几个成长点是管理者具备后才能修成驱动力的，第一是自身的人格魅力，第二是本身的强大执行力，最后是拥有思考驱动力的思想。

管理者每时每刻都在产生决策，如果在决策时，无法赶跑“犹豫不决”这只怪物，那么你只能被吞噬。

对于决策迟疑，缺乏决断力，我深深吃过它的亏。有一次，一个比较重要的项目实施开展到重要里程碑阶段，只要完成这个里程碑阶段的工作，就可以进入项目验收阶段了。但是在完成里程碑阶段工作之前， 存在一个比较头疼棘手的问题。

那就是有个项目组核心成员，在那个时间点刚好赶上他自己另外负责的项目有项紧急的事情需要他去处理。但因为当时部门项目的现状是几乎大部分数人手里自己都带有项目，也就是自己既是项目经理，又要做项目实施人员，可谓是光杆司令；不但如此，在自己项目空窗期，还要“接济”帮忙下其他同事的项目。

刚好，那个核心项目成员他自己身上也是刚好有几个项目在跟的，只是当时我手上这个项目刚好在做，需要人手。在那个时候，我刚好是关键节点比较赶，而他那边又着急需要安排处理他自己的事情，我面临要去做出选择决策：究竟是让他去处理自己的项目，还是让领导去另外安排协调同事去处理呢？

如果他去，我这边项目搁置，不好交代；但是他那边不处理，我绑着人家好像又有点不合理，安排其他的同事又可能搞不定。不过领导是有提到一点：那就是我这个项目的重要程度会比较高，其他的项目可以灵活安排。

领导虽然没有说得很明白，但是也很明显传递给了我一个信息，那就是目前你负责的项目的优先级是比较高的，在遇到与其他优先级低的项目事项冲突时，必须做出合适的判断，优先执行优先级高的事项，其他事项通过外部资源协调解决处理。

但我当时还是缺乏全局观的意识，在遇到这样一个急需立马做出决策判断的时刻，陷入的却是迟疑和犹豫不决，前面的领悟总结只是事后“马后炮”才正确意识到的。

我还是在“浪费性的思考”后，做出了错误的决策，“老好人”般地放了那位同事去处理自己的棘手事去了。之后我被领导狠狠地批了一顿，因为我失了轻重， 项目里程碑阶段工作拖了进度“后腿”，结果耽误了项目的正常验收。

这是典型缺乏决策力的表现，作为一名项目管理者，在遇到关键决策时，综合评判出各个选择的优先级和重要程度后，就应该强有力地去执行重要程度高及优先级大的事项，摒弃“完美周全”的理想想法，因为现实总是难以做到百分百的兼顾所有；因为有些其他选择可以选择移交转移，让别人来帮你实现。

自己都想揽在身上，自己解决，那只会让自己陷入困顿、犹豫，最后所有的事情都成了“耽误综合体”，决策成为痛点；而当拥有睿智的决断力时，事情可能就会因为精准理智的快速处理而变得高效，进而推到整体事态的进展，映射到项目上的话，那就相当于项目进展会因为管理者的强有力坚定的决策，而衍生影响全局的强大执行力，促进了项目完成里程碑式的跨越。

所以，当一名IT项目管理者拥有了非常扎实的专业技术能力、出色的沟通表达能力、优秀的协商能力、振奋人心的驱动力以及睿智强大的决策力，这些必需的一项项能力后，在项目管理领域，那便意味有了开辟属于自己疆场领域的绝对资本以及自信。

以上就是关于IT项目管理中开发项目时都有哪些角色全部的内容，包括:IT项目管理中开发项目时都有哪些角色、IT项目管理的20条锦囊妙计、当IT项目经理应该做哪些事情等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！