转型成为项目经理,鬼知道我经历了什么

产品经理就业培训班,12周特训,测、练、实战,22位导师全程带班,200+名企内推,保障就业了解详情

本文作者主要谈谈自己在初创小团队里,作为项目经理两年来的一些感受。希望可以给你带来一定的启发~

15年初,我怀揣着实现一个人生小目标的梦想加入到一家初创公司,希冀能见证公司产品从0到1,从1到10,融资从A到C。可是半年后,虽然产品从0到1是有了,但由于运营模式的限制,从1到10走的很难,用户规模上不去,融资也是没有影子。我开始焦虑起来,这样下去,我要当上总经理,出任CEO,迎娶白富美的人生小目标,可是要萎掉的啊。

于是,那时还是程序猿的我,渐渐”多事”起来:

一会跑到产品经理那里:

“我看到一篇某某博客,作者用Axure把需求文档、产品原型、PRD等等结合到了一起,这样不同文档切换查看就很方便,会节省大家一些时间,还特显高大上,我们也试试?”

一会跑到测试那里:

“这次迭代不仅新增了很多模块,还换血了不少旧接口。我们要不要来一次集体测试,大家都参与进来,对各个模块进行地毯式扫荡测试,这样能快速发现问题,也给你减轻了些负担?”

一会跑到项目经理那里:

“这次迭代中出现了某某问题,之前也发生过,我们可不可以在迭代结束后开展一个总结会议,统计下遇到的问题,是如何解决的,以后好吸取教训?”

……

  • 因为多事,我后来还学会用Auxre和墨刀做原型了;下班回家测自己开发的App,给自己提Bug单;主持一些会议并进行纪要……
  • 因为多事,我成了公司加班最多的人,也是微信步数最多人(经常跑堂);
  • 因为多事,在项目经理离职后,公司没有招人,而是让我顶上了。虽然不得不说,当时的项目千疮百孔,是个脏屁股。但是我知道,我的转型是从自己看待项目视角的转变开始的,而不是职责的转变。所以既然公司给予了认可,手臂就可以挥的更开了,屁股再脏,也能擦得干净。

接手项目后,做的第一件事,就是把我之前思考的项目中存在的问题进行了梳理。把那些大坑找出来,填了能立竿见影出效果。

一、使用Git

此前,团队用svn进行协作开发,最主要问题在于分支的切换合并不方便,以致于实际编码的时候,大家都只在主干上提代码,所以开发阶段,主干上的代码是没发随时打包的。测试要想针对已开发完成的模块进行提前测试,只能经常跑到开发那问,做到哪里啦?这个功能可以测了吗?现在可以打个包吗?导致开发的工作时常会被打断,而且即便测试拿到包,也会出现不同开发给的包是互斥的情况,即A给包有只有A功能,B给的只有B功能,分别测都OK了,最后合到一起又是一坨bug。

为了解决这个问题,我们尝试用git取代svn,并引入gitflow的协作方式。效果嘛,用一个字来形容,“爽的结盖盖”。进入编码阶段,开发兄弟会根据自己实现的功能模块从develop分支上拉出对应的feature分支,如feature-im,feature-moments。一个功能点开发完成,就可以合并到develop分支上,然后删掉对应的feature分支,接着拉出新feature继续开发。这就保证develop分支上是可以随时打包的,根据提交日志,也可以清楚的了解哪些功能是完成了的。测试只要从develop更新代码,脚本打包,完全可以自给自足了。详细了解gitflow,可参看我的这篇总结《使用Git必须要理解的GitFlow》

二、优化估算

估算千万不能随意,估算的准确度直接影响着项目进度计划的安排。那选择什么估算单位,如何进行估算呢?估算单位一般有理想人日,理想人时和故事点数,估算方式有自下而上估算,专家判断和扑克估算等。这里不分别展开讨论,只介绍下,进过实践调整,我们团队所选用的最为合适有效的估算方法:故事点数+专家判断+公式计算。

我们迭代会出现两种情形,一是实现固定需求,需要根据需求估算出完成时间,二是迭代周期确定,需要根据时间估算能完成多少需求。于是选择了故事点数作为估算单位,不仅仅因为故事点数估算是敏捷推荐的,更重要的是很适用于第二种迭代情形。具体怎么估算呢?以客户端开发为例,根据经验,一个功能模块的开发量与包含的界面数量、接口数量、数据同步方式成一定正比关系,所以只要找到合适的公式,就能根据这些因子算出开发量,即故事点数。我们先由经验丰富的开发定义一个参照基准:

