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