沐鸣娱乐


        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        对很多产品经理而言,特别是身处创业团队 ,往往都是一身挑几职,产品和项目,理不清理还乱。从本文开始,以产品经理的视角看待项目,以及如何管理项目。

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        接上篇 。

        四 、合适的人与靠谱的计划

        几乎每个项目都有人吐槽 ,太坑太扯淡。

        实际上,项目之所以会扯皮,往往在前期就埋了下巨坑,随着项目的进程问题越来越严重,直到不能收场。

        在上文我们已经厘清了项目的几个核心概念 ,我们知道要想做好一个项目首先要搞清楚项目利益相关方 ,组建合适的项目团队 ,然后我们需要分解我们的项目任务,制定一个清晰的项目计划,才能指导和推动项目的进展 。

        我们现在从案例来还原项目前期的挖下的坑 :

        A公司目前正在为一个医院开发一套系统,现在项目按时间开发完成了 ,也做好了相关的培训工作 ,但始终无法验收,医生说不好用,而且还有三个需求要变更,开发工程师下个月要离职了 ,各种问题层出不穷……

        假设你是这个项目的项目经理,我们一起来看看你踩的雷。

        1. 项目第一坑 :“人”才是最坑的

        你从销售经理那里获悉,这个项目是内科的科长最开始发起的 ,副院长也很支持 。

        你很开心 ,感觉这个项目牵涉的人比较少,就开始了这个项目,并且定期发送相关的进度报告:

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        随着在医院的了解越来越多,你发现医院的关系越来越复杂,各种不配合扯皮的现象——很多没必要的需要变更,培训的效果也没有看上去理想。

        你认为这是院长负责的项目,一定大家都会支持;你以为给内科做了一次培训 ,大家都会使用;没想到培训完之后他们还是反馈说系统不太好用。

        这些问题 ,本质上就是项目开始阶段想得太简单,没有能搞清楚相关方的利益关系。

        这是项目的第一步,也是项目的关键一步。

        多数情况下,一个项目有支持者,往往就有反对者;项目的支持者能让项目锦上添花,但反对者往往决定成败。

        如果在项目开始阶段,没有找出那项目能够施加积极和消极影响力的人,注定整个项目会很艰难。

        同时 ,你还需要找到一个最具有推动力的关键人 ,对内争取更多资源 ,对外摆平各种关系。

        所以,这个项目的干系人需要更完整:

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        越是大型的项目 ,人的因素影响越大,也越难以把控。

        那些决定项目成败的 ,能出力的人,都应该是你的项目组成员 ,还有一些人,你需要TA挂一个虚职,并告诉及时告诉TA进展 。

        我们常常见到一个项目进行了一半,才临时通知或者征调其他部分的人参与,带来的问题就是沟通成本非常的高,过程完全不可控。

        2. 项目第二坑:只有任务,没有成果

        项目的第二步,是要分解项目的具体工作任务,也就是要分配张三、李四分别要完成的工作。在PMP体系中这个叫WBS,在Prince2的体系中则强调的是PBS 。

        最直接的做法,通常都是根据“事项”来分解;毕竟我们需要把任务分配给不同的人来执行,并根据这个任务来估算时间 ,确定进度。

        所以最常见的分解方法就变成这个样子 :

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        但为什么这种分解方式会导致项目做到一半就会人员流失,士气低下呢?

        根源在于这种任务分解只关注了过程,没有确定到底要做成什么样,没有边界和具体的目标 。

        没有验收的标准,没有衡量的指标,所有的人都在忙 ,忙到最后发现客户不买账 。

        比如项目计划里面UI设计的是10天,为什么不是9天或者11天呢?要输出多少个页面?

        科室培训是培训一天就可以了吗 ?还是1小时就可以结束而且所有人都能熟练掌握?用户向要在用户登录模块里面添加一个找回用户名的功能,要不要增加 ?

        诸如此类的问题,随时可能发生。

        因为这种结构是没有办法落实到具体一个功能需要的耗时,所以会不会打乱整个计划就说不太清楚。

        仅仅知道什么时候做什么,对项目的成败而言是没有意义的,关键是结果是什么,没有成果的努力,都是一种自嗨。

        回顾前文 “ 如何用Axure输出高质量的PRD?”,为什么会强调“故事”呢?

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        基于“用户故事”来分解这个项目的任务——构建一套以用户需求驱动的PBS ,才能满足用户的需求,也才能真正估算一个可行的项目计划,双方也才能在一直的目标下推进具体的功能。

        这是一个项目成果的护身符,当任意发起与PBS相违背的变更都会影响到项目的进度,界定了项目的边界,为日后的项目进度规避了许多不必要的障碍。

        因为在这种结构下 ,任何的变更都可能导致整个路径的紊乱 ,从而项目失控。或者为了项目进度,投入更多的资源,或者友好协商推迟项目的进度。

        搞不定人事,理不清边界,是项目失败的最关键因素,作为项目经理(有一些情况下是产品经理直接带项目)务必保持清醒的头脑。

        五、项目节奏和潜在的风险

        我们搞清楚了项目的利益相关方,理清楚了项目的范围,要做什么工作也已经妥当的安排好了专人负责,然而项目依然还会失控。

        原因何在 ?

        展开话题之前,先回顾一下我曾经的一个项目 。

        大概在12~13年左右 ,我有幸参与了一个大型的项目,负责整个平台的搭建,这是一个从0到1的过程,公司和客户都没有过类似的项目实践 。

        这个项目 ,看上去“没有想象中的复杂” ,关于是接单、派单 、回单的过程 ,所有人都很乐观 ,整个项目氛围特别的轻松,3个月拿下完全没有问题。

        然而,随着项目的推进,直到整个项目真正上线 ,前后耗时8个月。

        项目开始前,当你能描绘一个美好蓝图的时候 ,所有人都会被感染,然后所有人都很乐观,被这种情绪感染的时候,每个人都会高估自己的产出 ,并且“有意识的”低估项目的复杂度。

        甚至直到项目被彻底拖垮后,人们并不愿意承认这种盲目自大的情绪最终会给项目造成危害 。

        在项目过程中,所有轻松的氛围下 ,极其容易带来错误的判断,低估项目复杂度,低估项目的资源消耗,在商业行为上会演变为低估项目价值,从而埋下巨大的隐患 。

        所以,对PM来说,关注和把握好团队的氛围非常的重要,深刻的发现和传递项目价值 ,争取相对于的资源是极为重要的。

        1. 合理制定计划,更需恰当的控制节奏

        路易十四把你抓为俘虏,要求你替他做一个计划,为他的城堡添加三个新地牢:

        • 小的地牢很难设计(最快要12周),但是容易建 成(1周)
        • 中等的地牢是典型的 ,设计(5周),施工(6周)
        • 大的地牢容易设计(1周) ,但是很难建造(9周)

        你是这个项目的项目经理,你有一个设计师和一个建筑师 ,但你的设计师不会建造而建造师不会设计 。

        你会怎么制定项目计划?

        在做这个计划前 ,根据我的经验,最好还是重新检查一遍项目的任务分解情况,其中往往暗藏风险,一定要让你的项目是根据结果导向来反推工作事项 ,才能真正估算每一个结果的产出所需要的工作量 。

        正确的工作量预估 ,才能带来可行的项目计划。

        所以,最直接的方式就是“物尽其用”,根据工作量估算直接安排项目计划 ,每个人的工作看上去都安排很饱和 。

        但实际上,整个工程工期太长,资源消耗过多 。

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        既然老板们不同意 ,那我们就必须寻找更好的办法来压缩工期。

        1.加班。

        在项目范围不变的情况下,加班是一个压缩项目周期的途径,但很容易导致项目团队的氛围下降,进而引发质量的下降。

        对于加班 ,我们先不去做过多的讨论 ,但我想强调的是 :项目中要把握好节奏,只加有意义的班,而不以加班为乐。

        2.加人。

        加人这个办法只适合项目早期,而且是越早越好——这其实意味着要在项目的早期争取到更多的资源。

        而在项目过程中,团队稳定才是关键的,往往不等于加人就可以压缩周期 ,甚至只会适得其反。

        把新人直接塞进项目,多少情况下不是好的选择。

        1个妈妈生一个宝宝要10个月 ,10个妈妈生一个宝宝,能不能是一个月?

        还有一种办法,就是通过关键路径法。

        既然造房子要先做好设计,那就可以把设计和建造的工作进行“分离” ,先排出项目事项的优先级 ,说白了就是资源的投入顺序。

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        再找到一条完成整个项目最短可行的任务路径 ,这个叫做“关键路径” 。

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        这个表,就很清晰的知道整个项目需要耗费的时间和资源,也很清晰的看到,什么时候什么资源应该投入项目 。

        也就是这每一个关键节点(里程碑)上都有真正的成功输出 ,管理好每一个关键节点 ,并准备好下一个节点的资源投入 ,项目总体的进度会比较有序可控。

        而且 ,这里有一个非常重要的工作——项目计划一定要实时更新。

        一个过时的计划表,等于项目没有计划。

        2. 风险往往存在于不经意之间,一定要头脑清晰

        假设一个公司有多个项目并行在展开 ,意味着全公司的资源能够交叉的完成的不同的项目,看上去多个项目在并行开展 。

        效率很高 。

        但这种方法却是最难管理的,而且还带来额外的管理风险 。因为我们难以准确的估算每一个工作环节的工作量 ,也难以确保项目进度没有其他因素的占用时间——比如某一个技术难点带来的某个节点的时间延期。

        在这种交叉的项目环境下 ,项目非常容易失控。

        很多时候,我们常能听到说并行开发,实际上是对整个资源的过度自信和对项目的认识不足 。看上去项目都启动了 ,但质量、进度难以保障。

        同时干几件事情的美好愿望最终导致一系列的糟糕局面。

        四处救火的局面 ,应该尽可能的少发生 。一定要能学会找出项目最重要的事情 ,而少去干紧急的事情。

        理论上来说 ,在项目进入到整个阶段,作为项目经理只需要定期检查里程碑的节点输出即可。

        在路易十四的项目中 ,如果你仔细再看这个表,你一定发现建筑工人有两周的空闲时间 。

        两周的时间 ,建筑工人无所事事,整天游手好闲——某一天路易十四巡视工地发现建筑工人睡大觉,还引起设计师的极大不满 。路易十四认为你的计划有问题,浪费资源 。

        所以他直接把资源调走,理由是:建筑师并没有完全被使用或者没有全情投入。

        你怎么办?

        这个就叫项目风险。

        所谓风险,就是不确定的事情。你不能完全的规避风险,有些时候你还需要把一些风险利用起来推动项目的进展 。

        通常的做法是 :在项目的开始阶段列出一个风险清单 ,提醒相关的人员注意可能的状况,防患于未然。

        也就是 ,在项目过程有一项关键的节点 ,就是搞一个正式的仪式——召开一个项目启动会 。讲清楚项目的价值、背景 ,需要的资源和进度,影响的范围以及可能的风险。

        把所有好的结果画一个大饼给所有人,把所有坏的局面讲清楚给所有人。

        这个会上  ,不仅仅是传递信息 ,也是争取资源和权力的关键时刻。那些资源是必须保障的,那些事情是需要经过审批的,那些事情是需要注意,都需要讲清楚。

        必须确保整个项目有一个完整的可行的规则。

        如果你只想做个老好人 ,没有通过一个正式的仪式来获得相应的权限 ,这个项目会变成非常的难以推进 。

        首当其冲的就是需求的变更。

        要知道牵一发而动全身,一个小小的变更 ,甚至会引发整个项目的范围  、进度 、质量、成本的大调整,甚至可能让整个项目处于一个分崩离析的状况。

        六、期望与权力

        任何项目都有一个特色,那就是项目之前群情激昂,至于过程和结果,有的怨声载道,有的劫后余生,万象丛生都很正常,越大的项目故事往往越多。

        在前述的文章里面,我从项目的环境 ,复杂的各方利益,项目的任务分解和任务进度的制定,多个角度分析和阐述了根本原因,这些诱因最终会在项目过程中成为无休止的变更,从而让整个项目陷入不可救药的局面 。

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        所以 ,需求的变动那是家常便饭,没有变更往往不正常,而变更的管理和文档的确实会进一步加剧这种现状。

        变更,分为两种类型,其一是完全不可控因素 ,既是未知的,也是不能改变的。

        比如,公司的经营方向发生了改变,导致项目的预算被削减(增加),从而影响项目的进度。特别是在创业型团队,老板临时改变注意 ,发现某个方向可能更有潜力,调转枪头也未可知 。

        作为一个项目的负责人(执行者),在项目启动之后,唯一的使命就是促使项目成果 ,或者结束项目。对未知和不可控的任何局面,都无需过多的投入精力 。你能做的,就是管理那些可以被管理的内容。

        那些内容是可以被管理的?(如何管理)

        可控的需求变更,无非三大类:

        • 没有细化清晰的项目需求
        • 没有明确清楚的项目边界
        • 存在设计缺陷的软件结构

        深究起来会发现,在项目已经启动后  ,真正与客户直接相关的就是第二条,由于没有明确的项目边界,从而导致用户无休止的提出各种需求和变更。

        而对需求本身的理解和软件的设计,则考验产品经理和整个团队对业务的理解、把握和产品设计能力。这也是为什么我一再强调“用户故事”的原因,而这种变更则需要团队具备极强的消化能力 。

        1. 建立完整的流程变更机制并严格遵守

        项目管理,本质就是对过程的管理 ,也就是要有完备的流程和坚决的执行 ,通过流程来规避可能的风险。

        所以,项目的第一件就是设立一个需求变更机制(如果你还记得之前谈到的项目启动会,项目经理一定要借助这个会议让项目的所有相关方知悉这个流程)。

        以产品经理的视角看待项目,以及如何管理项目(下)(作为产品经理如何做好项目管理)

        这个流程有两个核心观念,也是你一定要能争取到的权力:

        所有人都可以提出需求变更的请求,但只有一个需求的入口——这个入口必须是你 ,如果你争取不到这个权力 ,那整个项目一定会失控。任何都可以提出需求和变更,但你必须作为唯一的接口人和过滤器。

        为此,你应该有足够的心里准备,你需要面对N多方的压力和“撕逼”。甚至 ,为了项目交付的这一终极目标,你需要有不惜得罪人的思想准备。越是大项目 ,越是牵涉多方的项目,风险和协调都会是指数级的放大。

        只有当你具备这个权力的时候,你才能确保项目在预设的轨道上进行,也只有你才可以清晰的回答当前要做什么,能做什么,以及不能做什么。

        只有评审过的需求才可以被执行。

        “不要接到需求就直接动手”。这是项目的至理名言 。

        你需要让整个项目团队,包括上至老板 、直到程序员,也包括外部的客户,都认同、理解并遵守一个基本原则,那就是程序员不直接接受任何非PM的需求,不接收任何非经过评审的需求——所有未经过评审的需求,只可讨论 ,不可执行 ,减少(避免)张嘴就来的非必要 、非紧急、非合理的无效变更。

        切记:不是所有的需求都要接受,也不是所有变更都要立刻修改,一定要能敢于拒绝需求。

        作为产品经理,在需求变更收集上来之后,根据需求提出方的业务进行分析后,邀请需求方 、技术 、设计和测试多个环节进行分析 ,从而判定需求对于项目的影响如何,确定是否接受变更并将变更排列优先级。

        但最终一定要你拍板,这是你需要争取到的第二个权力。你不能最终决定一个需求的价值,对你而言,项目已经离失控不远了。

        当然 ,你可以适当根据需求的范围大小,决定评审的范围,甚至可以决定需要告知的对象 ,这没有标准,需要灵活把握。

        这里其实是有一个例外,那就是技术本身驱动的变更 ;比如有更好的实现方案可以带来性能的提升,这个情况,需要根据整体项目状况,结合技术本身的能力判断。

        一定要争取到合适的权限范围 ,才可能有序的推进项目进程。

        2. 建立完善的文档管理机制并落实到位

        俗话说“好记性不如烂笔头” 。

        项目过程中,文档是极为重要的工具,虽然管理文档费时费力。对于产品经理(创业团队还是兼任项目经理)而言,一定要持续的追踪项目的所有需求文档,变更记录。

        一定要所有的文档,形成版本机制并同步到到团队的没有给成员 ,你可以借助一些在线工具来帮助你完成这项功能。

        要知道 ,但凡失控的项目里面一定有一条就是找不到需求的出路,不知道为什么要这么做,也不知道谁要求这么做,反正就是做了 ,然后谁也讲不清楚由来。

        任何需求,都必须记录在案 ,甭管是否执行,需求的第一个动作就是备忘 ,第二步才是决定是否执行。一定要专人负责需求的梳理,跟踪和进度的反馈 。

        完整的需求变更记录文档将有助于你了解整个项目情况,包括执行的需求 ,被拒绝的需求,你需要一个“需求池”统一管理来自业务端 、技术端的需求,并针对项目中出现的资源、时间等因素可以合理的进行调配。

        3. 张弛有度,控制项目的节奏

        你确定了规则 ,梳理好了边界,甚至也形成了流程。下一步,你得控制好整个产品的推进节奏 ,合理的控制和调节需求、变更的优先级,以及资源的投放力度 :什么时候该投入多少资源,什么时候该做什么事情,什么是关键路径 ,什么是关键角色,你必须门儿清。你得想方设法让你的项目,在你所能控制的范围内进行,一旦超过边界,你可能需要启动后备资源予以干预,而且是在苗头开始之际 。

        你所有的干预手段,预防机制,都是为了确保项目按照一定的规则和秩序推进;也只有基于可控的节奏 ,你才能确保整个过程的质量,以及最终交付的质量。当过程不可控的时候 ,往往结果会很糟糕 。

        最后,一定要深刻的理解,需求是不断的演进和变化的,合理的规避不合理的变更方为上策。

        有些时候 ,无论你怎样控制,由于市场的压力,总会碰到各种“无理”要求 ,如何看待这样的问题,就不是简单的控制问题了,这就需要更高的层面去权衡利弊,如果确实不值得 ,也只能放弃。

        写在系列收尾处

        产品经理作为引路人,就是尽可能的让不确定性的因素 ,变为确定的 ,可被执行的流程 、方案。

        不管你是否兼任“项目经理”的角色,在一个产品从0到1的过程里面,产品经理必须深刻的理解整个过程的艰巨,要能与团队一起致力于整个项目的成功。

        至此,本系列从项目和产品的概念出发,到项目环境的分析,以及对项目过程的几大巨坑一一做了阐述,也许你还需要一些工具,或者模板来提高项目过程管理的效率。

        #专栏作家#

        杜松,公众号:产品微言,人人都是产品经理专栏作家。专注于人工智能方向 ,擅长产品规划和架构设计。

        本文原创发布于人人都是产品经理。未经许可,禁止转载 。

        题图由作者提供

        相关新闻

        联系我们
        联系我们
        分享本页
        返回顶部

          XML地图