项目管理知识库

1、纪律性： 纪律性是敏捷研发和交付团队的基础，千万不要因为我们敏捷起来以及团队自组织，就不需要纪律。敏捷团队的纪律性可以说比任何其他研发模式的团队更为甚之。敏捷团队的纪律性无处不在，例如：频密的检视和作出必要的调整，不论是产品本身还是微观工作方式和过程；频繁交付可用产品；严谨的DoD条款；对时间盒的尊重；对团队合作规则的尊重和遵守；节奏；信息可视化；频密提交、持续集成和自动化测试，等等。 2、主动性： 没有主动性，何来竞争力？对比其他的模式，包括其他敏捷方法，Scrum是特别强调团队主动性的工作方式。我们期望通过多种举措和引导技能带来和培养团队主动性。例如，PO想办法让我们做的产品更有意义和意思，懂得从为什么开始来进行思考和沟通；重视Sprint的目标，特别是业务目标；有一个优秀的ScrumMaster或者敏捷教练来打造团队；

许多企业由于缺乏软件自主研发经验，也缺少相关经验的员工，因此把软件项目外包给第三方公司开发，在与开发公司的外包合同中，写的往往比较简单和草率，给后面的纠纷处理埋下了很深的隐患。 1、技术要求：特别是对于需要转交开发源代码的项目，需要在开发技术上达成一致，例如前后端需要用什么框架和开发语言，以便后期转交代码时存在很多问题。作为甲方要考虑后期二次开发或者自己的团队开发时的问题。 2、部署要求：部署方式是本地部署还是云服务器部署，甚至分布式部署；以及服务器要求，包括CPU、内存、带宽；存储方案要求，磁盘阵列、云服务器OSS 3、安全方案：在安全上有什么要求，混淆技术、加密方案等等； 4、产品形态：是什么形态的项目，还是仅仅或者包含BS、

不管甲方还是乙方，一个项目成败的关键就是最终是否能顺利交付，影响项目交付都有哪些因素，让我们在不同的交付维度一起看下。 1、需求基准：很多项目在需求不明确，或者没确定的情况就开始启动项目的情况很多，这种问题大都是项目开始形式注意太重，乙方浮夸自己的技术有多牛，甲方每个人都好像是业务领域专家或者都是很牛的产品经理，每个人都可以指点江山。 2、需求变更：甲方需求变更频繁或者很多拖拉合同的需求变更，也会让乙方在人力投入或者返工上焦头烂额，严重影响了项目的开发质量和浪费。 3、项目评估：项目早期评估不足，一方面对项目调研不足，没有深入了解项目实际的需求和应用场景，从而工作量评估上也过于草率，到了项目中后期会发现传说中的“好多坑“。 4、验收标准：基于什么条件和标准去验收项目，是很多项目没有注明的，很多都是凭着需求和感觉去验收，这样对于每个验收的人都会有很多主观想法，导致很多功能点验收不通过。所以从签约合同时就要附属一个附件，

Scrum是敏捷管理中常用的工具，核心是快速为用户创造价值，及时进行迭代和可持续性版本发布交付。 最近也收到很多朋友的一个纠结问题，说敏捷迭代和版本发布有没有关系？基于这个关系可理解如下： 1、首先没有强关系，存在弱关系。共同点就是迭代和发布的对象一样，都是围绕用户故事或者需求进行开发和交付。 2、敏捷迭代Sprint 对内，版本对外。一个快速开发，一个基于成果对外交付。Sprint持续规划持续迭代，版本按需发布。 3、在工具的角度，迭代管理和版本管理是分开的、独立的。在版本维护的角度，可以按需选择迭代或者迭代的任务，进行选择性的发布和跟踪和追溯管理。

项目开发中最难的应该是开发工作量评估的问题，如果工作量评估不好牵扯到阶段性研发的进度和成本，甚至项目交付风险问题。 1、需求明确：这个阶段建议多放一些时间，软件或互联网产品存在太大的主观性，每个人对于一个简单的功能需求或者体验都有不同的想法和诉求，这就造成了太多的偏差性。所以把需求沟通清楚，在客户的角度知道客户要什么，解决了客户的什么问题。 2、内部一致：在开发的角度如果很清楚的了解客户的需求后，然后内部团队在产品设计或者各个纬度也能事先达成一致，对于开发工作量的评估我相信就会相对评估的精准一些。 3、经验数据：这块有些团队习惯历史实际产出数据作为参考，就是把之前做过的模块工时具体量化，然后沉淀为历史数据，每次做类似的功能开发时，再结合当前团队的实际情况进行参考和再量化。 4、缓冲评估：对于拿不定的一些工作量，会采用缓冲评估的方法，会预留一定的缓冲时间，以免在交付上太被动，或者客户的承诺上会有一定的余地，因为很多时候大部分客户都会纠结进度问题，为什么在计划的时间你的功能还出不来。

