背景
现有的需求进度管理方式比较传统，通过维护一份文档，由各参与人员在上面反映自己的进展，而一线的开发人员的向上汇报意识往往不强，项目经理想要了解需求的最新进展，需要口头进行询问，并且有部分同学并没有很好地承担起需求owner的责任，可能被问起时才会去找各个参与人员询问项目进度。这种情况使得项目的风险不能及早的暴露出来，在重点项目的推进中，容易出现重大纰漏，延期导致公司利益受损。项目经理需要消耗精力在询问进度上，一线人员也容易在繁杂的业务开发工作后忘记在文档中同步进度，为了达到进度同步，无形中占用了大量的人力。
除了需求进展之外，可能业务方会临时插入紧急需求，需要Team Leader（简称TL）对团队内现有的人力情况进行响应，以确定是否需要协调资源，而用文档的方式来记录需求进展，最大的问题就在于无法直观体现出人力的情况。TL想了解人力情况，得把所有在投入的需求先看一遍，再询问每个需求的进展，从而得出当前大概有多少人力可以释放出来承接新的需求，十分费事费力。在我自己的亲身体会中，每次紧急需求过来，被要求给出当前可释放人力，是一件非常“痛苦”的事，这也为后面做一个需求管理系统埋下了伏笔。
初步构思
既然进度情况的提供方是一线开发，关心进度情况的主要是项目经理，那就分别从一线开发和项目经理的角度出发，看看该如何突破当前的障碍。
对一线开发而言，做完业务开发后，还需要去同步进度，同步进度这件事，对于需求的完成并没有实质进展，可还要花费人力去填表格，有些得不偿失。那如果是很简单地点两下按钮就能完成，对一线开发来讲是不是就变得可以接受了呢。
对项目经理而言，不想去找需求owner询问，也不想等需求owner把进度搞清楚后再来同步，就想有个地方能立马反映出各个需求的进展，并且能看到当前需求卡在了哪个阶段，该阶段的负责人是谁，能立马进行一对一的沟通，来解决掉推进过程中的障碍。
除了一线开发和项目经理外，TL也需要在分配需求时，感知到当前的人力饱和情况，所以需要能有个功能，能让TL看到自己组的成员目前在做哪些需求，分别是什么时间能释放出来。
分析了各个角色想要的内容，其实就有了需求管理系统最基础的雏形。但开发人员的视角毕竟有限，所以这时就该发挥自己的能力，去“勾搭”专业的产品经理，想办法让他们加入到这个项目团队中来。
寻找帮手
在物色可靠的帮手前，也要先想一想该怎样去打动他们，他们愿意来一起参与这个项目，肯定是因为能给他们带去提升。我们当时考虑的方面就是，公司中现有的大多数产品都是很早以前就诞生了，绝大多数的产品经理的工作都是在上面添砖加瓦，从零到一去打造一款产品，似乎是一个比较吸引人的亮点。此外，做产品初期的推广与落地工作，也是我们这个项目的一处亮点。凭借着这两处亮点，我们也顺利地拉到了两位产品同学入伙。
除了需要专业的产品同学来参与之外，我们还需要一些能够将项目搭建起来的同学。同样的道理，我们需要想出一些针对开发同学的卖点，例如，这是一个全栈的项目，可以体会到从零开始搭建一个node项目的过程，另外技术栈可以直接使用最新的版本，不需要考虑历史包袱。能用最新版的第三方库，以及由node来做后端服务，对大多数前端同学来讲都是非常具有吸引力的，我们也顺势邀请到了四位得力的小伙伴加入我们的开发队伍。
产品层面规划
在有产品介入后，这个项目的原型设计就规范了起来。
我们开始和产品探讨更深层次的内容：
· 产品最终的价值是能以透明的方式将需求进度反映出来，并且在使用性上做到足够的便捷。确定最终的价值，有助于后面遇到多方矛盾时，协助我们做出正确的决策
· 业界有现成的项目管理工具，我们做出来的产品，有哪些不可替代的点，使得它能够在团队中推广开来
· 设计这么一款工具，我们面对的对象主要有哪几类，这些对象对于这款工具而言，哪些是生产者，哪些是消费者
· 产品在推广前，应该把重心放在满足哪些角色的需求上，这些角色应该可以对产品的推广起到重要作用
在经过几次对产品价值以及MVP版本范围的沟通后，确定下来MVP版本主要包含的模块有：
· 个人中心（便于快速查看与操作）
· 需求池（需求的统一存放处，支持产品录入需求）
· 甘特图（查看每个需求进度，查看每个一线开发的人力情况）
· 统计（用于查看一整周的项目进展情况）
回到技术落地角度
项目规划
要从头开始做一个新项目，那就必须有一个整体的规划，并能够为每个阶段都制定里程碑。通过完成一个个的里程碑，保证项目最终的完整度。通过倒推的形式，从项目完成上线的时间点为基准，由后往前的确定一个个里程碑的节点，这样就能对项目的进展有一个比较清晰的把控。
技术选型
除了项目维度的一些规划，在前期还需要做好技术的选型。由于是内部发起的一个项目，也是想要顺带提升一下node方面的能力的，所以打算后端部分的内容由前端同学自己用node来写。数据库方面则是用了公司内部应用得已经比较成熟的MySQL，在orm方面，也选择到了社区比较火热的sequelize。在前端方面，也是选择了内部普遍比较熟悉的React框架。
外部团队协作
另外，接入公司内部SSO登录，以及域名申请、与DBA对接数据库实例等事务，也最好在开始之前就打好招呼，保证项目的稳步推进。
考虑对开发人员的成长
结合不同同学的特点对任务进行分配，例如原本没有node经验的同学，可以多分配一些node相关任务，在其自身驱动的情况下，往往对待项目的积极性会提高很多。此外可以将一些比较有挑战的内容分配给有经验的同学。进入开发期后，需要定期进行进度同步会，让每位同学能了解到整个项目的进展，了解自己在项目中扮演的角色，不仅仅是完成分配的任务而已。这样可以提升积极性，也便于把控项目风险。
把控项目进展
在确定开发人员后，需要将每个里程碑，再拆分成可落地的，可回收结果的任务，分配到每个人手上，这样做是为了让每个人都能够认真对待这个项目，让每项任务的进展都能被掌握到。在工具方面，可以利用在线的Excel文档，来对每项任务进行排期，来对每项任务指定开始时间和结束时间，也能很好的反馈出项目的进展。另外，最好再组织每周一次的进度同步会，这样一是能够对项目的进展有更好的了解，二是也能够提升每位成员的参与感。
灰度推广
由于在项目开始前，找过个别人员进行痛点收集，所以这部分同学也是最适合来做项目的内测用户的。并且在前期准备时，就已经讨论过要寻求哪些角色来为我们做推广，所以这个阶段就是验证我们做出来的成品，是否符合了他们的预期，这都是能够从他们对推广的投入程度上感受出来的。另外在灰度推广期内，也要重点收集来自用户的各种建议，产研同学也会由于视角受限，没能考虑到一些方面。
除了收集反馈比产品进行优化之外，我们还需要从产品本身入手，输出产品的使用手册，组织培训等都是有效的宣传方式，降低用户的使用成本，能让用户更容易接受这一新事物。
找到推力
在经过一小段时间的灰度推广后，项目基本已经成型，此时的突破点就是让更多的团队接受这个系统。在这个阶段，就需要在团队中有很大影响人的人员来帮我们的系统进行推广。因为在我们公司，项目经理就是在团队中非常有影响力的一个角色，正因为我们这个系统的就是为了解放项目经理的工作，所以他们是非常乐意配合推广的。大家在开始一个项目时，一定要考虑好推动力的问题。
持续迭代
MVP版本在公司内部推广开后，会陆续收到许许多多的反馈，就会遇到一些特殊场景，例如不同团队的研发流程有一定的出入，未能满足特定的场景等等问题。那作为一个项目owner，就应该确定好优先级。因为我们在很早前就确定过这款产品的最终价值，所以只要把问题往这方面一靠，就很容易做出决定。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
