项目管理从零开始样本.doc

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。
项目管理从零开始
文/陈海春
项目管理简单吗? 非常简单! 因为只要你掌握了基本的思路和方法, 就能一通百通, 达到”一切皆项目”的境界。那么项目管理复杂吗? 当然复杂! 因为项目管理不但仅是根据相应的方法论依葫芦画瓢, 更重要和更具有挑战性的工作是在项目执行过程中的人员间的协调、 沟通、 冲突处理、 团队的凝聚力等与人密切相关的部分, 只有相互信任的团队才能到达项目顺利交付的彼岸。
本文记录了笔者近三年的时间里在四个不同业务部门从事项目经理工作的主要过程, 如何将纵横交织、 盘根错杂的业务部门各项目梳理到基本的井然有序交付, 提炼出一些在弱矩阵环境下项目管理基本思路, 供各位参考。
一、 经过访谈了解问题
项目经理要做好随时被空降到不同部门、 不同项目的准备, 项目经理往往是业务部门领导心目中的那个能够信赖的人: 组织者、 协调者、 促进者。可能是老板们一个紧急的合作项目希望项目经理管起来、 可能是一个迟迟看到不到进展的项目需要项目经理去拨乱扶正按期交付、 可能是一个迫在眉睫的有及具挑战性的deadline 项目需要项目经理去按时上线。项目经理被寄予厚望, 信心饱满的走马上任, 那么如何开始呢?
不论一个项目经理拥有多么理论的知识丰富、 多么牛逼的实战经验, 如果对项目背景、 团队成员不了解的话, 也是寸步难行、 举步维艰的, 更别说按时交付项目了。因此不论你接手的项目时间是多么的紧急, 多么的负责, 作为项目经理的你需要开展一些一对一的或者一对多的访谈。带着同理心去聆听大家的反馈, 并适时的引导到家朝正确的方向前进。
如何了解和知道当前业务部门对项目管理的期望呢? 如何了解项目的当前状态呢? 只有知己知彼方能百战不殆, 虽然业界有很多方法来达到这个目的( 如问卷调查、 面谈、 焦点小组、 匿名反馈等) , 但都比不上1对1、 面对面的访谈来了解情况直接和真实。面谈的问题列表主要包含以下内容:
l 部门的愿景是什么( 或者项目的目标是是什么) ?
l 当前项目或部门中的主要风险/问题有哪些?
l 当前的工作方式/流程是怎么样的? 团队成员的分工是怎么样的?
l 当前质量衡量指标有哪些?
l 影响项目成功的关键因素是什么? 如何界定项目的成功?
l 对项目管理的期望是什么?
笔者在初入一个业务部门时经过所有团队主管( 8名) 和部分同事( 6名) 进行1-1访谈后, 得到的主要反馈有:
1. 项目立项较随意
u 比较缺少市场调研分析, 对该项目/功能所带来的改变/收益没有详细的研究;
u 无法说服相关参与者真正的参与到项目当中, 下游开发测试团队感觉都是为上游的网站策划团队打工;
2. 需求变更频繁, 需求变更无流程, 变更原因不清, 变更后通知不及时
u 需求讨论和分解不充分, 测试和客服团队经常包含进来;
u 没有召集所有可能影响到得团队成员参与讨论( 如经常忘记加测试、 客服人员参加) 、 或者需求讨论只在会议上进行, 没有预留时间让大家提前了解需求;
u 需求文档和相关的交互、 视觉文档没有基线化, 大部分的需求变更都是经过在文档系统上追加备注进行更新的, 而下载的文档内容并不是最新的内容;
u 需求变更经常发生在IM通讯群里进行讨论, 而需求文档经常没有及时同步更新, 而且有些相关人员没有及时通知( 如测试人员)
u 无变更管理流程( 什么样的需求变更需要谁在什么时候做决定)
3. 各项目的计划不清楚、 项目状态不透明
u 无项目交付节点、 或者对milestone的交付物定义不清楚
u 相关项目参与人员很少有定期的面对面会议进行状态同步, 大多数沟通时经过IM工具来完成的
4. 产品策划人员没有得到充分授权进行项目的执行, 或不知道如何进行进度监控和风险规避, 部分策划人员没有动力去进行项目的计划、 跟踪、 交付过程, 认为策划出的功能后续团队就能自动化的交付;
5. 相互推诿比较多, 对于延迟的项目/任务, 基本上都认为问题出在其它团队身上( 如技术认为UED 是瓶颈, UED认为策划是瓶颈等)
6. 会议效率较低:
u 没有留出时间让会议参与人员进行准备
u 很少有会后跟踪措施, 没有做到问题的闭环跟踪
7. 很少有人在乎计划的交付日期:
u 产品部门无中、 长期的计划, 以及如何达成这些目标计划不可视, 希望能够有季度部门会议从业务优先级上使大家达成一致
u 无部门管理团队定期的面对面的周会, 周报大多流于形式, 各组间的依赖、 风险、 问题没有进一步的跟踪和解决措施
8. 临时性任务多、 经常打断正在做的项目/任务, 每个小组都认为问题出在其它相关小组上, 不认为是由于本小组导致项目/任务延迟, 无相关历史数据供参考;
总体来说, 大家对项目管理的期望是:
l 项目计划清楚、 可视、 可控
l 整理一个项目启动评审的决策流程, 能够帮助大家识别项目的价值和优先级
l 加强各部门在项目中的合作, 使相互的协作更加流畅
l 项目需求更加清楚合理, 考虑更全面
l 需求变更有据可依, 有据可查
l 提高项目参与人员的主人翁意识和责任感
l 尽快做1~2个标杆性的项目, 经过此项目向其它同事传播专业的项目管理方式
在得出基本的问题列表以及结合大家对项目管理的期望, 和业务部门主管一同讨论后水到渠成的得出了项目管理工作的基本思路, 不积跬步无以至千里, 改变和提升先从试点项目开始。
二、 改变从试点项目开始
试点项目的选取
首先试点项目要具有典型性和代表性: 其中包括项目规模、 人员构成、 时间长度、 结果跟踪。项目规模最好是平均规模的项目, 不可太大或者为了制造出一个试点项目而圈定2-3人参加的小项目。人员构成应该是保持全部流程参与方的团队, 例如一个典型的互联网项目需要有产品经理、 交互视觉设计师、 开发工程师、 测试工程师、 运维人员、 运营推广员主要角色, 在试点项目中最好能够包含这些全流程的角色。在互联网领域一般的项目交付时间长度应该是1~2个月, 不可选时间太短( 1~2周) 或太长( ＞3个月) 的项目, 时间太短可能一些项目活动都被剪裁了, 时间太长则试点输出的结果需要很久才能得到推广。试点项目的结果跟踪指的是被选定的项目需要在项目开始的时候定义清楚如何衡量这个项目的成功与否( 项目管理铁三角、 线上数据表现、 团队成员反馈、 用户研究访谈等指标)

