作爲開發人員避免範圍蔓延的最佳方法是不需要項目管理

Question

我是一家財務公司內部IT部門的小型開發人員，曾參與過許多中小型項目，整個項目管理都沒有。這似乎總是導致範圍蔓延，因此不能按時完成任務，不得不犧牲良好的設計/代碼以在短期內滿足用戶/管理人員的需求。

作爲開發人員，我可以做些什麼來確保在編寫任何代碼之前確定用戶需求，並根據用戶/經理的要求和期望正確管理任何更改請求。

謝謝。

Answer 1

如果您沒有管理員在需要附加功能時推回，您必須自己動手。我會發布發佈計劃併爲項目的未來階段添加其他功能，這樣您就不會因爲這些附加功能而拖延整個項目。讓人們知道這些附加功能將添加到項目中的時間以及他們何時能夠看到它們。

最難的部分是學習如何告訴人們，但這是你需要學習的東西。

Answer 2

不要害怕說「不」。當然，禮貌，專業。不要承諾任何你不可能做到的事情。不要立即承諾任何你不確定的事情。

此外，不要害怕拿起項目管理書，閱讀並應用它，即使你只是將它應用於自己。

Answer 3

如果您收到了每位經理簽名的要求，您可以自己管理項目，但在執行之前請其他人批准更改。那麼你可以使用簽字作爲槓桿來說不。

Answer 4

在這種情況下，範圍蔓延幾乎是不可避免的，利益相關者沒有時間先行分析，也沒有正式合同。我建議選擇一種敏捷的方法，讓您不斷調整目標和期望。類似於scrum。短週期將幫助利益相關者及早看到結果並調整需求，因爲他們能夠更好地理解問題，並且他們會讓你避免精神錯亂，因爲衝刺週期可以讓你適應這些變化。

Answer 5

關鍵是文檔和可見性。我們有一個易於使用的問題跟蹤系統，需求創建者用它來放入他們的功能請求。他們絕不會因此而不願意這樣做，但是在我們放棄對編碼進行編碼的估算之後，會議將花在審查請求上。如果時間有限，現在請求者必須在彼此之間競爭編碼時間，而不是僅僅期望它完成。因此，我們作爲編碼人員可以避免蠕變，因爲他們必須討論它是如何相互影響的。

Answer 6

記錄當前的要求。當顧客來問的新功能，確保他們知道，添加新功能，將導致以下情況之一發生：

1. 的交貨日期將被移回
2. 功能的要求將需要被丟棄以騰出空間給新的一個
3. 或者說，他們的新的要求不能得到滿足

正如鮑勃·金在他的評論在一個專業的事情說，說「不」是不是一個壞事情。

Answer 7

閱讀一本關於Scrum的書並在您的辦公室實施。它有效地改變了管理層的表格，使他們優先考慮他們想要完成的任務。我們經常會向開發人員提交一份巨大的需求清單和一個簡短的時間表。通過Scrum，您可以將這些需求分解爲多個任務，確定您可以在特定時間內工作多少個小時，然後在開始時間內召開會議確定此「衝刺」的優先級。還有更多，但真正的天才，管理你的經理的旁白是它消除了「可愛」的要求，因爲優先級往往是應用程序的真正優點。自從我在組織中實施後，作爲開發人員的生活更加愉快。

Answer 8

開始編碼之前，實際上不可能有全功能的規範。特別是在小公司。 敏捷方法效果更好，但這不會阻止您完成項目。

你可以做什麼：

• 儘可能多的可能溝通上當受騙 決定。即使你認爲你的老闆也應該這樣做。最好通過 電子郵件，所以沒有人可以聲稱無知
• 如果要求新功能，確保每個人都知道這需要多少時間。不要 低估。做一個受過教育的 猜測並將數字乘以 風險因素，具體取決於該功能的風險 。
• 當一個項目到達終點線時，將需要完成的任務 的列表與 一起作爲時間估計。再次，使 確保所有參與者可以隨時看到這個列表 。

基本上你需要做的是確保每個人都知道你在做什麼。這並不一定能使項目按時完成，但它可以作爲管理者的反映，以便他們看到他們的決定會帶來什麼後果。但總而言之，溝通，交流，溝通併成爲一種小型項目領導者。

Answer 9

有兩種類型的範圍蠕變。一個原因是預先沒有得到很好的要求。這導致意想不到的任務，以實現預期的目標。如果這是問題，那麼您可能需要在收集需求時花費更多時間，並嚴格記錄每個期間的期望值。一旦你有了這個，你可以創建一些低級任務和時間估計。如果有時間超時，那麼至少你會提前知道。

第二種類型源於在開發週期中添加的小功能。這是你必須學會​​如何拒絕的地方。你不能總是說不，但你必須選擇你的戰鬥。請記住，這種類型的範圍蠕變不是來自一件大事。它來自很多小東西。這是一千個紙片死亡。

Answer 10

一旦您和客戶滿意要求，請使用簽名的需求文檔鎖定它們。之後的任何事情都是花費更多資金的變更請求。

如果客戶不想簽收，這不起作用。看看您是否可以在合同中設置一些合理的期限，例如「軟要求期限」和「硬要求期限」。

