需求的改動不在計劃之中

[[277964]]

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

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

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

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

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

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

BUG震蕩

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

所以穩定的工程框架和牛逼的技術負責人牽頭，做需求評估是非常重要的。

項目延期加班風險

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

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

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

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

敏捷開發也許是一條必經好的路

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

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

版本啟動前需要開啟版本沖刺會議，確認任務細節、明確責任，確保信息對等在團隊內部。

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

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

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