所有文檔 ​​strong>

每次範圍更改時，請執行以下操作：

• 記錄更改。
• 顯示這將對您的工作產生影響
• 提交新的時間軸
• 讓利益相關者簽字同意

發生範圍爬行，但是要避免成為受到指責的唯一方法是記錄一切，證明其效果，讓人們簽字，這樣您就可以擁有紙條記錄

Mea culpa

我認為 @Neo的答案是正確的，但我不同意實施。考慮

自從我來過這里以來，我犯了一些錯誤。第一個重要的問題是，當您告訴我為該應用程序開發測試工具時，我並沒有堅持要我們對更改進行範圍調整。當時，我只是同意測試工具是一件好事，因此向前邁進了一步。那花了兩個半月。維護它還花了X個月的時間。

沒有意識到這個錯誤，當您告訴我將“實時編輯”更改為功能強大的管理面板時，我重複了一次。我並沒有堅持要確定變更範圍。我們花了一個月的時間進行更改。

我無法再犯同樣的錯誤。從現在開始，每次提出更改時，都希望時間軸更新。這就是今天的情況...

然後說明在當前要求下完成當前任務集需要多長時間。如果他們提出新的更改，請說明他們將如何更改該時間表。還要說明如果您現在不進行這些更改而以後再進行更改會發生什麼情況。您甚至可以通過他們已請求但尚未實施的更改來做到這一點。

我將繼續您在這裡所說的內容，因此我可能會丟失時間軸的某些部分。如果是的話，請確保您為它們寫了那些部分（除非您需要有關它們的幫助，否則我們真的不需要看到它們）。

這種方法的優點在於，它需要您自責。大概他們同意您犯了錯誤，所以您從同意開始。除了你，它沒有指向手指。它著重於問題，並最終轉向解決方案。

不要忘記在其中包括對測試工具的持續維護。如果那花費您一半的時間，請告訴他們。他們可以將工作轉移到您之外（前端或測試工具），也可以使用更長的時間。

如果您不告訴他們實際情況，那麼您將繼續遇到同樣的問題。

繼續前進

當我讀到這篇文章時，真正跳到我頭上的是測試工具。即使在維護之前，這也超出了六個月範圍的兩個半月。這就是為什麼我說X。我不知道X是什麼，但這聽起來很重要。如果您從那以後花了半個月的時間，那麼它將成為前六個月的大部分時間，如果再花更多的時間，則可能成為您在那裡的大部分時間。您確實需要對此進行量化。

從這裡計算出完成原始項目將花費多少時間。也許您已經添加了一些額外的功能。您不需要拿出東西。但是，如果您沒有添加原始要求中未包含的其他內容，那麼時間表將是什麼？然後向他們展示任何新的要求如何影響該計劃。然後向他們展示他們當前的建議將如何影響時間表。您無需拒絕，只需告訴他們他們要添加多少時間。

他們可以擁有敏捷或瀑布。他們不能混搭。敏捷接受不斷變化的需求，因為系統始終在某種程度上運行。因此，所有要求要么都在當前的sprint中，要么不存在。 Waterfall嘗試立即安排整個項目。這意味著，任何時間要求發生變化，您都必須更改整個計劃。從理論上講，項目經理應該處理此事，但實際上，如果那沒有發生，那是您作為承包商的責任的一部分。您需要管理時間表。

還請考慮您當前計劃在前端進行的某些工作可能會在後端進行的可能性。如果是這樣，您應該量化將花費多少時間。讓後端開發人員量化在後端進行編碼所需的時間。讓經理選擇在哪裡做會更好。即使在後端花費更長的時間，但如果您在後面，並且後端開發人員當前正在等您，那麼在那裡這樣做仍然有意義。

後端開發人員可能會接管測試工具。如果只有兩個開發人員，而這會花費您太多時間，那麼其他選擇就不多了。如果您可以專注於原始項目，情況將會好得多。如果後端開發人員一直在等待您，那麼與此同時您也需要做的工作。

有辦法解決這種情況嗎？

我認為您在這裡遇到了麻煩，因為它對我來說似乎不是您已管理了他們的期望。

在遊戲後期您能做的最好的事情是記錄整個場景，包括時間線，就像您與我們在一起一樣。有時，客戶記憶短促，只回想起過去（現在）或短期過去。我懷疑他們是否記得他們幾個月前要求您做的事情。

提醒他們

確保在拼出工作時，請注意導致您不得不大幅度修改體系結構的每個決定。

除此之外，我不確定還能做些什麼。

為了您的未來

請確保記錄下您所做的一切，並且如果您有變更請求（原始工作說明書中的變更），請確保記錄變更及其對時間表的影響。

但是我什麼也沒說

這不是開發人員工作的很大一部分，尤其是自由職業者嗎？

您的經理不是開發人員，他們不能告訴繁重的需求從輕量級的更改，也不能告訴錯誤的方向（從開發人員的角度來看）好的指導（例如，他們仍然有充分的營銷理由嘗試這些指導）。

每次您在討論要做的新事情時，都必須告訴他們這將花費多少時間（或者這一次是多麼不可預測），即使他們不問 >。

您需要進行損害控制，因為我認為這很多是您的錯。

您應該更快地管理更改，或者確保很明顯六個月後不再適用他們想要做其他事情。相反，您只是在看著時間表飛逝時才收錢。

有辦法解決這種情況嗎？

選項1：做點工作

選擇2：告知他們基於現實的時間表，以及無法滿足原始時間表並從那裡繼續前進的原因。聰明的人會理解，他們可能不會高興或留下深刻的印象，但他們會理解。

