团队创业项目目前具有哪些资源，团队创业项目的资源有哪些，创业团队的资源

hwyzw

    来源：（@）

    网址：

    前言

    创业公司有个很重要的环节，那就是在有限的时间与资源条件下，将产品需求转化为产品，这其实就是研发以及项目管理。毫无疑问，此阶段开发人员是主角。那么身为PM，要是把项目管理过程当作做产品的过程，是否应该多思考一下，怎样面向开发人员去优化整个研发过程与项目管理流程呢？本文讲述了提高研发过程中开发人员效率的方法，即通过优化开发环境搭建、代码管理、需求生命周期管理、开发任务分配和追踪、项目整体进度管理来实现，还讲述了通过持续集成和交付让开发中的问题更早暴露，以及通过合理的测试反馈工具让开发人员最快定位和解决问题。

    一点前提条件和背景

    我印象里有好多关于产品与开发因进度问题起争执的段子，我从开发岗位转到了产品岗位，因而对这两方面都有一定了解。我认为，研发效率并非仅是研发人员自身的技术能力与工作效率，而是涵盖整个研发过程以及项目管理流程的效率。不过我自己所理解的高效研发与项目管理存在两个前提：

    公司内各团队拥有大家认可的沟通协作方式，所有流程和工具都是供人使用的，只有团队主动沟通协作才能提升效率，这也是我在这个系列第一篇写“（点击查看）”的缘由 。

    产品经理的任务是让研发团队开发正确的任务，这就需要尽量清晰的需求定义。我遇到开发延期或交付失败，很多时候是因为自己对需求认识不够，以及开发中有过多需求变更。只有表达清楚、考虑完善的需求定义，才能保证随后的研发和管理不是在做无用功。聊到创业团队研发方面的实践，还要说一说项目管理方面的实践，在此之前，先得讲一下我们在研发和项目管理中所用到的工具，以此作为背景：

    最后进入主题了，本篇所包含的是我们在研发过程、项目管理流程中的情况，以及在其中为优化开发人员体验所做的一些努力，现在试着从各个环节进行总结，由于不同团队的研发流程和项目管理存在差异，各位可以挑选感兴趣的部分来查看：

    研发环境的搭建，涵盖了怎样引导新开发者入门，以及如何构建日常开发环境。

    代码的管理：包括源码管理，Code 和组织公共库

    需求在研发中存在生命周期管理，它涵盖功能需求清单，涉及功能需求定义，还包括其中开发任务项的分配以及状态管理。

    项目进度的管理：包括如何通过有效的执行敏捷开发

    产品处于研发阶段时会进行测试与反馈，其中涵盖在产品测试和反馈里的一些经验分享，还有工具分享。

    持续集成，持续发布，涵盖针对Web搭建持续集成和发布的方法，以及针对iOS搭建持续集成和发布的方法。

    一、研发环境的搭建

    如何让团队新的开发者尽快上手

    对于新的开发人员而言，通常会经历开账号、装系统、配环境、跑代码这些流程。我自己发觉每次都会低估这些工作所需的时间，有时不经意间一两天就过去了，代码却还没跑起来，一两周过去了，产品目前的功能也还没弄清楚。我归纳出了两点加快这个进度的办法：

    1.加快能让代码跑起来的速度

    有很多能够加速的环节，其中一个较为重要的是自动构建代码，这意味着开发人员编写代码后，借助简单的构建脚本就能实现代码依赖安装、代码编译以及单元测试运行，也就是我们通常所说的让代码跑起来。以Web为例，可通过npm的脚本完成npm依赖的安装，接着利用gulp完成代码的构建与运行，这同样是持续集成的基础。

    2.对产品功能需求和目前进度的了解

    保持尽量清晰的需求定义在背景中所说的用途就在此。新开发人员可通过浏览产品需求文档了解产品功能。我们的做法是，将“系统功能汇总(含已排期未完成功能)”作为一个Query，在上列出所有功能的PRD。有两种视图可供选择，一种是像下图这样按产品线，能看到每个产品线的功能：

    另一个视图是按照功能完成的时间进行归类，通过这种方式能够知道以前每个版本都做了哪些功能，还能了解未来有什么功能正在安排之中：

   

    如何方便开发人员进行日常开发调试

    目前对于Web开发而言，在一般构建过程中，代码会进行混淆操作，会进行合并操作，会进行CDN地址替换操作，还会进行CSS生成等操作，这使得在Dev服务器上调试极为不便。我们采取的解决办法是，在web的Gulp构建流程中进行不同的Build，本地调试时使用未混淆的代码，搭配本地搭建的环境，连接Dev数据库，以此方便Web开发人员进行本地调试。

    二、代码管理

    首先，最重要的是代码必须使用源码管理工具，我们一直使用的是Git。代码的查看与管理都在此工具上，能够查看代码、合并分支、打版本tag等。不过，这对开发者并非必须使用。所有这些操作都能用git解决。有两点我认为需要关注：

    1.怎么让开发人员高效的使用第三方库

    在项目开发过程中去抽象公共组件，使用第三方库能够提高开发效率，使用开发工具也能够提高开发效率，不过需要做好模块管理，还要做好版本管理。有时会碰到开发人员引入不合理的依赖，有时会碰到学习成本高的组件，如此一来，每个参与开发的人员都要增加学习成本。

    针对不同技术栈，存在相应的一套可使用工具，我们在Web、iOS等方面都有自己习惯的选择，若需添加新组件或替换正在使用的组件，都可在共同讨论后加入，如此能避免出现重复或后期产生分歧。

    2.如何做新功能开发的代码管理

    只要是多人进行开发，并且是多功能同时开展开发，就都无法避免要思考如何对代码进行管理，通常有两种方式，目前我们依据自身需求定义了一个Git模型，针对复杂的新功能创建来进行开发：

    虽然我个人更喜欢另一种方式，不过实践起来需要模板开发，还需要构建方式上的配合，Git对开发来说上手更简单，所以暂时没有更换，建议去看一下Baidu FEX的Flag功能发布控制，去考虑自己适合哪一种。

    三、需求在研发中的生命周期管理

    对于开发人员而言，开发工作通常围绕具体功能需求展开，背景中提及的“清晰的需求定义”是研发的主要输入，由负责的PM主导需求（User Story）的状态更新，本节以一个功能需求（User Story）为例，先呈现一个时序图，用以说明单个功能在研发中的生命周期状况：

    从功能需求（User Story）的时间线来看，能看出它分为以下几个状态：

    创建PM后，协作编写需求文档（新），进行需求确认，进入开发中（进行中），处于待测试（等待测试）状态，已完成且可以上线，完成且可以关闭

    可以划分为需求确认，需求开发，需求测试和上线三个阶段：

    1.需求确认

    对于需求文档的编写与确认，不同团队的方式存在差异。我的理解是，它涵盖功能需求的前置条件与后置条件，包含用户流程和规则，还有完整的产品交互原型以及经过评审确认的设计稿。下图展示的是在上定义的一个功能需求（User Story）

    2.需求开发

    需求定义清晰之后，开发之前，整个开发团队要参与进来，确认任务的分配。任务分配遵循一定原则，那就是把功能需求对应的任务按照树形结构进行分解，在敏捷开发里，这一分解方式有个学名，叫做“Work   (WBS)”，要确保其中每个任务都具备可开发性，并且是能够测试的。下图展示的是一个功能需求对应的任务的实例：

    具体到其中一个单独的任务项，里面会有它所属的功能需求，有当前的状态，有优先级，有任务指派的开发者，有任务所属的产品线，有一个简单的任务描述，有所属的预计开发时间和结束时间，有任务当前的状态和进度等等。如下图所给的就是一个Task的实例：

    从“需求在研发中的生命周期”的时序图上能看出，其对应的任务的生命周期是怎样管理的，还能知道前端和后台之间的任务协作是如何完成的，简单总结一下，Task有以下几种状态：

   

    新建，处于开发中状态，等待代码复查（目前仅需被检查代码），等待测试，等待反馈，完成（可上线），关闭（上线后可关闭）

    开发人员主要负责在开发时更新自身任务状态，状态看似较多，若开发每次都需登录修改会很累，实践过程中我们引入了优化方法：