其次试点项目要得到业务部门领导的支持和授权, 明确的让领导们知道这是试点, 在试点过程中可能由于新引入的一些方法、 流程不一定适合团队, 而且可能会导致团队的效率下降。需要对试点项目希望达成的结果有统一认识, 如经过试点项目找到比较适合当前团队的流程方法、 度量指标, 还是提高项目及时交付率, 抑或是经过项目交付打造优秀团队文化和自组织团队。

最后试点项目团队成员需要知道自己身处‘试点’之中, 犹如在拨打自助电话客服时被提示‘您的通话将会被录音’一样, 使每个人有心理预期和准备, 更能积极有效的加入到试点中来。
试点项目的执行、 数据收集&分析
试点项目的目的要明确, 需要针对性的收集数据, 数据是为下一步决策改进提高基础, 没有数据提供支持的决策基本上都是凭感觉和拍脑袋, 正所谓‘无量化, 不论理’。针对前面访谈所暴露出的主要问题, 在试点项目中重点收集的数据有: 项目人力支出、 项目规模变化、 线上bug数量、 及时交付率。
项目人力支出
网易能够说是一个不差钱的互联网公司, 很多产品/项目不需要进行相关的预算审核和营收考核的, 大家能够在一种宽松的环境下发挥创造力, 自由的打磨产品。但同时也带来一个问题, 有些产品投入了上百人月可是用户规模、 营收很不理想, 就是导致团队成员怀疑其产品定位和质疑我们的价值、 我们的ROI在哪儿。统计项目人力支出并不是想经过投入的人力来判断一个产品/项目的好坏, 而是希望经过统计实际支出人力让部门总监知道在不同项目的人力投入, 以及项目所带来的收益是否值得, 后续如果有类似的项目是否还会投入这么人力、 抑或是减少/加大人力投入, 甚至需要考虑类似的项目是否能够直接从市场采购。
下图是一个对外合作项目的投入人力情况, 数据来源是每周项目周会上每人记录在过前一周投入到这个项目的时间百分比, 历时4个来月, 总共投入了24人月。项目上线后的第一个月带来的销售额是2w多元, 新用户数也区区可数不足千人。

