《项目及项目管理从零开始》由会员分享，可在线阅读，更多相关《项目及项目管理从零开始（11页珍藏版）》请在金锄头文库上搜索。
1、项目管理从零开始文/陈海春项目管理简单吗非常简单！因为只要你掌握了基本的思路和方法，就能一通百通，达到“一切皆项目”的境界。那么项目管理复杂吗当然复杂！因为项目管理不仅仅是根据相应的方法论依葫芦画瓢，更重要和更具有挑战性的工作是在项目执行过程中的人员间的协调、沟通、冲突处理、团队的凝聚力等与人密切相关的部分，只有相互信任的团队才能到达项目顺利交付的彼岸。本文记录了笔者近三年的时间里在四个不同业务部门从事项目经理工作的主要过程，如何将纵横交织、盘根错杂的业务部门各项目梳理到基本的井然有序交付，提炼出一些在弱矩阵环境下项目管理基本思路，供各位参考。一、通过访谈了解问题项目经理要做好随时被空降到不同
2、部门、不同项目的准备，项目经理往往是业务部门领导心目中的那个可以信赖的人：组织者、协调者、促进者。也许是老板们一个紧急的合作项目希望项目经理管起来、也许是一个迟迟看到不到进展的项目需要项目经理去拨乱扶正按期交付、也许是一个迫在眉睫的有及具挑战性的deadline 项目需要项目经理去按时上线。项目经理被寄予厚望，信心饱满的走马上任，那么如何开始呢不论一个项目经理拥有多么理论的知识丰富、多么牛逼的实战经验，如果对项目背景、团队成员不了解的话，也是寸步难行、举步维艰的，更别说按时交付项目了。所以不论你接手的项目时间是多么的紧急，多么的负责，作为项目经理的你需要开展一些一对一的或者一对多的访谈。带着同
3、理心去聆听大家的反馈，并适时的引导到家朝正确的方向前进。如何了解和知道当前业务部门对项目管理的期望呢如何了解项目的当前状态呢只有知己知彼方能百战不殆，虽然业界有很多方法来达到这个目的（如问卷调查、面谈、焦点小组、匿名反馈等），但都比不上1对1、面对面的访谈来了解情况直接和真实。面谈的问题列表主要包含以下内容：l 部门的愿景是什么（或者项目的目标是是什么）l 目前项目或部门中的主要风险/问题有哪些l 目前的工作方式/流程是怎么样的团队成员的分工是怎么样的l 目前质量衡量指标有哪些l 影响项目成功的关键因素是什么如何界定项目的成功l 对项目管理的期望是什么笔者在初入一个业务部门时通过所有团队主管（
4、8名）和部分同事（6名）进行1-1访谈后，得到的主要反馈有：1. 项目立项较随意 u 比较缺少市场调研分析，对该项目/功能所带来的改变/收益没有详细的研究；u 无法说服相关参与者真正的参与到项目当中，下游开发测试团队感觉都是为上游的网站策划团队打工；2. 需求变更频繁，需求变更无流程，变更原因不清，变更后通知不及时 u 需求讨论和分解不充分，测试和客服团队经常包含进来；u 没有召集所有可能影响到得团队成员参与讨论（如经常忘记加测试、客服人员参加）、或者需求讨论只在会议上进行，没有预留时间让大家提前了解需求；u 需求文档和相关的交互、视觉文档没有基线化，大部分的需求变更都是通过在文档系统上追加备
5、注进行更新的，而下载的文档内容并不是最新的内容；u 需求变更经常发生在IM通讯群里进行讨论，而需求文档经常没有及时同步更新，并且有些相关人员没有及时通知（如测试人员） u 无变更管理流程（什么样的需求变更需要谁在什么时候做决定）3. 各项目的计划不清楚、项目状态不透明 u 无项目交付节点、或者对milestone的交付物定义不清楚 u 相关项目参与人员很少有定期的面对面会议进行状态同步，大多数沟通时通过IM工具来完成的4. 产品策划人员没有得到充分授权进行项目的执行，或不知道如何进行进度监控和风险规避，部分策划人员没有动力去进行项目的计划、跟踪、交付过程，认为策划出的功能后续团队就能自动化的交
6、付；5. 相互推诿比较多，对于延迟的项目/任务，基本上都认为问题出在其他团队身上（如技术认为UED 是瓶颈，UED认为策划是瓶颈等） 6. 会议效率较低:u 没有留出时间让会议参与人员进行准备 u 很少有会后跟踪措施，没有做到问题的闭环跟踪 7. 很少有人在乎计划的交付日期:u 产品部门无中、长期的计划，以及如何达成这些目标计划不可视，希望能够有季度部门会议从业务优先级上使大家达成一致u 无部门管理团队定期的面对面的周会，周报大多流于形式，各组间的依赖、风险、问题没有进一步的跟踪和解决措施 8. 临时性任务多、经常打断正在做的项目/任务，每个小组都认为问题出在其他相关小组上，不认为是由于本小组
7、导致项目/任务延迟，无相关历史数据供参考；总体来说，大家对项目管理的期望是：l 项目计划清楚、可视、可控l 整理一个项目启动评审的决策流程，能够帮助大家识别项目的价值和优先级l 加强各部门在项目中的合作，使相互的协作更加流畅l 项目需求更加清楚合理，考虑更全面l 需求变更有据可依，有据可查l 提高项目参与人员的主人翁意识和责任感l 尽快做12个标杆性的项目，通过此项目向其他同事传播专业的项目管理方式在得出基本的问题列表以及结合大家对项目管理的期望，和业务部门主管一同讨论后水到渠成的得出了项目管理工作的基本思路，不积跬步无以至千里，改变和提升先从试点项目开始。二、改变从试点项目开始试点项目的选取
8、首先试点项目要具有典型性和代表性：其中包括项目规模、人员构成、时间长度、结果跟踪。项目规模最好是平均规模的项目，不可太大或者为了制造出一个试点项目而圈定2-3人参加的小项目。人员构成应该是保持全部流程参与方的团队，例如一个典型的互联网项目需要有产品经理、交互视觉设计师、开发工程师、测试工程师、运维人员、运营推广员主要角色，在试点项目中最好能够包含这些全流程的角色。在互联网领域通常的项目交付时间长度应该是12个月，不可选时间太短（12周）或太长（3个月）的项目，时间太短可能一些项目活动都被剪裁了，时间太长则试点输出的结果需要很久才能得到推广。试点项目的结果跟踪指的是被选定的项目需要在项目开始的时
9、候定义清楚如何衡量这个项目的成功与否（项目管理铁三角、线上数据表现、团队成员反馈、用户研究访谈等指标）其次试点项目要得到业务部门领导的支持和授权，明确的让领导们知道这是试点，在试点过程中可能由于新引入的一些方法、流程不一定适合团队，而且可能会导致团队的效率下降。需要对试点项目希望达成的结果有统一认识，如通过试点项目找到比较适合目前团队的流程方法、度量指标，还是提高项目及时交付率，抑或是通过项目交付打造优秀团队文化和自组织团队。最后试点项目团队成员需要知道自己身处试点之中，犹如在拨打自助电话客服时被提示您的通话将会被录音一样，使每个人有心理预期和准备，更能积极有效的加入到试点中来。试点项目的执行
10、、数据收集&分析试点项目的目的要明确，需要针对性的收集数据，数据是为下一步决策改进提高基础，没有数据提供支持的决策基本上都是凭感觉和拍脑袋，正所谓无量化，不管理。针对前面访谈所暴露出的主要问题，在试点项目中重点收集的数据有：项目人力支出、项目规模变化、线上bug数量、及时交付率。项目人力支出网易可以说是一个不差钱的互联网公司，很多产品/项目不需要进行相关的预算审核和营收考核的，大家可以在一种宽松的环境下发挥创造力，自由的打磨产品。但同时也带来一个问题，有些产品投入了上百人月但是用户规模、营收很不理想，就是导致团队成员怀疑其产品定位和质疑我们的价值、我们的ROI在哪儿。统计项目人力支出并不是想通
11、过投入的人力来判断一个产品/项目的好坏，而是希望通过统计实际支出人力让部门总监知道在不同项目的人力投入，以及项目所带来的收益是否值得，后续如果有类似的项目是否还会投入这么人力、抑或是减少/加大人力投入，甚至需要考虑类似的项目是否可以直接从市场采购。下图是一个对外合作项目的投入人力情况，数据来源是每周项目周会上每人记录在过前一周投入到这个项目的时间百分比，历时4个来月，总共投入了24人月。项目上线后的第一个月带来的销售额是2w多元，新用户数也区区可数不足千人。在项目回顾会议上大家都认为这个项目的ROI 很低，需要在项目启动时慎重评估，项目发起方商务团队需要对接项目的结果进行预估和上线后有相应的衡
12、量考核体系。项目规模变化在不同部门的初期访谈过程中，研发团队反复提到的一个希望是能够控制需求变更，减少变更。为了能够衡量项目开发过程中的需求变化情况，在试点项目中从项目规模维度进行了量化和记录。由于大家以前都没有接触过敏捷中的故事点估算方法，在大家对敏捷还没有什么概念的时候如果推行故事点估算的话将会遇到很多困难（故事点和人天间的换算、模块负责人估算的权威性等）。这里使用大家最容易理解的人天来进行估算，下图的项目在初始阶段时规模是人天，中途增加了需求导致规模上升到人天，同时实际花费的人力也是人天，最后得出规模变化率为29%，其计算公式是：（实际花费人天-项目初始估算人天）/项目初始估算人天。得出
13、项目规模变化率的目的并不是想达到控制需求变化、减少需求变化，而是通过三个试点项目的统计数据发现在A部门中的项目规模变化率中位值是25%，通过回顾分析发现这些变化的需求大部分来源于两个方面：一是由于产品策划考虑不充分，例如一些异常情况的处理；二是技术实现上的难度比估算时更大。因此在A部门的后续其他项目中基本上预留额外的20%项目规模作为缓冲时间。线上bug在加入K部门后要求QA部门对线上bug进行了统计分析，并发出月度线上bug 总结邮件，P0级线上bug 是指已影响到用户使用的情况，不论影响了多少用户（如支付环节中支付不成功问题）。P1级线上bug 指的是不影响用户使用的功能（例如内部系统问题
14、，活动页面图片/链接配置错误问题）。统计时间区间P0 bug 数P1 bug 数线上bug 总数深入分析这些数据后还发现一个有趣的现象是约有1/3左右的线上bug是由于修改前一个线上bug 导致的，或者是由于测试场景不充分仓促上线导致的。基本上每天都在上线（当然如果CI做的好的团队、自动化测试足够的团队每天上线也许没有什么问题），合代码并进行手动回归测试基本上只有1天的时间。为了减少线上bug 的发生和做到有计划、有节奏的上线，因此制定了固定上线节奏（在K部门是每周二、周五两次）。及时交付率通过对部门中3个月里面交付的所有项目完成时间和计划完成时间的比较得出项目及时交付率，从日到日在部门中共上
15、线了16个项目，平均项目时长天（日历日），其中三个试点项目由本人作为项目经理，其他13个项目由开发负责人或者产品经理兼任项目经理。16个项目中按计划日期上线的有8个（部门中的项目及时交付率为50%），这和访谈中大家谈到的项目延迟严重比较吻合。8个延迟项目中，延迟率从2%到60%不等，详情如下图所示： （由于涉及到公司具体的项目和人员在下图中的项目名称已做模糊化处理，项目经理一列中具体的人名已移除）通过上图的数据可以看出超出一个月的项目延迟风险比一个月内的项目延迟风险要大得多，其中延迟57%、60%的两个项目主要原因是中途方案调整较大。三、建立基本的项目管理流程和度量体系项目集Roadmap机制公司的运营、部门的运作犹如行使中的高铁列车，一旦启动就很难停下来，部门中每位同事每天都很忙，最近两年互联网公司流行一个术语叫996（指工作时间从早上9:00到晚上9:00，每周6天），但是经过半年左右的996后，团队就会频繁的质问我们真的需要996吗为什么每天都在救火每个事情是真正值得做的事情吗由于业务部门的业务不断发展壮大，业务启动时的单一仓库无法满足要求了，需要将货物挪仓，有时同一货物需要在不同仓库中发货，而开始的系统是针对单一仓库设计的，有些功能无法实现。例如某天的主管站会上一运营同事提出希望在不同的仓库间售卖同一商品时能够做到用户看到页面一个，并且评论共享。产品经理答应会后给