很顯然，應該有一些擺動的空間，並且從來沒有一種難以確定的方式來確定事後應該吱吱嘎嘎地說什麼不應該，但是增加嚴格的最後期限和更多成本的威脅通常會確保大量的需求在某個特定的時刻處於不變的狀態，從而保護您的一些理智。

Answer 11

不幸的是，您基本上必須自己做項目管理，並瞭解一些關於變更管理的知識。你最好選擇一個可訪問的項目管理書（而不是PMBOK）並閱讀關於變更管理的任何章節。

在項目我工作，我們已經通過

1. 起草這是由利益相關者
2. 估計需要多少工作需要建立的被指定什麼解約的要求規範管理變革
3. 每次請求更改時，請估計需要多少工作量才能更改所需的工作量，以說明更改對成本和完成日期造成的影響
4. 對不包含對計劃進行更改的更改說「否」
5. 獲取已接受更改的簽名（包括接受更改時間表）
6. 記錄所請求的更改以及批准的內容。

根據我的經驗，變更管理從來都不好玩，不幸的是，還有很多地方可能出現問題。我聽到的最常見的情況是對估算精度的不切實際的期望，以及來自利益相關者的不合理要求（僅僅拒絕你已經闡明的變更的影響，或者忽略了需要完成的需求的過程）

Answer 12

範圍蠕變全部是關於未經批准的更改。閱讀你的問題看起來你知道答案，你需要的要求，變更請求和批准。

如果您有BA和PM以及所有其他管理中間件，您可以使用需求聲明，變更請求表單，變更審覈委員會等等。但是我猜這不是您想要的。

你可以簡單地做到這一切。首先確定誰是項目的贊助人。誰把它踢掉了，誰擁有它。這需要一個人爲您的項目批准預算和時間安排。你們兩個都需要提出一個類似於以下的流程，你們都可以達成一致。

接下來在Excel中爲您的需求註冊表創建一張表。列出所有要求。給每一個簡短的描述，並留下一個專欄，以便在必要時進行更長的描述。還包括誰要求這些要求的列，何時設計解決方案以及解決方案是否交付。與你的贊助商坐下來，並同意這是基準。

現在創建一個更改註冊表。這需要一個簡短描述的列，一個描述較長的描述，一個日期，一個影響列，一個批准日期和批准。影響欄是最重要的。每當有人要求更改時，您需要弄清楚這種更改會如何影響您的範圍，預算或時間表。額外的功能可能會增加5天和5000美元。如果您需要聖誕節送貨，則必須取消需求項目1,2,3。

一旦你有你的要求和溝通變化和影響的方法，最難的部分是你不能在未經你的贊助商批准的情況下進行變更。該批准可以是電子郵件或其他任何方式。但它需要明確地說「我批准更改號碼12」。沒有明確的批准步驟，您可能不會感到困擾。

這是關於您可以避開的文檔/過程的最小數量。主要目標是確保每個變更的影響得到充分溝通並被合適的人接受和拒絕。這個人不是你，一般也不是提出變更請求的人。

Answer 13

不要讓功能改變或加深，這對每個人都不適合。如果你不得不選擇其他的東西，決定應該使自己。

Answer 14

我多年來一直處於同樣的境地。然而，我的經歷有點不同。最初在我的公司，我是孤獨的狼。要求會議全由我主持。收集需求後，我會構建應用程序，然後瞧瞧，這不是用戶想要的。重建時間，有110億次更改。多麼可怕的過程。每個人都會爲我的經理，我的，用戶而生氣。

不幸的是，我發現那些想要軟件的人往往不想花時間幫助您設計解決方案，以解決他們正在尋找解決方案的業務問題。他們會一直含糊不清，不想承諾任何事情。

隨着我們的成長，我們聘請了一些人成爲即時項目經理，儘管他們之前從未管理過軟件開發項目，而且幾乎沒有任何技術經驗。這導致了「具體」的規格，每個人，但我是開發商，同意。

當然，結果幾乎和原來的情況一樣糟糕，但至少我們在強制執行規格時有管理層的買入。不幸的是，這些具體的規格，充滿了荒謬的，往往真正不可能的願望。

在應用程序中爲了理智而奮鬥之後，它將被構建。十分之九的用戶仍然感到不安，因爲他們總是和項目經理一起設計出愚蠢的解決方案，但這些方案對他們來說並不適用。

再次，重建地獄隨之而來。

我們現在已經走完了。所有的項目經理都離開了，我們有一些相當大的裁員，所以我再次對整個週期負責。幸運的是，我們從錯誤中吸取教訓，管理層仍致力於執行協議所需的內容。我們在爲用戶提供應用的方式上也發生了一些變化。

我們經常給他們小塊，並要求他們測試它們，並簽署該部分是他們想要和需要的部分。如果不是，他們想要的任何改變都會被添加到項目結尾，並且每個人都會被告知如何改變時間表。當底線明顯受到影響時，細小的變化和突發奇想很快消失。

Answer 15

你將不得不自己做一些項目管理。瞭解敏捷項目管理：

http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video

制定積壓，而不是說是/否來更改或功能，按優先級排序。爲了讓事情變得完美，「好」的東西總是可以推遲到更晚的版本，並且明確說明這就是計劃。專注於最低限度獲得功能性產品。