前言
今年Q1，我负责内部一个技术项目的产品、项目管理以及质量和运营工作，目前项目第一阶段规划的需求都交付了。我将做这个项目过程中的一些经历和感受总结了下，就是今天这篇文章的内容。
思维导图
需求的三个来源
先来聊聊需求相关的事情吧。
一般来说，像企业内部的一些技术项目，立项的前提几乎都是有相关的诉求，汇总分析后得到了可落地执行的需求。从项目角度来说，需求的来源无非下列三个部分。
立项阶段内部规划的需求
上面提到了，一般内部的技术项目都是从日常工作中收集的一些相关团队诉求或线上问题，需要针对性的进行处理。对这些诉求进行分析后，通过抽取共性和权重较高的部分，整理成可落地执行的需求，然后通过项目立项来落地交付。
用户访谈得到的业务痛点
除了对日常的问题和其他团队的诉求进行分析之外，项目立项后保持和用户的联系也很重要。
因为立项阶段规划的需求只代表过去，但用户的诉求是一直变化的。因此和用户保持积极的联系，多做访谈，也是更好看展工作的前提。用户访谈时，有一点要注意：明确做访谈的目的，了解用户的真实诉求和痛点。可以参考如下三点：
- 用户面临的痛点背景是什么？
- 用户希望解决的是什么问题？
- 有哪些解决问题的方案（最好多准备几个，在技术评估阶段进行选型）？
投产使用收集的反馈建议
对需求进行立项排期后，要做到按时交付上线，让用户尽快的使用起来，从用户的反馈得到真实的评价。用户一般会对很多功能提出一些使用上的建议，或者会冒出来一些新的诉求。这都很正常，最怕的是交付的东西不是用户想要的，或者无法很好的解决用户面临的问题。
项目的生命周期
接下来聊聊项目的生命周期。像这种企业内部的项目，我将其生命周期划分为四大阶段：
立项调研
立项调研阶段，主要工作是确定整体规划，对需求进行分析，确定优先级，要投入的资源以及交付时间。其中最核心的部分还是需求，知道要做什么，什么时候完成，用什么解决方案，这一切都依赖于需求本身。
需求采集
需求采集阶段要做的事情，上面已经介绍过了需求的三个来源，这里说点别的。
立项阶段内部规划的需求，主要来源于日常工作中遇到的问题。我的习惯是将这些问题都进行记录，在每周的周会或者专门拉个会议来讨论这些问题，是否需要解决，优先级是什么，评估解决方案的可行性。这里要注意的是，会议要尽可能收敛，明确要讨论的主题，尽可能将问题在会议中都解决掉。
用户访谈得到的业务痛点，这点其实蛮有意思。业务团队或者说用户并不总是很清晰的知道自己要什么，他们可能会说很多他们希望的诉求，但不一定都是优先级很高或者值得做的。访谈时要记住一点，多问面临的问题和痛点，不要问他们想要什么，这是你自己该思考并解决的问题。
投产使用收集的反馈建议，这个也挺有意思。从用户诉求到转化为可实现的具体需求，再到研发交付，过程中总会有点偏差。而且业务一直在变化，用户的诉求也是不断变化的。
我的做法是一方面通过专门的沟通对接群来实时响应用户的反馈建议；另一方面，专门开了一个反馈建议的入口，让用户能随时将建议反馈给我们。通过定时任务推送到专门的群里，便于及时响应。
排期研发
这个阶段，我个人的经验是需要注意如下六点：
1）选择合适的迭代模型
像这种需求多变且来源较多的项目，瀑布迭代模型就显得很不适用。尽快的交付和获得用户反馈，并进行快速响应迭代，比按部就班的交付更容易拿到好结果。
2）构建完善的项目文档
我负责的这个项目，选择了敏捷的交付模式，但敏捷不代表不需要文档或者轻文档了。完善的项目文档依然是很重要的。
经验之谈，所有口头的约定都是不可信的，你也不能指望团队里所有人都具备良好的职业素养和风险以及质量意识。
关于构建项目文档的具体内容，可参考我之前的文章：《如何设计良好的技术项目文档结构》
3）需求优先级定时排期
谈到了需求是多变的，那在需求排期时候就不能一锤定音，而是需要定时去复盘已交付的需求以及待交付的需求。有些需求实际上交付的并不是很好，而需求的优先级也是需要跟随项目的具体进度和用户反馈来实时变化的。当然，每个迭代周期中，还是不建议去做需求变更和紧急需求插入，这是对交付能力的一种伤害。
4）构建质量是核心卡点
对于需求不确定的项目，不能要求需求的质量有多高或者多么可靠，那么在研发阶段或者说质量构建阶段，要做好卡点。
并不是说一定要做单元测试或者多高的单测覆盖率，但codereview和快速的自动化验证还是很有必要的。至于我们熟知的像冒烟测试、提测评审等流程，还是需要的。选择了敏捷迭代模式，不意味着要牺牲质量。
5）风险需要实时的跟进
项目迭代过程中，总会出现很多问题或者影响交付的风险，比如紧急需求插入、帮用户排查问题、资源投入或者项目优先级的调整，都会影响项目的交付质量。唯一能做的就是实时跟进风险，灵活应变。
6）交付质量要保证可控
从测试角度来讲，要保障交付质量肯定少不了规范的流程、方案评审测试case评审、提测卡点、多轮测试以及线上验证等很多工作。但从另一方面来讲，选择了敏捷迭代交付，势必要在某些方面做一些牺牲。
我个人的经验，是可以容忍带着一些问题上线，但前提是不影响用户正常使用。像一些P2-P3的BUG，可以选择在下个迭代或者小版本的优化来解决。当然，可以选择延期上线发布，但需要确定的是这样做不会让用户对你的交付能力和交付效率有所怀疑。其中得失，还是根据具体情况自己评估吧。
交付上线
关于项目交付线上发布，我想聊下面三点：
1）快速交付可用的MVP产品
面对需求多变的项目，快速交付可用的MVP产品让用户使用起来，是最重要的一件事，闷头憋大招反而很容易错失机会。
2）重视上线后的用户反馈建议
业务一直在变化，用户诉求也是不断变化的。一方面要实时响应用户的反馈建议；另一方面，用户的反馈和建议才是让产品变得更好的源驱动力。多听用户说什么，不要替用户做决定。
3）复盘归因是提高交付质量的秘诀
这点可以参考我前面写过一篇文章：《复盘归因，提高交付质量的秘诀》
项目交付的四大要点
关于项目交付的要点，我试着从下面四点来聊聊我的一些看法。
交付能力
交付能力看着是个很玄的东西，我的理解是能否按期交付用户可接受的MVP产品。保持交付节奏很重要，让用户感受到产品是不断进化的更好，这样用户做小白鼠的心理抵触才不会很大。
交付质量
交付质量一定要保持可控！怎么理解这句话，实际上就是要保证质量的下限。
可以容忍带着一些问题上线，但前提是不影响用户正常使用。像一些P2-P3的BUG，可以选择小版本优化来解决。当然，可以选择延期上线发布，但需要确定的是这样做不会让用户对你的交付能力和交付效率有所怀疑。其中得失，还是根据具体情况自己评估吧。
交付效率
除了按期交付和保障质量可控，在有限时间和资源投入背景下，提高交付效率就很有必要了。
我在具体实践中，用到的一些提效手段有下面几种：
- 需求评审和排期要快速精准（尽量半小时搞定）；
- CICD是必不可少的提效手段（这个考验公司的技术基建能力）；
- 快速的自动化验证能节省很多时间（完善的项目文档能提高验证的效率）；
- 线上问题及时响应和完备的告警监控机制（既考验技术基建能力又考验职业素养）；
用户满意度
上面讲了很多内容，但你会发现我一直在提到用户满意度相关的事情。我认为用户满意度，可以分为三个境界：
最好的方式是你发现业务有痛点，快速主动的解决痛点，超预期交付；
次一点，业务提需求，按期保质交付；
最次的方式是你觉得需要这个，花了很多资源去做，闷头憋大招，结果没人鸟你。
