转型
15年初我怀揣着实现一个人生小目标的梦想加入到一家初创公司希冀能见证公司产品从0到1从1到10融资从A到C。可是半年后虽然产品从0到1是有了但由于运营模式的限制从1到10走的很难用户规模上不去融资也是没有影子。我开始焦虑起来这样下去我要当上总经理出任CEO迎娶白富美的人生小目标可是要萎掉的啊。
于是那时还是程序猿的我渐渐”多事”起来。一会跑的产品经理那“我看到一篇某某博客作者用把需求文档产品原型PRD等等结合到了一起这样不同文档切换查看就很方便会节省大家一些时间还特显高大上我们也试试不”一会跑的测试那“这次迭代不仅新增了很多模块还换血了不少旧接口我们要不要来一次集体测试大家都参与进来对各个模块进行地毯式扫荡测试这样能快速发现问题也给你减轻了些负担”一会跑的项目经理那“这次迭代中出现了某某问题之前也发生过我们可不可以在迭代结束后开展一个总结会议统计下遇到的问题是如何解决的以后好吸取教训”……因为多事我后来学会用和墨刀做原型了下班回家测自己开发的App给自己提Bug单主持一些会议并进行纪要……因为多事我成了公司加班最多的人也是微信步数最多人经常跑堂因为多事在项目经理离职后公司没有招人而是让我顶上了虽然不得不说当时的项目千疮百孔是个脏屁股。但是我知道我的转型是从自己看待项目视角的转变开始的而不是职责的转变。所以既然公司给予了认可手臂就可以挥的更开了屁股再脏也能擦得干净。
擦屁股
接手项目后做的第一件事就是把我之前思考的项目中存在的问题进行了梳理。把那些大坑找出来填了能立竿见影出效果。
一.使用Git
此前团队用svn进行协作开发最主要问题在于分支的切换合并不方便以致于实际编码的时候大家都只在主干上提代码所以开发阶段主干上的代码是没发随时打包的。测试要想针对已开发完成的模块进行提前测试只能经常跑到开发那问做到哪里啦这个功能可以测了吗现在可以打个包吗导致开发的工作时常会被打断而且即便测试拿到包也会出现不同开发给的包是互斥的情况即A给包有只有A功能B给的只有B功能分别测都OK了最后合到一起又是一坨bug。
为了解决这个问题我们尝试用git取代svn并引入的协作方式。效果嘛用一个字来形容“爽的结盖盖”。进入编码阶段开发兄弟会根据自己实现的功能模块从分支上拉出对应的分支如--。一个功能点开发完成就可以合并到分支上然后删掉对应的feature分支接着拉出新feature继续开发。这就保证develop分支上是可以随时打包的根据提交日志也可以清楚的了解哪些功能是完成了的。测试只要从develop更新代码脚本打包完全可以自给自足了。详细了解gitflow可参看我的这篇总结《使用Git必须要理解的GitFlow》
二.优化估算
估算千万不能随意估算的准确度直接影响着项目进度计划的安排。那选择什么估算单位如何进行估算呢?估算单位一般有理想人日理想人时和故事点数估算方式有自下而上估算专家判断和扑克估算等。这里不分别展开讨论只介绍下进过实践调整我们团队所选用的最为合适有效的估算方法故事点数专家判断公式计算。
我们迭代会出现两种情形一是实现固定需求需要根据需求估算出完成时间二是迭代周期确定需要根据时间估算能完成多少需求。于是选择了故事点数作为估算单位不仅仅因为故事点数估算是敏捷推荐的更重要的是很适用于第二种迭代情形。具体怎么估算呢以客户端开发为例根据经验一个功能模块的开发量与包含的界面数量、接口数量、数据同步方式成一定正比关系所以只要找到合适的公式就能根据这些因子算出开发量即故事点数。我们先由经验丰富的开发定义一个参照基准
1把界面根据复杂程度分成了三级赋予不同数值一级最简单值为1像微信的登录界面通讯录列表界面这类二级值为2界面稍复杂点开发量大概是一级的2倍三级为4像头条的首页。通常用到的是这三级当然如果有的界面非常复杂在计算的时候可以代入更高的值。
2接口数量直接代入计算。
3数据同步也根据复杂度分了三级直接从服务端获取数据展示与本地无关为一级定义值为0展示本地数据和服务端无关为二级值为1通过推送方式增量获取数据本地需要做存储和同步则为三级值为3。
定义好这些基准后便有了计算故事点的公式故事点数a*界面总复杂度b*接口总数c*数据同步总复杂度。a、b、c反应的是开发时间基准由经验我们将a取1b取0.5c取0.6。所以故事点数界面总复杂度0.5*接口总数0.6*数据同步总复杂度。故事点数估算是相对估算体现的是需求的开发规模不是具体的时间需要乘上系数才能得到开发所需时间。同样的功能给业务熟悉技术大牛做乘的系数可能是0.8给业务不熟经验不足的新员工做乘的可能就是1.5。
通过故事点数我们还能了解团队的开发效率例如分析一个sprint完成的故事点数和过去比是多了还是少了什么原因是团队状态变化了还是公式不准确需要调整。
虽然这种方式没有直接估算人日来的直接快速但能在保证了估算准确性的同时反应团队的开发速率和迭代规模能更好的帮助项目经理把控项目状态。团队适应后再也不用烦心因为估算问题带来的计划风险。
三.强调需求
需求不等于功能。此前我们产品的用户体验不好一部分原因在于产品需求没有正确传递给开发开发只知道要做哪些功能只关心如何实现功能。似乎只要功能做出来就等于满足需求了。
功能是解决方案需求是其解决的问题。在PRD评审会议讨论功能技术问题前要先传达清除为什么要做这个功能能带来哪些用户价值和公司价值。否则一旦评审时发现功能在技术实现上难度较大开发往往只会站在力求把功能实现的角度给出曲线救国的其他方案忽略了用户体验甚至违背需求。好比一个快饿死的人想要吃东西你却让他先回家洗个澡换身正装然后进了西餐店点了份甜点。你的方案看似优雅还考虑到了就餐环境但实际把人给等死了就算能坚持到最后发现端上的只是一份不够塞牙缝的甜品可能他也气死了。开发研究的是技术讨论方案问题时容易在技术上钻牛角尖这就需要项目经理产品经理具有用户视角抓住需求本质引导讨论方向。
另外在需求的管理上做了两件事一是重新建立需求池并注意跟进。一开始团队也有需求池但由于过分强调沟通忽略文档导致渐渐流于形式无从追溯产品需求的真实情况。需求池中要记录需求实现的版本号对于计划放到更高版本中实现的需求一定要在相应的迭代中纳入计划评审不能遗忘。WBS表中每个Task也要记录对应的需求池中的需求编号方便追本溯源。二是实施需求冻结。我们要拥抱变化但不是允许无休止的变化无节操的需求蔓延和朝令夕改的需求变更要禁止否则会严重影响产品的快速交付。在迭代进入编码阶段的2/3时期会冻结需求对于改动较大又不一定能带来实际价值的变更直接拒绝拥抱。当然需求冻结阶段也不是拒绝所有变更重大变革如苹果审核机制改变客户明确要求修改方案等等经过评审后然而可以拥抱。
四.规范会议
会议方面主要是启动会议和站会进行了开刀。
启动会议
迭代的启动不能是由项目经理一声口头通知就开始了哪怕团队就几个人。一定要有启动会议在会议上交待清除迭代目标统一大家对实现需求及其背景的认识避免大家只知道要做什么却不知为何做有什么价值。此外会议会给人一种仪式感严肃感能使团队做好心理准备正式进入新一阶段的工作状态。
站会:
之前团队的站会时间不固定有时是连续3天都举行有时是隔了3天才举行而且每次时间很随意一会早上一会下午。导致大家没有例行的习惯也常常在工作中途被打断去参加站会然后站会成了汇报会各自交待做了哪些任务便赶紧结束把屁股挪回椅子上。这样的站会成了鸡肋。所以我把站会固定在了每日早上9点10分明确站会目标是为了跟踪项目进度和问题同步成员状态。会上每个人应交待昨天完成的工作今天计划做的工作面临什么阻碍需要什么帮助。这样团队成员形成站会习惯每天到公司都会脑子先过一下这些内容同时在站会前解决一些杂事如吃早饭。
上面说的这几个方面的动作现在回想起来当时推进的都很困难。一方面大家都已对原来的方式方法形成习惯即便存在问题打破习惯也不是易事另一方面公司迟迟未能融资成功领导间还存在利益矛盾一些同事担心公司走不了几个月因而士气低落。那时不知道该怎么办最后用软磨硬泡加请了几顿饭的方式让事情顺利进行起来。虽然新习惯的建立需要一定的学习成本试错成本好在团队适应后效果改善的非常明显交付能力变强产品质量也有保证。遗憾的是屁股算是擦干净了半年后公司还是因为融资和内部矛盾问题凉了。之后公司一位领导找到新的合伙人成立公司把我拉去继续负责项目。
由事到人
进入新的公司依然是初创团队虽然有了之前的经验迭代的流程框架很快就搭建起来但我面临了新的挑战人。如果说前一阶段的项目管理重点在管事那来到新的环境面对互相不熟悉的新同事我开始重点关注到如何“管人”。
一.影响他人
说到项目管理老生常谈范围、时间、成本铁三角而在我看来互联网行业里还有两个角非常重要一个是“价值”一个是“人”。做项目简单理解就是找来一些人资源按照一定要求协作完成一件事过程最终产出可交付成果结果。我们常说的“范围”、“时间”、“成本”是从项目过程的三个方面去管理把控确保把事情做对。“价值”看的是项目成果从公司利益和用户利益角度去审视判断所完成的项目是否具有价值确保项目做得是对的事情。“人”是项目最重要的资源团队能否整齐划一高效协作直接影响着项目的成败。而恰恰“人”是最难管理的不同于物资作为项目成员的每个“人”都是鲜活的富有个性的有不同诉求和见解的个体难就难在如何影响他人驱动他人去做一件事情。
这里先介绍下Fogg行为模型。Fogg说人的行为由动机能力和触发条件这三要素组成这三个要素同时都满足了行为才会发生。举个栗子到中午你肚子饿了要吃饭可以下楼吃也可以叫外卖此时外面下着小雨于是你打开外卖App叫了外卖。从Fogg行为模型去看你叫外卖吃的这个行为它的动机是你饿了外卖平台是能力触发条件是外面下着小雨。
产品经理就常常会利用Fogg行为模型去设计产品刺激用户在产品上产生行为提高活跃度、转化率等。项目经理也可以从这个角度出发进行团队建设驱动团队成员去做事。比如iOS开发兄弟A想成长为全栈工程师(动机)工作之余学习了Android(能力)那项目经理如果发现项目中Android开发的任务有点重触发条件就可以适当分配些给A。再如新员工技能水平不足渴望和老员工有更多的学习机会老员工渴望建立个人影响力那项目经理可以根据时间安排开展内部的分享沙龙让大牛分享他们的技术研究成果。在满足个人诉求的前提下即便事情是额外多出来的员工也会发自内心的愿意主动去把事情做好。命令式要求或者像我之前通过请吃饭来进行推进都只是短期有效实属下策。
二.自我管理
有的人以为做项目管理应该要比开发轻松许多因为不用写代码就盯盯进度。就像我们小时候觉得上学好辛苦还是大人舒服不用写作业。但实际上项目经理就像父母项目是孩子天下有哪个爹妈不为孩子操碎了心呢。最近一年来我觉得我的工作时间和地点是不分上班下班的。在微博上看到一个长图或横图立马想到保存下来发到自家App上看看显示效果怎样进入电梯或坐地铁立马想到打开我们的App看看网络连接正不正常手机24小时不静音话费充的足足的公司群、用户群统统置顶…..可是依然会觉得时间不够用。一天下来事情杂七杂八做了很多可也说不上来到底做了些啥。
《卓有成效的管理者》一书中说“管理者的时间往往只属于别人不属于自己”“管理者常常被迫忙于日常运作”我很感同身受。后来我学着进行自我管理管理自己的时间管理事务的处理。
我先记录了自己一周每天时间所花的地方以及不同时间点的精神状态。接着找出哪些时间是浪费掉的哪些时间段不容易被打扰什么时候工作状态不佳什么时候精神更专注哪些事情是临时处理的哪些事情例行公事的…..然后做出相应的改善调整最终形成舒服的工作节奏。比如我发现自己睡得晚导致有时候起得迟会在路上买早饭带到公司吃9点半之前的状态也不佳10点钟还习惯性的去蹲大号。这使得我开始工作的头1个半小时效率是不高的。为了改善这个情况我调整作息保证7点起来在家解决掉早饭和大号留半小时看看资讯、博客出门前10分钟拿出ToDoList看看今天要做哪些事情排个优先级。这样坚持下来的确很有效果。
三.向上管理
刚做项目管理的时候自己还并没有从一个执行者的角色完全转变过来。只知道要去协调资源规范流程解决阻碍推进迭代顺利进行。对下是有一定的管理了对上依然是接受任务执行任务接着就是在会议上汇报完成情况。似乎没什么问题但在随时都有可能死掉的初创公司这还远远不够。初创公司往往是小团队上上下下一共没十几二十个人大家孤注一掷一做一个项目项目经理作为承上启下的角色对上也要有个主动沟通的过程要正确理解传达Boss对产品的决策对团队的期望确保公司上下目标一致避免把项目带跑偏。团队遇到障碍也要及时反馈寻求必要的资源和帮助。
当时我们新公司Boss由于还有别的工作在身平时一周只来公司一次。如果我仅在周会上向Boss汇报工作很可能一个月后出来的产品不是他想要的。因为每个人对于产品都有自己的理解即便启动阶段大家方向一致但在迭代过程中会不断有新的idea出来需求在经历一次次调整后方向很可能就偏离了最初的目标。所以我会每隔一小段时间就找老大聊聊。老大不在公司就电话说。大不用觉得不好意思或者怕打扰Boss其实Boss也希望下属能及时找他沟通。当然也有些要注意的地方1.明确沟通目的直蹦主题。你的时间很宝贵老板的时间当然更贵2.选择合适的时间。我们老大白天要忙于别的工作事务所以一般我是在晚上8点左右找他尽量一次沟通到位3.不要报喜不报忧。遇到难以应对的困难和挑战抛出来憋着就是定时炸弹4.给出你的方案。发现问题反馈给领导时要拿出你的解决方案而不是只问怎么办5.提出你的想法。创业绝不是靠老板一个人思考就能成功的当你对产品有自己的想法时要敢于说出来。无论是获得支持还是反对你都会释怀知道该如何继续工作。
结束语
上面聊得这些都是自己在初创小团队里作为项目经理两年来的一些感受。有的是填别人的坑有的是填自己的坑。虽然公司平台很小没人教你该怎么做一切靠自己摸石头过河但这样的环境让自己成长很多也真切感受到创业的不易九死一生。