(1)把界面根据复杂程度分成了三级,赋予不同数值:

  • 一级最简单,值为1,像微信的登录界面,通讯录列表界面这类;
  • 二级值为2,界面稍复杂点,开发量大概是一级的2倍;
  • 三级为4,像头条的首页。通常用到的是这三级,当然如果有的界面非常复杂,在计算的时候可以代入更高的值。

(2)接口数量直接代入计算。

(3)数据同步也根据复杂度分了三级,直接从服务端获取数据展示,与本地无关,为一级,定义值为0,展示本地数据,和服务端无关,为二级,值为1,通过推送方式增量获取数据,本地需要做存储和同步,则为三级,值为3。

定义好这些基准后,便有了计算故事点的公式:故事点数=a*界面总复杂度+b*接口总数+c*数据同步总复杂度。a、b、c反应的是开发时间基准,由经验我们将a取1,b取0.5,c取0.6。所以故事点数=界面总复杂度+0.5*接口总数+0.6*数据同步总复杂度。故事点数估算是相对估算,体现的是需求的开发规模,不是具体的时间,需要乘上系数才能得到开发所需时间。同样的功能给业务熟悉,技术大牛做,乘的系数可能是0.8,给业务不熟,经验不足的新员工做,乘的可能就是1.5。

通过故事点数,我们还能了解团队的开发效率,例如分析一个sprint完成的故事点数,和过去比是多了还是少了?什么原因?是团队状态变化了,还是公式不准确需要调整。

虽然这种方式没有直接估算人日来的直接快速,但能在保证了估算准确性的同时,反应团队的开发速率和迭代规模,能更好的帮助项目经理把控项目状态。团队适应后,再也不用烦心因为估算问题带来的计划风险。

三、强调需求

需求不等于功能。此前,我们产品的用户体验不好,一部分原因在于产品需求没有正确传递给开发,开发只知道要做哪些功能,只关心如何实现功能。似乎只要功能做出来,就等于满足需求了。

功能是解决方案,需求是其解决的问题。在PRD评审会议讨论功能技术问题前,要先传达清除为什么要做这个功能,能带来哪些用户价值和公司价值。否则一旦评审时发现功能在技术实现上难度较大,开发往往只会站在力求把功能实现的角度给出曲线救国的其他方案,忽略了用户体验,甚至违背需求。好比一个快饿死的人,想要吃东西,你却让他先回家洗个澡换身正装,然后进了西餐店点了份甜点。你的方案看似优雅,还考虑到了就餐环境,但实际把人给等死了,就算能坚持到最后,发现端上的只是一份不够塞牙缝的甜品,可能他也气死了。开发研究的是技术,讨论方案问题时容易在技术上钻牛角尖,这就需要项目经理产品经理具有用户视角,抓住需求本质,引导讨论方向。

另外在需求的管理上,做了两件事,一是重新建立需求池,并注意跟进。一开始团队也有需求池,但由于过分强调沟通,忽略文档,导致渐渐流于形式,无从追溯产品需求的真实情况。需求池中要记录需求实现的版本号,对于计划放到更高版本中实现的需求,一定要在相应的迭代中纳入计划评审,不能遗忘。WBS表中,每个Task也要记录对应的需求池中的需求编号,方便追本溯源。二是实施需求冻结。我们要拥抱变化,但不是允许无休止的变化,无节操的需求蔓延和朝令夕改的需求变更要禁止,否则会严重影响产品的快速交付。在迭代进入编码阶段的2/3时期,会冻结需求,对于改动较大又不一定能带来实际价值的变更直接拒绝拥抱。当然需求冻结阶段也不是拒绝所有变更,重大变革如苹果审核机制改变,客户明确要求修改方案等等,经过评审后然而可以拥抱。

四、规范会议

会议方面,主要是启动会议和站会进行了开刀。

启动会议

迭代的启动,不能是由项目经理一声口头通知就开始了,哪怕团队就几个人。一定要有启动会议,在会议上交待清除迭代目标,统一大家对实现需求及其背景的认识,避免大家只知道要做什么,却不知为何做,有什么价值。此外,会议会给人一种仪式感,严肃感,能使团队做好心理准备正式进入新一阶段的工作状态。

站会

