完整的项目流程

1. 问题定义

2. 需求分析

3. 系统架构（顶层设计）

4. 详细设计

5. 编码

6. 测试

7. 部署

问题定义

首先要知道客户的遇到的问题或者困难是什么。如果你做了问题定义，那你会发现客户有些问题的最佳解决方案并不是一款软件。

• 要求

  • 使用客户的语言描述问题，尽量不要使用程序化或者规范化的语言进行问题定义。

  • 避免在问题描述中规定解决方案

错误示例：“我需要一个报表系统，能够在每个月底把本月的收支信息通过短信发到我手机”

正确示例：“我不知道公司这个月的收支”

在该示例中，第一个示例无意中规定了解决方案——报表系统以及某个具体的方式——短信，其他人看到了可能第一时间就开始思考报表系统的过往案例或者发送短信的技术支持。而第二个示例就有可能让人这么回答：“你可以让你的秘书每个月整理后发你一份”。当然，这话或许会让你丢掉工作🤡。

需求

确定了客户的问题之后便要划定软件的范围，编写一份相对详细的需求文档，并且需要对需求文档进行评估以确保需求明确且没有遗漏。

• 以下核对表可以帮助你评估需求表是否达标：

  • 核对表

处理需求变更

身经百战的项目经理都知道一次性得到用户的所有需求并且后续不再更改是近乎不可能的，那也意味着对客户的置若罔闻以及对项目本身的不负责。合格的项目经理需要在客户需求变更时做出正确的处理，以下方法或许能对减少需求变更或者适应变更有一定帮助：

1. 使用一套优秀的核对表来评估需求的质量（减少前期部分需求模糊或遗漏导致的变更）

2. 让客户或者老板知道变更的代价（减少那些因为“热血上头”导致的变更）

3. 建立一套合理的变更控制流程，将那些不是很紧急的变更放到之后的版本或者给一个较低的优先级，或者一个较晚的时限。（稳住客户，让客户知道我们准备处理他的需求）

4. 使用一种更能适应变更的开发方法

5. 注意该变更的商业价值（某些变更或许确实能给客户带去快乐，但其代价与带来的利润并不匹配，比如炫酷华丽的交互页面，比如献祭几个光头想出来的极低内存极高效率的算法）

6. 放弃（如果这真是一个糟透了的变更）

架构

系统架构，又称为顶层设计或高层设计。（也有人将高层设计与系统架构进行区分，认为高层设计是对子系统或者模块的设计）

在系统架构环节，需要对系统的工具、框架、环境等进行规划，同时还要对系统中的主要模块、主要的类进行划分和描述。一个详细的架构会与详细设计存在许多的重合之处。

• 架构中所需要进行的活动可参考：

• 架构的经典组成部分

• 架构的总体质量

  无论你是否想要按照 架构的经典组成 中提到的内容进行架构，都应该至少遵循以下原则：

  • 好的架构应该与待解决的问题和谐一致（不应该充斥着不相关的话题、不应该盲目追寻最前沿的技术、不应该花费大量篇幅在优化上等）

  • 架构师应该清楚地知道系统的灵活性和性能通常是两个相悖的方向，架构时应该描述清楚：如何在满足性能要求的前提下尽量提高灵活性（或者如何在满足灵活性要求的前提下尽量提高性能），以及当两者冲突时应该更倾向于哪一头

  • 架构时应该记录下所有主要决策的思考或动机

  • 架构时既不能 “欠描述” 也不应该 “过度描述”

• 架构应该明确指出有风险的部分、为什么有风险以及已经采取了哪些步骤来使风险最小化

  • 架构不应该包含任何仅仅为了取悦老板的东西，不应该包含任何难以理解的东西

• 事实上，架构不可能完全独立于机器、环境和编程语言，但仍要让架构尽可能独立。优秀的架构很大程度上是与机器、语言和环境无关的。