一般文章都是在学习pmp或者p2后，如何去进行项目管理实践。每个人的经历不同，不知道有多少同学和我一样，从实践开始，在进行项目管理pmp培训，从野路子到正规军，再从想海陆空全栖发展。虽然对现在从正规院校正规专业的科班出身，再去职场打拼，积累实战经验不同。
很多人在分析问题的时候，第一时间会在自己的经验库里去搜集之前的应对方法，然后对照之前的老方法去解决眼前的问题，而不是依靠一套科学的分析方法，完成对问题的分析和解决。当你经验足够充分的时候，凭直觉确实可以做出比较正确的判断，但是这样做的一个坏处是，面对新问题，你的经验库就不够用了，你对问题的分析不够准确，提出的往往是碎片化的解决方法，而不是一套系统的解决方案。
这就是为什么随着业务越来越复杂，换工作的跨行业、不同业务、产品之间如何的快速切换，包括职位的晋升，越发觉得项目管理方法论，体系化越来越重要，他可以让你有一套方法论支撑，快速接手一个新业务或者历史经验库里没有做过的事情。在带团队后，可以用这个“套路”让团队达到“平均”水平，要求和帮助项目经理提升项目管理能力。
又要说起老生常谈的话了，我们那会项目经理都是从技术出身，逐渐升职为项目经理。项目经理对于业务、产品、技术、客户都非常熟悉，一担儿挑，所有事项基本都可以掌控住。这会儿不需要特别体系的项目管理方法论，可以用最简化的方法去执行项目，比如制定项目计划。那会也没啥立项、申请资源的情况。客户来了，根据客户合同，凭经验就可以知道需要多少人，多长时间，项目过程文档是按照甲方要求突击和补。对于项目规范性要求，更多是代码层面，比如代码规范要求比较多，比如复用性、命名、注释等。过程文档更多是产品、技术层面，为了让后面接受大开发人员，可以快速上手代码的编写工作。后来想了解下正规军如何做的，总是野路子，能解决问题，但总是觉得少些什么。参加个pmp培训并通过拿证，知识体系更完善了，但是如何把这套体系用到项目中，又遇到困难。能凭经验可以完成的事情，为什么要用更复杂的项目管理方法么？费这些事儿，还不地多接点项目，多给团队分点项目奖金呢。
后来遇到职业生涯的一个转折点，一个新的未知领域全新不同类型的项目。长期做2B产品的交付类项目，突然来到一个2C的互联网公司，还是用户运营类产品研发项目，非常的不适应。没有技术做抓手，很多事情无法把控。客户变成了用户，产品、需求、技术完全不了解，如何去做一个项目，如何找到抓手。最开始只能通过组织会议，协调员做起。经过一段时间观察，我发现很多都是新开展业务，从0-1的过程，没有可参考文档或者经验，大家都是摸着石头过河。就像我上篇说的，每个岗位都有自己的定位和分工，工作内容相对确定。但项目经理做什么？项目经理的好处是可以看到整个项目的全局，把各部门团队工作联结起来。项目结束后，完成了自己的第一张项目业务流程图，也是这张图被领导发现，逐渐被塞各种“机会”。比较粗糙，不够精美，细节上也不够详细，但对于当时一穷二白的情况，这张图已经可以清晰的指导后续同类型项目执行作为参考。
后来所面临的项目越来越复杂，业务也从没接触过，连业务部门的人也没有类似项目经验。在这个时候，回归了项目管理方法论层面，从PMP中提炼出一套快速上手项目的方法，可以简单称为项目管理三板斧。其实也很简单，不复杂，关键是否能够理解和执行到位。
第一板斧：明确项目目标，每个团队职责分工、工作内容明确，项目经理职责也很明确，简单说就是保证项目目标达成，过程可控也是为了目标达成。如果项目目标都不明确的话，那做这个项目为了什么？没有最核心的主线，只能是走一步看一步，那也不是项目了。目标可以渐进明细，一开始也要个有大方向。总体目标确定后，还要根据总体目标，按照各业务部门工作内容拆解成业务目标。
第二板斧：项目全景图，全景图包括的内容比较多，项目范围明确后，涉及的部门架构、职责分工及工作内容，按照部门维度在时间跨度上核心关键任务及里程碑。在这个阶段也要有项目计划，项目计划也是逐渐明细，一开始比较粗，随着项目任务逐渐清晰，再细化。没有计划的话，无法跟踪项目的执行情况是否有偏差；没有项目计划，每次开会就只能说我干了什么，准备干什么，流水账式汇报，项目风险非常高。
第三板斧：项目管理机制，比如每周开哪些会沟通什么内容，如：进展、完成情况、协同事项，开会的时候需要提前准备什么材料，以及怎么去汇报，团队成员达成共识，步调一致往前走。
上面最复杂的是第二步，尤其是没有历史积累，各业务部门配合度，以及不确定性，这是把不确定事情逐渐变成确定性任务计划的过程。最核心的是第一步，也是最重要的，没有这个后面有可能犯方向性错误。阻碍也很多，项目整体目标和各团队目标可能有冲突，这就是职能型组织架构对项目牵制。还有就是那种老板一拍脑门的项目，有时老板都不想把目标说清楚的情况。还是以一个实例来去描述如何去做的，还是以曾经说过的手机项目为例，为什么每次都是他，因为他是该方法第一次打磨，也是具有重大意义的项目。
先把整个项目范围粘贴出来，项目背景和基本情况请翻到前面的文章，这里不再赘述。项目总体目标是2015年手机售卖xx万台。可以先研究下这个目标，是售卖台数，并不是收入也不是利润，为什么是xx万台，而不是xxxx万台？为什么这么去设计是有底层逻辑，商业秘密不过多透露。这问题就来了，与售卖xx万台这个目标相关性的子项目包括：硬件的生产供应、销售，一个是生产一个是售卖，其他的子项目来支持销售项目。下图是项目目标分解，目标拆解也是按照项目阶段来的，项目阶段的划分是按照营销活动来制定的。与软件研发类项目-需求调研、产品设计、开发、测试、实施部署、上线、试运行（找了个最简单的按照软件交付过程划分）类似，只不过这个是按照营销事件来划分的。这个阶段划分是项目整体，每个子项目都有自己的阶段和重大里程碑。但核心要围绕主线进行。
这个项目并不是一开始就能拆解出上面的表格，也是渐进明细的。一开始能知道的就是总体目标，阶段一比较明确的目标及任务。销售任务按照经验或者老板拍脑门，硬拍给销售团队。但随着项目集推进过程中会动态调整更加准确。指标之间有相互关联性，作为项目集经理需要了解依赖关系，平衡资源及重点事项。最简单的就是供应和销售之间的关系，想卖出xx台，必须要有这么多手机（不考虑负卖的情况）。还有营销活动如何配合销售活动，由于手机一大亮点是应用、内容，这些版本开发内容集成情况也非常重要。这个项目比较痛苦是所有内容都从0-1的过程，比如售后、物流、客服。
项目管理知识体系经历了这么多年的积累，覆盖了各行业各种类型的项目，具有很高的参考价值，关键是基于这个知识体系如何去剪裁。也可以把PMBOK当成工具书，当项目遇到问题和困难的时候，总可以在里面找到工具和方法支持。
既然说到知识体系和方法论，再加一个也不嫌多——“库博学习圈”，一个完整的学习，是“行动->经验->规律->行动”的四步大循环，缺一步都是假学习。规律可以是自己总结，也可以是通过引入成熟的知识体系。每个人所处的阶段不一样，但过程一样。刚才总结自己是从“行动->经验->规律->行动”；有些同学是刚学习完PMP知识体系去行动，“知识->行动->经验->规律->行动”。
知识是死的，环境是变化的，人是活的。唯一不变的就是持续学习和总结。希望你和我一起，把你的经验总结下来，和大家一起分享，共同成长。