之前,团队的站会时间不固定,有时是连续3天都举行,有时是隔了3天才举行,而且每次时间很随意,一会早上,一会下午。导致大家没有例行的习惯,也常常在工作中途被打断去参加站会,然后站会成了汇报会,各自交待做了哪些任务,便赶紧结束,把屁股挪回椅子上。这样的站会成了鸡肋。所以我把站会固定在了每日早上9点10分,明确站会目标是为了跟踪项目进度和问题,同步成员状态。会上每个人应交待昨天完成的工作;今天计划做的工作;面临什么阻碍,需要什么帮助。这样团队成员形成站会习惯,每天到公司都会脑子先过一下这些内容,同时在站会前解决一些杂事,如吃早饭。

上面说的这几个方面的动作,现在回想起来,当时推进的都很困难。一方面,大家都已对原来的方式方法形成习惯,即便存在问题,打破习惯也不是易事,另一方面,公司迟迟未能融资成功,领导间还存在利益矛盾,一些同事担心公司走不了几个月,因而士气低落。那时不知道该怎么办,最后用软磨硬泡加请了几顿饭的方式,让事情顺利进行起来。虽然新习惯的建立,需要一定的学习成本,试错成本,好在团队适应后,效果改善的非常明显,交付能力变强,产品质量也有保证。遗憾的是,屁股算是擦干净了,半年后,公司还是因为融资和内部矛盾问题,凉了。之后公司一位领导找到新的合伙人成立公司,把我拉去继续负责项目。

由事到人

进入新的公司,依然是初创团队,虽然有了之前的经验,迭代的流程框架很快就搭建起来,但我面临了新的挑战:人。如果说前一阶段的项目管理,重点在管事,那来到新的环境,面对互相不熟悉的新同事,我开始重点关注到如何“管人”。

(1)影响他人

说到项目管理,老生常谈范围、时间、成本铁三角,而在我看来,互联网行业里,还有两个角非常重要,一个是“价值”,一个是“人”。做项目,简单理解就是找来一些人(资源),按照一定要求协作完成一件事(过程),最终产出可交付成果(结果)。我们常说的“范围”、“时间”、“成本”,是从项目过程的三个方面去管理把控,确保把事情做对。“价值”看的是项目成果,从公司利益和用户利益角度去审视判断,所完成的项目是否具有价值,确保项目做得是对的事情。“人”是项目最重要的资源,团队能否整齐划一,高效协作,直接影响着项目的成败。而恰恰“人”是最难管理的,不同于物资,作为项目成员的每个“人”都是鲜活的,富有个性的,有不同诉求和见解的个体,难就难在如何影响他人,驱动他人去做一件事情。

这里先介绍下Fogg行为模型。Fogg说人的行为由动机,能力和触发条件这三要素组成,这三个要素同时都满足了行为才会发生。举个栗子,到中午你肚子饿了要吃饭,可以下楼吃,也可以叫外卖,此时外面下着小雨,于是你打开外卖App,叫了外卖。从Fogg行为模型去看你叫外卖吃的这个行为,它的动机是你饿了,外卖平台是能力,触发条件是外面下着小雨。

产品经理就常常会利用Fogg行为模型去设计产品,刺激用户在产品上产生行为,提高活跃度、转化率等。项目经理也可以从这个角度出发,进行团队建设,驱动团队成员去做事。比如,iOS开发兄弟A想成长为全栈工程师(动机),工作之余学习了Android(能力),那项目经理如果发现项目中Android开发的任务有点重(触发条件),就可以适当分配些给A。再如,新员工技能水平不足,渴望和老员工有更多的学习机会,老员工渴望建立个人影响力,那项目经理可以根据时间安排开展内部的分享沙龙,让大牛分享他们的技术研究成果。在满足个人诉求的前提下,即便事情是额外多出来的,员工也会发自内心的愿意主动去把事情做好。命令式要求,或者像我之前通过请吃饭来进行推进,都只是短期有效,实属下策。

(2)自我管理

有的人以为,做项目管理应该要比开发轻松许多,因为不用写代码,就盯盯进度。就像我们小时候觉得上学好辛苦,还是大人舒服,不用写作业。但实际上,项目经理就像父母,项目是孩子,天下有哪个爹妈不为孩子操碎了心呢。最近一年来,我觉得我的工作时间和地点是不分上班下班的。在微博上看到一个长图或横图,立马想到保存下来发到自家App上看看显示效果怎样;进入电梯或坐地铁,立马想到打开我们的App看看网络连接正不正常;手机24小时不静音,话费充的足足的,公司群、用户群统统置顶…..可是,依然会觉得时间不够用。一天下来,事情杂七杂八做了很多,可也说不上来到底做了些啥。《卓有成效的管理者》一书中说“管理者的时间往往只属于别人,不属于自己”,“管理者常常被迫忙于日常运作”,我很感同身受。后来,我学着进行自我管理,管理自己的时间,管理事务的处理。

