最近项目的几点感受

qbhua 2003-02-18 09:46:14

从大学算起，接触计算机已经九年了。也许做过或是参与过不少的项目。
基本上没有一个项目是令我满意的。
最近参加一个方案的编写，我负责写一个子模块。对这个方案，感觉甚是不爽。我参与进来写的时候，其方案的目录与模块都已经定好了。

1.需求分析其实没有分析，完全只是一堆原始信息，没有整合加以分析。现在好象很多做需求的在分析方面都做得不够。

2.模块划分极其不合理，相互交叉太严重，耦合性太强，并且作为总体设计，针对一个大系统来说，模块的划分粒度过小，应该以更大的粒度，如子系统之类的概念来表达。

3.与用户交流设计方案的问题。呵呵，很多公司的人都强调幻灯做得越乎越好，首先要用户晕，甚至自己也跟着晕。
，，，有很多感触，极其不爽。

...全文

78 26 打赏收藏转发到动态举报

写回复

用AI写文章

26 条回复

切换为时间正序

请发表友善的回复…

发表回复

zhf_karen 2003-02-24

打赏
举报

在一些系统中,的确,需求是成熟的,但是我个人认为,并不是所有的需求都可以归类玉这样的需求,比如我说过的行业软件,比如以前公安部门是采用农业户口,非农业户口,但是,在现在,仅仅是一年,需求已经出现一些所谓"实住人口"的观点.这不可以仅仅说需求是存在的.但是挖掘不够了.这是一方面,在另一方面,任何工作是需要付出代价的,比如,了解所有的需求(即使仅仅是用户方面的使用需求),而且,这意味着对需求人员,设计人员的要求极高,开发人员可以通过Debug来完成软件的调试,但是,需求人员不得不去做脑袋里的Link,Debug,设计人员也是一样.

工作是需要一项一项做的,但是,如果风险控制在你可以接受的程度上,你还是应该开始下一部分的工作.需求的修改的可以接受的,而且几乎也是必然的.不然用户层很难给予你一个肯定的答复的.

还有采用哪些方法开始项目,也和公司的价值观有一些关系.这一块话题比较多,我不详细说了.

其实,从市场层面来说,还是采用迭代的方式比较合适一些,你可以看成这是一种方法,来引导用户说出他的隐藏需求.这有点象我们现在说的Visual Thinking的工作方法.我知道,在当时我开始迭代开发地时候,我也非常抱怨,担心,因为你必须对项目负责,同时不愿意由于某一种开发方式,引入其他地风险,对于这个,我曾经和Ozzzzzz争论过,呵呵,现在我认同了这个观点.你可以尝试一次.的确是在降低风险.当然,我一直认为这样地开发方式未必适合所有形式地软件,但是,对于应用系统来说,应该是比较合适地.

顺便说一句:需求有隐藏的,但是,需求更多层度上是技术人员和用户对需求的理解不同,有一屹笑话:一个老和尚,要一个小和尚去拿一本书,书拿来了,老和尚说:太薄,于是,小和尚以为老和尚说书的内容太简单,一本一本地挑有内涵地书,其实老和尚仅仅想用他来垫枕头.我们称那样地需求为需求后面地目的需求,而把一些需求称为表面需求.

whwjn 2003-02-21

打赏
举报

skywww 2003-02-21

打赏
举报

真是不错！我被你们的思想深深的吸引！你们现在讨论的我无法参与，因为工作环境不同，但我能理解你们说的东西，我正在做一些非商业性的软件开发，你们的想法对我很有启发！

zhf_karen 2003-02-21

打赏
举报

恩,看了,有点意思,我思考一下,现在也没有时间了,周一讨论吧

zxdragon 2003-02-21

打赏
举报

http://www.csdn.net/develop/Read_Article.asp?Id=17010

zhf_karen(zhf):
看看第五条，呵呵，开个玩笑。
需求一直都存在着，只是你不能将他捕获。你怎样引导他自己描述出“隐藏”的需求，而同时又不误导他？很高深的艺术哦...

kanaima 2003-02-21

打赏
举报

zxdragon(zxdragon) 、zhf_karen(zhf)从你们的谈话中我受益良多
希望看见更多大家能说些更精辟的见解来：）
关注中......学习中......

zhf_karen 2003-02-20

打赏
举报

bjzhanghao(bjzhanghao)：
产品和项目的需求差别很大,大到你不可能从这个项目项目中抽一点,那个项目里抽一点,就可以形成产品.当然这是我个人的观点,因为我实在没有看见过如此完美的事情,而且在我们实施过程中,也发现在产品形态上,他们实际上是不同的东西.

回答这个问题,首先要明确一点:什么是产品,我想大家对此都有自己的概念,如果你认为给用户部署上的系统就叫产品,那么就没有讨论的意义了.我的产品的概念是可以由部署团队在脱离开发团队的基础上给用户部署.你可以给部署团队提出比较高的技术要求,但是,不要什么工作都需要开发团队来做.

于是,你就发现,在项目上,我们的理想目标是提取用户100%的需求,然后实现.而在产品需求需求上,我们的理想是提取使用用户80%的需求,提取高级决策用户120%的需求,如果你不理解那个行业,那个产品,那么还是从项目开始吧.直接做出来的产品,说难听了,就是一个Demo.看看是可以的,但是很难适合用户的需要.

