我们都知道，软件项目中很多问题都和需求相关，比如说需求不明确，需求变更。这些问题轻则导致返工造成浪费，重则导致项目失败带来巨大损失。所以在软件工程中，搞明白需求是一件至关重要的事。
上一篇我带你学习了如何分析需求的方法，而分析需求，同样也离不开工具的支持。所以这一篇，我将带你学习需求分析中原型设计的用法，借助原型设计，用最小的代价完成产品特性。
什么是原型设计？
通过前面的学习，我们知道在瀑布模型中，第二个阶段就是需求分析阶段，同时需求分析的结果也决定了后续的系统设计、开发、测试等阶段能否顺利如期进行。即使是用敏捷开发，同样也少不了对需求的分析整理。
可以说需求就是整个产品的源头，所以需求分析的结果往往决定了产品的成败。如果没有正确把握客户需求，可能就会一步错，步步错！
就像我在《特别放送 | 从软件工程的角度解读任正非的新年公开信》提到的秋千的案例：
说到风险，很多人都模模糊糊有一些了解，然而在软件项目中，有风险意识的却不多。比如说：
- 估算一个模块工作量，程序员总是会给出一个乐观的进度，而最终实现这个模块的时候，却发现总是有些其他的事情发生影响了进度；
- 一个关键的程序员，突然离职了，导致项目进度停滞。其实早前就有一些迹象，而项目经理没引起重视；
- 技术负责人很激进的采用了一个最近很流行的新技术，结果做的过程中，发现这个技术还不太成熟，很多坑没法填，导致项目最终失败；
早些年我在做项目管理工作的时候，除了制订计划外，还要花不少时间去跟踪计划的执行情况。
项目管理上出了问题，管理者总是喜欢从流程规范的角度去想办法，于是为此设定了不少流程规范，例如每天要写日报，根据日报更新项目进度，每周要开周例会，看看项目有没有执行上的问题。
对任务进度的量化也是个很困扰项目经理的事情，需要频繁的去问程序员：“你这个任务进展如何，大概完成比例多少？”，从程序员那得到的答复通常都是个很乐观的数字，例如80%。第二天以为他能做完，结果一问是90%，就这样要持续好多天才真的算做完。
说到开会，是很多人心中的痛，每天白天忙于参加各种会议，压缩了本来就少的可怜的工作时间。最可气的，有的人开完会工作就算完成了，而像我们写程序的，还得下班后加班加点赶进度！
所以一说到开会，程序员们往往如遇洪水猛兽一般，避之不及。
开会是有价值的
不知道你所在的软件项目中是不是也有各种流程规范，例如：
- 开发人员不能直接在生产环境修改代码操作数据库，必须在本地先测试验证后，由运维操作；
- 代码需要Review通过才能合并主分支；
- 代码需要遵守各种规范，像命名、格式，还有缩进用几个空格还是tab的细节问题；
若干年前，我接手一个陷入困境的项目，当时的项目经理刚从技术高手转型项目管理，还是没有摆脱技术思维，项目没有什么计划。
他把关键模块分给了自己开发，同时还要兼顾项目管理，导致自己的工作遇到瓶颈，其他人的进度也受影响，大家加班加点也没什么进展，士气低落。
我接手后，第一件事是重新制定项目计划，在排任务时，避免了对某个人的过度依赖，设置了几个关键里程碑。我还特地把第一个里程碑设置的相对容易一点，只需要运行核心功能。
技术转管理，是很多技术人员的梦想，所以经常有人问我，怎么样才能转型管理？
项目管理，是最基础的管理，既要管理一个项目，又要协调整个团队一起，完成共同的目标。
我的管理转型就是从项目管理开始的，在从技术转型项目管理的过程中，让我从以前专注于局部技术实现，逐步转向关注项目整体；从个人的单打独斗，到借助整个团队的力量一起完成一个项目。
如果你随手拿起本软件工程教材翻翻，第一章一般都是讲“可行性研究”的，呈现顺序仅次于“绪论”，可见其重要性。
“可行性研究”通常讲的是如何科学地论证项目的可行性，以及这个项目是不是值得做。这个知识点比较简单，落实到期末考试的题目上，一般只是一道像这样的选择题或填空题：
“可行性研究主要从哪几个方面进行？”
专栏已经上线更新一段时间，看到同学们对软件工程有了更深刻的理解和思考，我很受感触。
有些人说走了很多弯路，日常搬砖，增删改查；也有的同学跟我一样“野路子”程序员出身，非常困惑希望建立自信；还有的同学发表上千字的学习心得，可以说非常用心。
编码的最终目的还是为了实现一整个软件的开发，在程序员的晋升之路上，总有单独挑大梁负责项目的时候。你会发现软件开发中的很多问题，都是可以通过软件工程的知识来解决的。
在《从软件工程的角度解读任正非的新年公开信》这篇文章中，我已经提到了“软件项目管理金三角”的概念。由于这个内容对于软件工程来说，非常之重要，所以我今天特别展开再讲一下。
你会发现，在实际的软件项目中不乏这样的例子：
- 一个项目，正常估算，要三个月才能完成，但是老板或客户要压缩到一个月完成，而你不知道如何说服他们；
在上一篇文章中，我们一起看了一下大厂和敏捷相关的一些流程规范，同时也为你留了一道思考题：
如果每周一个Sprint，怎么保证每周都有交付，还能保证产品质量？
所以在这一篇中，我们就以每周一个Sprint的小项目组为例，看看它的日常是怎么应用敏捷开发的。
