前言
不知道作为开发的你有没有感觉一味地埋头开发却收效甚微。在公司时常加班至深夜，但有时又闲得怀疑人生。好不容易开发完成的功能迟迟无法上线，甚至还没有上线就回炉重造。这样一些问题在各个公司中多多少少都会存在，那么问题到底出在哪里呢？
本文是一篇偏实践性质的文章，主要是从一些前辈身上学到东西的总结以及我个人在的项目实践中的经验收获，希望能帮埋头做技术的同事解答一些代码以外的疑问。相关主题的文章是站在开发的角度来谈项目管理，后续还会有项目中分支管理、组织架构、敏捷开发等相关的文章，敬请期待
目录
- 从需求到项目
1.1. 一个需求的诞生
1.2. 版本规划
1.3. 需求设计
1.4. 可行性分析/内部评审 - 项目筹备
2.1. 团队组建
2.2. 环境协调
2.3. 项目排期
2.4. kick off - 项目进行时
3.1. 需求澄清
3.2. 设计阶段
3.3. 开发/用例编写阶段
3.4. 测试/Bug修复阶段
3.5. 需求交付
3.6. 一些建议 - 项目尾声
4.1. 验收阶段
4.2. 预发版阶段
4.3. 项目发版
4.4. 项目总结
4.5. 线上问题跟进 - 总结
从需求到项目
一个需求的诞生
我们可以将一个项目理解为若干个需求的集合，一个项目的形成首先要有需求，那么一个需求是怎么形成的呢。我们大部分技术可能会觉得这是产品经理的问题，并不太关心。但是理解一个需求的形成，对于技术与产品经理的沟通尺度的拿捏，对于需求的取舍，对于了解产品动机等都大有益处
需求来源
我们做的所有需求都不是凭空捏造的，每一行代码的背后都有其对应的现实意义，那么产品的需求是怎么来的呢，有这么一些方面：
- 用户：用户访谈、线上问卷、AB测试、用户日志分析等。需求是服务用户，从用户中来当然要回到用户中去，这是我们产品需求的重要来源，但可能并非主要来源
- 运营：运营反馈、客户反馈、运营策略等。如果技术对于一个公司来说是造枪造炮的人，那么运营就是使枪使炮的。一个好的运营团队会鞭策产品不断的提升进步。
- 老板：俗称“老板需求”，“老板们”不管是从产品的从零到一还是在产品的迭代过程中，总会有很多千奇百怪的想法，特别是对于初创公司，这可能是主要的需求来源
- 技术：很多需求其实开发或者测试发起的，比如系统改造、系统重构、架构优化等都是由技术团队提出的
- 其他：公司其他职能部门如财务、行政有时也可能提出一些内部项目，他们是发起者同时也是用户
需求分析
产品经理拿到需求后也不是照单全收，需求要经过一系列的定量/定性分析，专业的产品经理会根据收集到的数据代入分析模型中，分析用户诉求、用户场景等等因素并提炼出确确实实可以实现的产品需求。需求提炼、需求分析很多是产品的专业技能，这里不再展开。总之，产品经理将一个一个现实社会中需要解决的问题转换为用互联网的方式去解决，一个需求就算形成了
需求池
一个粗略的需求形成后会被丢入需求池中等待被召唤，需求池中每一个需求都有需求的详细信息，包括需求来源、需求场景、涉及模块、紧急性、重要性等等。根据以上各个需求的特性，需求池中的需求会在下一个环节 —— 版本规划中被重新提取出来
版本规划
版本规划往往是由产品总监、公司领导等决策层根据需求的重要性和紧急性同时结合市场需求确定的。版本规划需要确定下一个版本或几个版本所包含的具体需求。一个版本可以视为一个项目或一个项目的组成部分，因为一个大的项目可能需要多个版本的迭代才能完成。而一个版本的周期是根据公司具体情况确定的，互联网公司主流的发版频率大概是15天/次，周二周四发版比较常见
需求设计
版本规划出炉后，一个版本内通常会包含一个或多个需求，需求会被分配到各个产品经理/助理手中。产品经理/助理会对初步形成的需求进行详细设计，形成并输出MRD、BRD、PRD等产品相关文档
可行性分析/内部评审
产品经理的需求形成后会进行一轮或多轮的产品部内部评审，其中需要有技术人员的参与，完成评审后的需求需要被证明是确实可行的，并且敲定需求实现方案
至此，从无到有，从需求到项目，一个新的的项目就形成了
项目筹备
项目有了，但是还不能立即开始，磨刀不误砍柴工，慢即是快。项目开始前还需要经过一系列的筹备工作。这些筹备工作本身可能跟需求跟技术都没有太大关系，但是却是项目按时上线、项目质量的重要保障
团队组建
项目进行前需要进行团队人员的组建。首先要有一个人来全权对整个项目负责，这个人就是项目负责人。项目负责人不一定要求职位高低，不一定精通业务，可以是产品、开发、测试，但是一定要有良好的统筹协调能力，他是项目的第一责任人，对整个项目质量及按时上线负责
项目负责人有了过后，他需要负责招募其他项目成员。如后端开发、前端开发、移动端开发、测试人员等。项目负责人作为一个组织架构以外的角色需要到各个部门或小组沟通协调，明确参与的项目人员及各项目成员进入项目时间
为了全项目组成员信息的实时同步，最好立即建立起可靠的信息连接，可以是邮件组、微信群、钉钉群等。完成以上工作一个项目团队就算组建完成了
协调环境
除了人员上的准备，项目负责人还要负责开发、测试环境的协调。一个公司的硬件资源通常是有限的，如果存在多个项目并行的情况不能及时腾挪出合适的环境提供给项目开发，也可能影响后续的项目排期，所以需要重视
项目排期
项目负责人拿到产品的PRD文档且完成团队组建后就可以进行项目排期了。项目排期主要可以分为以下几个阶段：
- 需求估时：项目负责任可以以多种形式进行项目估时，可以将各个需求发送到各个小组中进行独立估时，完成后进行汇总
- 项目协调：各个小组估时可能不尽相同，还可能遇到项目组成员同时兼顾多个需求、项目组成员进组时间不一致、需求估时时间过长等等问题。这个时候项目负责人就要动用协调功能，比如增加人力、调整需求优先级、<del>安排加班</del>、与公司领导协商等
- 项目计划：完成以上工作就可以拟定项目计划了，需要注意的是项目计划一旦制定就需要严格执行，尽量不要修改，如果要修改也需要走子流程进行项目计划的修改，同时会影响项目上线。所以项目计划的制定一定要谨慎，最后预留一定的风险时间。且负责人最好频繁跟进项目，及时调整开发节奏
- 确立关键节点：完成项目计划后还需要提取出几个关键的时间节点，公司决策层可能需要了解，时间节点包括项目启动时间、转测时间、QA时间、上线发版时间等
kick off
kick off 源自于足球，就是开球、发球的意思。后来，这个足球术语逐渐引入到商业中，引申为“开始做某事”的意思。完成了一系列的前期项目筹备，一个项目就可以正式开始了。kick off 的形式可以是一场 kick off meeting 也可以是一封发送项目成员同时抄送相关领导的 kick off 邮件。总之，kick off 的发出标志筹备的结束，项目的正式开始
项目进行时
项目的进行大致可以分为以下五个阶段：需求澄清、设计阶段、开发/用例编写阶段、测试/Bug修复阶段、需求交付
需求澄清
需求澄清通常是以产品、开发、测试、项目负责人共同参与澄清会议的形式进行的。作为整个项目周期中难得的需要全体参与的会议其重要性不言而喻，一次好的需求澄清就像一场扫雷可以为后续的项目开发排掉很多的坑或者雷，节约时间成本、人力成本。需求澄清会议很重要，但我认为澄清会议只是澄清需求的结果，并非澄清需求的过程。具体来说，我认为需求澄清应该经过以下几个流程才算是一次完整的需求澄清。
- 需求熟悉：在项目筹备的同时，当项目负责人确定项目人员后就需要将需求发放给相关人员进行需求熟悉，需求熟悉的过程中需要开发或者测试人员发现问题、提出问题。这一工作需要在需求澄清会议之前就进行而不是在澄清会议过后，因为如果是在澄清会议上或者之后才发现提出问题，会降低会议质量和效率，产品经理也可能无法及时作出解答，最终导致多次需求澄清，延误项目计划
- 影响点评估：个人认为是需求澄清中最重要的一个环节，需要所有项目相关人员参与评估本次需求或者项目的影响点。因为作为产品经理，可能会因为各种的主观或客观原因不能完全列举需求的影响点。这时候就需要所有的项目人员来把关，筛选影响点。为什么说这一步最重要，因为根据我个人的观察，项目中的纠纷或者导致项目延期的原因很多时候都是因为影响点的考虑不全，很多影响点可能到开发了一大半才发现，而且短时间内无法解决完成，那么就会导致项目延期
- 技术预研：在充分了解需求后，就可以进行技术预研了，涉及重点难点可以提前作准备。如果遇到部分需求设计性价比不高也可以作记录并在需求澄清会议上提出
- 需求澄清会议：完成了以上准备工作，就可以由项目负责人发起并组织需求澄清会议了。会上不只是产品经理的主场，在产品经理完成需求讲解后，所有人都应该充分表达疑问并解决疑问，这是对项目负责，也是对自己负责。如果是重大需求或者疑问点较多，就需要项目负责人组织第二次或第三次需求澄清会议，如果问题较少，可以提出问题跟踪表并指定问题的跟进人，解决后向项目组内同步解决方案。需求澄清的目的就是需要所有项目相关人员都充分理解、认同需求，为项目的后续工作排雷，所以可以进行多次澄清，但个人建议最好不要超过三次
设计阶段
在充分理解、认同需求后，就可以进行相关的设计工作了。设计阶段对于开发来说包含影响点评估、数据库设计、系统设计、接口设计等等。对于测试人员来说就是制定相关的测试方案
设计阶段通常是由两个重要的会议作为结束，分别是接口评审会议、用例评审会议。
- 接口评审：接口评审需要前后端、客户端的开发人员参加。后端开发人员完成数据库及接口设计后由相关开发人员评估接口的合理性和可行性
- 用例评审：测试人员在充分理解需求后会提出测试方案，确定冒烟测试用例、自动化测试方案、是否需要回归测试等内容。在测试人员完成设计后同样需要进行评审，防止功能的漏测。用例的编写应该与开发是同步的，所以用例评审通常会放到开放阶段中，转测之前。
开发/用例编写阶段
进入开发阶段，代码的编写、自动化测试编写、用例编写都是同步进行的。如果项目计划足够科学，项目成员就可以按部就班的进行开发了。但是实际情况往往跟项目计划是有出入的，这就是项目负责人存在的意义。在项目成员开发的过程中，项目负责人需要完成以下工作
- 根据项目大小一周至少进行一次项目沟通会，同步项目进度
- 记录开发中存在的问题整理问题记录表
- 跟进开发中单元测试完成进度、代码审查等工作
- 项目测试环境提前协调准备
- 组织测试用例评审
- 跟进开发对冒烟测试用例的执行
- 准备转测 checklist 文档
测试/Bug修复阶段
项目满足转测条件就可以由相关的开发负责人发起转测申请了，项目的转测标志着开发的正式完成，也标志着由开发人员编写的代码已经能够顺利通过测试的冒烟测试用例。转测后如果发现无法通过冒烟测试，项目应该被打回，这是明确开发和测试职能和责任的重要环节，需要重视。
进入测试/Bug修复阶段，项目负责人需要完成以下工作
- 根据项目情况跟进同步测试进度、bug 修复进度
- 根据 bug 数量评估 bug 修改策略。比如在测试已经充分测试的前提下，bug 数量完全可控，那么一轮功能测试就已经足够，如果 bug 数量远超预期，可能就需要安排二轮、三轮的功能测试了。同时如果需求的影响点过多或需求体量较大就可能还需要安排对整个系统的回归测试
- 根据测试阶段与 bug 的影响性评估 bug 是否修改。实际的 bug 修复中，我们需要综合考虑 bug 的影响性、修改的成本、当前所处的测试阶段、项目周期等因素，来判断一个 bug 是否有必要修改，如果暂时不在当前版本修改，我们需要给出影响点及修改计划
- 预发版环境提前协调准备
- 准备 QAcheckList 文档
完成测试工作后，相关的测试负责人需要发出测试报告，告知相关人员冒烟测试、一轮功能测试、二轮功能测试、回归测试等测试结果。如果存在遗留问题，需列出问题根据表注明并说明原因
需求交付
需求交付也可以称为产品验收。项目测试人员完成测试过后输出测试报告，如果测试结果为通过就可以进入到验收环节。由产品经理对项目组开发的需求功能进行使用，检查是否满足设计要求，在此期间不建议作大的需求变更，可以尽量放到下个版本中进行迭代。产品经理完成验收后输出验收报告
一些建议
实际的开发中也许并不会像文中这样的一帆风顺，一个项目的进行往往充斥着各种突发事件，为了更好的处理突发情况，这里有一些原则和建议：
- 每一个关键节点都需要有相关邮件并形成邮件流。邮件需要发送至下个节点负责人，如开发负责任、测试负责任、产品验收负责人等，并抄送项目成员。
- 前期排雷工作非常重要。需求熟悉、影响点评估要引起重视，极端情况未考虑到影响点可能导致工作量增加一倍不止
- 每一个项目中的问题都应该指定跟进的责任人。如果遇到临时问题，应该遵从第一责任人原则，第一个接受到问题的人应该带领提出问题的人共同处理直到解决问题，而不是将问题抛给下一个人
- 及时同步消息。特别是需求的变动，最好能实时同步到每一个人。很多时候产品和技术的矛盾点就是没有做到信息的及时同步，导致技术做了无用功。这也是建议在团队组建完成一开始就建立同步机制的原因
- 项目负责人就是项目的接口人。项目组是一个整体，对内对外应该由项目负责人协同，项目负责人在处理组内问题的同时还需要实时与组外同步项目进度等信息，遇到不能解决或权限不够的问题一定要及时上报或请求帮助
项目尾声
验收阶段
项目验收通常由公司QA或由测试兼任来执行。所谓QA就是质量管理职位，很多公司有专门的质量管理部。在项目开发过程中，会由QA进行全程的监督，查看是否按照CMMI的标准进行软件开发。文档是否齐备，开发基线是否明确，是否存在风险，BUG的削减是否能够完成目标等都是QA关注的目标。
一个成功的项目除了结果的成功还需要过程的规范，项目验收需要对项目过程中的文档、交付内容、遗留问题、测试结果、产品验收结果等等进行验收。这就需要项目负责人严格遵守公司的项目规范并及时整理项目文档。需要整理的文档包括但不限于交付文档、项目计划、测试计划、测试用例、设计文档、单元测试报告、性能测试报告、遗留问题清单... 具体视公司项目规范而定
预发版阶段
项目验收通过后就进入到准上线阶段了，预发版阶段主要就是进行UAT测试，通常是测试人员在模拟生产环境的条件下进行冒烟测试。如果在之前的环节质量过关通常到UAT测试基本就很少出现 bug 了，如果此时依然出现重大 bug 可能就需要申请项目延期了
项目发版
通过UAT测试后，项目就进入到了正式上线阶段。上线前需要拟定发版策略，比如是常规发版还是灰度发版，是可选升级还是强制升级，这部分内容可能需要版本经理的参与制定。而作为项目负责人需要根据版本经理制定的策略梳理发版清单，清单内容应包含发版内容、是否新增配置文件、是否有SQL脚本、是否新增微服务、发版支持人员、注意事项等等。发版过程中也可能遇到一些紧急或临时性的问题，这时候就需要项目负责人与发版支持人员一起处理解决问题
项目总结
发版成功，项目正式上线，这时候很多公司会组织项目的回溯会议，回顾整个项目过程中存在的一系列问题以及改进方案。所以项目负责人在项目过程中收集整理问题的能力也很重要，这些总结是项目运行过程中的黑匣子，是下一次项目开始前的排雷兵
线上问题跟进
项目总结会议的结束，标志着整个项目告一段落。但对于部分项目组成员来说，项目还没有结束，线上用户反馈的问题以及项目遗留问题还需要继续跟进。线上问题的常规处理是在下个版本或者下一个项目当中作为影响点进行修复，但是对于波及面较广或者比较紧急的 bug 且经过公司决策层评估认为需要紧急发版的情况下就需要原来的项目组的相关成员重新进入战斗状态，进行紧急修复和发版
总结
可能很多人觉得决定一个项目质量的因素更多取决于项目成员的职业操守和责任心，但个人认为项目质量的好坏更多的取决于公司项目制度及流程规范程度。项目流程越规范的公司，越能从根本上排除潜在风险，比如产品设计的漏洞、开发的代码无法通过基本流程、测试漏测功能点等问题。这些都是通过职业操守无法解决，但是可以通过更加规范的项目流程解决的问题。所以项目规范和个人影响力是此消彼长的关系，规则越弱则个人施加的影响越大，规则越强则个人施加的影响越小
注：本文暂未涉及项目中需求变更、项目变更、项目延期等子流程或逆向流程内容，仅作基本项目流程表述
原创内容，转载请注明出处
