本文想和大家分享一个创业公司的项目管理经验，希望创业路上的小伙伴们也能有所收获。 　　

　　# #创业公司的项目特点和问题 　　

　　说起初创企业，初创初期最大的痛点之一就是如何实现高效、低成本的项目管理模式—— 　　

　　跑得快，迭代得快？如何有效地组织研发；团队在一个可控的可视范围类中迭代更新产品版本？如今，大多数互联网初创公司都遵循敏捷开发的思想，甚至许多成熟的大公司也遵循这种开发管理模式。敏捷开发是一种以人为中心的、迭代的、循序渐进的开发方法。" 　　

　　固定时间，灵活范围”是敏捷迭代的核心思想。 　　

　　在创业公司中，很多创业者在项目管理初期就采用了任务看板、日常会议、计划卡片等手段，这也是项目管理的常用手段。因为这种方法会更方便，没有“套路”，人们一眼就能看到现在正在发生的事情和未来将要发生的事情。但是会出现以下问题： 　　

　　*手动离线操作，录制粘贴费时费力； 　　

　　*修改删除麻烦，不方便随时更新； 　　

　　*历史记录不能看，历史数据不能审核； 　　

　　*拆分子任务不方便，拆分后不能修改； 　　

　　*人员管理不方便。随着团队的扩大，操作变得越来越困难。 　　

　　# #在创业的道路上，我们是如何做到的？ 　　

　　最近两年，在创业的路上，经历了从0到1的团队建设，直到有40多个研发；研发团队，包括产品、设计、研发；d和测试。整个研发；d团队按照一个项目的节奏运行自己的产品，曾经拆分小项目团队运行其他项目。无论是大项目团队还是小项目团队，都是面向产品的功能迭代开发。一个办公区40多人(基本不存在异地沟通问题)，整个项目都是以敏捷开发和版本迭代的方式运行，产品版本迭代近30次，基本保持1-2周迭代一次的流程。 　　

　　虽然跑得很快，但一开始我们也遇到了一些问题，创业公司常见的项目管理问题。 　　

　　整个合格品分为安卓/ios/Web /PC等。 　　

　　多系统多平台。但是后台人员是公开的，基本上是一对多的关系。这种多终端协同开发方式需要一套成熟的项目流程进行管理，整个团队也尝试过通过任务看板等线下方式来管理项目研发。但是，我们仍然会遇到以下问题。 　　

　　*最初在耗费时间和精力：,大家还是愿意接受线下手工书写来操作自己的任务记录，后来大家花了很多时间写任务清单、贴卡片。最后整个团队都觉得这样写很麻烦，逐渐放弃了手工写的过程，转向了线上工具的管理。 　　

　　*更新删除麻烦：团队中的每个人都需要每天更新今天完成的任务。很多时候，当大家拿起笔更新重写内容的时候，就开始感到难过。写了一天的代码，又要重新写，更新今天的任务，特别是遇到需要删除新任务的时候。 　　

　　*历史记录找不到：每天只能看到当天和昨天取得的成就。整面墙都贴满了，想找人做任务的时候还要看半天。这个时候，每个人都很想拥有一个“搜索”功能。尤其是每次迭代结束，统计每个人的任务进度时，简直会崩溃。这个时候，我希望有一个工具可以帮我做到这一点。 　　

　　*子任务拆分不方便：'s产品需求将始终分为分子任务和研发；在开发过程中，d也需要被分成更精细的子任务。这时候手动去做特别麻烦，尤其是需要拆分修改被拆解的子任务的时候。 　　

　　*人员管理麻烦：,我们整个广告牌的名字在一开始就被固定了。新同事进来，老同事离开，整个广告牌都需要更新。此时，有必要在重新布局之前清除看板上的所有任务。 　　

