工作心得（一）

项目大约开始于年月日，由于之前的补货预测不能满足目前的业务需求，存在预测数据不准确的问题，因此采购表需要IT协助完善相关脚本。

通过前期的需求调研，了解了需要调整的格式、公式、逻辑等，经过一个多月的深入研究，比较细致的讨论了脚本的关键技术，在弄清楚需求和修改的方法之后，就是具体的实施了。

对于这个项目我的心得是这样的：

1、需求调研

需求是否必要？必要的话，现有的条件是否可以满足？新开发的话，效率和成本如何？

必须了解最终客户的真正需求，有时客户会直接提出解决方案，但还是需要了解其真正目的，目的不同，方案自然不同。

2、需求文档

对前一步的需求分析写成文档，明确指出了客户需求，并让客户进行签字确认（每一个细节最好都有确认，如计算逻辑、函数的使用等），同时，对于其他相关人员而言，也便于理解需求，方便程序员维护脚本。

文档可以包含以下几项：项目概述，目标，应用范围，名词定义，详细需求，用户用例，显示结果等。

3、蓝图设计

画出逻辑关系图，列出关键步骤、制定执行计划。这一步也非常的关键，如果考虑不够周全，后期就需要翻工！

如果是多个人合作完成项目，要将工作分工落实到每个人头，以及安排出相应的时间表，时间安排要合理，同时要有弹性，可能会有临时紧急重要需求，可能突然有重大变更，当然这时计划也需要再安排。

4、项目实施

a.对相关原始脚本进行逐行分析，了解每句的含义（如果是新项目，就需要自己写代码）

b.进行相应的修改

c.在数据库中搭建运行环境（调度相应的表到备库，把表结构设计写下来）

d.创建外部数据表（如工作日表）

e.考虑后期影响因素，维护工作，可扩展性（时间范围按系统时间自动截取，年初可能会有问题）

5、检验结果

   自己检查结果，是从技术角度检查；客户检查结果，从业务角度检查，因为在需求上可能仍存在误解。

6、部署实施

在真库上创建存储过程、视图、物化视图等。如果是多地系统，需要再从第三步开始。

但是之前的旧版还需要保留一段时间，在这期间两个版本同时运行，当新版没有问题了，再停用旧版。

7、调整维护

在运行过一段时间后，用户可能感觉某些方面没有达到期望，需要修改，这时的需求应该是比较明确的，修改相对容易。将后期需要做的维护工作，注意事项等写入相关文档。

 

在写脚本的时候，良好的编写习惯也很重要，既可提高编写效率，保证脚本的正确性，同时易于扩展和后期维护。在操作的过程中，要时刻注意按照需求说明进行，不要一味的盯着具体的语句或者以前的逻辑，而偏离了目标。总的来说，项目的实施和具体代码的编写都要有一定的规范和流程。要有全局的观念，不要只专注于几个细节，考虑周全，项目完成后还应该注意哪些方面，后续工作还有哪些。

对于一个项目，计划是很重要的，如果在调研了需求之后，认为项目是必须要执行的，那么就要制定计划了，从需求调研开始，就要拍计划。当然这些也不是线性的，应该是螺旋上升的，后期可能还会做一些修改，但是大的框架应该保持不变了。