作为软件工程师的我们应该都曾有过一个疑问，开始写程序之前，要不要先做规划。
这个问题也曾经困扰着我跟我的朋友。如果不做规划，可能会导致程序杂乱不易维护。
若做了规划，又可能花费大量的时间与精力，可能还不敷成本。

某个阳光明媚的上午，朋友突然找我讨论起要不要做UML的话题(简单翻译就是程序的蓝图)
朋友: 欸，你不觉得写UML很浪费时间吗?
我: 是很花时间。
朋友: 你会Coding前会画Class(类别图)吗?
我: 不会。
朋友: UseCase(使用者案例)?
我: 不会。
朋友: 那...
我: 不会。
朋友: 对吧，不如直接边写边想就好，做一堆文件浪费时间。
我: 还是会先写一下流程图。
朋友: !@#$%....刚刚不会先等我问完喔...

制定目标

在上一篇(寻找日常生活中的问题)，
我们提到老板可能因为某些原因掉单。所以我们为了解决那些问题要来开发一套程序。
首先，老板可能因为字丑，或是纸张飘掉的问题改成电子化就解决了。
但是人多的时候，即便改成电子化，依然有可能会忘记写。
所以我们这边更改一下作业方式，开发成一个网页版的菜单，
让客户可以在上面点餐，这样不用担心电话被占线问题打不进来，
也不用担心，老板在忙的时候忘记了。(把问题丢给客户，这样就没问题了)
所以我们决定做一个网页让客户可以在网页上点餐，这样子初步的目标就订好了。

如何评估可行性

在职场上很常看到业务/业务工程师，之类的职位出去跟客户说得天花乱坠，
回来之後再把问题丢给开发人员，把自家工程师当作007去解不可能的任务。
会出现这样的问题，最主要的原因是他们在与客户讨论需求时，没有做可行性的评估。

做评估的时候其实就两件事:

1. 建立 步骤/流程
2. 检视 步骤的合理性

建立 步骤/流程

为了避免不可能的任务，在开始之前我们需要建构出一个可走到终点的步骤。
以这次的题目为例，我们可以开始思考当这个专案如果真实运行时应该会是怎样的流程。

首先，我们打开网页，在网页的画面上点了我们要的菜单之後送出。
之後老板在网页上看到我们的单子，开始做我们的餐点，做完之後我们取餐。
接下来把它整理成步骤:

1. 打开网页点餐
2. 老板接收到单子
3. 老板做餐点
4. 取餐

这样就完成了我们整个流程了，这边有一点很重要就是一定要有开始，有结束。
很多人最常犯的问题就是只把流程写到，想要呈现的功能就结束了。
例如，最常听到业务工程师都是这样说需求。
客户要能够打开网页，进去之後上面要有Button可以按，下面要有下拉式选单，旁边要有公司电话.....等。
要是你问客户说客户需求就这样?
他们可能还会说:就这样阿，不然你还要甚麽?
这样有头没尾的，又说了一堆可能会更动的细节，不仅会造成开发时候的混乱。
等哪天，真的工程师开发出这种一堆按键却没有功能的程序交差时，就准备大家头痛了。

所以千万千万要记住有开头也要有结尾。

检视 步骤的合理性

在检查步骤合理性的时候，有一个比较简单的方法，
就是去观察资料(data)的流向，在这边资料就是我们点餐的单子。

我们来跑一次前面的步骤:

1. 打开网页点餐 (客户建立单子)
2. 老板接收到单子(单子送到老板这)
3. 老板做餐点(单子依然在老板这)
4. 取餐(单子依然在老板这)

(虽然看起来有点怪怪的，但不知道问题在哪里~~~)
那我们再跑一次:
打开网页点餐 (第二个客户建立单子)
2. 老板接收到单子(此时老板会发现，有两笔单子)
3. 老板做餐点(还是两笔单子)
4. 取餐(还是两笔单子)

这时候我们就会发现好像出了个问题，那就是当我们完成单子的时候没有把单子删除。

所以我们修改一下我们的步骤:

1. 打开网页点餐
2. 老板接收到单子
3. 老板做餐点
4. 取餐
5. 标示已完成的单子

这个例子是一个很常见的思考盲区，会把平常时习以为常的事情给忘记了(但还是有做)。
这可能就会导致做出不如预期的成果。
这时我们透过观察资料流向的方式，可以比较容易发现流程上的错误。

结语

我们可以透过画流程图，或是建立一个一个的步骤来确定我们是否能达到我们要的目标。
之後透过检查资料的流向来确定我们的步骤是否合理。

这篇我们没有任何程序的元素，
下篇开始我们会进入程序的角度来看看我们应该要如何规划