在项目回顾会议上大家都认为这个项目的ROI 很低, 需要在项目启动时慎重评估, 项目发起方商务团队需要对接项目的结果进行预估和上线后有相应的衡量考核体系。
项目规模变化
在不同部门的初期访谈过程中, 研发团队重复提到的一个希望是能够控制需求变更, 减少变更。为了能够衡量项目开发过程中的需求变化情况, 在试点项目中从项目规模维度进行了量化和记录。由于大家以前都没有接触过敏捷中的故事点估算方法, 在大家对敏捷还没有什么概念的时候如果推行故事点估算的话将会遇到很多困难( 故事点和人天间的换算、 模块负责人估算的权威性等) 。这里使用大家最容易理解的人天来进行估算, 下图的项目在初始阶段时规模是112.5人天, 中途增加了需求导致规模上升到145.5人天, 同时实际花费的人力也是145.5人天, 最后得出规模变化率为29%, 其计算公式是: ( 实际花费人天-项目初始估算人天) /项目初始估算人天。

得出项目规模变化率的目的并不是想达到控制需求变化、 减少需求变化, 而是经过三个试点项目的统计数据发现在A部门中的项目规模变化率中位值是25%, 经过回顾分析发现这些变化的需求大部分来源于两个方面: 一是由于产品策划考虑不充分, 例如一些异常情况的处理; 二是技术实现上的难度比估算时更大。因此在A部门的后续其它项目中基本上预留额外的20%项目规模作为缓冲时间。
线上bug
在加入K部门后要求QA部门对线上bug进行了统计分析, 并发出月度线上bug 总结邮件, P0级线上bug 是指已影响到用户使用的情况, 不论影响了多少用户( 如支付环节中支付不成功问题) 。P1级线上bug 指的是不影响用户使用的功能( 例如内部系统问题, 活动页面图片/链接配置错误问题) 。
统计时间区间
P0 bug 数
P1 bug 数
线上bug 总数
.7.16~ .8.15
4
21
25
.8.16~ .9.15
3
7
10
.9.16~ .10.21
3
7
10
深入分析这些数据后还发现一个有趣的现象是约有1/3左右的线上bug是由于修改前一个线上bug 导致的, 或者是由于测试场景不充分仓促上线导致的。基本上每天都在上线( 当然如果CI做的好的团队、 自动化测试足够的团队每天上线可能没有什么问题) , 合代码并进行手动回归测试基本上只有1天的时间。为了减少线上bug 的发生和做到有计划、 有节奏的上线, 因此制定了固定上线节奏( 在K部门是每周二、 周五两次) 。
及时交付率
经过对部门中3个月里面交付的所有项目完成时间和计划完成时间的比较得出项目及时交付率, 从3.11日到6.4日在部门中共上线了16个项目, 平均项目时长31.8天( 日历日) , 其中三个试点项目由本人作为项目经理, 其它13个项目由开发负责人或者产品经理兼任项目经理。
16个项目中按计划日期上线的有8个( 部门中的项目及时交付率为50%) , 这和访谈中大家谈到的项目延迟严重比较吻合。8个延迟项目中, 延迟率从2%到60%不等, 详情如下图所示: ( 由于涉及到公司具体的项目和人员在下图中的项目名称已做模糊化处理, 项目经理一列中具体的人名已移除)

