本节书摘来自异步社区《妥协的完美主义：优秀产品经理的实践指南（卷二）》一书中的第2章，第2.2节，作者 陈洁，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.2 项目管理方法
由于项目进度紧张的安排，要求项目经理必须具备紧迫感，善于捕捉工作中的问题和难点，思路清晰，掌握并灵活运用数据说话。在会议效率低下毫无建设性意见的沟通中，清楚要解决哪些问题，清楚难点在哪里。优秀的项目经理善于安排时间和项目计划，能够掌握数据并灵活运用，善于沟通协调各方面资源，果断做出判断和决定。
除了不断提高自身素养，在实践中身经百战外，使用项目管理工具也是必不可少的。一般说的项目管理工具是现成的软件工具，常见的项目管理工具有Sciforma公司的ProjectScheduler、Primavera 公司的SureTrak、Microsoft 公司的Project、IMSI 公司的TurboProject等软件。但这些软件适合大型的工程类项目，对于软件开发项目有时候并不太实用，因此国内也有人根据具体情况自己开发小工具来使用。项目管理是对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理，但项目具体还是由人来执行的，说白了记录管理的还是人的工作，解决协调的还是人的问题，就算是没有工具，只是利用文档进行管理，只要方式方法正确，也能够做好项目管理的工作，因此产品经理如果掌握一定的项目管理办法有助于管理能力的提升，对于非专业从事项目管理工作的产品设计人员来说，掌握一定的项目管理方法，对于版本迭代、文档管理、项目进度也有一定的帮助。下面就对三种项目管理方法进行论述。
2.2.1 分阶段
1．项目、版本和产品的关系
在移动互联网行业，产品就是可以满足外部用户需求的软件、硬件或者系统平台，对于外部用户产品是可使用并获得感知的。对于普通手机用户来说，某个公司提供的客户端软件安装包和服务就是一个产品。
版本是产品在不同时间段的特性集合，包括产品的交付物、后续升级的交付物，一个产品可以有多个版本，版本是在产品的生命周期中，依据特性对产品做出的细分。
而项目是产品或版本的实现过程，反过来说，版本和产品是项目的输出。例如，新浪公司推出的手机微博客户端就是一个产品，它包括了客户端软件，以及软件内的内容服务。这个产品又分为V1.0版本和V2.0版本。为了实现和V1.0不同的功能需求，V2.0版本作为另外一个独立的项目展开，在实现新功能完成上线后，发现一些缺陷，每个月再升级补丁版本发布V2.1、V2.2等新的版本。分为不同的版本是为了满足不断变化的需求。
2．项目周期
和产品有一定生命周期一样，项目也是有周期的，但产品生命周期和项目周期是两个不同的概念，产品生命周期是从产品概念产生到产品停止维护使用的过程，项目周期是产品生命周期的一部分，指项目从开始到收尾。产品生命周期开始于一个想法或者概念，结束于产品停止运维和使用。例如，市场部门在拜访某运营商时，发现了一个新需求，市场部的客户经理把这个需求反馈给产品部，这个产品就算开始了；经过市场分析和产品分析，如果证明是有价值的，可以进行开发，完成后交付给运营商客户使用，最后这个产品逐渐过时，公司决定不再支持这个产品，就表示这个产品的生命周期结束了。
有时候项目周期已经结束，但产品依然在被使用或维护，只能说项目周期结束了，但产品生命还继续存在，可见产品周期一般都长于项目周期。
3．项目阶段
根据项目周期，将项目管理分为7个阶段，如图2.3所示。
（1）项目组织准备阶段：从资源、技术和组织等多个方面进行评估和准备，完成项目立项计划书。
（2）项目概念阶段：制订初步的项目计划，完成设计需求和备选需求。
（3）项目计划阶段：制订详细的项目计划，完成架构设计和概要设计。
（4）项目开发计划：执行项目计划，完成模型demo开发。
（5）项目验证阶段：执行项目计划，完成可用性评估和beta测试。
（6）项目发布阶段：执行项目计划，完成交付和维护支持。
（7）项目关闭阶段：完成项目，总结项目，关闭项目。
在本书后续的章节中，大家可以看到产品设计团队的项目流程，虽然和开发人员的工作内容不同，但项目流程也是7个阶段，并正好和项目开发计划一一对应。
2.2.2 文档化
项目的管理执行是否顺利，取决于产品设计团队的专业素养能力高低，也取决于团队总体的工作方法，相比国内的团队，国外的团队做设计，非常注意方法和目标：输入是什么？输出是什么？采用什么模型？相关影响分析？
输入是什么？输入是要获取各方面的资料，做到信息全面，收集整理来自市场部、客户、用户、开发团队以及其他相关团队的资料，这种资料有文档、照片、产品的应用场景记录、开发技术评估等，获取资料的过程，实际上是一个理解需求的过程，只有先理解需求，产品设计人员才能根据确定的需求一步一步地进行需求整理、功能分解、模块划分、建立逻辑流程、模型验证等。
设计输出是设计团队的设计成果，不仅仅是线框图、设计图稿、开发文档、需求记录等交付物，还应该包括设计团队对会议、思维过程、信息流的记录、共享、传达，输出的不仅仅是文档，还应该有设计思路、理由，只有充分输出，才能给相关团队成员足够多的信息。同时，通过暴露设计思想，团队成员之间才能发现问题，共享成果，及时纠正设计偏差。
文档化包括文档的归类整理、上传、更新、共享、作废等，为了减少返工，防止全盘推倒重来，前一步的输入是后一步输出的基础，也就是进行下一阶段工作之前，要求必须完成前一阶段的工作并为下一阶段工作提供高质量的输入，以保证每一阶段的工作都是连续的、正确的，才能保证一次性把设计工作做好。一般来说，通过运营专业的管理工具，或者最简单地建立共享网络空间等方式，做到输出的充分共享，才能在项目变更，或者被摒弃的需求又重提时，回忆一下，当时为什么我们不做这个功能，当时的理由和原因是什么，帮助产品团队结合现有情况重新评估需求。
要做到项目管理的文档化并不简单。首先项目成员日常工作繁忙，“手懒”不愿意占用时间写；其次很多急性子不耐于写那些他们称为形式化的东西。但事实是，文档化正在潜移默化地改变我们的工作方式，并从一个侧面优化产品的设计构造，使之不偏离最初的设计初衷，防止走歪路走冤枉路。
再者，要解决文档细化程度的问题。有的公司对产品文档怎么记录，有自己的一套规定，比如对设计团队的输出，可见部分的长宽高都做了严格的设计，代码设计上更是细化到方法体。团队成员可以在公司内部的管理工具上查到记录，当然首先得根据团队和项目的具体情况，确定符合项目的细化程度，然后作为制度和规范规定下来，团队成员统一执行。
最后，项目的文档化在改善人际关系方面有很好的作用。项目文档无记录、文档记录混乱，导致团队成员在接手时不容易看懂，或对某个需求理解不一致，出现争执等，在项目中非常常见，小则影响心情，大则影响工作，影响团队合作。
因此项目管理工作中，项目输出中代码管理、设计输出、需求纪要等的文档化非常重要。
2.2.3 规范化
在文档化的过程中文档如何记录、记录的格式是否统一，如果没有明文规定，容易造成查无对证的隐患，造成的设计理解出现偏差、责任不明确，更是诸多问题的根源。被“冤假错案”搞得一头雾水的项目成员，可能会产生恐惧或排斥的心理，这种心理对于项目是不利的。那么问题是谁造成的呢？都归结为文档输出者，或者项目经理吗？具体地说是项目管理策略的不严谨、不规范造成的。
在设计输出中有一大堆的开发文档、需求列表等，其中需求列表主要是用于审查系统的高层设计，比如系统设计上是否应该采取什么措施或设计操作，满足产品目标用户中哪一类人的需求就算达标了呢？虽然目前设计行业没有严格的标准，但至少各个系统平台发布的开发设计功能实现应该作为基础的标准，如果连这个基础标准也无法满足，那么再好的设计也是不规范的。
虽然网络上流传着很多指导书和规范，但很多初级的项目执行人员没有看规范要求再工作的习惯，而是通过自己的经验或者模仿他人设计作品完成工作任务。作为产品设计人员，不论项目大小，都应该遵循设计指南，为自己的App产品制定GUI规范、设计开发标准。越详细标准的开发规范越利于项目，一方面有利于养成良好的工作习惯，对自身素养提高有帮助；另一方面，将来产品团队扩大，项目规模扩大时，标准的开发和设计规范也有利于项目的延续性和规范化。
