需求的改動不在計劃之中

[[277964]]

“謀殺一個程序員最簡單的方式是，讓他改三次需求”雖然是一句玩笑話，但充分表達的需求的變更對程序員的影響之大。其實只要是設(shè)計和真正在干貨的工種，在面臨需求變動的時候就會產(chǎn)生很大的影響。

實際上很多需求的變更，不在版本開發(fā)計劃之中，由于缺乏有效項目管理和版本管理，程序員就淪為了一臺機器，成為了版本迭代的苦力。叫苦不迭。

需求改動背后可能隱藏了更多需求

一個需求變更，也許是一個小的按鈕的改動，從軟件設(shè)計上，初生牛犢不怕虎的程序員小張，在產(chǎn)品經(jīng)理的一頓忽悠下，沒經(jīng)過評審就直接開干了。

殊不知，哪怕是一個按鈕的增加或刪除，他后面可能影響了一系列功能的變化，而這些變化后續(xù)都是需求，這些需求，可能完全不在版本迭代是主線上。有可能導(dǎo)致技術(shù)債務(wù)增多。

所以不要輕信一個人說這個功能很簡單，幾分鐘之類的話，很可能這是一個無底洞。

BUG震蕩

修改一個需求，改動一行代碼，從程序員角度看，可能要重構(gòu)某一部分代碼，重構(gòu)可能帶來巨大的工程風(fēng)險，形成更多缺陷，給程序員帶來巨大的技術(shù)壓力，后期可能需要償還更多的技術(shù)債務(wù)，這個程序員不加班都難。

所以穩(wěn)定的工程框架和牛逼的技術(shù)負(fù)責(zé)人牽頭，做需求評估是非常重要的。

項目延期加班風(fēng)險

改動需求，需要評估，需要重新排計劃，這勢必打亂原來的計劃，如果市場不允許時間上的推遲，那么加班的風(fēng)險非常之大。

加班往往很可能是項目延期的前兆，筆者見過不少團隊，天天加班，天天改BUG,天天改需求，每個版本都會延期，都會被老板臭罵。

所以筆者看來，加班可以，但請不要是用來過多的償還技術(shù)債務(wù)。作為一個團隊需要更多的時間分析到底是什么導(dǎo)致的加班這個很重要。

筆者看到過一些年輕的開發(fā)人員，白天改需求，晚上加班改昨天寫的BUG，這是惡性循環(huán)，需要更高一層的人，來解決這個問題，而不是這個年輕開發(fā)人員本身，畢竟他的技術(shù)積累是需要時間的，合理的安排任務(wù)和跟蹤任務(wù)非常重要。年輕開發(fā)人員容易迷失開發(fā)節(jié)奏，他是一個小成員，但最終會成為項目的一個很大的風(fēng)險。

敏捷開發(fā)也許是一條必經(jīng)好的路

筆者個人畢竟推行敏捷開發(fā)，短平快的迭代和各自例會，能保證項目信息的對等和產(chǎn)品精細(xì)程度更好的把握。

筆者曾經(jīng)待過一個6人的敏捷開發(fā)團隊，每日有15分鐘早會，各自發(fā)言2分鐘，團隊負(fù)責(zé)人，需要知道每個人昨天干了什么，今天干了什么，有什么問題。

版本啟動前需要開啟版本沖刺會議，確認(rèn)任務(wù)細(xì)節(jié)、明確責(zé)任，確保信息對等在團隊內(nèi)部。

版本結(jié)束后需要開啟版本復(fù)盤會議，總結(jié)存在的問題，這些問題規(guī)劃到下面哪一個版本，哪一些問題是牛皮癬，需要做專題，用1周的實際去全力解決。

團隊內(nèi)部一定需要有自己的節(jié)奏，不能輕易被其他部門打亂，那這樣團隊才有發(fā)言權(quán)，才能掌握更多，不然就會淪為其他部門的工具，任人擺布，這句話可能不好聽，但現(xiàn)實中，太多這樣的例子，很多程序員、運維人員，淪為了其他部門隨意使喚的“傭人”

所以你是一個精彩改動需求的程序員，可能不是你的問題，可能是你的技術(shù)負(fù)責(zé)人更多有問題，他更需要反省，只是他比你工資待遇要多，他要想更多，解決這些問題。你更多的是按部就班，不要被外部打擾，如果你經(jīng)常被其他部門的人打擾，而你由不是部門負(fù)責(zé)人，拿就是這個門沒控制好，出問題，團隊內(nèi)部要關(guān)起門來解決問題。提升團隊?wèi)?zhàn)斗力，幫公司解決問題，輸出價值。