老K浅谈项目管理

目标清，范围明，时间成本动平衡，用户满意是根本，团队向心信息灵。趋利避害勤变更，取长补短定合同,短短的一句顺口溜就涵盖了项目管理的九大知识领域，今天老K只能浅谈一下项目管理，讲的浅还请一笑而过。

这篇文章是我的好朋友（老K）写的，我会在这里给大家分享他的东西，他写的好的东西我会在这里跟大家分享，也希望大家能够多支持他，谢谢啦~~~

一、项目管理概述

谈起项目，首先要提到它的一个关键特点：独特性。何为独特呢，独特就是每个项目都是独一无二的，比如项目目标？ 实现功能？时间长短？内外部环境？资源？约束？那么多要素，所以没有完全一模一样的项目，那每个项目的管理办法也就不是一模一样的，故，项目不是一些模板式的流程、也不是书本上的各种技巧？他需要我们在每个项目中审时度势，通过各种线索寻求信息、识别风险，针对性的采取措施，促使项目成功上线。
项目成功。那成功的标准又是什么呢？按时上线？所谓的零缺陷？成本最低？高层十分满意？对于不同的干系人，可能满足某一条标准，项目对他而言就算成功了，但是对于项目经理而言呢，项目经理的成功，是在各类项目干系人中，寻求最佳的平衡，满足了目标，满足了铁三角，避免了那些令人讨厌的缺陷，迎合了市场等等。当然，每个项目都有关键性因素，但关键性因素的满足，往往也是一种平衡。
平衡。在实际工作中的项目中，项目经理最常遇到的便是项目的工期被压缩，被严重的压缩，而且是再三协调又无法改变的压缩，那我们需要如何去做呢？除了”向关键路径要时间，向非关键路径要资源“之外，还可以进行需求压缩（时间和范围的平衡），开发和测试的进度压缩（时间和质量的平衡）；一个好的研发团队，时间在非常紧急的情况下，往往也会通过缩减范围（非需求）的方式首先满足高优先级、重要性的功能。总之，不要认为得到了时间，也会得到其他，这其实都是平衡的取舍。最后，想说的一点是，很多大企业盘根复杂，所以，项目往往会采取一些极致的手段（流程规范等），确保一些关键因素的成功。
说起范围，便想到了项目中的信息获取，项目从开始到结束，其实全部都是信息获取的过程，初期获取客户和需求的信息，以及后续获取项目的进程、开发和测试的信息、缺陷的信息等等；项目的管理更是如此，也是一直获取信息的过程，好的项目经理，要不过各种不同的方式去获取信息，分析信息，发现风险，提出方案，解决风险。
风险。风险其实就是阻挠项目成功的各种绊脚石，那如何想要项目成功呢，那就是干掉绊脚石，所以说，项目成功的目标就是发现风险、发现风险、发现风险！
综上，项目管理是非常注重实效的，它需要我们实战、实战、实战！正如张无忌学太极剑一样，先记后忘，最终达到伺机而动，见招拆招的境界！
说了一些整体性的，后面再简单说说项目的启动、排期和项目的掌控。

二、启动项目

项目开始后，首先我们要确保项目的尽快开始。这里面有需求的平衡，有计划的平衡，对于“度 ”的掌握，只能根据团队的不同特点来定。如果每次需求不完善，导致研发团队对需求的理解、评估产生了极大的影响（风险很大，必须先解决），那需求就不能从简，即使在敏捷模式下，需求的质量如果引起了很严重的后果，那就必须采取措施，采取瀑布流的一些做法也是可行的。如果需求在分层、在需求框架等方面都做的非常好，和团队一起达到一种循序渐进的开发，那需求就没必要那么繁琐，尽快的启动就可以让更多的风险暴露在我们面前。
项目初期，很多人喜欢制定非常复杂的计划，把项目后续的每一项事情都考虑了进来。其实，这是一种不妥的做法，因为项目的风险是随时产生的，为了解决风险我们会采取各种解决方案，甚至会对我们的计划产生极大的影响。所以，我们需要波浪式的计划，因为他会随时在变，另外，计划制定时，我们要重前期，轻后期，并在项目的不断进行中，逐步丰满。
项目启动时，我们需要确定里程碑节点，这会对研发的一些关键活动进行指引和限制。
最后，如果项目感觉没有头绪时咋办呢，我们可以采用试点的方式，也就是我们常说的哈德逊湾式启动。尽快的迭代，尽快的开始，才会有更多的思路和方法。