经过上图的数据能够看出超出一个月的项目延迟风险比一个月内的项目延迟风险要大得多, 其中延迟57%、 60%的两个项目主要原因是中途方案调整较大。
三、 建立基本的项目管理流程和度量体系
项目集Roadmap机制
公司的运营、 部门的运作犹如行使中的高铁列车, 一旦启动就很难停下来, 部门中每位同事每天都很忙, 最近两年互联网公司流行一个术语叫996( 指工作时间从早上9:00到晚上9:00, 每周6天) , 可是经过半年左右的996后, 团队就会频繁的质问我们真的需要996吗? 为什么每天都在救火? 每个事情是真正值得做的事情吗?
由于业务部门的业务不断发展壮大, 业务启动时的单一仓库无法满足要求了, 需要将货物挪仓, 有时同一货物需要在不同仓库中发货, 而开始的系统是针对单一仓库设计的, 有些功能无法实现。例如某天的主管站会上一运营同事提出希望在不同的仓库间售卖同一商品时能够做到用户看到页面一个, 而且评论共享。产品经理答应会后给出解决方案来帮助运营同事减少评论复制、 页面复制的人肉工作量。可是, 详细分析和了解当前系统架构和数据结构后发现底层商品逻辑不支持, 需要对相关系统进行重构, 也无法承诺具体什么时候能够重构完成。而仓库间货物转移早在2个月前就已经开始了, 那是什么导致了如此重要的功能一直没有被提上产品开发日程呢? 第二天项目经理和业务部门CTO就此事进行了讨论, 得到的结论是平时大家都忙于应付紧急的事情, 而这些重要的事情往往就被一而再、 再而三的delay了。
这类情况在其它部门也经常见到, 因此对应的解决一个方法是设立部门重点项目集管理, 经过每两周一次的产品roadmap 会议来对项目集中的每个项目状态在核心主管团队中review, 以评估当前的重点项目是否有风险/问题、 以及是否有新的项目需要纳入重点项目集中。
下图是在K部门所使用的项目集列表, 其中1~6个浅绿色背景的项目为部门重点项目。

为了保障重点项目能够有足够的人力投入, 和CTO及各位主管达成的协定是: 一旦重点项目立项, 那么需要保障人力来交付项目, 如果其它项目或事情需要挤占重点项目的人力而且影响到重点项目交付的话, 需要部门CTO批准。
三步评审法
在完成了三个试点项目后, 摆在项目管理工作面前的问题是: 如何找到适合于业务部门的项目管理基本方法和流程? 诚然, 原封不动的应用Scrum流程时机未到, 而且阻力较大( 涉及到组织结构的调整、 新的角色职责、 考评方式的改变) , 也无法照搬CMMI/IPD等繁重的流程体系。在和业务部门领导、 及团队主管同事讨论后提炼出里程碑规划+迭代的项目管理基本思路, 从项目启动到项目上线期间辅以3次主要的评审活动, 取名为‘三步评审法’, 这些评审活动的目的是使项目团队在‘做正确的事’方面更有保障。
经过对业务部门的项目交付流程的整理, 梳理出如下图所示的基本过程, 其中产品idea讨论阶段、 和项目需求确认阶段是市场/需求小组和部门主管间的一些讨论, 主要集中在市场前景分析、 ROI预估等方面, 不需要包含大部分项目组成员, 因此这两个步骤没有纳入项目评审会议中。而最后面的项目总结阶段当前仅仅针对于有营收指标的一些项目进行分析, 并没有覆盖到所有的项目中, 所有项目的评审会议中也没有包含这一步骤。因此, ‘三步评审法’包含的内容是下图中红色框内的内容: 策划需求评审、 交互/视觉评审、 上线评审。

