创业公司在项目管理中的难点和解决方案

2017-09-13 10:23:00

本文想跟大家分享下创业公司的项目管理经历，希望在创业道路上的小伙伴也能有所收获。

创业公司的项目特点和难题

说起创业公司，在创业初期面临的一个比较大的痛点，莫过于如何实现高效低成本的项目管理模式 – 小步快跑、快速迭代？如何将研发团队有效组织起来，在可控、可视化的范围类进行产品版本迭代更新？现如今，大多数互联网创业公司都追崇者敏捷开发的思路，甚至很多成熟型大公司都沿用这种开发管理模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。“ Fix time, Flex Scope”是敏捷迭代的核心理念。

在创业公司，很多创业者初期在项目管理上都使用任务看板、每日站会、计划纸牌等手段进行项目管理，这也是比较常见的项目管理手段。因为这种方式会更加便捷，没有“套路”，能让人一目了然、快速看到现在在发生什么，未来将要发生什么。但是这里会存在以下几个难题：

人工线下操作、记录粘贴耗费时间和精力；
修改删除麻烦，不方便随时更新；
历史记录看不到，无法回顾历史数据；
子任务拆分不方便，拆分后无法修改；
对人员管理不便，随着团队扩张，操作越来越困难。

我们在创业道路上是如何做的呢？

最近两年在创业的道路上，经历了从0到1的团队搭建，直到研发团队超过40人，包括产品、设计、研发、测试。整个研发团队按照一个项目的节奏跑自己的产品，曾经也拆分过小项目组跑其他项目。不论是大项目组跑也好，小项目组跑也好，都是以产品为核心导向进行功能迭代开发。40多人都在一个办公区域（基本不存在异地沟通问题），整个项目采用敏捷开发、版本迭代的过程在跑，产品版本迭代将近30次，基本保持每1-2周一次迭代的过程。

虽然跑的很快，但开始我们也存在一些问题创业公司共同的项目管理问题。

整个够格产品分为android/ios/网页端/PC端等多系统多平台。但后台人员是公用的，基本是1对多的关系。这种多终端协作开发的方式需要一套成熟的项目流程进行管理，整个团队也尝试过用任务看板等线下的方式进行项目研发管理。然而依然会碰到下面几个问题

耗费时间和精力：最初大家还是愿意接受线下手工的方式写字操作各自任务记录，后面每人每日都要花费大量时间手写任务列表，进行卡片粘贴。到最后整个团队都觉得这样写起来很麻烦，逐渐放弃了手动写的过程，转而进入线上工具的管理。
更新删除麻烦：团队每个人每天都需要对今天完成的任务进行更新，多数时候当大家拿起笔去更新时重写内容时就开始愁苦。写了一天代码要下班了还得重新写字更新今日任务，尤其碰到需要删除重新的需求任务更是崩溃。
历史记录找不到：每天只能看到当天完成了什么，昨天完成了什么。当整张墙贴的密密麻麻时，想找一个人任务时，眼睛都要瞅半天。此时大家真想有个“搜索”功能。尤其在每期迭代结束后，统计每个人任务进度时，简直要崩溃。此时多希望有个工具能帮我做这件事。
子任务拆分不方便：产品需求永远都会拆分子任务，研发在开发时也需要拆分更细的子任务。此时自己用人工的方法来做就显得特别麻烦，尤其拆好的子任务要做拆分修改时，更是麻烦。
人员管理麻烦：我们当初整个看板名字是固定的，随着后续有新同事进来，旧同事离开，整个看板都需要更新。这时就需要把看板上的所有任务全部清除后再重新布局。

后面尝试转移到线上工具管理后，整个研发团队的迭代节奏明显加快许多，原先将近两周才完成的迭代、现在相同任务量缩短到一周。每日晨会、站会时间也由半小时缩短到15分钟。研发团队每日下班的时由原先花费将近10分钟更新今日任务的时间，缩短至1-2分钟搞定下班回家。从这个现象可以看出一个有效的工具能帮助研发团队提高效率。

在产品迭代流程方面，我们采用周期的研发节奏，整个产品研发的迭代顺序大致是需求收集 – 需求分析 – 功能策划 – 原型设计 – 需求评审排期 – 开发阶段 – 测试阶段 – 上线阶段，这里实现一个完整的迭代。

对项目时间管理，本来采取的是线下excel表格管理，后面也逐渐转移线上工具化管理。

下面就详细讲解下在产品迭代项目的每个阶段我们都做了什么。

需求收集阶段

产品部门有自己的需求收集和分析方法，我们会在建立一个“需求池 ”，产品会将收集来的各方面需求收录到池子里。需求池的需求主要来源于市场、用户、竞品、老板、产品经理。我们会用线上工具将需求进行分类管理，比如APP端需求、运营需求、网页端需求等等。并定期对需求池中的需求进行合并删减。

在需求收集阶段，产品部会和运营、市场、商务等同事进行详细沟通，确保了解每一个需求的目的和意义。

需求分析阶段