项目有了意向后，一般都会启动需求调研，了解项目的需求和在实际业务中所面临的问题，然后通过什么方案去解决这些需求。 1、调研对象：一般建议基于不同的用户角色进行调研，大的范围分为管理人员和具体的系统使用人员。在管理的角度，一般会关注数据和统计的纬度，期望通过这些数据来进行了解项目的整体情况，成本投入和产出，以及提前识别风险。在系统使用的角度，一般会关注具体功能的使用，功能好不好用，直观不直观，更关注使用体验和能不能解决具体的问题。 2、调研方式：大概分为问答式、体验式和观察式。问答式可以事先准备好需要提问的问题列表，然后一个一个和相关的人员进行针对性的沟通。体验式就是参与到实际的项目业务操作中，去体会下实际的业务流程是怎样的。观察式就是在不打扰任何人的前提下，在业务现场进行观察，并记录业务场景。当然这些方式和结合在一起使用。 3、需求调研管理：需要把调研的实际情况录入响应的系统或者输出调研文档，

项目成不成功就是做的项目能不能交付给客户，客户满不满意，做好客户满意度预期和项目交付需要注意的事项是项目管理中的重中之重。 1、客户定性：要先对客户类型进行定性，要看交付的对象是什么类型，是战略长期合作，还是短期合作，如果是短期合作，项目限制性需要写入合同，和客户达成强制的约束关系，在这个阶段要做好客户管理和客户预期管理。 2、需求范围：需要和客户定义明确的需求范围，并且把需求规格说明书尽量写的详细一些，需要和客户进行当面确认。如果对客户定性存在很多不确认性，那就进行签字，大家还是要重视，有时会认为不好意思，其实没什么，签字不伤感情的。 3、验收标准：这个特别重要，一样的交付项目一样的项目，面对不同的用户，要求也不一样，这个我相信做项目实施的同事感触最深。有的客户很难斥候，那最好的方式就是做好验收标准的确认，

需求变更是软件工程项目中最为常见的问题之一，同时也是项目交付中最大的一个风险点，那我们看一下需求变更常见的一些问题和场景。 1、合同没有约束：甲方是上帝，我们做项目时有时会过于迁就甲方，没有做太多的交付约束或者没有验收标准，这在后期会存在很大隐患。甲方一旦想变更需求或者添加需求，乙方会很被动，大家有时会出现扯皮现象。所以建议在合同里附加一些，需求范围说明和验收标准。 2、甲方也不明白产品或项目要做成什么：这在现象往往在项目初期，大家沟通都很开心，描述者项目有什么有什么，但没有把它可视化出来，一旦到了项目执行层面，我们会发现，大家都忘记了当时说过的话。会造成项目来回变更，一个版本一个样都不为过。因为一个产品或者项目，在不同的角度都存在主观性，大家都会有很多想法，但很多时候有没有对与错，所以尽量把需求原型化，然后再确定好，再然后就是要去执行，哪怕是错的，

CFR是什么？包括Conversation、Feedback、Recognition，字面意思是对话、反馈和认可。OKR和CFR是相互促进的，两个工具“联姻”，才有真正的威力。 对话（Conversation）：领导和员工之间进行高质量的交流，目的是对绩效提升进行驱动。反馈（Feedback）：面对面进行双向沟通，评估工作进展情况并探讨改进的方案。认可（Recognition）：根据个体所做贡献进行认可、鼓励和表彰。 CFR是有效沟通的“刺激物”，是一个完整的交付执行系统，用于衡量什么才是最重要的事情，让绩效管理“直击要害”。CFR完全体现了安迪.格鲁夫创新方法的精髓和力量，也使得OKR更加人性化。 最为重要的是，OKR和CFR是相互促进的。