　　后来尝试转移到线上工具管理后，整个研发的迭代节奏；d团队显然要快得多，花了近两周时间完成的迭代现在缩短到了一周。每天的晨会和常务会时间也从半小时缩短到15分钟。当研发；d团队每天下班，更新今天的任务需要将近10分钟，缩短到下班回家1-2分钟。从这一现象，我们可以看出，一个有效的工具可以帮助研发；团队提高效率。 　　

　　在产品迭代过程方面，我们采用周期研发的节奏；d、整个产品研发的迭代顺序；d大致是需求收集-需求分析-功能规划-原型design-需求评审排期-开发阶段. 　　

　　在测试阶段上线阶段,实现了完整的迭代。 　　

　　对于项目时间管理，最初采用的是线下excel表格管理，后来逐渐转移到线上工具管理。 　　

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

　　需求收集阶段 　　

　　这个部门有自己的产品。 　　

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

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

### 需求分析阶段

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

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

1. 整理需求池内容，从优先级和重要性两个纬度进行产品功能筛选。

2. 确定需求池优先级和重要性后，进行需求标记，创建新迭代并关联需求。

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

### 功能策划阶段

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

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

1. 可以让研发同时知道下一期功能范围和模块，提前进行技术框架搭建或技术预研。

2. 方便产品同事（多人负责一个模块）的协作设计。

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

### 原型设计阶段

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

1. 产品经理的原型稿件

2. 设计师的高保真设计稿

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

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

### 需求评审排期

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

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

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

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

紧接着就是第二天下午的项目排期了，会直接在线上工具已经拆分好的子任务上进行人员分配，包括开发人员、测试人员，之后进行开发周期的安排。在线上管理的目的是

分配好人员后，大家就能自己登录后看到负责的任务，同时系统也会自动计算出开发周期。

### 开发阶段

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

* 每日晨会： 每天早上全员参加，围绕 昨天进度，今日安排，遇到问题 三个话题展开。每人大约几十秒时间，不讨论详细解决方案。遇到问题的同事或者需要跟xx对其的人在晨会后 以小组的形式单独详细讨论。晨会的目的是做到明确每个人的安排，同步及知道要解决的问题。

* 每周例会： 每周的例会一般安排在周五下午。1个小时左右，主要同步项目整体进度，集中解决规则及制度性的问题。

* 临时会议： 一般遇到开发过程中的重大问题，需要即可解决的，才会组织临时会议。一般是问题的干系人及老大们参加。

* 分享会议： 每周会安排一次项目成员的分享会，由一个人准备，分享自己的所闻所感。建立团队间乐于分享的友好氛围。

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

### 测试阶段

测试同事会提前根据需求编写测试用例，测试用例也会在开发前进行评审。测试用例会更新到线上工具，让每个人都能看到。测试时也会根据评审的用例进行，防止带入主观判断。碰到的测试问题也会自动提交到bug池，关联给对应的开发人员，确保不遗漏bug修改。

因为创业公司测试人力少，我们一般都是全员找bug，可以设置一些有奖活动。比如谁找的bug多，谁就可以获得奖励。

### 上线阶段

当所有任务测试

完成后，即可上线。上线前产品、运营都需要列出对应的负责内容。建立checklist，逐一检查是否有遗漏问题。一般版本是否上线会由测试邮件发布测试质量报告，并提出是否可以上线的建议。产品会根据邮件反馈进行判断是否可以上线。这样既有了双保险，由能一封邮件就完成上线同步工作，提高上线效率。

除了研发团队外，公司还将运营和商务也划归到项目中统一管理。为了让各部门信息互相同步，让技术同学了解业务帮助他们更好基于业务层面进行开发，让业务同学更了解技术难处，能提出更加合理的需求，用开发的语言跟开发同事沟通。

以上是从创业经历的实战项目总结出来的创业公司项目管理流程，并不一定适用于每一家创业公司，但其中一些方法不论是大公司还是小公司都可以尝试使用。

作者：水度力子，一年咨询顾问，两年产品经验。曾就职世界500强外企，两年创业经历。产品，运营，咨询分析。

本文由 @水度力子 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pixabay，基于 CC0 协议