❶ 程序员要怎么考虑用户的需求
回答之前先说一句:这不是一个程序员要明白的东西。程序员要做的就是敲代码。
还有,你说用户的需求似乎永远都无法完全满足,这是错误的想法
你要主动的问客户问题,了解他们的情况。
比如说要实现什么功能,还有客户的硬件配置,以及客户他们的各个部门之间的关系。
他们的业务流程,和他们各部门的权限。
这些必须要明明白白。也许,你会说这些对软件有什么关系啊?
当你真正需要这些东西的时候就会明白了。
然后就是把这些在纸上打出“草稿”让客户浏览
如果他们满意就签字。签字很重要。
要注意一点:他们不懂软件。他们是客户。
他们只要把需要实现的功能告诉你,然后就是把钱给你。
大部分的情况你是在玩一帮不懂软件的人,所以他们不会理解做软件需要哪些信息。
❷ 为什么说杀死一个程序员需要改三次需求
你知道开发一个商用环境的需求要写多少行代码,要加多少班,要熬多少夜,要自运行多少次,要修改多少次,要怀疑人生多少次么?最后提交给你,你反馈说是系统BUG也就算了,我给你改,可是你说是需求变了,你知道很多东西又要重头来过甚至是一行行查代码的痛苦吗?还TM把需求变三次!
❸ 我是一名程序员刚入职一周,已经开发一年多的游戏让我改需求,代码还没熟悉,什么也找不到,怎么改我改
谢谢邀请。
从你的描述中,可能心中有很大不愉快,这会影响你的判断和工作效率。趁中午午休时间简单聊一下:
1、你的岗位和你现在说的工作问题不矛盾,是你职责所在,份内的工作而已,这没抱怨的必要。我们公司技术部门也会出现这样的问题,一个BUG,要连续加班几晚上,不停修改。这是你这个岗位的工作性质决定的。
2、你现在面临的是无法完成工作,中途接手,不熟悉,心里烦躁,这个可以理解。但入职一周了,还没了解自己公司开发的一个游戏逻辑,这有点说不过去,再怎么忙,熟悉了解的这个过程所需的时间总有的吧。
3、找不到问题,就虚心请教,向前面的同事向其他高手求教,三人行必有我师,这个应该不难吧?
4、摊牌,,,,,这个太过激了。
或许是你的一时气话吧,但很不恰当!说严重点就是不负责任!在我的理解中,工作中发生问题一点都不可怕,完全可以坦然面对。难以接受的是问题发生了,没有穷尽人力没有千方百计的去设法解决它,而是投降,撂挑子或不干了,,,,这真的是职场大忌!
不要灰心也不要意气用事,谁还没遇到过麻烦事吗?
端正态度 然后 去执行!
就这么简单!
与你共勉。
希望对你有所帮助。 来自职Q用户:邢先生
新官上任三把火,新员工入职三个困难,这是第一个吧?降临一个艰巨的任务在你的头上,公司的陈旧问题希望得到解决,这是老板的期望!先别急着投降,也先别摊牌,认真思考一下问题在哪里,评估同事和你个人有没有这样的能力能力,带上一两套方案,跟老板商量这件事怎么解决~《白日梦想家》主角米提华特的经历说明,只要你尽全力,甚至突破自己,希望和机会总是会在最后出现的~ 来自职Q用户:匿名用户
❹ 频繁更改需求,为什么会令程序员烦
比如:“杀一个程序员不需要用枪,改三次需求就可以了。”
下面把多个网友的段子综合一下:
你去饭店,坐下来。
“服务员,给我来份宫保鸡丁!”
“好嘞!”
——————这叫原始需求
大厨做到一半。
“服务员,菜里不要放肉。”
“不放肉怎么做啊?”
“不放肉就行了,其它按正常程序做,不就行了,难吗?”
“好的您稍等”
——————中途需求变更
厨房:
大厨:“你大爷,我肉都回锅了”
服务员:“顾客非要要求的嘛,你把肉挑出来不就行了吗”
大厨:“行你大爷”
然而还是一点点挑出来了
——————改动太大,部分重构
餐厅:
“服务员,菜里能给我加点腐竹吗?”
“行,这个应该简单。”
——————低估改动成本
厨房:
大厨:“你TMD,不知道腐竹得提前泡水?炒到一半才说?跟他说,想吃腐竹就多等半天”
服务员:“啊你怎么不早说?”
大厨:“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”
然而还是去泡腐竹了
——————新需求引入了新研发成本
餐厅:
“服务员,还是把肉加回去吧”
“您不是刚说不要肉吗”
“现在又想要了”
“…好的您稍等”
——————某一功能点摇摆不定
厨房:
大厨:“日你啊,菜都炒过火了你让我放肉?还好肉我没扔”
服务员:“客户提的要求你日我干嘛?”
大厨:“你就不能拒绝他啊?啊?”
服务员:“人家是客户嘛。”
——————甲方是大爷
餐厅:
“服务员!服务员!”
“来了来了,你好?”
“怎么这么半天啊?”
“稍等我给您催催啊”
——————改动开始导致工期延误
❺ 如何正确的给程序员提技术向的需求
一、发需求的方式
我相信所有人都经历过这么一种场景:
你发了需求,但是对方没有看到,于是在交付的那天你什么都没有收到!
别怪别人!怪自己!
发需求的方式强烈建议2种结合:邮件+口头
邮件:很正式,内容完整,并且容易回溯
口头:最好是口头,因为消息和邮件是繁多的,很容易被忽略,但是语言的交流是印象深刻的。如果无法实现口头交流,最好是通过IM再提醒一下,让对方明确的回复已经看到邮件,加深印象。
二、需求是人做的,人心是肉长的
需求之所以复杂就是因为需求是人来做的,如果是机器来做就太简单了:只要输入正确的命令,机器会准确的帮你实现好。
有了人的存在,需求就会存在delay、错误、品质不够等问题。
但这并不能成为需求实现不理想的接口,为何别人的需求可以加塞在你的前面?为何别人提的需求实现品质就比你的高?
同一个忙,你找陌生人,朋友,亲人来帮,其过程和结果肯定是不一样的!
那你能不能让对方成为你的朋友甚至哥们,就要看你的本事了。
三、需求内容需要符合“SMART原则”
Specific——需求必须是具体的,明确的,别摸凌两可
Measurable——需求必须是可以衡量的,要能够评价他的好坏
Attainable——需求必须是可以达到的(这个也是对方经常拿出来的理由,遇到之后参见要点一)
Relevant——需求必须和其他目标具有相关性,没有意义的需求是浪费时间,要告诉对方意义何在
Time-based——需求必须具有明确的截止期限
❻ 程序员,还在为需求方反反复复的修改提出而烦恼么
最近跟客户谈的时候,经常会听到这样的话:&lo;你们美工不就是做图?除了做图还能干吗&ro; &lo;那样的图我随随便便花两三百块就能找人做出来&ro; 等等,而且客户在炫耀自己()实力的时候都会以&lo;我花了多少多少钱从某某大挖了个技术回来&ro;而不是&lo;我花了多少钱挖了个设计回来&ro;。 反正给我的感觉就是在大众眼里,程序的身价地位总是要比设计高。你做的图,别人也做得出来。 按理说做项目的时候,设计要做的工作量不比程序少多少,甚至为了个极致视觉效果挖空心思反反复复修改,结果出来的时候给别人印象也仅限于&ro;这图不错&lo;。 人艰不拆,说多了都是眼泪。虽然这些话早已习惯,但是我还是很矫情地想:我们做这行的也花心思花时间花精力做,为毛会这么卑贱。 对于设计师的地位,我说几点: 1. 设计师,由于其职业特性,更容易遭到外行人的随意评判。 虽然我们知道设计的大部分功夫(用研、思考、决策等)都在最终的图稿之外,然而最终给外人展示的,却通常只有外在的“皮”。 虽说从表象上看,“技术是里,视觉和交互是外”,然而事实上,“设计”对于产品价值的实现,以及塑造差异性、传递品牌价值等更高层面的要求是具有核心意义的。但设计终究是面向普通用户的工作,其最终的产出(不管是平面,还是用户界面)必然会直接面对用户。而他们中的绝大多数,只会对设计的直观表现作出感性的认识。在这种感性认识的影响下,人们很容易误以为设计的全部内容就是塑造他们所感知到的直观表现。这就造成了对于设计“谁都可以指指点点”的事实。 而人员不同。他们的工作主要是关于产品内部的技术细节,而这些技术细节对于普通人是不可见的,于是普通人自然也就无从评判这些内容。 这一点是由职业特性决定的、无法改变的事实,然而我认为这正是设计的魅力所在:我们为普通人服务,而普通人可能不理解我们。那么如何将我们认为好的、优美的东西在这些普通人中推行出去?这是一项非常有趣的挑战,它需要的不仅仅是设计师自身的技巧、美感和品位,还有对人、社会和文化的理解。 2. 设计师(包括美工),由于行业门槛非常低,造成了过分平庸的现实,也造成了设计可替代、低价值的特性。 关于这点,需要强调的是,现在的设计师大部分是商业设计师,它们的一部分主要价值是为产品和带来收益。然而商业思维恰好又是现在设计师所欠缺的。事实上,由于种种原因,很有可能发生的事情是:商业设计师们不仅不会带来商业价值,还会增加成本。这也是其地位不高的原因之一。 3. 从产品的角度考虑,设计师(这里将产品设计师也归为设计师)决定了产品做的好不好,而人员决定了产品能不能做出来。 他们的关系就好似温饱之后思淫欲。对于那些连温饱都没法保证(连实现都没法保证)的产品,苛求它们去重视设计岂不是强人所难么? 依然从产品的角度考虑,对于那些不愁温饱的、成熟的产品,随着自身的发展,在对设计有了更高需求的同时,技术方面也会面临更大的挑战。而对于软件来讲,应对技术挑战,最具价值的资源依然是人才。而此时,技术依然是整个产品向前发展的基础保障。这也就决定了在很多时候,人员对整个产品的价值是高于设计师的。这是一个事实。 4. 整个社会的需求层次还不足以让设计师的工作获得足够的承认。 这点大家应该都深有体会,我就不废话了。 设计是有逻辑的,就如同程序员设置的变量一样,每个变量都应该有它存在的理由。所以设计师和程序员一样重要。但问题就出在: 1)程序的背后对于非程序员来说就是天书,没人会要程序员去解释(除了程序员们)。 出问题的时候,若是个不懂编程的上司,除了向程序员施加压力以外,只能暗自着急。不管出不出问题,这都捎带一种依赖的微妙关系。但若是设计,似乎谁都可以自信满满地扔几个鸡蛋烂番茄过去,因为,设计是直观的,长了眼睛就能看见,还都觉得自己看得懂。 2)设计从业人员大多有艺术背景。 艺术是对情绪的表达,艺术是天马行空的,而设计却产生于要求与限制。就如同程序员设置的变量一样,每个变量都应该有它存在的理由,若非如此,则是不够简洁不够巧妙(而只有同行才可知)。设计也是如此,如果你说不出这个按钮为什么用了蓝色,或者你觉得答案就是“我觉得就该是蓝色”,那么你不可能是客户眼中的好设计师。但我可以告诉你,很多时候设计没有什么黄金定律,真的就是“我觉得就该是这样”,但即使如此,就算你编,也得编出个理由来。客户付钱,不是来题名“无题”的艺术品的。 我不是说提问者,但那些常常被客户否定的设计师,是否想过,我们的作品都是出于我们的双手,包含了我们的理解,采用的是我们擅长的表达方式,我们是否考虑过什么是客户会喜欢的?什么是客户的顾客们易于接受的?若是全部算在设计计划之内,那么客户喜欢的方案,很抱歉,也许就是最艳俗的那个——再次抱歉,这是我们的工作。设计不是搞艺术,不是个人去参加比赛。 那么我们该如何让自己进步呢? 设计需要创意,程序员也需要创意,但即使是 out of the box thinking,巧妙的创意也是用来达到一个目标,一个可以写下来的,可以用额、利润、未来潜力来衡量的目标,甚至有可能是是直抵人心的一场场心理战。而漂亮的展示,我不认为是设计师最重要的能力。漂亮的展示,可以交给真正的艺术家——美工——来完成。 另外,要懂得沟通。比如,客户不明白为什么这里要放丑陋的二维码,你怎么解释二维码这东西?“扫一下就行”、“方便”、“直接”都不如“不用打字”这四个字直击科技小白的心。(这是沟通的例子,重复,是沟通的例子不是设计的例子!) --- 最后,对所有设计师的建议: 最核心的事,依然是提升自己能力。君不见也有程序员被称作码农,也有产品经理实际上是打杂工。唯有让自己成为一个各方面成熟的设计师,才能让设计职位的价值得以真正实现,进而获得尊重。 对于产品本身,从更多方面考虑。例如成本,例如场,例如产品需求,例如运营数据…… 考虑得尽可能全面,设计决策才会尽可能完整,方案也会更加成熟。 想要被人承认是设计师,那么自己就需要先成为设计师。美工们津津乐道的 pixel-perfect 是应该的,然而对于设计师来讲,这还不够。在技法、细节上辛勤劳作是很好的,然而对于设计师而言,更重要的应该是思考。 最后,一个不太“正确”的事实:很多抱怨设计师地位不高的人,其实并不能被称作“设计师”。
❼ 为什么程序员那么讨厌改需求
这不是“程序员”的问题,做其他行业也一样,比如策划,老板让你交一份XX策划,提交之后老板不满意,需要再次修改,同样会让人感到烦恼,这关乎人自身的问题,不是某种职业的问题。
❽ 如何向外行解释产品经理频繁更改需求为什么令程序员烦恼
某产品经理经过多年努力,终于研制出可定制多层冰淇淋,可以根据顾客的需要现场定制。开张第一个顾客是聪明可爱的小汤姆,指着摊位的冰淇淋机问:我可以要多个自己喜欢的口味吗?产品经理:当然了,你可以自由选择4种口味来叠加哦。汤姆:那太好了!那我第一层要巧克力味的。产品经理:好嘞,巧克力味的。第二层呢?汤姆:我还喜欢吃奶油,那就要奶油的吧。产品经理:奶油,OK了。汤姆:第三层要花生酱吧。产品经理:搞定,花生酱。汤姆:嗯...叔叔,我能不能把花生酱的换成草莓味的呢?我刚想起来,隔壁小妹妹花生过敏。产品经理:啊,这样啊,那我帮你换掉。汤姆:谢谢!那我还要原味的...产品经理:好,原味的...汤姆:等,等下,我觉得还是橙子的吧产品经理:怪我手快...橙子的汤姆:嗯...好像我妈妈不让我吃奶油,能不能帮我把第二层换成梅子的呢?好不好~产品经理:...好吧,看在你是我第一位顾客的份上,帮你换。汤姆:太感谢了!...哎呀!狗狗不能吃巧克力对吧?!产品经理:狗狗确实不能吃巧克力。汤姆:我怎么忘了呢,要是我家布丁吃了巧克力死掉怎么办呢?产品经理:那就不要给狗狗吃呀。汤姆:那怎么行,这么好吃的冰淇淋怎么能让它就这样看着呢?帮我把巧克力换成抹茶的吧~叔叔~产品经理:...小兔崽子,怎么学成这样了,你爸也是个产品经理吗?!汤姆:不,我爸是程序员。
❾ 好累,程序员听不懂产品经理提的需求,问多了,产品经理嫌烦。该怎么办
这个东西应该有一定经验积累会理解比较快,也是一个过程。只有多沟通,在沟通前想想沟通的目的,这次沟通要解决什么问题。用笔记下来。然后在实操,在实操过程中如果遇到问题先想一想,试着自己去解决一下。再去询问,至少让别人感受你是在用心做这件事。而且也是想做好这件事。其实你们的目的都是一致的。注意方式方法,不要让别人觉得你一个问题重复的问还没什么结果。大家都有自己的事情都会比较烦。