W
woyaoying
Unregistered / Unconfirmed
GUEST, unregistred user!
大体说一下时间：
开发：2003－9－10日——2003－11－7日
测试：2003－11－7日——2003－12－13日
学习Delphi半年时间。
接触电建项目半年，先说一点：我不是项目经理。
我只做一个很小的项目，虽说一个很小的项目，但是体会却是非常深刻。
也是我这个年龄段的体会，望各位朋友指教，但是不要故弄玄虚的说自己经验多少多少？
先说这次项目得总体体会，一个字：累！
首先体会到编程与做项目是完全不同得概念。原来以为那些搞项目分析得不知道整天做什么。
现在终于明白了，做项目更像是在完成一项艰巨的任务。当然没有一定的编程功底做项目，也是空谈。
做项目更多的是从实践中总结后精华的汇总。资源分配，整体把握，项目整体抽象、结构。说实在的：
项目更多的还是经验，这点不得不承认。这点只有在做完项目后进行不断的积累了，如果一点体会都没有，恐怕就应改考虑换职业了
闲话少说，我就开始从头到尾谈谈吧，不过首先说一点，这个项目并不算成功，正因为它的不算成功，让我心里有太多的话要说，不说心里老憋屈的慌。如果是一番丰顺我想就不谈体会了，而是改成经验了，呵呵
调研与分析：
在公司的前期调研，这个环节应该说是最最重要的，正是因为在这个环节的错误，导致后来项目工期托长，当然了，带给我们的只有是加班，没有加班费的啊。做需求不成功，可能导致后来的结构不断变化，每天都会把你累个半死。真的，先告诫一下各位。虽说这也是老生常谈了，但是我认为还是把问题的根源找到是最重要的。
是因为什么原因犯下的错误：
首先一点有些需求根本就没有那么复杂，根本客户不需要的需求。
其次就是没有任何经验的市场人员在做需求。
更多的还是将别人的需求理解错误，我想这点不是每个人都具备的，这需要长时间不断的经验积累。
这是这次主要的原因之所在。真的公司里系统分析员太少了，可以说根本就没有。只能让程序员去代替系统分析员的职责了，我想那段开发的时间纯粹就是在想象式的开发，没有任何目的的开发。那次听了台湾一个也是做建筑行业的ERP公司的演讲，真是太让我感觉到国内与台湾之间的差距了。更让我体会到做项目真的不是那么的简单。
如果不把系统分析放在最终要的环节，恐怕你永远只配做一个Code Worker，往好了说也就是一个High programmer
系统分析决定你的项目工期，将来的可扩展性，它代表了一个一个人真的从根本上将业务完全理会。并且能在这方面能提出自己独到的见解。这将是做项目的第一步，也是最难的一部。
编码：
谈完了需求，我想下面的编码应该是大多数人接触最多的，我也是一个狂热的技术分子。对技术有无比的热情。但是热情有时会让你掉进陷阱。
对于将业务模块进行抽象，ERP技术已经是千篇一律了。没有什么只得在这里进行分析的。只是系统构架还算可以，扩展性不错。还是那句老话，将业务模块抽象成类是比较好的。恐怕这也是大多数人的设计方式，希望大家畅所欲言，希望大家在这里都能学到一些东西，也是我的初衷。
我想在这里也问问大家，你们是模块式的开发呢，还是将整体构架搭好后在进行模块式的开发。一般我看大公司的开发模式都是先将用户界面画好，然后提交用户审核。通过后进行业务抽象，具体编码。当然了我们也是采用此方式。不知各位还有什么好的方式？
测试：
测试我想不能发到最后来讲。测试是紧跟开发的，开发必定需要测试。有时候流程走不同必须要经过测试，才可以进行一步的编码。有些问题要问，测试人员应是什么样的人员，例如是市场人员，或者是刚毕业出道的学生，在或者是编码人员，更甚至是系统分析员。最后或者是用户。我得意见是将用户用作测试在好不过了，我想大家还有什么别的看法，希望大家能有常人不同的见解与看法。那我发这片帖子就收获不小了。
实施：
我想作为一个大的项目，实施是一个非常重要的环节。首先要讲自己软件的思想灌输给用户，特别对于一些对信息技术比较落后的客户，要进行不断的培训与思想感化。讲清楚软件的最终意图，或者这套软件到底能为他带来什么，能改变什么。
望大家畅所欲言，谈谈是怎样做项目的。更多的是让我们这些小辈能学点东西。
我想在中国来说，系统分析、编码、测试、实施一个人做的情况多的是。只是我没有做系统分析（别人做的），也看到了
系统分析的重要性，并且我是深受其害
对于我们这些程序员来说，我想更多的还是提升自己。不过我想提到一个名词：合作
不要只埋头写代码，提升自己对整个项目的把握与业务的理解。将会减轻你的这种压力与烦恼。在我的眼里系统分析员是比不可少的，并且是具有非常经验与编程技术于一身的高手。他能从整体上把握整个项目的进度，并且与于客户的交流变得更容易。将客户的思想用编程的语言将给程序员，他是架设客户于程序员之间的纽带，是合理分配任务的管理者，是能让程序员发挥自己最大价值的使者，更是贯穿整个项目的灵魂。自始至终担任着艰巨的任务，可是这样的人毕竟少之甚少。
也许我们正是继承这个艰巨任务的，让我们程序员从整体上提升自己。看到眼前虽说是狼藉一片，但是更多的挑战摆在你的面前，更多的机会摆在你的面前，只要你用心……
只有想不到，没有做不到！
开发：2003－9－10日——2003－11－7日
测试：2003－11－7日——2003－12－13日
学习Delphi半年时间。
接触电建项目半年，先说一点：我不是项目经理。
我只做一个很小的项目，虽说一个很小的项目，但是体会却是非常深刻。
也是我这个年龄段的体会，望各位朋友指教，但是不要故弄玄虚的说自己经验多少多少？
先说这次项目得总体体会，一个字：累！
首先体会到编程与做项目是完全不同得概念。原来以为那些搞项目分析得不知道整天做什么。
现在终于明白了，做项目更像是在完成一项艰巨的任务。当然没有一定的编程功底做项目，也是空谈。
做项目更多的是从实践中总结后精华的汇总。资源分配，整体把握，项目整体抽象、结构。说实在的：
项目更多的还是经验，这点不得不承认。这点只有在做完项目后进行不断的积累了，如果一点体会都没有，恐怕就应改考虑换职业了
闲话少说，我就开始从头到尾谈谈吧，不过首先说一点，这个项目并不算成功，正因为它的不算成功，让我心里有太多的话要说，不说心里老憋屈的慌。如果是一番丰顺我想就不谈体会了，而是改成经验了，呵呵
调研与分析：
在公司的前期调研，这个环节应该说是最最重要的，正是因为在这个环节的错误，导致后来项目工期托长，当然了，带给我们的只有是加班，没有加班费的啊
。做需求不成功，可能导致后来的结构不断变化，每天都会把你累个半死。真的，先告诫一下各位。虽说这也是老生常谈了，但是我认为还是把问题的根源找到是最重要的。是因为什么原因犯下的错误：
首先一点有些需求根本就没有那么复杂，根本客户不需要的需求。
其次就是没有任何经验的市场人员在做需求。
更多的还是将别人的需求理解错误，我想这点不是每个人都具备的，这需要长时间不断的经验积累。
这是这次主要的原因之所在。真的公司里系统分析员太少了，可以说根本就没有。只能让程序员去代替系统分析员的职责了，我想那段开发的时间纯粹就是在想象式的开发，没有任何目的的开发。那次听了台湾一个也是做建筑行业的ERP公司的演讲，真是太让我感觉到国内与台湾之间的差距了。更让我体会到做项目真的不是那么的简单。
如果不把系统分析放在最终要的环节，恐怕你永远只配做一个Code Worker，往好了说也就是一个High programmer
系统分析决定你的项目工期，将来的可扩展性，它代表了一个一个人真的从根本上将业务完全理会。并且能在这方面能提出自己独到的见解。这将是做项目的第一步，也是最难的一部。
编码：
谈完了需求，我想下面的编码应该是大多数人接触最多的，我也是一个狂热的技术分子。对技术有无比的热情。但是热情有时会让你掉进陷阱。
对于将业务模块进行抽象，ERP技术已经是千篇一律了。没有什么只得在这里进行分析的。只是系统构架还算可以，扩展性不错。还是那句老话，将业务模块抽象成类是比较好的。恐怕这也是大多数人的设计方式，希望大家畅所欲言，希望大家在这里都能学到一些东西，也是我的初衷。
我想在这里也问问大家，你们是模块式的开发呢，还是将整体构架搭好后在进行模块式的开发。一般我看大公司的开发模式都是先将用户界面画好，然后提交用户审核。通过后进行业务抽象，具体编码。当然了我们也是采用此方式。不知各位还有什么好的方式？
测试：
测试我想不能发到最后来讲。测试是紧跟开发的，开发必定需要测试。有时候流程走不同必须要经过测试，才可以进行一步的编码。有些问题要问，测试人员应是什么样的人员，例如是市场人员，或者是刚毕业出道的学生，在或者是编码人员，更甚至是系统分析员。最后或者是用户。我得意见是将用户用作测试在好不过了，我想大家还有什么别的看法，希望大家能有常人不同的见解与看法。那我发这片帖子就收获不小了。
实施：
我想作为一个大的项目，实施是一个非常重要的环节。首先要讲自己软件的思想灌输给用户，特别对于一些对信息技术比较落后的客户，要进行不断的培训与思想感化。讲清楚软件的最终意图，或者这套软件到底能为他带来什么，能改变什么。
望大家畅所欲言，谈谈是怎样做项目的。更多的是让我们这些小辈能学点东西。
我想在中国来说，系统分析、编码、测试、实施一个人做的情况多的是。只是我没有做系统分析（别人做的），也看到了
系统分析的重要性，并且我是深受其害
对于我们这些程序员来说，我想更多的还是提升自己。不过我想提到一个名词：合作
不要只埋头写代码，提升自己对整个项目的把握与业务的理解。将会减轻你的这种压力与烦恼。在我的眼里系统分析员是比不可少的，并且是具有非常经验与编程技术于一身的高手。他能从整体上把握整个项目的进度，并且与于客户的交流变得更容易。将客户的思想用编程的语言将给程序员，他是架设客户于程序员之间的纽带，是合理分配任务的管理者，是能让程序员发挥自己最大价值的使者，更是贯穿整个项目的灵魂。自始至终担任着艰巨的任务，可是这样的人毕竟少之甚少。
也许我们正是继承这个艰巨任务的，让我们程序员从整体上提升自己。看到眼前虽说是狼藉一片，但是更多的挑战摆在你的面前，更多的机会摆在你的面前，只要你用心……
只有想不到，没有做不到！