三次评审会议内容结构是:
会议名称
会议时长
会议目的说明
Input
Output
Owner
Approver
参与者
策划评审会
<= 1h
用户场景描述;
技术可行性;
项目的期望交付计划;
项目背景简介
网站逻辑上如何被用户使用
功能列表
交互计划
项目整体大致计划
确定项目组成员
项目经理
所涉及部门的leader们共同决策
项目组同事、 所涉及部门的leader
交互/视觉评审会
<= 1h
阐述用户的交互体验是怎么样的
交互稿/视觉稿
视觉计划
开发计划
项目计划更新
项目经理
所涉及部门的leader们共同决策
项目组同事、
所涉及部门的leader
上线评审会
<= 1h
各方判断是否能够上线
准备启动上线后相关活动
上线评审PPT
可演示的软件
是否同意上线
项目经理
部门总监
产品总监、
项目组同事、
所涉及部门的leader
上述三个评审会时长限制在1个小时是希望会议组织者、 参与者能够在会议前准备好, 在会议上重点讨论有分歧的问题, 避免冗长而低效的会议。
形成每周固定上线节奏
结合前述访谈的反馈和试点项目的反馈, 在业务部门中建议实施了每周二、 周五两次固定上线节奏, 上线窗口之外的上线均需要部门CTO批准, 项目计划时将上线时间匹配入对应的上线时间窗口。这样的安排所带来的最直接的一个好处是使研发部门( 开发、 测试团队) 的计划性更强了, 工作也更从容了。
经过两个月的观察和数据统计发现紧急上线频率下降的有限, 实行固定节奏上线的机制后的第一个月紧急上线了20次( 22个工作日) 、 第二个月紧急上线了18次( 21个工作日) , 这其中主要原因是电商活动相关的一些修改和上线。经过和研发同事对这些数据进行分析, 发现每次紧急上线的内容变少了, 没有了以前那种搭便车的情况了, 因而研发的压力并不是很大。
要做的业务人员眼中的‘想发就发’的境界, 下一步需要建立其比较完善的CI系统, 其中最重要的是完善相关的自动化测试脚本, 能够做到回归测试交由机器来完成, 而测试人员聚焦在新功能的完备性测试和相关的探索性测试上。
最小度量数据集+闭环跟踪指标
经过在试点项目中形成的数据统计, 和业务部门领导达成了项目的最小度量数据集、 以及闭环跟踪指标, 其中最小度量数据集主要包含内容是: 人力支出、 及时交付率、 规模变化率、 线上bug。
①人力支出: 在每次项目站会上收集项目成员投入到本项目的人力占比, 单位为人天, 用于衡量项目的基本人力投入。由于计算机服务器资源在互联网公司一般都是在云端了, 因此这一块的成本基本不用在项目中进行记录和衡量了。
②及时交付率: 用于项目延迟/及时交付情况, 计算公式是: ( 项目实际上线日期-项目计划上线日期) /项目计划时长, 日期对应的单位为工作日。
③项目规模变化率: 能够使用人天或者故事点来衡量项目规模, 规模变化率是指实际项目所花费的人天或故事点除以计划的人天或故事点, 用于衡量产品方案的完备程度。获得较多数据后将能够用于项目缓冲时间的基准。
④线上bug: 用来衡量项目质量的一个主要指标, 记录线上bug 数量和严重程度。线上bug严重级别根据不同的业务能够进行划分, 例如下面P0-P2级别划分是某部门的定义:
故障等级P0: 重要性高的服务功能不可用或功能异常, 且大面积影响到用户使用。
故障等级P1: 重要性高的服务功能不可用或功能异常, 但影响的用户有限; 或者是, 重要性中等的服务功能不可用或功能异常, 且持续故障大面积影响用户体验。
故障等级P2: 重要性中等的服务功能不可用或功能异常, 轻微影响用户体验。
其中闭环跟踪指标主要是在上线的1~3个月内对线上表现情况进行跟踪分析, 记录的数据主要是营收和新用户数两大类指标, PV,UV以及复购率作为辅助指标。
全员培训
一个流程的确定和实施需要广而告之, 让部门所有同事知其然、 知其因此然, 需要讲解为什么选取这样的流程、 记录这些数据等内容, 对部门全体同事进行培训, 是开展后续全面项目管理必不可少的一个环节。
全员培训的内容主要放在如下四个方面
①流程和项目最小数据集: 三步评审法的内容、 输入、 输出以及需要参与的人员介绍。解释为什么要进行项目的最小数据集度量, 每个历史数据将如何使用( 这些基本的数据不能用以团队成员的季度考评, 主要用来衡量一个部门的整体的项目健康度情况) 。
②成员职责说明: 除了团队成员的各自角色介绍外, 其中项目经理和产品经理的职责需要重点介绍, 这是一般人比较容易混绕两个角色。项目经理主要工作职责是组织和协调项目中各项活动, 提高团队效率; 项目计划跟踪执行, 识别风险和解决团所遇到的问题; 服务于产品, 使项目顺利交付。产品经理主要工作职责是理解用户需求、 定义产品形态、 形成需求列表和决定功能优先级。
③不同项目类型的定义: 为了简单起见将项目分为重点项目、 非重点项目两大类别。特别需要对重点项目的评选机制、 变更流程要重点说明, 而且让大家清楚的知道当前有哪些项目是重点项目。
四、 对项目管理的反馈
每个人都希望自己的工作能够得到她人的承认, 作为项目经理也不例外J。为了能够知道过去一段时间在业务部门的贡献和价值况, 基本上每半年会对业务部门全员进行匿名反馈, 以下是其中一个部门在项目经理介入6个月后的一些团队反馈, 其主要结果如下:
l 100%受访者认为项目管理介入后项目管理及时交付有了提升; ( 数据显示在项目经理介入的半年中项目及时交付率从20%上升至68%)
l 78%受访者对项目管理工作是满意或者非常满意的;
l 75%受访者认为项目管理介入后对项目的透明性、 质量方面有提升;
l 50%受访者认为三步评审法适合于当前业务部门的现状, 38%受访者认为比较占时间或没什么感觉,12%受访者认为没有必要;
虽然基本的项目管理流程三步评审法接受程度不是太高, 但使项目经理深刻的认识到一个流程是需要不断优化和演进的, 没有一个能够解决所有问题的‘万能药’式的流程能够解决当前业务部门所有的问题。知道问题所在才是更进一步的工作的动力之所在。
除了上述量化的反馈外, 在工作中的项目管理对项目风险的管理、 减少外界对团队的干扰、 为项目保驾护航等方面带来的好处而赢得团队成员的称赞是无法用量化数字能体现的。
五、 项目管理的下一步
项目管理在一个部门中得到初步的认可了, 基本的项目管理流程也已建立, 及时交付率得到了一定的提升, 后续项目管理在业务部门该如何发展呢?
及时交付项目是我们项目管理的基本要求、 持续优化项目管理相关流程是我们项目管理的本职工作。三步评审法只是一个起点, 计划后续结合项目的实际情况使这些评审更好的落实, 而且在效果和会议时间上取得更合理的折中;
项目中‘硬性’的东西( 例如流程规范、 度量指标、 工具使用等) 是相对而言比较容易建立的, 而团队中‘软性’的东西( 团队文化、 激情和士气、 认同感等) 是需要长时间的引入改变的。后续在保持和维护基本的硬性要求外将在这些偏软性方面发挥更多的项目管理增值服务, 例如打造相互信任的自组织文化、 减少浪费、 闭环反馈、 教练机制。
· 打造信任的自组织文化, 团队是否认同所设定的基本项目管理流程? 团队是否还为产品的未来心存梦想? 团队是否还在为达成项目目标而自愿奉献? 这些更深层次的问题需要的不但仅是项目管理的流程方法去解决了, 需要更深入业务部门和团队中去, 希望经过聆听大家的心声, 施加相关的正能量影响之。要想在上下级中获得信任, 一个前提条件是团队的产出能够是一个完整的交付物, 而敏捷圈的特性团队( feature team) 能够从基础上提供一个良好的组织架构。
特性团队( feature team) 是指承担端到端交付任务、 长期的、 跨职能成员合作的一种团队形式, 例如一个典型互联网项目的特性团队包括策划、 交互视觉、 开发、 测试、 运营成员。相对当前大多数组织所采用的功能团队(function team)而言它的好处是一个特性团队能够承担完整的、 端到端交付、 能为结果负责, 而不是众多环节中的一个螺丝钉, 无需在功能团队间进行任务传递, 整个特性团队对项目的成败负责。
在项目集管理方式中各项目团队成员在一个一个项目完成后就解散了, 针对这种项目成员不固定、 项目周期比较短的项目性质是否能够采用固定的特性团队方式来提高团队合作效率呢? 在参加的CSM( Certified Scrum Master) 培训中和今年上海的Scrum Gathering上和业界同行聊起这个话题时, 几乎大家建议都是把业务部门当前的功能团队组织架构改成类似下图中的特性团队:

