不懂了，软件到底怎么做？
茫然了，难道不应该站在用户的角度去思考吗？
原本那些将来会使用我们软件的人已经约定俗成的概念：为什么我们这些做开发的还要抽象成别的名词呢。
那只是你的理解。你做出来的软件最终还是要给用户用，你把他们本来理解好的概念，抽象成别的了。就像本来在他们日常
工作中已经习惯的流程，概念，你把他改变了，按照你的理解改变了，用户还怎么用，用户觉得不好用，还会买吗？
连我们这些开发的人都不能理解的概念。为什么不能站在用户的角度思考。
我现在还要测试这样的一个软件的功能。
大到作为一个用户单位日常工作的流程习惯，
小到一个小对话框的各个参数的配置，可供选择的属性（读写问题，变量单位）有很多很多问题。
说了也没有，还是让我测功能。测结果。哎。。。
既然说了，让我测软件好不好用，我说了不好用的地方，又把我拉回到他的理解当中。
我作为一个这个项目开发的参与者，在你的解释说明的情况下，我理解了流程，但是我们做软件不能一味地自己想怎么样就怎么样。还是要站在用户的角度，根据他们日常的工作流程，根据他们的习惯，来做软件。
项目开始时，没需求调研，没有需求分析，其他的什么概要，详细设计，什么都没有，
作为今年才毕业的我，在我的理解作软件就得明确需求，开始写代码前，就得做好充分的设计。难道那些软件工程学，项目管理学上学的那些理论，以及那些成功的，失败的项目实例，都是虚构的吗？
7个月前我就疑惑了为什么我们这个项目没写需求，没有画个什么UML，什么的。
忽悠我。我是搞不懂，这个软件到底是怎么做的。
是我没经验，想得太理想，太按软件工程上的那套理论，
还是主管太自我，专制，顽固。
不懂，不懂，真的不懂。
20万的项目，200万的项目，有多大不同？小项目就不需要分析需求啦。
郁闷中。
慢慢熬吧。。。。
坏情绪out
呵呵。。。今天是圣诞节，祝各位 圣诞快乐，有个好心情.
[解决办法]
一样，一个人包办所有
[解决办法]
up
[解决办法]
基本流程还是一样的
用户的需要最重要
[解决办法]
这公司没前途，楼主另谋高就吧...
不讲软件工程的作坊式开发也许还有存活之道，但不从用户角度考虑不做需求分析就闭门造车的只有死路一条...
[解决办法]
这些理论虽然重要，但不太符合中国的实际，中国的软件都是在开发的过程中积累需求
[解决办法]
程序时写给用户用的啊!!?没办法!?
[解决办法]
很多的东西都不是照框框来的.
[解决办法]
理想终归不是现实
社会主义到了中国还是得叫 具有中国特色的社会主义。
而原创的 苏联 早就不是哪里去了
[解决办法]
楼主啊，我终于找到同道中人了，呵呵
什么是好软件？用户觉得好，才是真的好！
[解决办法]
[解决办法]
1、在国内做软件还要会做咨询，你面对的客户有可能并不是业务专家或者企业管理专家用户的描述的需求不见得是企业真正的需求
比如客户说要一个统计表格，你是不是能够判定出他实际需要一个统计图，并且能得到用户的认可，
又比如通过调研，你能不能发现一个企业实际需要的功能，而他们并没有意识到，
所以客户最根本的需求只有2点：1、你能“猜”到他们的需求；2、满足变化
2、好的产品是工业化和人性化相妥协的；
3、需求分析可以从6个角度展开:
动机：用户为什么需要他描述的那些功能、影响企业发展的的重点制约是哪些
行为：用户现有的业务列表、用户希望增加的业务列表
数据：用户现有的数据列表、用户希望增加的数据列表
人：用户的人力资源架构以及人力资源策略
地点：实现功能的地理位置的分布、
时间：相关的业务周期，以及软件项目能考虑到的时间跨度
4、把握和发掘客户需求以及软件生产方式基本就是软件公司的核心竞争力了，所以：很难很难。
5、比尔盖茨在退休接受专访时说：不是我们做得好，是其他软件公司做得太差了，他们不重视客户需求，不及时更新软件……
[解决办法]
We do make a difference!
[解决办法]
用户的描述的需求不见得是企业真正的需求
-----------------------------------
不过常听大虾说：国内软件行业就是骗钱。
也不知道是真是假...
[解决办法]
如果我的客户认为我们骗钱，那说明我们做得太差了，
我们离党和人民的要求还很远
[解决办法]
理论只是指导思想，有时候过于理想化，要知道实践和理论有很多时候是脱节的。必要时候，可以修改理论的，而实践改变起来就有点儿困难了。思想要灵活一点儿，思想是人进步的推动器，不要让它成为负担。楼主还是好自为之……
[解决办法]
------解决方案--------------------
[解决办法]
我很喜欢直言不讳，傻得可爱，也可敬。等你工作一段时间将来“放聪明了”，很可能就不可敬了。
办公室政治其实是可以让人无以立足的。一方面，喜欢批评的人往往又不能成事；另一方面，许多老板经常因为某人说了一两句话就认为不是自己人。
高软件开发的，能做自己的人越来越少了。
[解决办法]
为什么意识不到用户需求？
其实不是意识不到，一方面正如你说的，可以归咎于前期设计不够全面。不过过渡强调前期设计的人几乎（99%以上）都变成了再讨论编程方面的小伎俩，结果前期设计得到的是垃圾，仍然不能明白业务。由于走形式（例如遵循CMMI）也仍然不能搞懂设计要诀，于是只好放弃。
许多时候，我们挑出简单的几点问题就能攻击别人，但是轮到自己做到让别人挑不出来就完全蒙了。这就是难点。带着好的目的，求全责备，也容易从另一角度把工作引向失败。
于是许多人不论理论多么漂亮，实践时也不过是“功能分解+强迫加班+小恩小惠”这种作坊管理思路。
求全时还能够保证项目进展更迅速、更敏捷，这是需要一定的软件工程技术的。软件工程的核心技术是你看不到的，你只能看到一点成果。
[解决办法]
[解决办法]
[解决办法]
唯一不变的就是变化
[解决办法]
现在开发和测试的好像都是这样子的呀。不过这些东西都依需求做为依据就好了，开发人员只听需求的，呵呵
[解决办法]
up
[解决办法]
楼主,能不能把你的头像换一下。？
按照我的经验，软件工程书上说的基本没错，就是有些书稍微落伍了一些。
软件怎么做，其实不同的公司会有不同的风格，做产品和实施一个项目也会不一样。
我们做项目的时候，我可以很负责任的告诉你，我们就是写软件需求规格说明书的，就是从概要设计到逻辑设计再到详细设计，即便只有2个人的时候，仍然会做设计，至少会做逻辑设计。
从项目发起时的商务洽谈的意向开始，一直到最终的用户测试报告，每一步都是要做的。
楼主你要坚信，书上的没骗你，我们就是这么做的，我见过的其他项目团队也是这么做的，否则就是灾难！
概念转换，需要看是用户测试，还是项目内部测试，你把教科书翻出来看看整理一份测试计划和测试用例出来，然后按照测试用例去测试，你再去看看怎么做回归测试，测试很耗费时间。有时候为了控制风险，还需要整理每日缺陷统计，做成图表给项目组。
这些不是天方夜谭，我们就是这么做的，所以做软件是很辛苦的。
用户测试的时候会轻松一些，如果前期做得比较充分，那么用户测试就是走过场，但是，往往是用户测试的时候发现需求偏离，这时候要么让用户认可现有结果，要么让用户认可增加的工作量再做变更，如果用户都不认可，就意味着项目会加班，累得半死还被老板骂。
[解决办法]
用户需求说明书(客户)—>需求规格功能说明书（分析师和架构师)
[解决办法]
很傻很天真，这么说吧，软件工程，最基本的三个条件：资金成本， 时间成本，人力成本。
现在国内的行业情况就是这样了， 恶性竞争导致软件成本被压缩到最低点，项目周期同样如此，
关于人员，一个很著名的“彼得原理”即不称职现象， 目前十分充分地体现在了中国的软件行业，本职工作做得稍有起色都想着高升了， 而绝大多数的职位都是刚刚上任的，可以做好项目统筹和规划的pm，在考虑自己做公司，或者晋升部门经理，可以写好需求分析和设计的人，都在筹划着晋升为pm， 可以写好程序的人，都在计划着转leader，可以负责任地说，国内60%以上的团队都是这样组成的，那么三个条件的任何一个都很难保证，还谈什么软件工程呢？
[解决办法]
买本项目管理的书，仔细看一遍，就知道了。
[解决办法]
up