程序員離職前改需求

Ⅰ 頻繁更改需求，為什麼會令程序員煩

比如：「殺一個程序員不需要用槍，改三次需求就可以了。」

下面把多個網友的段子綜合一下：

你去飯店，坐下來。

「服務員，給我來份宮保雞丁！」

「好嘞！」

——————這叫原始需求

大廚做到一半。

「服務員，菜里不要放肉。」

「不放肉怎麼做啊？」

「不放肉就行了，其它按正常程序做，不就行了，難嗎？」

「好的您稍等」

——————中途需求變更

廚房：

大廚：「你大爺，我肉都回鍋了」

服務員：「顧客非要要求的嘛，你把肉挑出來不就行了嗎」

大廚：「行你大爺」

然而還是一點點挑出來了

——————改動太大，部分重構

餐廳：

「服務員，菜里能給我加點腐竹嗎？」

「行，這個應該簡單。」

——————低估改動成本

廚房：

大廚：「你TMD，不知道腐竹得提前泡水？炒到一半才說？跟他說，想吃腐竹就多等半天」

服務員：「啊你怎麼不早說？」

大廚：「早說你MLGB我怎麼知道他要往宮保雞丁里放腐竹」

然而還是去泡腐竹了

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

餐廳：

「服務員，還是把肉加回去吧」

「您不是剛說不要肉嗎」

「現在又想要了」

「…好的您稍等」

——————某一功能點搖擺不定

廚房：

大廚：「日你啊，菜都炒過火了你讓我放肉？還好肉我沒扔」

服務員：「客戶提的要求你日我幹嘛？」

大廚：「你就不能拒絕他啊？啊？」

服務員：「人家是客戶嘛。」

——————甲方是大爺

餐廳：

「服務員！服務員！」

「來了來了，你好？」

「怎麼這么半天啊？」

「稍等我給您催催啊」

——————改動開始導致工期延誤

Ⅱ 離職前刪光代碼，程序員遭公司索賠52萬，離職的正確流程是什麼

肯定是先把申請書給寫完，同時把你的工作給交接完畢，不要留下任何個人隱私。

Ⅲ 產品經理和程序員,如何避免矛盾

產品實現是你的目的，為了這個目的不必太講究。

做了一陣子之後我有了自己對於與程序員相處的方法論，對這句話並不苟同，我還是傾向於把事做好的同時也能把話說好，雖然我現在也能深刻的領會到當時leader的核心意思是產品本身是第一位的。

接下來我就闡述下自己的一些心得：

• 產品經理與程序員最大的矛盾在於——改需求。這牽涉兩個問題，一個是如何盡量地做足前期工作，盡量把需求細化，需求做的足夠扎實就會大大減少改需求的次數，這是產品本職工作，不屬於溝通問題；另一個問題就涉及如何溝通了，就是需求無論如何確實要改。這個時候有一點很重要就是努力與程序員（或者開發經理）達成共識，比如「我們的目的是要做最好的xxAPP」、「這個功能對於我們的目的來說是必不可少的」等，然後再來談詳細的需求點，程序員也就會逐步認可改需求這件事情。（還有一點很重要的就是，如果無論如何也達不成一致，也有必要反思這個需求是否真的有改的必要？）

• 用數據和客戶來幫你增加底氣。在談論某項功能實現的時候，產品經理經常會碰見程序員消極被動不願意做，或者質疑這么做有沒有道理的時候，採取需求依據的數據和真實的客戶需求是能有效推進的好辦法。比如「80%的同類產品都有這個功能」、「每周都能收到幾個客戶對某某問題的反饋」，一般來說程序員是能夠接受這種說服的。

• 試著多用詢問的語氣。讓程序員感到他是專業的，他是能夠解決這個問題的，要依仗他才能做的更好。這會無形中賦予他一種責任感（因為你把問題拋給了他，他就隱形中負有解決這個問題的責任），在傳達出意願的同時也避免了話語的生硬，讓程序員感受到對其職業技能的尊重。

• 注重日常交往。日常生活中交個朋友，比如一起打球、打游戲，聊聊電影和漫畫，實在是沒有共同語言就經常沖他賣個萌、攪個基、撒個嬌、講個笑話。這樣，大家都是朋友了，不看工作職責的那一半看交情的那一半，溝通起來也會順暢很多。

總結：有很多時候產品的產生不完全是靠嚴格的流程和規章制度誕生的，也需要很多溝通的潤滑。能夠開開心心地把產品做出來最好，但是最終我們還是不能離開產品實現這個 標的物。

Ⅳ 為什麼程序員那麼討厭改需求

這不是「程序員」的問題，做其他行業也一樣，比如策劃，老闆讓你交一份XX策劃，提交之後老闆不滿意，需要再次修改，同樣會讓人感到煩惱，這關乎人自身的問題，不是某種職業的問題。

Ⅳ 程序員在交接過程中應做哪些工作

如果能事先確定接替他的工作的人選,交接應該在接替人在場的情況下進行,如果有一段交接期就更好了,可以讓接替人在這段時間內參加交接人的項目,根據該程序員的重要性按下面順序[重要性遞增],交接工作主要針對未完成的項目任務進行:
1.目前未完成的軟體代碼和文檔,代碼和文檔應相對應,關鍵代碼應該有詳細注釋,各個模塊的解釋性文檔,設計文檔等.[這塊如果公司有好的規范是很方便的,如果沒有一個好的規范一般只有代碼沒有文檔就很麻煩了,要求重新寫出代碼說明,規范代碼注釋.對關鍵代碼要求交接人和接受人之間有口頭的說明和解釋]
2.目前未完成的設計任務,其中按其擔當職責不同有下面幾個東西需要交接:模塊設計文檔[系統架構/主程序員],模塊變動文檔[主程序員],模塊測試文檔[主程序員/程序員],系統測試文檔[主程序員/系統架構],系統分析書[系統架構],需求分析書[系統架構/主程序員].要求所有交接必須項目經理,交接人,接收人三人在場,並口頭解釋說明.
3.人事關系交接,這塊應該不屬於項目交接了呵呵.
4.長期有效的聯系地址或電話.

交接工作的成效考核:接收人必須對原有項目有充分的認識,能夠完全代替交接人進行工作.所有文檔符合規范,代碼有充分的注釋.已完成的測試文檔必須詳細.至此交接工作應該算是圓滿完成了.

上面是一般性交接工作的流程和需要注意的地方,一個好的交接必須有完善的規范做支撐,才能達到事半功倍的效果,希望對LZ有幫助.

Ⅵ 武漢一程序員辭職回鄉改行送菜，一年騎行7000公里，是否大材小用了

當一個人上過大學，也就是接受過高等教育之後，在人們的心目中，他應該從事一些辦公室裡面的工作，至少看上去是那種白領的工作，所以，如果一些大學生從事一些體力勞動，可能會引起人們的一些議論，甚至有的人可能會覺得上學白上了，這么多年的心血，就這樣付諸東流了。在武漢，有一名程序員，辭職之後，回到家鄉改行送菜，一年之內騎行了7000多公里，那麼他這是否算是大材小用呢？

三、這種改變算不算是大材小用呢？

其實任何一個人從事的工作都說不上是否大材小用，大材小用，只是在別人眼裡的看法。只有適合自己的工作才是最好的。雖然在之前這名男子從事的編程工作跟他的所學知識是相符的，但是或許對他的身體是一種摧殘，因此，他的這種改變也是為了適合自己的需求，讓自己的生活變得更好，從事什麼樣的工作，不需要去看別人的議論。