需求，谁说了算？
详情点击这里阅读http://blog.csdn.net/vancechan/article/details/13623999很多牛人的大作在说到需求时，大多数的人都会说“需求是在产品构建之前必须要发现的那些东西”。ok，我同意此观点。
那么你呢？和我一样的观点吗？
那么需求谁说了算呢？
客户，购买者，管理者，出钱让我开发软件的人，使用者。。。等等，也许你列出的比我还多。他们说什么我就做什么，客户是上帝，要听客户的话，要站在客户角度想问题，做事情，领导才会中意你。从你的职业生涯来看，是这样的吗？
我举个例子，知名艺人某冰冰，最近身体不舒服，来到了医院。对医生描述症状说：最近有点恶心呕吐，头晕目眩，有点儿发烧，不消化，睡眠不好，脸上还长出了痘痘。冰冰其人虽然长得好看，身材火辣，但是性格强势，在耳濡目染中对医学知识也有一些理解。脾气也比较急躁，啥事都想越快办成越好，于是乎，她就展现了其女王的一面。对医生说到：我很忙的，想好怎么治了吗？这样吧。你给我开点阿莫西林，开几片安定，一盒健胃消食片，再来点去火的药。好了，就这些吧，赶紧去办。。。
软件开发过程中，是否你也有遇到类似的经历。
某总对某项目经理小刘说，我们要开发一套采购预算系统，需要管控每个部门的采购预算，控制企业的运营成本，采购的时候，各大小领导需要审批哪些东西可以买哪些不可以买，是否超出预算等，这个系统对公司很重要，小刘啊，你赶紧组织团队开发吧，时间紧迫，年底之前要上线。能不能拿年终奖，就看你了。
为了满足客户的需要，我们必须马上行动起来。
医生给冰冰开了她想要的药，项目经理开始制定计划，组织程序员，程序员开始编码，测试员准备环境，好一派热闹的景象。可接下来大家会面临的是什么？(停留思考片刻…)
噩梦，难道不是吗？
冰冰用药后没有效果，天天电话骂医生没用，自身又受病魔困扰；某总迟迟看不到成果，程序员不知道到底要构建什么什么样的产品，项目经理无法推进项目进度，用户反馈说这不是我要的。。。各种噩梦。。。慢慢的有人开始抱怨了，选错了人，选错了行业，选错了职业，有人换了工作岗位，有人转了行，有人开始感叹命运的悲催了。。。
这样的场景是不是在我们周围经常见到呢？
为什么会是这样的剧情？神啊！救救我吧！
老实说，这个世界上没有神，能改变现状的只有自己。
大多数情况下，医生面对冰冰这样的客户时，需要采纳的是其对病情的描述，而非开什么药的解决方案。（事实上，好的医生都是这么做的）。医生接下来要做的事情，抽血，量体温，或者把脉，拍X光片。。。搞清楚病人的病因。刚刚怀孕的症状和感冒发烧的症状有些相似，但是如何治疗却有根本的区别，难道不是吗？医生在找到病因后，开出处方1,2,3，这才是病人真正的需求。
软件开发过程中对需求的归纳，与医生开处方类似，但是医生比项目经理做得要好。为什么？医生诊断不力，后果会及时显现，严重程度可以评估得到。而一个软件系统，好与坏，谁去评估过？这也是造成乱象的原因之一。
项目经理在听取了某总的描述之后，接下来要做什么？组建团队，制定计划。。。当然不是，前文已说。
首先要明白的是，某总提出的仅仅是对未来软件产品的一个愿景，或者是一个期望，而绝非需求。在这个愿景或者期望之下，进一步理解它所涉及到人，部门，需要改善企业哪个环节的业务以及需要花多少资金来达成这个愿景。这个和医生需要了解病人愿意花多少钱看病其实是一个道理。
其次，理解愿景之下，找出当前的问题所在。正如医生给冰冰做的抽血，量体温，把脉，拍X光片，这一系列的检查。然而在软件开发过程中，认为这样的检查就是在收集用户的需求，或者这样耗时太长，耗不起。我认为这是大错特错的，做不起来，不是因为耗时长，而是所需的技能没有。然而实际上很多人都是在这样做(还没明白要做什么的时候，就已经开始构建产品了，建几个表，CRUD走起)。这样做的后果就是噩梦，噩梦啊。。。
很多人都这么做，并不代表这么做就是对的。当今社会世风日下，道德沦丧，崇拜金钱，很多数人为钱不择手段，能说这是对的吗？
在找出当前问题所在之后，其实需求也就呼之欲出了。
比如：现在的问题
1.部门主管知道部门今年的预算是10万，但是不知道到目前为止已经花了多少钱，都花在哪些东西上。那么未来的软件系统就必须让部门经理看到当前的结余，以及钱都花在了哪里。
2.采购申请，或者采购人员采购某物品之前，不能及时知道该物品的库存，可能出现重复采购，造成库存积压，资源浪费。未来的软件就必须显示当前物品的安全库存，以及消耗规律等参数，提供给采购人员作出是否要采购的决策。
3.。。。不一一列出了。
这里列出的1,2,3就好比医生开出的处方。冰冰的病要怎么治是医生说了算。软件的需求是软件设计人员说了算，整理出从客户期望到软件需求的推理过程，并与客户沟通其可行性，再以文档形式记录结果，开发团队有了这样的文档，还不知道要构建什么样的产品，或者构建出来的产品仍然不是客户想要的，那么至少可以说明问题并非出在需求上。
从客户的期望出发，得到软件需求，这个过程其实很难，需要的各种软技能，谈判，沟通，演讲，总结等等。这个过程做不好的直接结果，就是后续工作中团队成员的各种迷惑。
到此，你还认为需求是某总，某客户，某冰冰提出来的吗？他们提出来的只是愿景，期望，或者是现状问题的描述。而需求是你依据现状问题得到的解决办法。
怎么通过程序区实现一个需求， 又对应着有很多种解决办法，这属于软件设计的话题了。一个设计又对应着很多种实现方法。。。后续博文会慢慢道来。
需求 项目经理 软件开发 软件设计 职业生涯 --------------------编程问答-------------------- 当然是客户说的算.不然尾款不给你怎么办 --------------------编程问答-------------------- “客户”和“需求”之间总会存在着一个变态 --------------------编程问答--------------------
至少一个 --------------------编程问答-------------------- 钱说了算，简单来说，资本推动了社会的进步和变革 --------------------编程问答-------------------- 变态?
why? --------------------编程问答-------------------- 感冒发烧，即时不吃药也能自然痊愈；
项目没这个能力，实际操作上难度更大； --------------------编程问答-------------------- 要看你的沟通技巧了
--------------------编程问答--------------------
沟通技巧再好，也不能直接得到需求。
医生如何治病不是病人说了算。
软件如何开发同样不是客户说了算。
其实我想说的是获取需求的一种正道。 --------------------编程问答--------------------
因为没有沟通，才有患者杀医的
--------------------编程问答--------------------
这个事件不在于有么有沟通导致的。
你去看医生，不可能什么症状都不说，就接受了医生开出的处方。
当然医生也不可能什么都不问，就看出处方的。
沟通肯定是有的，只是没有找到双方的平衡点。造成一方感觉吃亏了。所以杀之。
软件开发过程其实也有类似的场景。
要么开发方像孙子一样，客户说啥就是啥，
要么客户方像孙子一样，你做出什么东西，他就用什么东西，结果就是迟迟不付账。
上述两种都是导致项目不成功的原因之一。
甲方乙方能通力合作的时候，项目成功才会有基线。 --------------------编程问答-------------------- 你用医患关系打比方就是不对，中国医少病多可以去各大医院门口看看就知道了完全是卖方市场，更恰当的比喻应该是饭馆你花钱却不上你要的菜你怎么想
--------------------编程问答--------------------
+1.在中国，有权的人不懂，懂的人没权 --------------------编程问答--------------------
--------------------编程问答--------------------
--------------------编程问答--------------------
给钱的是大爷
--------------------编程问答--------------------
楼主提到的东东其实与需求无关，更多的是客户关系方面的问题，当然，打好客户关系的难度并不亚于需求分析。我觉得需求分析最难的是，我们通常只是IT行业的专家，并不是客户所在行业的专家。
在短时间内，我们除了依赖客户，根本没办法熟悉他们的行业。
但许多时候，客户也只具备经验，不具备理论知识，所以他们在描述需求时会颠三倒四、词不达意，甚至自相矛盾、南辕北辙也不稀奇。
而我们对行业两眼一抹黑，客户说什么就是什么，根本无法怀疑。
等到项目做出来了，客户一使用 ———— 靠，这不是我们想要的嘛！
别和我提需求冻结，客户在需求规格说明书上签了字也没用 ———— 你可以在需求冻结上卡客户，客户也可以在验收上卡你。
唯一的解决之道就是，我们成为跨行业的专家。
不过行业这么多，你能跨几个？ --------------------编程问答-------------------- 敏捷开发的优势就体现出来了，至少不会等到所有的错误都犯了之后才去改正。
敏捷开发是贴近客户，小步前进，短时间迭代，把错误减到最小。 --------------------编程问答-------------------- 项目的发起者，使用者对需求说了算，我们有责任挖掘处需求并将需求实现。
关于你举的这个例子：
某冰冰提出的要什么药的时候，她的身份就变了，她已经不止提出了需求，
她连实现方式都给你了，她变成了项目实施方式的提案者，
在这种情况下，评估他的实施方案的风险才是应该要做的事情，
你都没评估实施方案的风险，就直接开药方，那搁谁那里都会骂你，
但是如果事先明示了这些风险，客户自然也会接受并愿意和你一起承担这些后果。
某冰冰说，我忙，我没时间检查。
那在这种不确定性及其大的情况下，这种项目无法动工，你就算做好了也很可能不是客户想要的，
这种摆明了要吃亏的项目不如不做，但是可以告诉客户，我们需要什么样的前提才能开始做，
或者是在现在的前提下，我们只能做什么，选择权交给客户。
作为PM，有些事情可以硬着头皮扛下来，有些是无论如何不能扛的，这不利于个人，更不利于项目和客户，
这是一种及其不负责的做法。 --------------------编程问答--------------------
--------------------编程问答--------------------
需求天天改，烦死了。
--------------------编程问答--------------------
撸主，你那样做确实不错，但是在当今情况下，根本没有条件让你这样做，老板再催，急着回款，项目经理在催，急着验收，客户再催，急着上线，你有什么时间经历去做？就算你是老板，自己干，我估计也干不长久，因为早就拖死了。
--------------------编程问答--------------------
三流项目经理，客户逼着走。二流项目经理，跟着客户走。
一流项目经理，带着客户走 --------------------编程问答-------------------- 病人有什么病，应该怎么医，当然是医生说了算。
但,软件的需求绝不是软件设计人员说了算.
你的立论根本不成立。
最大的问题，你的类比错了。
病人唯一的需求是,我不舒服,我要治好它。
他不知道他要怎么治，这件事上，医生懂得比他多。
但你写业务软件的，具体流程，用户比你懂得多，而且多很多很多。
你不是医生，医生也绝不是你。
他对你的要求，你看到的只是表面。
用户可能告诉你，这里"我要右击，而不是双击",也许，他并不是真的有这个需求，只是他不能完整描述出来(比如你右击已经让其它事件替代了)。
你的问题，在于你不能正确引导他描述。
用户要做的也许只是一辆单车，你会做个坦克，甚至一颗原子弹出来，对他来说，都没有用。
看你的语气，就是刚毕业的小屁孩，再过几年你会懂的。
你的项目经理也许是混出来的，但一般，绝不是混出来的。这件事，只可意会，不可言传. --------------------编程问答-------------------- 的确国内的情况真的不如人意 --------------------编程问答--------------------
没错！！！ --------------------编程问答-------------------- 问题是：你不是“冰冰” --------------------编程问答-------------------- 1、“刚刚怀孕的症状和感冒发烧的症状有些相似，但是如何治疗却有根本的区别？”
2、需求这个东西是需要引导的，有的时候客户也搞不清楚他们到底想要什么，这个时候需要多沟通、多交流，磨刀不费砍材功~~~
3、当然实际操作过程中你也会面临需求不断变化这个事实----这个时候就得看你能力以及魄力了，不能跟着客户或者领导的思路走，要在他们的基础上综合评定，关键时刻要会说“不”。 --------------------编程问答--------------------
--------------------编程问答--------------------
需求当然是客户说了算。只不过客户很多时候需求不明确，
需要引导提取。
有时候客户提的实际不是需求，而是他认为实现需求的手段。
好像有人想上山，他觉得开车上去比较好，因此要找辆车。
而实际上有缆车，更本不用车的。
因此调查需求的时候，就要多问几个为什么， --------------------编程问答--------------------
--------------------编程问答--------------------
顶这个。
另外，这种烂题都推荐上首页，这版主不是帮着找人抽你吗? --------------------编程问答--------------------
--------------------编程问答--------------------
给谁用就谁说了算
--------------------编程问答--------------------
问题是，给钱的都是发号施令者，而不是执行者
--------------------编程问答--------------------
其實呢？需求，老子說了算！
--------------------编程问答--------------------
客户提需求的时候，多问问为什么，60%通过沟通就能解决，并不需要做大的改动。但有些领导性指令没办法，虽然明知bt，but用户给钱啊。 --------------------编程问答--------------------
太对了，
很多时候前期需求调研时，客户的需求是模糊的，更有一些一脑x糊的用户，连它自己要什么都不清不楚，
必须要你开发出来第1版本，先用用再说。
--------------------编程问答--------------------
--------------------编程问答--------------------
这就是是典型的“纸上谈兵”。
至少对于管理软件而言，大多数需求，都是在用户看到你得产品原型之后才会想到如何更加准确地告诉你。之前用户根本并不知道该怎么告诉你需求。
因此需求是千变万化的，而且会在用户看到产品演示、开始试用等等之后，随着用户的体验增多而不断涌现出来。 --------------------编程问答-------------------- 软件开发必需依据“需求”，但是有些人为什么会把这句话反过来理解、而成为借口呢？
聪明人其实一下子就可以看到某些人的问题出来。通常这些人的开发水平是作坊式的，公司没有平台、没有在一个行业深入研究的经历，没有在一个具体的领域有（至少）十个用户正在高强度地使用你们产品的“市场”。往往是那些“刚开始做”某个领域软件的小作坊软件公司，想用非常低层次的手工开发方法、找几个实习生就能应付用户需求，可是用户又太“矫情”，于是当自己的人员因为无限制地加班儿“怠工”之后，就会提出跟用户那边“冻结需求”的想法。 --------------------编程问答-------------------- 如果你们的所谓的软件产品研发，以为就好像那些“按照书本知识开药、开一大堆检查单子”给病人的小医生一样容易对待，那么我相信你们的销售其实靠某些人的“脸”去销售，你们的技术开发人员只不过整天躲在公司办公室里说三道四。
这个所谓的“软件的需求是软件设计人员说了算”，靠的绝不是你们现在这么低级的产品，而是别的产品或者别的人。 --------------------编程问答-------------------- 我们一般只是了解IT方面的技术，但可能并不了解客户所在的行业。
在软件开发周期内，我们除了通过客户去了解这个行业，很难有其它方法去了解了。
正如上面有人说的：“许多时候，客户也只具备经验，不具备理论知识，所以他们在描述需求时会颠三倒四、词不达意，甚至自相矛盾、南辕北辙也不稀奇”
所以你自己写的需求根本就达不到客户想要的那种效果，虽然先把需求写好然后交给客户确认，但这种做法其实也不能完全的保证你做的东西就是客户想要的..
--------------------编程问答--------------------
--------------------编程问答-------------------- 即时搞需求需要很长时间，在开始做项目前必须把项目需求跟客户沟通好，让客户确认过才开始付诸代码，不然后期的麻烦会接憧而至。 --------------------编程问答-------------------- 我们公司测试人员都会跑过来给我说:哎呀,你们这个需求有问题,用着不人性化什么的. --------------------编程问答-------------------- 自行车自行车自行车自行车 --------------------编程问答-------------------- 客户说了算……
while( 回扣==null ) 重写需求;
------------------------------------------------------AutoCSDN签名档------------------------------------------------------ --------------------编程问答--------------------
这种测试人员不用太理他。通常你们应该立刻这样来“表现出合作态度”，问他：你们有测试用例吗？如果有一两百个测试用例，那么请拿出来咱们开会讨论一下你们的测试用例，然后再来纠结什么“需求设计”问题。
通常，测试人员会灰溜溜地落荒而逃了。因为他们自己没有技术，却指责开发人员。
任何合作都是相当程度技术人员的合作，不可能让那些成事不足败事有余的人指手画脚。
不够话要回到lz的问题上来，如果软件设计人员没有长期积累而形成的随需而变的平台技术，以为靠低级地对用户说的一大推未经设计过的需求描述就进行“功能分解”、“要求用户冻结需求”等等教条来知道开发，是不行的。
一些学了一点点书本知识，或者被 PMBOK 之类的给建筑项目用的工程（滥用到敏捷软件开发、特别是滥用到国内项目）给毒害了的项目经理，会喜欢教条的。但是结果是大家都累得贼死，而做出来的产品层次却很低，不能预先就面对用户的需求变化。 --------------------编程问答-------------------- 靠低级地对用户说的一大推未经设计过的需求描述就进行“功能分解”、“要求用户冻结需求”等等教条来指导开发，是不行的
说到底，软件开发是创造性的。你们做出来什么产品，很大程度上在于之前你们有什么样的平台产品已经推出了市场。而不在于你死气白咧地跟用户“硬磕”需求冻结。如果你们没有工具的思想，什么样的开发都是手工白手起家、从头开始编写代码，必然很累。 --------------------编程问答-------------------- 为什么把管理软件研发（特别是面对大中型企业的软件的研发）比作简单地貌似“照着书本知识、找一大堆仪器来检测”就能搞清楚的所谓“感冒”呢？
这说明有些人低估了做软件的难度了。或者就是被那些原本给建筑项目写的所谓教程（最近几年国内有许多公司到处打电话忽悠这种PMBOK培训和考证，坑人）给毒害了。 --------------------编程问答-------------------- 即时搞需求需要很长时间，在开始做项目前必须把项目需求跟客户沟通好，让客户确认过才开始付诸代码，不然后期的麻烦会接憧而至。 --------------------编程问答-------------------- 不是指最低级的、为了忽悠用户预付款而确定的所谓需求，是指用户是否真正用上了软件。 --------------------编程问答-------------------- 我要强调的是，用户永远是需求的提供者，程序员不要去想当然地去发明什么需求。但是用户不懂得如何告诉你他的需求，这是他的严重问题，我们要以这个为契机，而不是什么“冻结需求”而制造荒唐的想法。
但是另一方面，程序员应该拿出在一个行业长期积累的东西、工具、平台来实现用户需求。如果你本身的技术手段是作坊式的，你自然就很累，我们可以看到无一例外地程序员会骂用户需求。 --------------------编程问答-------------------- 楼主提到到了“用户不懂得表达需求”，这是我们共同的地方。
但是我们深层次上是有着本质的区别的。楼主竟然想让程序员来本末倒置，我仔细体会，认为这是某些人发生的无奈的变化。 --------------------编程问答--------------------
我觉得一个资深的开发人员应该能判断一些需求的不合理,应该提出自己的意见,如果遇见不合理的需求不提出问题,那这样的开发人员永远只是最底端的码农,就如测试人员提出这样的设计不人性化,那作需求的就应该好好反省了. --------------------编程问答--------------------
你说的千变万化不断涌现出来是客户的问题,但是作为一个在此行业资深的产品经理来说,自然能判断有些客户提出的需求其实和他本意是不同的,成功地产品经理是能够引导客户,用最经济的方法实现客户的要求,而不是客户要求什么就做什么!否则后果可能客户反悔了,软件返工不断修改.这个就是有经验的产品经理的价值. --------------------编程问答-------------------- 说到底，沟通是网道啊。 --------------------编程问答-------------------- 还好！这种事儿不好说！ --------------------编程问答-------------------- 直属领导脚怎么干就就听他的
--------------------编程问答-------------------- 程序员的工作比医生苦难得多：
医生看病，感冒发烧，即时不吃药也能自然痊愈；再大的病，治不好治死了，也可以推脱是病人送医太晚，或者并入膏肓治不好了
程序员的工作没得推脱，出问题的时候，一定是你的责任。 问题也不会“自愈”！ --------------------编程问答--------------------
有的客户在项目接近尾声的时候，忽然提出对数据库结构进行大的修改，因为想跟另一个项目的数据库结构一致便于数据共享。这样的稀里糊涂的客户多得是 --------------------编程问答-------------------- 领导说了算 无非就是资源和钱的问题 --------------------编程问答-------------------- 我们的客户在项目上线前不久，提出要把mysql数据库改成access，真晕；而且把另一个已经上线应用的相关数据库结构拿来让我们改成一样的。而且还问下周五能不能改完？ --------------------编程问答-------------------- 确实，我们一般对项目的前期支持力度都不够，导致项目后期出现各种问题 --------------------编程问答-------------------- 关系说了算，关系好了怎么都好说 --------------------编程问答--------------------
--------------------编程问答--------------------
哎！！！
--------------------编程问答--------------------
除
--------------------编程问答--------------------
客户和钱说了算
--------------------编程问答--------------------
敏捷开发，再一个迭代期内，需求是不能修改的。
--------------------编程问答--------------------
我举个例子，知名艺人某冰冰，最近身体不舒服，来到了医院。对医生描述症状说：最近有点恶心呕吐，头晕目眩，有点儿发烧，不消化，睡眠不好，脸上还长出了痘痘。冰冰其人虽然长得好看，身材火辣，但是性格强势，在耳濡目染中对医学知识也有一些理解。脾气也比较急躁，啥事都想越快办成越好，于是乎，她就展现了其女王的一面。对医生说到：我很忙的，想好怎么治了吗？这样吧。你给我开点阿莫西林，开几片安定，一盒健胃消食片，再来点去火的药。好了，就这些吧，赶紧去办。。。好形象 --------------------编程问答-------------------- 在N此原型迭代之后，绝大部分客户的需求都会（也才会）明朗
因为其实客户明确地知道他想要做什么，但是他并不知道应该怎样达到这个目的。
软件设计人员存在意义，其实就是帮助客户做出一个可以让他去实现他的目的工具。
而确定客户的目的，就需要N此原型迭代。
从他最核心的功能开始一路向外拓展。知道做出最终大家都认可的完整的软件原型——这个时候才能说：需求已经明确，可以文档化备案了。
纠结“谁说了算”，那很简单，客户说了算。因为他/她/它出钱。
具体操作，请想着怎么去实践，而非找理由说明“我懂得多，所以客户最好听我的”。 --------------------编程问答-------------------- 路过帮顶。。。 --------------------编程问答-------------------- 首先，设计人员应该是在该行业有丰富经验的，应该是整个解决方案了然于胸的，重点是如何将此特例化到该项目，或该公司，而不是让用户将每一个细节告诉你，那不是设计。。。
然后是各种开会，同样需要你有充足的经验来问到或诱导出你想要的，开会后同客户确定功能明书，确定后开工，就ok啦
所以，我觉得lz的问题应该是 熟悉。net sql等多种编程技巧但不熟悉该行业及其主流的解决方案，应如何确定需求 --------------------编程问答-------------------- 需求一般都有一个迭代的过程。 --------------------编程问答-------------------- 医生和PL确实很相似.断症要细心，自信。 --------------------编程问答--------------------
--------------------编程问答--------------------
--------------------编程问答--------------------
谁说一个迭代期内的需求是不能修改的？
如果一个需求明显是错了，难道你还一路走到黑，等到下个周期再“重构”？
教条主义害死人啊 --------------------编程问答--------------------
你怎么知道需求会错，是你能力不够吧，换人。
这种事很常见吧~~~ --------------------编程问答-------------------- 求后续帖子。。。 --------------------编程问答-------------------- 改需求全是下一期的事
控制客户预期
这些都靠沟通,尽量用之前成功案例引导
不是客户说什么就做什么 --------------------编程问答-------------------- 客户预期与你做出的东西一致的时候,对方的满意度自然就提高了 --------------------编程问答--------------------
客户说的你做不到 我都不敢想后果。。。 --------------------编程问答--------------------
你以为需求调研、需求分析完了就不会出现需求错误了？
许多问题都是开发期间才发现的。
而往往一个需求问题会导致一大串的流程有变化，如果这个迭代期间内都受这个需求变化影响，你们仍然一成不变？
莫非你们真想以此来严格规定客户不能随意变更需求？太天真了吧？
你们难道就忘记了“需求唯一不变的是需求是变化的”？ --------------------编程问答-------------------- 能力不够？
在领域专家30年行业经验面前，你所谓的“能力”算什么？
你所有的需求、业务规则都是领域专家教给你的，他如果说他开始搞错了，你以为凭你的“能力”可以反驳得了？
不要以为行业经验是你做几个网站，搞几个进销存就能把握的，隔行如隔山啊。
--------------------编程问答-------------------- 除 --------------------编程问答--------------------
我说的是反话。。。没看见 “~~~”这3个波浪线吗 ？ --------------------编程问答--------------------
--------------------编程问答--------------------
一线程序员需要权力， 对需求没有反驳权，只能被动接受， 这样干不好，也干不开心
--------------------编程问答--------------------
三流项目经理，客户逼着走。二流项目经理，跟着客户走。
一流项目经理，带着客户走。
钱说了算，简单来说，资本推动了社会的进步和变革 --------------------编程问答-------------------- 霸道的头儿说了算。 --------------------编程问答-------------------- 愚蠢又混账到极点的头儿说了算。 --------------------编程问答-------------------- 直属领导叫做什么就做什么
我没有废话，最多提提自己的意见，但是一般领导是不听的，但是出于职责，还是的说说 --------------------编程问答-------------------- 软件项目的需求，是最扯最乱的。大部分需求是中后期客户才提出来的。
从这么可以看出，项目开发比产品开发还难
补充：.NET技术 , 非技术区