对建立的“需求池”，产品对定期进行评估，评估也是基于产品内部的讨论，在讨论前一定要确保了解每一个需求背景和意义，不要一个人拍脑袋把需求拍出来。我们崇尚以产品为公司核心导向，所以产品经历的决定权很重要，直接影响公司战略走向。所以对于需求池的需求进行详细分析时，一定多基于用户、市场和公司角度出发。

对需求池的需求分析主要做两件事：

整理需求池内容，从优先级和重要性两个纬度进行产品功能筛选。
确定需求池优先级和重要性后，进行需求标记，创建新迭代并关联需求。

确定要做的需求后，就需要开始细化需求。这时候就考验产品经理的功底了。

功能策划阶段

在确定要做的需求后，为了保证需求在研发阶段的完整性和可分工。需要在功能策划阶段就要对产品需求进行模块拆分和任务拆分。确保需求的颗粒度与研发时间评审的模块一致，如果不知道怎么拆分，需要提前与研发同学沟通。

在任务拆分后，为了保证及时同步给研发同事，需要将子任务先在线上工具关联到迭代，目的主要有两个：

可以让研发同时知道下一期功能范围和模块，提前进行技术框架搭建或技术预研。
方便产品同事（多人负责一个模块）的协作设计。

在线上工具上，可以对需求进行关联，比如父子关系，方便连续查找，树形结构更容易一目了然。

原型设计阶段

原型设计阶段最难管理的是版本问题，这里包括两类文件的版本管理。

产品经理的原型稿件
设计师的高保真设计稿

首先，原型稿修改的次数远远会大于设计稿，主要因为一些需求会在评审后或者开发中才会发现问题。修改或者补充的。再者，我们的创业公司原型稿上大都有交互说明一起的，一般修改/补充文字说明比较多。而且原型稿的使用对象更多是研发和测试同学，所以每一次版本记录和修改后同步都是巨大的工作量。做好的方法是建立统一的svn或线上管理工具，如果有修改可以实时同步。

设计稿也是类似，一般设计稿改动的频率较小，但我们当时为了保持同步也会统一以版本命名，上传到在线管理工具上，统一管理。确保信息同步及时，研发过程中不至于使用版本不同而导致提测是几个端的功能效果不同。

需求评审排期

需求评审我们一般会有3次评审，之前有过两次，但发现在开发时存在很多重复沟通，很多需求研发同事都没有搞明白。分析原因主要是需求评审会上时间短，很难短时间就搞懂所有逻辑。所以后面换成了3次，添加了一次“预评审会”。

在第一次“预评审会”上，不讨论需求细节，只讨论框架和流程。让大家知道下个迭代要做什么，先在脑海中有概念。一般预评审会的时间会在上个迭代的测试阶段，这样在距离这个迭代结束的下次评审会前，大家有时间提前带着框架和流程去熟悉下需求细节，这样就可以带着问题进行第二次需求评审会评审了。同时也可以在这个评审会上遇到一些技术改动比较大的问题，或者技术难点提前周知产品，评估看是否要对需求进行调整。

第二次评审会上，属于正式评审，会把产品需求从每个细节进行一次评审。每个人都带着问题来听，没问题的地方快速过，有问题的地方着重讨论确定的方案，这样就节省大量时间。因为都是线上需求管理，遇到问题直接当场标记，会议后针对标记的地方进行修改。有记录，而且还不会遗漏。

第三次评审会，主要对第二次需要修改的地方过一遍，顺便加深研发同学对需求的理解程度。一般第三次评审会会在第二次评审会的第二天。我们一般选择第二次在前一天下午，第三次在第二天上午。利用晚上的时间修改需求，这样就可以节省项目时间。

紧接着就是第二天下午的项目排期了，会直接在线上工具已经拆分好的子任务上进行人员分配，包括开发人员、测试人员，之后进行开发周期的安排。在线上管理的目的是分配好人员后，大家就能自己登录后看到负责的任务，同时系统也会自动计算出开发周期。

开发阶段

开发人员按照每个子任务的排期时间，在每个需求的时间节点前完成开发即可。在开发周期内会安排几种会议：

每日晨会：每天早上全员参加，围绕昨天进度，今日安排，遇到问题三个话题展开。每人大约几十秒时间，不讨论详细解决方案。遇到问题的同事或者需要跟xx对其的人在晨会后以小组的形式单独详细讨论。晨会的目的是做到明确每个人的安排，同步及知道要解决的问题。
每周例会：每周的例会一般安排在周五下午。1个小时左右，主要同步项目整体进度，集中解决规则及制度性的问题。
临时会议：一般遇到开发过程中的重大问题，需要即可解决的，才会组织临时会议。一般是问题的干系人及老大们参加。
分享会议：每周会安排一次项目成员的分享会，由一个人准备，分享自己的所闻所感。建立团队间乐于分享的友好氛围。

开发阶段，会项目的管理主要是线上工具，同步及沟通的工具一般都是线上管理平台及在线聊天工具。因为我们都在一起办公，遇到问题吼一声，人就过去了。