我的项目总结

简介:      终于做完了两个项目,几乎用了近两年的时间,应该好好总结一下了,要不然这么好的经验就白白浪费了。我做的项目都是企业定制开发的,所以总结也是侧重于定制开发的项目,可能并不适合成型产品的项目。

 

     终于做完了两个项目,几乎用了近两年的时间,应该好好总结一下了,要不然这么好的经验就白白浪费了。我做的项目都是企业定制开发的,所以总结也是侧重于定制开发的项目,可能并不适合成型产品的项目。

     1、签合同

          合同里面关于项目功能的地方要尽可能的详细,范围要尽可能的缩小。如果功能比较模糊,而范围有比较大的话,那么就很危险了,因为客户会在这个范围内不断的增加内容,“加深”功能。这些足以让预期的时间和工作量成倍的增加。

          当然,想要在合同里把项目的功能给说细了,并不是一件很容易的事情,除非对客户的行业和客户的情况很了解,或者说我们做的就是一个产品。如果我们是给企业定制开发的软件,而我们有对客户的业务流程不太了解,那么要把合同里的功能确定好了,确实很不容易,但是也要尽力的去做。这个很大程度上要看经验了。

     

     2、调研

          有些情况是先调研后签合同(至少我就遇到了一次),当然大多是还是先签合同然后再做调研。好了,不管谁先谁后了,我们先说调研。

          一般呢是项目经理带着几个人去客户那里去了解客户的需求和客户业务逻辑,这时呢,大多数情况是只和客户的“领导级别”的人打交道,比如大老板、各部门的经理等。我们也许会有一个误区:“领导级别”的人说的就是准确的,就是全部的业务逻辑了,只要按照领导说的功能去做,实现了领导想要的就可以了。但是实际上往往没有那么简单。

          因为领导嘛,自然不会去关心细节,对于业务流程也不见得就100%正确。我就遇到了机会,领导说要这么做,但是到了录入数据的人员那里就变样了,要么是一些细节被领导忽略了,要么就是领导的要求根本就不能实现!

          不要认为当出现这种问题的时候,一定是录入数据的人员“遵从”意见,我就很点背的遇到了几回,居然是领导“让步”了。没办法,我只好改程序了。

          所以调研的时候,不仅要听领导怎么说,还要看看录入数据的人员的现在的做法,也就是在没有软件的时候客户是如何做的,最好能够跟着客户完成一个完整的业务流程。

          和大老板沟通的时候,要注意他的真实需求,他要上这个软件的真实目的;

               有的时候,大老板是想用这个软件来重新规划一下业务流程,堵住一些漏洞,如果是这样的话,那么就会和一些人的利益有些冲突,这时就要万分小心了!

          和部门经理沟通的时候要注意他们对于业务逻辑的了解和掌握程度,还要看他的描述的能力;

          和录入人员沟通的时候,要注意他们的对电脑操作的熟练程度,现在的操作习惯是什么,对于什么样的“操作形式”可以接受。

          还有就是年龄段,一般年轻人是比较“听话”的,而有些人就比较很难改变他们现有的操作习惯,就是说不容易接受新的操作方式。

           每个人都是只关心自己的工作量,总是希望自己的工作可以很简单、很轻松的完成。

          其实决定一个软件是否好用,往往是录入人员“说的算”。正所谓“三人说虎”,一个人说这个软件不好用,领导不一定会信;两个人说,领导会有所怀疑;三个人说,领导就会很怀疑。而带着怀疑的眼光看一个事物的时候,问题就会被扩大,就会满眼都是bug。再有,领导哪会有时间详细的看你的软件呀?领导只关心报表,而报表的数据是要有录入人员录进来的,没有数据,或者数据不准确,那领导看什么呀?

          所以我觉的不仅要和领导打好关系,录入人员也不能忽视!

     3、设计

          这里就有分歧的地方了,我是习惯以数据库为主,用表和表的关系来体现业务逻辑。而OOer喜欢先画一个UML,设计领域模型,设计实体类等等。不管使用什么方式,设计好的东东要尽快让客户确认。避免出现理解错误的情况。

     4、编码

          如果在编码前就能确定,我们写的就是客户想要的,那该多好哇。如果能够实现那自然是好,但是对于企业定制开发的项目来说,要做到这一点好像异常的艰难!修改似乎是在所难免的,所谓“唯一不变的是变化本身”。那么如何才能确定自己实现的功能就是客户所取要的,或者说客户的需求变了,我们如何才能尽快的、尽量简单的修改就是实现?这里似乎又有很多的分歧,每个人都有各自的应对方法吧。

          这里好像没有什么具体的建议了,一切靠经验吧。

 

     5、面向对象的问题

          先举个例子吧。50米开外有一个靶子,目的是命中靶心,可以选择武器有弓箭和枪。相信您一定会选择枪吧,枪对于弓箭来说确实准确度、射程、易操作性都高了很多。但是并不意味着,你使用了枪就一定会命中靶心!如果您是第一次使用枪打靶,第一枪很可能会脱吧,经过一段时间的联系后,可能达到枪枪打中靶子,但是想要达到枪枪命中靶心,就必须要经过艰苦的训练才行。

          我想要说的是,并不是说使用了面向对象这样的“先进武器”,就可以很轻松的实现传说中的那些好处!必须要多多练习、用心练习才行!

 

     6、面向对象的威力。

          还是先举个例子。假设有一个一吨重的石头塑像需要换一个地方。由于它太重了,一个人搬是不可能的,那么就多找几个人吧,找十个人,每个人承担100公斤的重量就可以了,但是这样的大力士并不是随便就能找齐的,那么怎么办?再加人。找二十个人,每个人只需要承担50公斤就可以了。这个视乎容易多了,但是这么多的人如何来配合工作呢?塑像的底座周长比较小,人多了申不上手。

          如果有一个神奇的分割方法,可以把这个塑像分成100份,每一份只有10公斤重了,这样一来就容易多了,找一百个人,一人一块就走了。找五十个人,一人两块也行。当然他的神奇之处不在于分割,而在于“组合”。当到达目的地之后,这个神奇的分割方法又会把小块恢复如初,达到“无缝连接”的效果。

          这个“神奇的分割方法”就是面向对象,他会把一个大的项目分成n份,然后找n个人来完成,然后再把每一个人做好的“组合”起来。这个就是面向对象的威力吧。

          您可能会有一个疑问,移动塑像一定要用人力吗?用起重机不行吗?这样就可以整体移动了呀。如果有起重器可用的话,用起重机是更好了。这样找一个会驾驶起重机的,再找一个司机就OK了。

          不过话有说回来了,如果这个塑像有1000吨重,显然一个起重机是搞不定的,起重机多了就又有了一个如何配合的问题了。

   

 ps:您可能会问,这里怎么没有测试呢?因为这两个项目比较特殊,直接让客户去测试了。但是这个也只能是一个特例,所以也就不多说了。

        

 

 

相关文章
|
4月前
|
Java Maven
给项目添加chechstyle
给项目添加chechstyle
47 2
|
7月前
项目章程
项目章程
38 0
项目章程
|
8月前
|
前端开发 JavaScript 微服务
项目-已完成
ERP 1. erp_parent (Java-后端) 2. erp_web (Java-前端)
50 0
|
8月前
|
算法 知识图谱
|
10月前
|
C++
项目练习1
项目练习1
|
10月前
|
搜索推荐 开发者
关于AskBlog项目存在的问题
关于AskBlog项目存在的问题
54 0
|
10月前
|
IDE Java Linux
tbfetcher项目小结
tbfetcher项目小结
52 0
|
Ubuntu 编译器 开发工具
ShiftMediaProject项目介绍
ShiftMediaProject项目介绍
146 0
|
JavaScript 前端开发
项目生成
项目生成
133 0
|
NoSQL Java 数据库
完成项目的一点思考
在新公司搞一个项目练练手,熟悉流程。到现在大体流程也熟悉了一遍,做东西的时候有点思考。 毕竟自己读书少,大部分时间花在写代码上,如果写代码的时候再不思考,那就和咸鱼没什么区别了。
1051 0