程序员拿到需求不知道该怎么实现

A. 身为程序员碰到的最奇葩的需求是如何的

要我把图表和数据导出到Excel，并且在Excel里改了数据，Excel里面的图表和系统里的图表都要变。。。😂

B. 如何正确的给程序员提技术向的需求

一、发需求的方式

我相信所有人都经历过这么一种场景：

你发了需求，但是对方没有看到，于是在交付的那天你什么都没有收到!

别怪别人!怪自己!

发需求的方式强烈建议2种结合：邮件+口头

邮件：很正式，内容完整，并且容易回溯

口头：最好是口头，因为消息和邮件是繁多的，很容易被忽略，但是语言的交流是印象深刻的。如果无法实现口头交流，最好是通过IM再提醒一下，让对方明确的回复已经看到邮件，加深印象。

二、需求是人做的，人心是肉长的

需求之所以复杂就是因为需求是人来做的，如果是机器来做就太简单了：只要输入正确的命令，机器会准确的帮你实现好。

有了人的存在，需求就会存在delay、错误、品质不够等问题。

但这并不能成为需求实现不理想的接口，为何别人的需求可以加塞在你的前面?为何别人提的需求实现品质就比你的高?

同一个忙，你找陌生人，朋友，亲人来帮，其过程和结果肯定是不一样的!

那你能不能让对方成为你的朋友甚至哥们，就要看你的本事了。

三、需求内容需要符合“SMART原则”

Specific——需求必须是具体的，明确的，别摸凌两可

Measurable——需求必须是可以衡量的，要能够评价他的好坏

Attainable——需求必须是可以达到的(这个也是对方经常拿出来的理由，遇到之后参见要点一)

Relevant——需求必须和其他目标具有相关性，没有意义的需求是浪费时间，要告诉对方意义何在

Time-based——需求必须具有明确的截止期限

C. 程序员的java功能的实现不知道怎么动手，没有思路，怎么办

多写一些算法题，写熟了就好了，理清思路，知道自己要做什么，有时候不知道怎么做，你可以选择反推，从后往前延伸，建议还是多做算法题，可以锻炼编程能力

D. 程序员接到项目后应该怎么做

第一步：分析需求。也就是必须找客户把需求确认好，这一步最重要，最好能形成书面的东西，防止客户反复修改
第二步：设计模型。这一步其实是需求的补充，有了一个具体的东西，双方更好交流，也能给予客户部分信心，当然时间能快点最好了
第三步：框架选用或者设计。一定要选择一个灵活的框架，防止有后续开发或者需求反复变更
第四步：模块设计。设计各个模块，充分考虑其中的耦合
第五步：编码，同时思考测试用例
第六步：测试
第七步：项目验收，可能会goto第一步
第八步：收钱

E. 新程序员，刚入职两个月，感觉好闹心，简单需求有时出错，复杂需求又做不来，而且有好多不会的东西。

先装傻，不要盲目去揣度上级的想法。新人刚进公司，基本都是这样的，刚开始一年时间是最难混的。只要你自己有态度，肯努力，多学习，会熬过去的。如果最后经理主动提出不留你，那也没办法了，就只能走了。

F. 程序员要怎么考虑用户的需求

回答之前先说一句：这不是一个程序员要明白的东西。程序员要做的就是敲代码。

还有，你说用户的需求似乎永远都无法完全满足，这是错误的想法
你要主动的问客户问题，了解他们的情况。
比如说要实现什么功能，还有客户的硬件配置，以及客户他们的各个部门之间的关系。
他们的业务流程，和他们各部门的权限。
这些必须要明明白白。也许，你会说这些对软件有什么关系啊？
当你真正需要这些东西的时候就会明白了。

然后就是把这些在纸上打出“草稿”让客户浏览
如果他们满意就签字。签字很重要。

要注意一点：他们不懂软件。他们是客户。
他们只要把需要实现的功能告诉你，然后就是把钱给你。
大部分的情况你是在玩一帮不懂软件的人，所以他们不会理解做软件需要哪些信息。

G. 程序员应该如何去设计需求