上面的话说得比较虚了,虚得话都很容易说(还真得有一帮人靠着虚得东西就能挣钱,比如客户导向,比如综合,决策,统一,平台.然后大家就认为他很牛,好期待啊,我哪天也能成为那样的人),我试图举一个例子,希望能够表达出我得意思:
比如你做一个ERP数据抽取传输平台.如果你按照项目做,那么很简单,你去了解你需要从哪些系统中抽取什么数据,然后做数据集市,然后给OLAP抽取抽取就可以了.如果我需要你做一个产品,那么你就会发现你的目标太大了,我就从一点着手,比如消息中间件(主要负责数据的传输),我要首先要满足安全稳定的数据的直接传递,然后,我要求网路路由的可配置,然后我要求网络带宽要可以充分利用,然后......,这样的产品很难从所谓完成一部分功能,然后再完成一部分功能来做.因为开始做产品(包括项目)以前,我们需要基本需求,所以这些需求的提出来源就包括项目的需求,相关产品获取,行业专家的意见提取等等.并且需要一个好的产品经理,来对产品进行产品规划.我想说的意思是:在产品中,没有人明确告诉你要做什么功能,不做什么,哪些功能是共性的,哪些不是,这一切依赖于你.所以我们认为,使用项目方式做产品,往往出来的东西就是一个没有用户需求的项目.

希望我说明白了.累,其实,如果我自己说这个概念那么累,也说明了我对这个概念的想法不成熟,权当作一面之词. :)

载舟之水 2003-02-20

打赏
举报

深有同感，在中国搞研发是比较困难，中国的大部分IT公司的能力成熟度（管理方面、技术方面、及其他诸多方面）还只达到第二级别（项目的可重复级别），如果项目要成功只能依靠项目中一个或几个核心角色，其他人就是有好的想法也只能干着急。所以我们的项目经验大部分都从失败项目中积累的，我们甚至不知道要成功的实施一个项目该从何下手......
最后以此句做结“趁风破浪终有时，直挂云帆济沧海！”。

fallentopaz 2003-02-20

打赏
举报

可怜，我的思维还是停留在coding阶段。

zxdragon 2003-02-20

打赏
举报

zhf_karen(zhf):
呵呵，你说的我有深刻体会。我们原先经常给客户作基于我们自己的一个产品的定制开发，争取单子吗。定制的功能较容易实现，但是如果想在好的定制功能中提取共性，加入到产品中去，成为Common功能就是另外一回事了，难得多，关键是较难把握。
：）

twinsant124(蚂蚁的天空) ：
在现在国内的市场上，除了金碟用友之类的大户
Product for market sales is more difficulter than for project:)

twinsant124 2003-02-20

打赏
举报

Product for market sales is more common than for project:)

zxdragon 2003-02-19

打赏
举报

zhf_karen(zhf) :
谢谢你的指教。
最欣赏的就是最后一句话了，听到很多遍，但是暂时很没有很深刻的体会。
我会向着这个方向努力的...：）

zhf_karen 2003-02-19

打赏
举报

zxdragon(zxdragon):
恩,我很容易理解你地说法,因为实际上,我以前也是那样做的.大家交流一下.

用户的需求是肯定会变化的.这不是以你的意愿为转移的.因为这基于两点认识
1.在用户看到东西以前,连用户都不清楚她的需求是否一定是完备的.这一点,你可以从你使用电器的情况上想象(我要VCD机器,我要遥控器,我要定时自动关机,我希望能够一次放多个碟片,顺序不一定对,大致意思是那样的)应用系统对用户来说是陌生的,他们最开始的想法就是吧现在的工作搬到电脑上实现,但我们都知道,如果信息化就是这么一个东西的话.我们是在没有必要去做着样的信息化系统.
2.用户的需求是不断发展的(这在行业产品中非常多见),用户会今天提出一个想法,过了一个月,又提出另一个想法,这代表着他们的思路在进步.
以上两种都是大家都在认真做事情的情况下,更别说大家都在"糊弄"的情况

如果抱着我要做好一件事情,然后才能走下去.那么最大的可能就是你永远走不过去,还记得一些学生发誓除了北大其他学校不上,他们的结果大多数情况下,就是把自己耽误了.

你说得很对,我们不能去误导用户,但是这是我们可以控制得,相对与对用户的要求,这一点更容易做到,实际上,除非设计人员故意,误导用户是不太可能的,因为在那个行业,还是客户是专家.顺便说一句,设计人员是应该了解系统,但是并不意味着设计人员和用户拉需求,应该有特殊的需求人员来负责,我们实际上,故意使需求人员脱离设计,让他仅仅对用户需求负责.了解"做什么",而不讨论"如何做,成本多少".

目标和我们做事情的方式中间是存在差异的.我们采用先期设计介入,就是为了降低风险.因为评价风险有风险的后果,风险的概略,风险的解决措施,风险的应急措施,应急措施启动时间等综合考虑,在实际使用过程中,在有经验的项目经理带领下,采用迭代的方式使可以接受,至少在我们使用一年多的情况下,还没有项目仅仅因为使用迭代方式而导致失败的.

这一点,你可以通过一两个小项目来实施一下,注意一点,我们在做的是工程项目,所以别给自己提出非常完美的要求,虽然你可以往那个理想去努力,但是,别让理想阻碍了你现在的行动.所有项目能够按照质量,时间,成本完成,你就是一个异常优秀的项目经理了.

Jinq0123 2003-02-19

打赏
举报

有位前辈告诉我需求分析不可能完备。
我自己的经验是：明确的需求是理论上的假设。瀑布开发模型就是基于这一假设。实际操作中，能确定的需求都应文档化，通过原型挖掘模糊的需求。需求越明确，设计会更容易把握。但设计和代码阶段仍会发现不完整的需求，应及时变更。只要需求分析阶段确定了基本问题，细节性的需求变更不会对项目产生大的扰动。正因为需求总是不可能完全明确，甚至在产口发布以后仍会有新的需求认识，不可以死板地套用瀑布开发模型。

imdt 2003-02-19