三、项目排期

需求评审后，我们要进行研发的排期，这里牵扯需求的拆分、任务的分解、接口的识别，工期的评估、人员的分配。
首先，研发会按需求的优先级进行选择，先实现优先级等级高的功能。最后实现优先级最低的需求（在风险大时可放弃），这便是我们常说的，永远在做最重要的事情。
识别优先级后，便进行需求的拆分，需求的拆分，其实是对需求深刻理解的过程，团队人员一起针对需求提出讨论，这其实便是提前规避了需求理解不充分的风险，在拆分的过程中，我们还能识别接口，及早与接口方对接。
在工期评估时，我们常采用卡牌出牌的形式评估，这有利于团队熟悉需求、确定研发方案和工期的相对准确性，另外，这是团队自己主动给出的时间，执行起来的偏差会很低。
之后我们根据优先级和工期，再确定对应的开发人员、测试人员等。这样，一个简单的、团队内部认可的工期便可以引导大家绝大部分的工作。
最后，在项目排期时，有的团队喜欢按小时计算工期，有的团队喜欢按天计算，这其实要依据项目、团队来定的，我们最主要的是保证他的相对准确性，而不是他的衡量标准，过渡关注“小石子”的颗粒度，会慢慢陷入日程安排游戏，在后期的工作中不厌其烦。

四、掌控项目

如何掌控项目，我先从6个方面进行阐述：

• 业务理解：无论是需求、UI、开发还是测试，对业务、规则的理解程度直接决定项目的质量，我们通过各种方式（需求拆分、规格文档、需求反讲、团队任务拆解等），目的就是为了加深大家对业务的理解，提前规避需求不明确、需求理解偏差、传递偏差的风险。

• 里程碑交付物：项目进行中，我们需重视里程碑，更需要重视里程碑的交付物，它可以是代码、可以是文档，可以是一次代码review，更甚至是一次培训或者一次面对面的交流，我们要监督每次交付物的质量，规避风险。另外，比较重要的一点便是按功能交付，增量式的交付，这样不但能提高产品的质量，更极大的提高了机动性。

• 晨会&看板：晨会是非常重要的一个环节，他能促进研发的进度，促进产品研发和测试的沟通，识别风险，当然，晨会绝对不是解决问题的战场。

• 进度监控，信息获取：我们通过项目报告，项目仪表盘等来监控项目的进度，收集信息，发现风险。这里更重要的是信息获取，通过各种方式来获取信息（沟通很重要），发现偏差后及时纠正，关键时刻也可通过日计划进行推进。

• 人员状态：一个团队的状态很重要，如果发现一些令团队或者个体不愉快的事情，这其实也是一种风险。

• 拒绝打扰：“流”是研发人员的一种状态，当研发进入“流”之后，效率会极大提升，当研发人员没有入“流 ”时，效率会大大折扣。所以，我们要尽可能少的打搅研发人员（包含测试人员），以免在任务切换和入“流 ”中浪费大量时间。当然，在同一段时间，研发全身心仅处理一件事情，效率也是极高的。除了人员打扰，项目不被打扰也是极好的。

  今天，就简单和大家分享这些，后期再和大家逐步分享，这些只是项目的冰山一角。比如为什么不倡导过渡设计？项目为什么在很好的势头下突然结束？项目经理为什么期待需求变更？怎么保证项目的高质量？如何培养团队的全局性？为什么要敏捷？为什么要持续集成？等等，更多精彩，请持续关注“巧吧软件测试”公众号，二维码如下：