程序员离职前改需求

Ⅰ 频繁更改需求，为什么会令程序员烦

比如：“杀一个程序员不需要用枪，改三次需求就可以了。”

下面把多个网友的段子综合一下：

你去饭店，坐下来。

“服务员，给我来份宫保鸡丁！”

“好嘞！”

——————这叫原始需求

大厨做到一半。

“服务员，菜里不要放肉。”

“不放肉怎么做啊？”

“不放肉就行了，其它按正常程序做，不就行了，难吗？”

“好的您稍等”

——————中途需求变更

厨房：

大厨：“你大爷，我肉都回锅了”

服务员：“顾客非要要求的嘛，你把肉挑出来不就行了吗”

大厨：“行你大爷”

然而还是一点点挑出来了

——————改动太大，部分重构

餐厅：

“服务员，菜里能给我加点腐竹吗？”

“行，这个应该简单。”

——————低估改动成本

厨房：

大厨：“你TMD，不知道腐竹得提前泡水？炒到一半才说？跟他说，想吃腐竹就多等半天”

服务员：“啊你怎么不早说？”

大厨：“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”

然而还是去泡腐竹了

——————新需求引入了新研发成本

餐厅：

“服务员，还是把肉加回去吧”

“您不是刚说不要肉吗”

“现在又想要了”

“…好的您稍等”

——————某一功能点摇摆不定

厨房：

大厨：“日你啊，菜都炒过火了你让我放肉？还好肉我没扔”

服务员：“客户提的要求你日我干嘛？”

大厨：“你就不能拒绝他啊？啊？”

服务员：“人家是客户嘛。”

——————甲方是大爷

餐厅：

“服务员！服务员！”

“来了来了，你好？”

“怎么这么半天啊？”

“稍等我给您催催啊”

——————改动开始导致工期延误

Ⅱ 离职前删光代码，程序员遭公司索赔52万，离职的正确流程是什么

肯定是先把申请书给写完，同时把你的工作给交接完毕，不要留下任何个人隐私。

Ⅲ 产品经理和程序员,如何避免矛盾

产品实现是你的目的，为了这个目的不必太讲究。

做了一阵子之后我有了自己对于与程序员相处的方法论，对这句话并不苟同，我还是倾向于把事做好的同时也能把话说好，虽然我现在也能深刻的领会到当时leader的核心意思是产品本身是第一位的。

接下来我就阐述下自己的一些心得：

• 产品经理与程序员最大的矛盾在于——改需求。这牵涉两个问题，一个是如何尽量地做足前期工作，尽量把需求细化，需求做的足够扎实就会大大减少改需求的次数，这是产品本职工作，不属于沟通问题；另一个问题就涉及如何沟通了，就是需求无论如何确实要改。这个时候有一点很重要就是努力与程序员（或者开发经理）达成共识，比如“我们的目的是要做最好的xxAPP”、“这个功能对于我们的目的来说是必不可少的”等，然后再来谈详细的需求点，程序员也就会逐步认可改需求这件事情。（还有一点很重要的就是，如果无论如何也达不成一致，也有必要反思这个需求是否真的有改的必要？）

• 用数据和客户来帮你增加底气。在谈论某项功能实现的时候，产品经理经常会碰见程序员消极被动不愿意做，或者质疑这么做有没有道理的时候，采取需求依据的数据和真实的客户需求是能有效推进的好办法。比如“80%的同类产品都有这个功能”、“每周都能收到几个客户对某某问题的反馈”，一般来说程序员是能够接受这种说服的。

• 试着多用询问的语气。让程序员感到他是专业的，他是能够解决这个问题的，要依仗他才能做的更好。这会无形中赋予他一种责任感（因为你把问题抛给了他，他就隐形中负有解决这个问题的责任），在传达出意愿的同时也避免了话语的生硬，让程序员感受到对其职业技能的尊重。

• 注重日常交往。日常生活中交个朋友，比如一起打球、打游戏，聊聊电影和漫画，实在是没有共同语言就经常冲他卖个萌、搅个基、撒个娇、讲个笑话。这样，大家都是朋友了，不看工作职责的那一半看交情的那一半，沟通起来也会顺畅很多。

总结：有很多时候产品的产生不完全是靠严格的流程和规章制度诞生的，也需要很多沟通的润滑。能够开开心心地把产品做出来最好，但是最终我们还是不能离开产品实现这个 标的物。

Ⅳ 为什么程序员那么讨厌改需求

这不是“程序员”的问题，做其他行业也一样，比如策划，老板让你交一份XX策划，提交之后老板不满意，需要再次修改，同样会让人感到烦恼，这关乎人自身的问题，不是某种职业的问题。

Ⅳ 程序员在交接过程中应做哪些工作

如果能事先确定接替他的工作的人选,交接应该在接替人在场的情况下进行,如果有一段交接期就更好了,可以让接替人在这段时间内参加交接人的项目,根据该程序员的重要性按下面顺序[重要性递增],交接工作主要针对未完成的项目任务进行:
1.目前未完成的软件代码和文档,代码和文档应相对应,关键代码应该有详细注释,各个模块的解释性文档,设计文档等.[这块如果公司有好的规范是很方便的,如果没有一个好的规范一般只有代码没有文档就很麻烦了,要求重新写出代码说明,规范代码注释.对关键代码要求交接人和接受人之间有口头的说明和解释]
2.目前未完成的设计任务,其中按其担当职责不同有下面几个东西需要交接:模块设计文档[系统架构/主程序员],模块变动文档[主程序员],模块测试文档[主程序员/程序员],系统测试文档[主程序员/系统架构],系统分析书[系统架构],需求分析书[系统架构/主程序员].要求所有交接必须项目经理,交接人,接收人三人在场,并口头解释说明.
3.人事关系交接,这块应该不属于项目交接了呵呵.
4.长期有效的联系地址或电话.

交接工作的成效考核:接收人必须对原有项目有充分的认识,能够完全代替交接人进行工作.所有文档符合规范,代码有充分的注释.已完成的测试文档必须详细.至此交接工作应该算是圆满完成了.

上面是一般性交接工作的流程和需要注意的地方,一个好的交接必须有完善的规范做支撑,才能达到事半功倍的效果,希望对LZ有帮助.

Ⅵ 武汉一程序员辞职回乡改行送菜，一年骑行7000公里，是否大材小用了

当一个人上过大学，也就是接受过高等教育之后，在人们的心目中，他应该从事一些办公室里面的工作，至少看上去是那种白领的工作，所以，如果一些大学生从事一些体力劳动，可能会引起人们的一些议论，甚至有的人可能会觉得上学白上了，这么多年的心血，就这样付诸东流了。在武汉，有一名程序员，辞职之后，回到家乡改行送菜，一年之内骑行了7000多公里，那么他这是否算是大材小用呢？

三、这种改变算不算是大材小用呢？

其实任何一个人从事的工作都说不上是否大材小用，大材小用，只是在别人眼里的看法。只有适合自己的工作才是最好的。虽然在之前这名男子从事的编程工作跟他的所学知识是相符的，但是或许对他的身体是一种摧残，因此，他的这种改变也是为了适合自己的需求，让自己的生活变得更好，从事什么样的工作，不需要去看别人的议论。