敏捷管理中Scrum是最常用的敏捷开发工具之一，围绕为用户创造价值展开迭代的规划和迭代执行，并不断可持续进行迭代集成和发布。 为了更好的管理版本，需要进行很好的版本规划，例如在项目加的版本管理模块，可进行版本的相关管理，更好的管理产品版本，还可以把本版本预期要发布的范围做个预期目标规划，方便实时跟踪任务范围的状态。 1、每个迭代版本执行后就需要及时发布版本，每个迭代要求也是在质量上需要达到可用的状态，及时变向用户，不断基于市场反馈进行完善。 2、也可根据迭代的完成情况，规划版本范围，可选择多个迭代进行规划版本。当规划范围内的迭代没有完全完成时可再根据实际情况进行版本发布范围的调整。

看板具有可视化工作和规则、限制在制品的数量和促进工作快速管理和流动的特性，本身就具备了横向和纵向流程、协作的元素。 1、横向：横向本身如果基于团队协作流程去自定义的话，在协作执行时会存在每个任务卡片执行完谁操作的原则的问题。一种是当前列的任务卡片负责人完成任务时修改下任务自身完成状态即可，例如标示一下已完成，然后下一列的负责人看到后把此卡片拖拉到下一列即可。还有一种时当前任务看片负责人完成后就把它拖拉到下一列。 2、纵向：纵向看板列本身包含了很多任务卡片，任务卡片自身有优先级或者任务之间的依赖性，在协作上也需要来定义执行的方式。一种可能按优先级高低来从上向下排列，也可以把相关系的任务放在一个泳道里进行独立处理之间的协作性。 那到底什么方式好那，其实对每个团队都不一样，需要成员自己达成一直即可。流程和协作需要在具体执行时不断的改善，才能找到适合自己团队的感觉和节奏。 执行一段时间可以基于回顾复盘不断的总结，不好的流程再不断的完善，最后把大家都认为好的看板和流程作为项目管理模板推广出去。

敏捷看板是一种最直观淡化管理流程的一种项目管理工具，在做任务管理时看看有哪些实践。 1、看板泳道尽量少：建议一个实践阶段指开辟2到3个泳道最合适，原则是泳道太多，任务交叉就会增多，开发速度会减慢，就类似现实中的游泳池一样，泳道多了后相互干扰度加大。 2、单个任务时间短：单个任务评估时间最好控制在8个小时内，这种需要把任务粒度不断的细化，确保每个任务投入时间最小化，同时加快任务进展速度。 3、看板投入人力少：每个看板投入的相关人力不要多，一般建议在2-5人为好，人力太多相互间的沟通和偏差以及交叉流程也会加大，相对会减少开发速度。所以一般建议基于分工可以增加多个看板。 4、看板列尽量少：看板列尽量简化，看板列越多，说明流程或者协作过程太长，相对也会影响任务进展速度。

MVP(Minimum Viable Product)的意思最小化可用产品，是让开发团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。 MVP概念是由硅谷创业家Eric Rise在其著作《精益创业》 一书中提出的“Lean Startup精益创业”的一个理念，其核心思想是：开发产品时先做出一个简单的原型——最小化可行产品，然后通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求，我们可以在几个方面简单的看下MVP所关注的维度。 1、最小化，速度大于完美：有时我们做产品或项目时，我们自己或者客户会有很多美好的憧憬和想法，需求很多，但到底哪些需求是用户最痛的点，有时我们基于分析或者客户也不明白。但项目又不能处于等待或者投入大量的调研阶段，否则也会浪费很多市场先入机会，所以只能梳理出最优先的需求去做，

看板做任务管理是基于敏捷看板的最大特点直观性和全局性，方便个人关注自己的任务完成情况，也能直观的了解全局任务进展。 怎样用看板管理做任务管理，首先需要结合自身团队的角色组成和任务进度流程，我们就在这两个维度看一下怎样用来进行看板式的任务协作管理。 1、团队角色：团队角色的划分是用来确认团队协作和责任分工的基础，如团队角色复杂，如包括PM、BA、SA、DBA、UE、UI、Dev、QA、Ops等等，此看板在规划上就相对复杂，我们需要考虑怎样让这些角色人员更好的去管理自己的任务卡片，然后还可以进行跨角色的协作。如：我们可规划Todo、SA、UE、UI、DevDoing、DevDone、Test、Ops和Done等看板列，此看板管理包含了跨角色分工和任务状态的交叉看板。 2、