其实，程序员的悲催完全是由于程序员的自大引起的。有些程序员开发过几个软件，就以为自己对需求的把控程度很成熟了，于是在与用户做需求的时候，就省去了做原型设计的过程，在听了客户的简单介绍之后，就按照自己的想法把软件的需求分析确定下来，向领导做个简短的报告，然后开始搞开发。 作为程序员，作为需求分析设计人员，更应该明白客户就是上帝。在与用户交流的时候，不要把客户想象成架构师，要把他们当做“白目”来对待，因为客户的没有开发过软件的经验，他们表达的想法不是按照程序来执行。如果程序员只是一味的揣测客户的意愿，而不能自己的所想转换成原型，那么很可能会弄巧成拙。 比如客户甲说想要在应用软件中加个公鸡报时的功能。程序员A以为客户想要一个公鸡宠物，点击时可以报时，而实际上客户是想让软件可以设置闹钟，在某个时间点发出公鸡鸣叫的声音。可想而知，设计出来的宠物再好，也不是用户所需要的。 也许有一些客户是属于“钻石王老五”类型的，他们对软件一窍不通，偏偏还在和你谈需求，他们会对软件提出很多意见，他们会很固执的让我们按照他的思想去设计、实现，尽管那样可以，但是软件的性能及维护性将大大降低，这时候我们需要去主动的引动客户，不是客户左右了你，就是你左右了客户。 如果客户左右了你，尽管可能你按照客户的需求把软件设计出来了，但这却是一个失败的软件，因为它的运行效率很低，而且需求又经常发生变动，而这个软件没有丝毫的可扩充性，那么最后客户会说这个软件设计师给他们设计的软件不够好，而不是客户影响了正常的开发，那么作为软件的需求分析设计师就应该对这件事会责任。 一个好的需求分析设计师，应该是引导客户去正确的使用软件，提高软件的效率与性能，而不是盲目的随从客户，被客户所左右。

H. 初级程序员如何提高项目需求分析能力

找本需求分析的书来看看。其实初级程序员不需要太强的需求分析能力。

I. 程序员做项目，发现有些需求真的完不成，该怎么办。目前那个模块只有我一个人比较懂。很纠结现在，该如何

可以和上级沟通一下啊，或者一起讨论看看有没有好的想法，项目这个东西最终定型是在不断的讨论修改过程中生成的

J. 程序员怎么知道用什么方法解决问题

一般程序员开发的版本分为两类，我将之称为：新开发和N次开发。
新开发版本是指之前没有的、本次为了实现需求而专门开发的版本，也就是所谓的第一个版本。对于此类版本，个人的开发经验如下：
(1) 在动手编码之前，我们要理清需求，看一下软件有什么特点、哪些功能的实现比较容易、哪些功能的实现比较困难。“读书百遍，其义自见”，通过多次阅读需求说明之后，我们的头脑中就会形成对于该软件的大致的轮廓。
(2) 在阅读需求的同时，我们要想一下或咨询一下同事，看之前是否有类似的软件版本已经存在了。如果有，我们就可以在已有的版本的基础之上进行修改，节约开发时间，提高开发效率。
(3) 一定要做好软件的详细设计并且评审通过之后再开始编写代码，在详细设计里面，要针对软件需求列出程序的大体流程及相关算法设计等。很多软件后期出现问题，都与前期的详细设计没有做好有关。因此，宁可多花些时间在软件的详细设计上，也不愿后期将程序改过去改过来。
N次开发版本是指在已有的软件版本之上为新增需求而开发的版本。打个比方来说，一栋楼已经有五层了，现在要在上面加一层，那么第六层(新增加的这层)就是N次开发版本。对于此类版本，个人的开发经验如下：
(1) 在添加或修改代码之前，一定要对原程序的流程有一个全面的了解，要搞清楚本次要在哪个地方添加、修改或删除代码。很多开发人员为了赶进度，拿到代码就开始修修补补，那是不对的。
(2) 一定要确保本次修改不会影响之前的老的程序流程，在修改完代码之后，要对之前的重要程序流程进行回归测试。这点很重要，如果新增流程影响到了原有流程，那么要向相关人员提出，大家在一起商量出一个好的解决办法。
(3) 如果发现原程序架构不合理，或原代码的编写不规范，可以考虑对之进行适当的修改(重构)。但在修改之前，要向开发经理提出自己的想法，大家商讨出一个折中的方案。因为原版本已经发布，所以任何对它的修改都要谨慎，千万不可任性。