15年初，我怀着实现人生小目标的梦想加入了一家创业公司，希望见证公司产品从0到1，从1到10，融资从A到C。但半年后，虽然产品从0发展到1，但由于运营模式的限制，很难从1到10，用户数量不能增加，也没有融资的影子。我开始着急了。再这样下去，自己想当总经理，当CEO，嫁给白富美的小人生目标，都枯萎了。所以，那时候我还是个程序员，渐渐地“多事”起来：过了一会儿我跑到产品经理那里：“看到某篇博客，作者用Axure结合需求文档、产品原型、PRD，等在一起，切换查看不同的文档会很方便，会节省大家一些时间，而且会很高端，我们也来试试？”过了一会儿，我跑去测试：“这次迭代不仅增加了很多模块，还换了很多老接口。要不要来个群测，大家参与，扫一扫在每个模块上，这样可以快速发现问题，减轻您的负担？”过了一会，他跑到项目经理那里：“这个迭代出现了某个问题，以前也有过，我们能不能在迭代之后开个总结会，统计一下遇到的问题，如何解决，这样我们就可以了。”以后向他们学习？”...因为有很多我后来学会了用Auxre和InkKnife做原型；我下班回家测试我开发的应用程序，并为自己提交了错误报告；主持了一些会议，做了记录……因为很多事情，我成了公司里加班最多的人，也是微信步数最多的人（经常跑大厅）；因为很多事情，项目经理走后，公司就没有招人，而是让我top。虽然不得不说当时的项目千疮百孔，一坨屎。但我知道我的转变始于我对项目的看法的改变，而不是职责的改变。所以现在公司批下来了，胳膊可以摆的更宽一些，屁股再脏也可以擦干净。接手项目后，我做的第一件事就是梳理之前想到的项目中存在的问题。找出那些大洞并填补它们以获得立竿见影的效果。1、使用Git之前团队使用svn进行协同开发。主要问题是切换合并分支不方便。结果在实际编码的时候，大家只提了主干上的代码，所以在开发阶段，主干上的代码是拿不到的。随时打包。如果你要测试提前开发好的模块，只能去开发这边问，你在哪里做的？这个功能可以测试吗？现在可以打包吗？导致开发工作经常中断，即使测试拿到包，也会出现不同开发者提供的包相互排斥的情况，即A提供的包只有A的功能，而B提供的包只有B功能。一堆错误。为了解决这个问题，我们尝试用git代替svn，引入gitflow的协同方式。至于效果，我可以用一个词来形容，“爽结”。进入coding阶段，开发兄弟会根据自己实现的功能模块，比如feature-im，feature-moments，从develop分支拉取相应的feature分支。一个功能点开发完成后，可以合并到develop分支，然后删除对应的feature分支，再拉出新的feature继续开发。这样保证了开发分支可以随时打包，根据提交日志，也可以清楚的了解完成了哪些功能。测试只需要从开发和打包脚本更新代码，完全可以自给自足。2.最优估算估算不能随意，估算的准确性直接影响到项目进度安排。那么选择什么估算单位，如何估算呢？估算单位通常包括理想工时、理想工时和故事点数。估计方法包括自下而上估计、专家判断和扑克估计。这里不单独讨论，只介绍我们团队经过实际调整后选择的最合适最有效的估算方法：故事点+专家判断+公式计算。我们的迭代中会有两种情况。一是实现固定需求，需要根据需求预估完成时间；二是确定迭代周期，需要根据时间预估能完成多少需求。所以我们选择storypoints作为估算单位，不仅仅是因为storypointestimation是Agile推荐的，更重要的是它非常适合二次迭代的情况。具体怎么估算呢？以客户端开发为例，根据经验，一个功能模块的开发量与包含的接口数量、接口数量、数据同步方式等成正比，所以只要找到合适的公式，你可以用这些因素来计算开发量，也就是故事点数。我们先定义一个有经验的开发者的参考基准：(1)将界面按照复杂程度分为三个级别，并赋不同的值：级别1最简单，取值为1，比如微信登录界面，通讯录列表界面等；第二层为2，界面稍微复杂一点，开发量是第一层的2倍左右；第三层是4，比如今日头条的首页。通常使用这三个级别。当然，如果有些接口很复杂，计算时可以代入更高的值。(2)接口数直接代入计算。(3)数据同步也按照复杂程度分为三个层次。数据展示直接从服务器获取，与本地无关。1.通过push的方式增量获取数据，需要本地存储和同步，那么就是level3，值为3。定义好这些benchmark之后，就有了计算storypoints的公式：storypoints=a*total接口复杂度+b*接口总数+c*数据同步总复杂度。a、b和c反映了开发时间基准。根据经验，我们将a设为1，b设为0.5，c设为0.6。所以故事点=接口总复杂度+0.5*接口总个数+0.6*数据同步总复杂度。storypoints的预估是一个相对的预估，反映的是需求的开发规模，而不是具体的时间。需要乘以一个系数得到开发所需的时间。同样的功能，如果由熟悉业务的人来做，倍增系数可能是0.8，如果由不熟悉业务、没有经验的新员工来做，倍增系数可能是1.5。通过故事点，我们还可以了解到团队的开发效率，比如分析一个sprint中完成的故事点，是比过去多了还是少了？是什么原因？是团队状态变了，还是公式不准确，需要调整。这种方法虽然没有直接估算人日那么直接和快速，但是在保证估算准确性的同时，能够反映团队的开发速度和迭代规模，能够更好的帮助项目经理把控项目的状态。团队适应后，再也不用担心估算问题带来的规划风险。3.强调需求需求不等于功能。以前，我们产品的用户体验并不好。部分原因是产品需求没有正确传递给开发。开发只知道做什么功能，只关心如何实现功能。好像只要把功能做出来，就相当于满足了需求。特性是解决方案，需求是它解决的问题。PRD评审会在讨论功能技术问题之前，需要先沟通一下为什么要做这个功能，它能带来什么用户价值和公司价值。否则，一旦评审发现功能在技术上难以实现，开发往往只会从功能实现的角度提供其他救国方案，而忽视用户体验，甚至违背需求。就像一个人快饿死了，想吃饭，你让他回家，洗个澡换上正装，然后进西餐厅点甜点。你的方案看似高雅，用餐环??境也有考虑，实则让人等死。就算你能坚持到最后，如果你发现端上来的只是一份不够合牙的甜点，他也说不定会被气死。开发和研究是关于技术的。在讨论解决方案时，很容易挖到技术的角落。这就需要项目经理和产品经理要站在用户的角度，抓住需求的本质，引导讨论的方向。另外，在需求管理方面，做了两件事。一是重新建立需求池，注重跟进。一开始，团队也有一堆需求，但由于过分强调沟通，忽视文档，逐渐流于形式，无法追溯产品需求的真实情况。需求实现的版本号应该记录在需求池中。对于计划在高版本实现的需求，必须在对应的迭代中包含在计划评审中，不能遗忘。在WBS表中，每个Task还应记录相应需求池中的需求编号，便于追溯。二是实施需求冻结。我们必须拥抱变化，但不允许无休止的变化。必须禁止肆无忌惮的需求传播和变更需求变更，否则会严重影响产品的快速交付。在迭代进入coding阶段的2/3期间，需求会被冻结，那些变化大不一定能带来实际价值的变更会直接拒绝拥抱。当然，需求冻结阶段并不意味着拒绝所有的改变。重大的变化，比如苹果审核机制的变化，客户明确要求修改方案等，经过审核都可以接受。4、规范会议方面，主要开展了启动会和站会。启动会议迭代的开始不能以项目经理的口头通知开始，即使团队只有几个人。一定要开个kick-offmeeting，交代清楚迭代的目标，统一大家对实现需求和背景的理解，让大家只知道做什么，不知道为什么，什么是价值。此外，会议给人一种仪式感和严肃感，可以让团队做好心理准备，正式进入新的工作阶段。站会前，团队的站会时间不固定，有时连续3天开，有时3天后开，而且每次的时间很随意，上午一场，下午一场下午。导致大家没有套路习惯，经常在工作中途被打断参加站会，然后站会变成汇报会，各自说明自己做了什么任务，然后很快结束和将他们的屁股放回椅子上。这样的站会就显得鸡肋了。于是我把站会固定在每天早上9点10分，明确站会的目的是跟踪项目进度和问题，同步成员状态。会上，大家要对昨天完成的工作进行说明；今天计划完成的工作；他们面临什么障碍，他们需要什么帮助。这样，团队成员就形成了站立会议的习惯。每天来到公司，他们都会先把这些内容过一遍，同时在站会前解决一些杂事，比如吃早饭。上述这些方面的动作，现在回想起来，在当时是很难推进的。一方面，大家已经习惯了原来的方法。即使有问题，也不容易改掉这个习惯。另一方面，公司长期未融资成功，领导层之间仍存在利益冲突。有同事担心公司走不出去。几个月，因此士气低落。一时不知如何是好，好不容易用软磨硬泡，请了几顿饭才算顺利。虽然新习惯的建立需要一定的学习成本和试错成本，但好在团队适应后，效果大大提升，交付能力变强，产品质量也有保障。不幸的是，屁股被擦干净了。半年过去了，公司因为融资和内部矛盾，依旧遇冷。后来公司的一个领导找了新的合伙人成立公司，拉着我继续负责这个项目。进入新公司从工作到人，还是一个创业团队。虽然有了之前的经验，很快搭建了一个迭代的流程框架，但是我又面临了一个新的挑战：人。如果说前一阶段的项目管理重在管事，那么当我来到一个新的环境，面对彼此不熟悉的新同事时，我就开始把重心放在如何“管人”上。(1)影响他人说到项目管理，谈及范围、时间、成本的铁三角是家常便饭。在我看来，互联网行业有两个重要的角落，一个是“价值”，一个是“人”。做一个项目，简单理解就是找一些人（资源），按照一定的要求协作完成一件事情（过程），最后产出可交付成果（结果）。我们常说的“范围”、“时间”、“成本”，从项目过程的三个方面进行管理和控制，确保把事情做好。“价值”是看项目成果，从公司和用户的利益角度判断，完成的项目是否有价值，确保项目在做正确的事。“人”是项目最重要的资源。团队能否高效组织和协作，将直接影响项目的成败。恰恰是“人”是最难管的。不同于素材，作为项目成员的每个“人”都是新鲜的、充满个性的，有着不同的诉求和看法。难点在于如何影响他人，带动他人去做某事。这里首先介绍Fogg行为模型。福格说，人的行为由动机、能力和触发条件三个要素组成，而这三个要素在行为发生前同时满足。例如，中午你饿了想吃东西。可以下楼吃，也可以叫外卖。这时外面下着雨，你打开外卖APP点了外卖。从Fogg行为模型看你点外卖的行为，它的动机是你饿了，外卖平台是你的能力，触发条件是外面下雨了。产品经理经常使用Fogg行为模型来设计产品，刺激用户对产品采取行动，提高活跃度和转化率。项目经理也可以从这个角度出发，进行团队建设，带动团队成员做事。比如iOS开发小弟A想成长为全栈工程师（动机），工作之余学习Android（能力）。如果项目经理发现项目中Android开发的任务有点重（触发条件），可以适当分配一些给他们。A。又如，新员工缺乏技能，渴望有更多与老员工一起学习的机会，而老员工则渴望建立个人影响力。然后项目经理可以根据日程安排发起内部分享沙龙，让大牛分享自己的技术研究成果。在满足个人诉求的前提下，即使是额外的事情，员工也会发自内心地愿意主动把事情做好。硬性要求，或者请我吃饭来推销，都是短期有效的，是非常糟糕的策略。(2)自我管理有人认为项目管理应该比开发容易得多，因为不需要写代码，只需要关注进度即可。就像我们小时候觉得上学很辛苦，但是大人还是很舒服的，不用写作业。但实际上，项目经理就像父母，而项目就是孩子。世界上有不为孩子操心的父母吗？在过去的一年里，我觉得我的工作时间和地点都没有从工作到下班。当我在微博上看到一张长图或者横图的时候，我立马想到了保存下来发到我的App上看看会是什么样子。进电梯或者坐地铁，第一时间想到打开我们的App看看网络连接是否正常；手机24小时不静音，话费充足，公司群和用户群都在最前面……不过，还是觉得时间不够用。到头来，我做了很多杂七杂八的事情，但我也说不清自己做了什么。《卓有成效的管理者》一书中说“管理者的时间往往只属于别人，不属于自己”，“管理者常常被迫忙于日常运营”。我有同样的感觉。后来，我学会了管理自己，管理自己的时间，管理自己的事情。我首先记录了一周中每一天的时间都花在了哪些地方，以及不同时间点的精神状态。然后找出哪些时间被浪费了，哪些时间段不容易被打扰，什么时候工作状态不好，什么时候精神比较集中，哪些事情是临时处理的，哪些事情是例行公事……然后做出相应的动作完善调整，最终形成舒适的工作节奏。例如，我发现我睡得很晚，这导致我有时起床很晚。我会在路上买早餐，然后带到公司。这让我的第一个半小时的工作毫无成效。为了改善这种情况，我调整了自己的作息时间，保证7点起床，不吃早饭和晚饭在家，留出半小时看新闻和博客，拿出待办事项出门前10分钟列出今天要做的事情，并按优先级排序。这样坚持下来，确实很有效。(3)向上管理刚开始做项目管理的时候，我还没有完全从执行者的角色转变过来。我所知道的就是协调资源，规范流程，排解障碍，促进迭代的顺利进行。对于下属，有一定的管理。对于上级来说，还是需要接受和执行任务，然后在会议上汇报完成情况。看起来不错，但在一个随时可能死去的初创公司，这还不够。创业公司往往是一个小团队，最多也就十几二十个人。每个人都渴望做一个项目。项目经理作为连接过去和未来的纽带，必须与上级有一个积极的沟通过程。需要正确理解和传达Boss对产品的理解。决策，对团队的期望，确保与公司的目标一致，避免将项目带入歧途。当团队遇到障碍时，要及时反馈，寻求必要的资源和帮助。当时我们新公司的老总因为有别的工作，一周才来公司一次。如果只在周会上跟老板汇报，很可能一个月后出来的产品不是他想要的。因为每个人对产品都有自己的理解，即使在创业阶段大家的方向一致，在迭代过程中也会不断有新的想法冒出来，而在需求调整之后，方向可能会偏离原来的目标.因此，我会每隔很短的时间与老板交谈。老板不在公司，打电话就好。不必感到尴尬或害怕打扰老板。其实，老板也希望下属能够及时与自己沟通。当然，还有一些需要注意的地方：1、明确沟通的目的，直奔主题。你的时间宝贵，老板的时间当然更贵；2.选择合适的时间。我们的老板白天忙于其他工作，所以我通常在晚上8:00左右找到他，并尽量立即与他沟通；3.不要报告好消息或坏消息。当你遇到难以应对的困难和挑战时，把它们扔出去，像一颗定时炸弹一样憋在心里；4.给出你的计划。当你发现问题并反馈给领导时，你应该提出你的解决方案，而不是只问怎么办；5.提出你的想法。老板一个人想，创业是不会成功的。当你对产品有自己的想法时，一定要敢于说出来。无论是支持还是反对，你都会感到如释重负，并知道如何继续你的工作。结语这些是我在创业小团队当了两年项目经理的感悟。有的是在填别人的坑，有的是在填自己的坑。虽然公司平台很小，没人教你怎么做，自己摸着石头过河，但是这样的环境让我成长了很多，真的觉得创业不易，我九死一生。
