一次完整的项目之旅

1. 项目前期准备:
   1.1整个项目首先肯定是现实中有需求，才会有需要做系统的必要，系统的使用首先肯定以简化流程，规范化操作为主要目的，如果系统的使用，只会让目的越来越来麻烦，那还不如不做系统。
   1.2系统的目的;
   实现薪资+绩效
   人员培训
   员工考评
   人效评估
   员工生命周期管理
   人才库搜索
   整体的开发schedule流程如下：
   

2. 各种需求收集（已经开始画UI草图）
   2.1：笔者所在的公司需要设计一个 hr绩效考核系统，使用者就是公司的全体员工（并发量不大+内网使用），绩效的生成肯定是十分敏感的（涉及工作流），
   2.2：由于制定和发布考核模板的是一些公司的中层管理层，所以免不了会有各种相互推诿，财务部和绩效部门和人事部门都希望能尽量的少做事，理由是：他们都很忙，不想做过多的操作。ps：由于中层管理层是这群“上海土著”，他们确实会投胎，所有不那么想奋斗，所以最好每天就喝喝茶，吃吃零食，领领工资，等等死就行了，所以收集需求和确认需求十分的困难，恰好又是一群“肥婆”，开需求会时，各种吵闹，笔者都一一包容了，想来他们也就只是领一份薪水的“肥婆”，心里就释然了。——鉴于肥婆们很忙和傲娇，所以需求收集过程中，引入真是场景进行介绍，以 who在when和where做了what，why？当场景介绍中，有所遗漏时，可以让将来的使用者做出一个比较具象的判断，同时更加精确的判断哪些草图满足实际生产中的需要。
   2.3：收集了需求后，尽管有各种的困难，项目还是如期进行，大概的需求确定后，开发经理开始将项目所需要的 基本技术 框架进行归纳，开发经理是一个什么严谨老派程序员，在上市公司待过，文档写的什么好，但是内向到不会交流，
   2.4:整体的系统架构图示：
   
   2.5：整体的技术点:技术点大多根据需求涉及到的业务功能所决定
   

3. UI图+项目框架的设计
   3.1当需求收集过程中，就可以事先搭建系统框架了，还可以对前期的系统预设框架以及技术点进行修改或者优化，例如： 系统最大并发用户数为100个，每秒钟的最大数据库事务请求为76个。按照每个事务的数据量为10K/S，则带宽的需求为760K/S，网络带宽和服务器配置应满足上述要求—– 4台4核内存8G的服务器。
   3.2;整体的AD设计文档目录截图：
   
   3.3：当整体的项目需求有了雏形之后，起始就可以尝试画UI草图了，同时为了让日后的开发人员可以对系统业务功能更加熟悉，可以尝试让前端工程师和后端工程师对UI草图进行简单的模块UI介绍，再画好了UI草图后，开始一次一次拿着UI草图给日后的使用者代表进行一个一个确认，
   3.4：对于整体的系统框架demo，只需要对框架进行小小的演示就行。

4. 基础库表的设计：
   4.1：对于基础性表的设计，我们采用固定的企业级的开发套路，类似于用户表角色表权限表的使用，是可以在UI草图开始的过程中就可以并行开发的，十分独立的模块也是可以提前开始进行的。
   4.2：整体的项目详细schedule-task和WBS;
   
   
   
5. 辅助性记录
   5.1：在多次开会的过程中，我们发现参会者会前后口径不一，所以对于会议记录是很有必要的：
   示例如下：
6. 职场小技巧
   6.1：对于哪些需求阶段的争吵，和无法确认拍板的中层是无法得出结论的，必须是和可以做决定的人做确认就行了，内部系统就是具有强制性的，不存在个性化的讨好使用者，所以可以强势，