<p style='margin-bottom:15px;color:#555555;font-size:15px;line-height:200%;text-indent:2em;'>    <pre style="margin: 30px 8px 0px; text-align: left; background-color: rgb(50, 50, 50); color: rgb(97, 180, 146);"><code>组件，Abc，（问题编号：Id），加，消息，（问题状态）。</code></pre></p>
    这是任务所属的模块，例如ios、web等，它与Build Job绑定，一旦有对应模块的代码提交，就会触发相应部分的持续集成和交付。操作的是什么是Abc，例如Add、Mod(ify)、Ref()、Fix、Rem(ove)和Rea()，其目的是让代码提交信息看起来比较清晰。对应的Task的Id是什么是(Issue #Id)，这么做是为了将其和task绑定在一起。

    提交以后就会自动更新的Task：

    3.需求测试和上线

    单个功能需求下面对应的所有任务开发完成后，由PM进行测试并反馈，确认与PRD一致后，PM可将其更新为“待测试(Wait for test)”。“待测试(Wait for test)”意味着该功能需求能发布到测试服务器(Test )，供业务团队及测试用户参与测试 。当测试不存在问题后，若为Web功能，便依据上线计划上线到相应位置；若为App，那么按照版本计划，有可能需要在固定时间发布，或者等待几个功能完成后一同发布。

    这里讲的是单个功能需求的研发周期，测试和上线更多是在整个项目这个Scope上讨论，所以针对测试和上线的部分，在后面持续集成和发布的部分会详细说明。

    四、项目进度的管理

    顺着上面的思路，当你拥有针对单个需求的研发流程后，整个项目的管理便是管理所有需求，安排优先级以及迭代计划，接着对所有需求实施同样的研发流程管理。敏捷开发中将一个迭代周期称作一个，每次进行一次产品发布，随后回顾其中的问题，规划下一个的开发任务，如下图：

    我们的实践并非完全等同于Scrum，不过较为相近。我们的迭代周期是一周，能确保每周至少进行一次同步。项目的进度管理在Scrum实践中，实际上是在它的三个阶段完成的：

    在产品体验优化中存在一个理论，即在所有直接接触用户的方面进行体验优化。我个人认为这三个属于项目进度管理范畴。在这三个方面，PM会与开发人员或Owner进行接触。若此处体验不佳，将会影响项目管理。实际上，我们总结的优化方案较为简单，是通过项目管理工具来实现功能需求和开发任务的“看板”。

    我会建立一个来存放平时积累下的需求，这样在上面可以直接以这些作为产品以后可以去做的内容，这些需求能按照功能模块来组织，然后在上面一起规划出下一个要完成的功能：

    Daily  

    每日的站立会议是粒度最细的会议，其目的是追踪每个人每天的任务情况。在这里，我们要建立一个名为“本周需要完成的任务(开发人员)”的Query。将这个Query里的任务按照不同类别，如网站、后台管理、iOS等来归类，以此作为我们的看板。

    开发人员只需按前面提及的提交代码方式更新任务状态，无需额外工作就能汇报每日进度。每天早上上班时，所有开发人员聚集在一起，按不同类别逐一梳理任务项，同步昨天完成的任务，确定今天的任务，有疑问的在早会解决。

    对于项目进度而言，Scrum的看板管理会把任务项依据状态进行分类，如此一来，能更清楚地看出哪些已完成，哪些尚未开始，可通过变换Query来达成：

    一般不只是研发团队参与，为辅助相关业务人员和测试用户，我们通过建立一个叫“本周已经完成的任务(业务人员)”的Query准备上线的功能，里面是已完成的功能，将已完成功能按某种方式归类，PM可据此测试已完成功能，全部完成测试提交到测试服务器后，相关业务人员和测试用户也可按这些任务试用，节省每次都要介绍更新内容的时间。