作為自由職業者，您的聲譽是您最大的財富，您需要比平常人更好，更有組織，更快和更專業為了建立聲譽，有時這意味著在壓力大的情況下免費工作幾個小時。

直言不諱地說，如果這是您的錯，您最終要么會受到打擊，要么是聲譽受損，要么是錢包受損。

作為專業人士，您通常是希望能夠提供合理的估計工作時間，並在時間表不切實際的情況下立即通知您的雇主。

我並不是說您要全責，而是您確實應該在4個月前告訴他們的事情，然後您犯了一個錯誤，而這要花費他們。而且，您保持沉默的時間越長，情況就越糟。

這就是說，據我所知，團隊中已經有前端和後端開發人員，他們也應該對范圍變更的影響有一個合理的認識。因此，聽起來每個人都在恐慌和擠壓其他人，或者也許他們只是彼此信任而不是信任您，所以他們在擠壓您。

一件事要記住，很多時候，每個人都是強調，人們完全不同步，完全誤解了別人在做什麼。例如，也許您看到的“動手”就是他們希望迅速擺脫絆腳石，而您看到的“降低溝通”實際上只是每個人都在匆忙中。同樣，他們可能會錯誤地對待您。解決這些問題的方法是通訊。

首先，我會很快在紙上提出該項目的現實時間表，並弄清您可以工作的最長時間和在替代方案失去工作以及評估很差的情況下可以接受的最低費用。您需要頭腦中的這些類型的數字，因為事情可能很快就會陷入談判過程。並找出他們是否更擔心預算或時間軸。

然後繼續說：“伙計，這個項目顯然給每個人帶來壓力。我們可以退後一步，對此進行一次平靜的討論嗎？我想了解一下，也許對我們從這裡開始如何做貢獻有所貢獻。”

如果他們拒絕，請告訴他們，儘管您將繼續盡力而為，但由於工作量過多而工作量不足，您現在無法滿足他們的期望。時間。

否則，您可以與他們討論該項目。不要對抗。強調您了解存在復雜的業務壓力，最終的決定取決於他們，但從您的觀點出發，提出您認為是最佳的行動方案。如果他們向您扔出曲線球（例如，您不確定需要多少時間的功能），請告訴他們您必須先對其進行研究，然後才能確認它是現實的。

最重要的是，提供解決方案，而不是問題。與其說“我沒有聽說過blah”，不如說“請您將來告訴我有關blah的信息嗎？”

您寫道：“我們沒有指定。這是一個臨時合同，剛開始之前我們開會了。”

這是您的根本原因。那裡有足夠的工作，這個項目的任何打擊只會給您（IMO）造成些小問題。此外，許多公司還了解這是怎麼發生的，而不是為此而怪罪您。

記住，儘管他們在影響您的聲譽方面發揮了作用，但您卻可以利用，因為他們花費了大量的金錢和時間在這方面，會花更多的錢在別人身上。您已經在計劃中學到了教訓。項目的80％應該在計劃中，而20％應該在實施中。

您已經學習了有關在合同工作中使用好的合同的經驗，並且只要您履行合同義務，就不必擔心自己的聲譽。的確，只要您滿足要求，如果給他們低分或給您低分，他們就會處於危險之中。

簡而言之，創建一份好的合同並進行真實會議計劃！您可以從中恢復過來，但是現在您需要採取正確的方法，即通過使用合同和涵蓋所有內容的真正的逐步計劃來保護自己和客戶。

仍然，根據我的經驗，我認為這是一個很好的經驗教訓，可以在其他地方尋找新的起點，從而大踏步前進。

我想在Brythan的答案上做些擴展。提出但要掩飾的要點之一是使用Waterfall或Agile。從您的描述中，我嚴重懷疑他們使用的是敏捷，從他們公司的描述中，他們甚至可能不知道它是什麼。我將寫出我的答案，假設任何人讀它都不熟悉敏捷（或就此而言瀑布）。至少，這可能有助於向公司解釋您想做什麼，因為敏捷可能很複雜，尤其是如果他們習慣於瀑布式的話。如果您不熟悉該術語，那麼瀑布就是舊的“開始時就計劃好一切，給整個事情定一個時間範圍，然後祈禱沒有錯，並且您對多長時間的猜測是準確的

在Brythan的回答示例中，我將結束段落更改為如下內容：

在為了避免將來出現這種情況並為項目帶來更大的透明度，我想提出以下建議：

首先，每兩週召開一次會議，決定需要採取什麼措施。在接下來的兩週內完成。我將提供仍需要完成的任務列表，我們可以共同決定優先級是什麼，以及在這兩週內我可以合理地完成的任務。在兩週結束時，我們將舉行另一次會議，以演示已完成的工作，以便您可以退出會議。

通常，將項目分解為“任務”（或稱為“用戶故事”的用戶故事）的過程將由您和項目經理完成，但您可能必須自己處理。將它們分成幾部分，可以在兩週或更短的時間內完成。在這兩週結束時，每個任務都應該作為完整的工作組件向公司展示。有時，您創建的東西實際上並不是可以獨立交付的，但是即使那樣，也要嘗試找出某種方式來顯示功能。想法是，他們看到進度。

此外，我想召開每天不超過15分鐘的會議，討論日常進度。這樣，您始終可以確切地知道項目的狀態，如果出現任何問題，可以立即解決。

這是Agile的非常基本的實現，但是對Waterfall進行了巨大的改進，並為項目所有者提供了有關項目位置的即時和持續的反饋。