提需求的岗位叫什么程序员？

一、提需求的岗位叫什么程序员？

提需求得是各个业务部门，包括运营，甲方等，这些需求会跟需求分析师反馈，需求分析师收集以后会跟产品经理反馈，产品经理收到需求以后构建产品模型，理顺交互设计流程，然后跟程序员做需求评审，开发方案可行性分析，步入开发，然后开发完成进行测试，测试完成后开始产品验收然后交付使用。所以说提需求得不是程序员而是甲方

二、为什么程序员那么讨厌改需求？

你花了半天搭配了一套自己喜欢的美衣，结果却被说“不和场合，需要换”

三、程序员需求是什么意思？

应该是项目需求吧。项目开发之前，需要进行项目的必要设计，需要项目组成员进行讨论，制动出合理的项目解决方案。

一般企业级项目在开发的时候，先要分析出业务需求，通过业务需求设计出合理的数据表，再通过合理的数据表设计出相关数据模型，业务层的开发就是通过业务逻辑操作数据模型。

简单举例写，学生选课系统。就要设计出学生表，课程表，学生选课表。反映出一个学生可以选多门课，一门课程可以由多个学生选择。

四、一般公司程序员需求年龄？

一般公司程序员年龄在21到35岁之间 。程序员的岗位大多996工作制，IT业的知识更新迭代的又快。为了能跟上IT业的前进步伐，程序员需要不停的学习新的知识，新的代码。

很多项目赶工时熬夜是常事，这样很耗费体力和脑力的，好多程序员身体可能受不了，这时候就要考虑转岗了。

五、程序员需求做不出来怎么办？

首先排除这个需求是否合理，不合理的交互是做不出来的，可以和产品经理沟通需求合理性，如果需求合理，做不出来，大概率就是技术问题，可以资询技术大牛，也可以在github或gitee上看有没有开源的类似demo，改一改也可以节省很多时间，最后想说的是，程序员得不断学习，不断沟通，避免闭门造车。

六、为什么频繁更改需求会令程序员烦恼？

对需求方来说，可能只是需求上一个小小的改动，但是在程序角度，可能意味着需要增加一个成员，一种方法，甚至改变整个类或者结构体的结构，如果更底层一点，可能对内存分配本身都会造成一定的影响，而且取决于改动发生的位置，其影响可能会遍布整个系统，从而导致一个小小的需求，却需要大量工作来实现。

另外为了保证产品的质量，每一次代码改动理论上都需要进行测试避免regression，而这种小的改动可能会频繁发生，意味着上一次测试结果还没出来，下一次需求已经提出来了，结果就是可能会由于冲突导致一些潜在的问题没有被发现。

程序一般会从整体需求考虑去进行一个设计，如果不停地对需求进行改动的话，设计就定不下来，一个定不下来的设计用代码去实现就需要在很多部分留有修改的余地，而且这个修改会自动被传播给所有影响对象，来避免下一次修改的时候修改不会在所有地方生效。

七、为什么程序员对频繁更改需求感到烦恼？

前几天我去饭店吃饭，我点了土豆烧牛肉，过了2分钟，我就后悔了，把服务员叫来，改成炒土豆丝，后来服务员说土豆已经切成块了，必须重新做，两个菜的钱都要我出，我就让他把厨师叫过来，然后我问厨师，土豆块能不能切成丝，厨师说可以，还没等他说其他的，我就让他去做土豆丝了，没过几分钟，我又改想法了，我又把服务员叫过来，我想吃土豆片，服务员说稍等然后就离开了，过了一会，就看见厨师拿着刀冲我过来了，嘴里还说着，我看你是来找茬的，我把你剁成肉酱看看你还能不能复原成人！

八、程序员喜欢什么样的需求文档？

一、产品简介

1.简要说明产品的使用价值

我是谁（一两句话写清楚产品的身份）？

我有什么用（我是做什么的，我能提供什么服务等）？