虽然特性团队的好处是能够将团队固定下来, 不同的项目能够由任意一个功能团队完整的交付, 每个团队对从头至尾的项目定义、 开发、 测试、 上线、 运营负责。但另外一方面在应用特性团队之前需要和相关团队、 上司达成一致: 这些以前每个团队的负责人角色如何定义? 每个同事的领域能力如何能够得以提高? 如何让部门领导能够授权给团队? 团队的能力成熟度是否足以承担为结果负责?
· 减少浪费, 曾经笔者经历的一个真实而典型的项目是这样的: 一个 的Win 8 Metro风格客户端项目花费的研发人力成本是24人月, 可是 整个上半年贡献的销售额不足1万人民币, 当时项目是及时有效的交付了。可是这样的项目即使我们及时交付了, 它的价值/ROI是什么呢? 另一方面, 这种情况对团队长远发展是非常不利的, 长此以往将没有人会认同业务愿景, 士气低落, 对业务的发展将形成负反馈。除了加强项目立项评审、 多方共同参与决策外, 应用精益创业中最简产品( MVP) 概念来验证需求, 将会使这样的‘大’失败更少一点, 为公司节省一些资源、 费用;
· 闭环反馈, 是为产品、 市场、 运营活动提供结果跟踪、 意见反馈的跟踪手段。曾经在一个网易的垂直电商产品( 个性化印品定制) 中推广了这一方法: 对所有的运营活动、 推广合作、 新产品上线制定出上线后一个月内的线上数据表现情况、 客服反馈情况的闭环反馈和评价机制。在这过程中客服的意见被更加的重视, 不能说当前的客服同事意见不够重视, 只能说客服反馈意见的时候大家都觉得有道理, 可是后续没有相应的措施来保证客服意见被产品接受、 和修改到产品、 活动中去。久而久之, 有时客服就有点儿麻木不仁了, 有点儿不想反馈意见了。在后续的过程改进中让客服参与到产品定义、 需求讨论中来, 使客服( 客户意见的代 表) 的意见真正被重视和被落实。项目上线一个月后的数据分析会上邀请全体项目组同事进行线上数据分析( 销售额、 PV/UV、 新用户数、 复购率等指标) , 使大家能够切切实实的感受所交付的项目带来的价值是什么。如果没有达到目标需要业务负责人给出原因分析和后续改进措施。
· 教练机制, 教练是一个集多种角色于一身的人。但主要是挑战和激发团队成员的潜力, 做团队中那个看不见皇帝新衣的小孩, 能够把团队中的问题真实的反映出来, 然后促使大家意识到该问题的存在, 并经过引导建立相关的团队文化、 工具、 流程。它不是一朝一夕能够立竿见影的, 需要比较长的时间才能看到团队的变化, 是一种润物细无声的境界。
笔者一直认为在弱矩阵下的项目经理是一个成本中心而非利润来源, 项目经理的价值是经过提高团队的效率、 提高项目成功交付率而体现的。项目管理是为业务部门解决问题提高效率的, 而不是单纯的推广流程、 文档。
只有成功的产品上才有成功的项目, 项目管理需要和业务紧密结合才能体现价值, 项目管理需要为业务发展提供支持和保障, 它没有职责边界限制, 它取决于所在的环境需要什么样的项目管理服务。