我先记录了自己一周每天时间所花的地方,以及不同时间点的精神状态。接着找出哪些时间是浪费掉的,哪些时间段不容易被打扰,什么时候工作状态不佳,什么时候精神更专注,哪些事情是临时处理的,哪些事情例行公事的…..然后做出相应的改善调整,最终形成舒服的工作节奏。比如我发现自己睡得晚,导致有时候起得迟,会在路上买早饭带到公司吃,9点半之前的状态也不佳,10点钟还习惯性的去蹲大号。这使得我开始工作的头1个半小时效率是不高的。为了改善这个情况,我调整作息,保证7点起来,在家解决掉早饭和大号,留半小时看看资讯、博客,出门前10分钟拿出ToDo List看看今天要做哪些事情,排个优先级。这样坚持下来,的确很有效果。

(3)向上管理

刚做项目管理的时候,自己还并没有从一个执行者的角色完全转变过来。只知道要去协调资源,规范流程,解决阻碍,推进迭代顺利进行。对下是有一定的管理了,对上依然是接受任务,执行任务,接着就是在会议上汇报完成情况。似乎没什么问题,但在随时都有可能死掉的初创公司,这还远远不够。初创公司往往是小团队,上上下下一共没十几二十个人,大家孤注一掷一做一个项目,项目经理作为承上启下的角色,对上也要有个主动沟通的过程,要正确理解传达Boss对产品的决策,对团队的期望,确保公司上下目标一致,避免把项目带跑偏。团队遇到障碍也要及时反馈,寻求必要的资源和帮助。

当时,我们新公司Boss由于还有别的工作在身,平时一周只来公司一次。如果我仅在周会上向Boss汇报工作,很可能一个月后出来的产品不是他想要的。因为每个人对于产品都有自己的理解,即便启动阶段大家方向一致,但在迭代过程中会不断有新的idea出来,需求在经历一次次调整后,方向很可能就偏离了最初的目标。所以,我会每隔一小段时间就找老大聊聊。老大不在公司,就电话说。大不用觉得不好意思,或者怕打扰Boss,其实Boss也希望下属能及时找他沟通。当然也有些要注意的地方:1.明确沟通目的,直蹦主题。你的时间很宝贵,老板的时间当然更贵;2.选择合适的时间。我们老大白天要忙于别的工作事务,所以一般我是在晚上8点左右找他,尽量一次沟通到位;3.不要报喜不报忧。遇到难以应对的困难和挑战,抛出来,憋着就是定时炸弹;4.给出你的方案。发现问题反馈给领导时,要拿出你的解决方案,而不是只问怎么办;5.提出你的想法。创业绝不是靠老板一个人思考就能成功的,当你对产品有自己的想法时,要敢于说出来。无论是获得支持还是反对,你都会释怀,知道该如何继续工作。

结束语

上面聊得这些都是自己在初创小团队里,作为项目经理两年来的一些感受。有的是填别人的坑,有的是填自己的坑。虽然公司平台很小,没人教你该怎么做,一切靠自己摸石头过河,但这样的环境让自己成长很多,也真切感受到创业的不易,九死一生。

目前我已离职,正在寻求新的工作机会,如果你有项目管理职位提供,且坐标在上海,欢迎联系我。

 

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

题图来自 Pexels,基于 CC0 协议

赞赏是对原创者的最大认可
6人打赏
评论
欢迎留言交流
  1. 开发想转产品,请教

    回复
  2. 平面想转产品,表示看不懂

    回复
  3. 1024

    回复
  4. 我也是经历了从开发转项目经理,但是又想做产品,😔

    回复
  5. 学习了

    回复
    1. 。。

      回复
  6. 我有准备去初创团队~可能会有相同的体会

    回复
  7. 能加个微信吗?大神

    回复
  8. 写有很棒,很实在。

    回复
  9. 来深圳吧。我招待你。

    回复
    1. 啤酒和龙虾么

      回复
  10. 学习了,我现在就是很难,互联网公司6个人,我就是运营这块,看到这篇文章有点思路了,谢谢

    回复
  11. 基本上蛮真实的。可以看的出,作者挺拼的。由此也想到我自己。

    回复
    1. 都是项目狗🐶哈

      回复
  12. 良心好文,感触颇多

    回复