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

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 协议