为什么选择我们（与竞争对手相比，我们产品的优势，核心竞争力是什么）？

2.目标用户、使用场景

产品的主要用户群是谁？

用户主要在什么场景下使用我们的产品。

二、行业概要

简要阐述行业现状

未来的发展趋势

竞争对手情况分析

补充：如何快速了解一个行业？

1.通过艾瑞咨询、易观等网站查看行业的分析报告，深入了解整个产业的上下游结构；

2.通过商业模式画布工具，分析行业主要玩家的商业模式

三、版本

按照版本来分类，点击版本链接可进入查看每个版本的文档。

文档的第一页如下图：

（一）、排期

每次的大版本开发，最好对应有一个排期表（与开发沟通确认时间的安排），开发过程中，根据进度情况，适当调整时间安排。

开发人员可以根据自己负责的模块，进入排期详情查看当天的任务，完成的模块可以进行标记，如图。

（二）、产品设计（重点）

1.实体关系图

当你做的产品是从0到1时，为了让数据库的开发人员更快速的了解你的产品，实体关系图（E-R图）将会发挥很大作用，数据库的开发人员可以参考此图来做数据表结构的设计（具体这里就不说了，大家可以网上详细了解E-R图）。

厂家、经销商、客户等这些都是属于实体，实体包含的的属性（字段）最好也要写出来，如下图举例：

2.用户角色权限表

涉及到角色和权限的，需要做一份全面的角色权限表格，方便开发人员参考。

3.业务流程图

通过业务流程图，可以在大方向上知道产品的整体逻辑，业务流程图拆解可以得到任务流程图，任务流程图拆解可以得到页面流程图。

4.全局说明

一些通用的控件、状态等，不需要每次都说明，比如空数据、网络异常、加载失败、刷新状态等等，只需说明一次即可。

5.需求、功能、交互说明

很多人在写功能说明、交互说明时，总是会遗漏一些细节，逻辑不严谨。从以下几个维度去说明，将会让你考虑的更加全面：

字段、字段说明、数据来源

前置条件、排序机制、刷新机制

状态流转（一个页面可能有多个状态，需要说明）

交互操作（正常操作、异常操作）

下面，笔者将以一个页面做举例说明：

产品设计模块里的结构如图：

（为了方面查看以及和视觉页面的对照，每个页面需要标注编号）

（三）、非功能需求

1.埋点需求

页面的打开率、按钮点击率等，如果需要记录，则需要做说明。

埋点是数据分析的基础，建议使用“GrowingIO” 这个工具进行可视化埋点，操作简单、方便，能减少很多的工作量。

2.性能需求

请求数据的响应时间要求、并发数要求等。

3.兼容性需求

系统版本的支持、多终端的支持、浏览器的支持等。

（四）、修改记录

文档的第二页如下图：

为了让开发人员更方便的浏览，增强阅读体验，使用markdown语言来辅助写需求文档是最好不过了，浏览体验会大大提升。

程序员必读书籍

这里有份程序员各方面齐全的经典书籍，有需要的话可以下载下来看看：

九、程序员需求做不出来但是很急怎么办？

任何时候都不要着急，越着急越做不好事情，编写程序也是如此，按照下面步骤一步一步来:

第一步首先应该将自己的心情平复下来，可以上个厕所，或者听一首歌曲，冷静下来;

第二步打开需求文档逐条分析，一字不落的理解需求的意思，这个时候可以借助纸和比做记录;

第三步当自己一个人搞不定的时候，及时向同事或者领导求救，争取不同的意见。

通过以上三步就能把文档分析透彻从而开始编码。

十、刚毕业的程序员可以做需求分析师吗？

Java工程师： 从事一些代码编写、项目维护、bug修复，难度较大。

需求分析： 一般需求分析是具有开发经验的老手，有较好的熟悉和解决问题思路，写一份需求文档给开发者，其实从事需求分析大部分都是程序员晋升的。

顶一下

(0)

0%

踩一下

(0)

0%