飛機上有機師嗎？
「如果有試驗上線，請撥打他們的通話按鈕嗎？」 是任何乘客都不想要聽到的。 我重新閱讀真實事件中的顯著新聞報導，就像 2013 年 12 月所發生的一樣。 在駕駛班機離開德馬因之後，愛荷華州發生醫療緊急狀況，共同試驗人員對機上的任何試驗提出要求。 上層。美國陸航的 B1 飛行試驗 Mark Steppedol 已逐步進入缺口。 飛機、乘客和機組員全都安全地著陸。
這是一個很棒的故事，但我最近要重新閱讀，卻因為一些非常不同的內容而觸發。 我們的潛在客戶最近呼叫，詢問他們是否可以「試驗」我們的企業專案時程表軟體。 這類呼叫一律會讓我暫停。 當飛機上的某人說「試驗」時，我們完全清楚其意義，但當正在評估軟體選項的人說「試驗」時，我不確定。
軟體世界中的「試驗」一詞通常與其他具挑戰性的評估方法混合在一起，例如「概念證明」。讓我們看看這些詞彙的意義，以及如何在自己的企業評估程式中使用它們。
概念證明
這是一個可回溯許多年的詞彙，在電子工程中很受歡迎。 已完成線路的「階層上線」，以查看線路是否可行，而不是開始建立線路以供生產環境使用。 在概念證明中，您在實驗室工作臺上花費的時間可能會比建立生產線路的時間還多，但唯一可能造成的損害是您在前面工作的電路板。 這是一種低成本且低風險的方法，證明電路可以提供所需的結果。
在軟體方面，概念證明應該設計來證明某些專案。 當潛在客戶呼叫 詢問我是否可以協助他們提供企業專案管理或企業時程表軟體的概念證明時，我一律會有相同的回應：「您想要證明哪些概念？」
這通常會遇到無聲和混淆的運算式。
如果您要進行概念證明，而且您對於嘗試證明的內容沒有任何概念，您要如何知道它是成功還是失敗？ 當然沒有任何方法。
您會問，為什麼有人甚至想要執行概念證明？ 最常見的答案是，要求者可能沒有必要的管理購買來實作他們所研究的軟體，而且希望如果只是在他們前面執行，他們就會愛上想法，並同意應該部署它。 在此情況下，「證明」是管理，而「概念」則是企業軟體的完整概念。
如果能夠輕易地接受管理，企業專案和時程表軟體很適合他們，我們會部署大量專案。
此方法的問題在於，部署此概念證明實例時，您將能執行的工作，不太可能與您在企業系統生產環境部署時所得到的支援相同。 當組織部署企業系統，例如時程表或專案管理系統時，需要許多專案才能成功。 首先，對於部署中隱含的任何組織層面，必須有來自管理和行人員的輸入。 接下來，需要時間進行設定、技術服務的協助以連結至其他企業系統、管理贊助、訓練時間，以及是、金錢。
如果您沒有任何這些專案，那麼您可以在概念證明中完成的系統為何？ 這會是您最想要的陰影。 在現今的雲端中，您或許可以存取完全裝載的系統，因此您至少不用擔心購買伺服器和軟體，但只要安裝系統，就只是進行概念證明系統基本部署所需的一小部分工作。
很容易瞭解為什麼組織會擷取投入大量金錢和資源來實作可能會影響整個組織的專案。 這是高風險的練習。 我們通常只會討論企業專案管理軟體的優點，但很容易想像出相同的專案發生錯誤，可能會有同樣負面的影響。 因此，降低風險是一個明顯的考慮。 但是，如果真正的挑戰是要相信系統優點的管理，那麼有更好的方法可以這麼做。 在 HMS Software 中，我們著重于下列幾個技術：
與實際且已存在的用戶端交談。
我們在這裡很高興有一些很棒的用戶端，這些客戶非常滿意。 當新的潛在客戶對於其進入的內容有所疑慮時，我們會將該組織與現有的用戶端整合在一起。 在許多情況下，現有的用戶端已足夠好客，可提供來主持親自會議。 在其他情況下，它們會彼此呼叫，而我們刻意不會成為其中的一部分。 我們鼓勵現有的用戶端分享好消息和挑戰。
讓我們證明一下。
如果您真的有需要證明的概念，請讓我們協助向您證明。 有一些合理原因需要先證明某些實作的某些層面。 也許部署會有非常大量的特定資料類型。 例如，我們曾要求過一次，以顯示我們的方案在特別大型的專案負載下運作。 我們被要求顯示使用特定瀏覽器或特定資料庫的軟體，或連結至特定外部系統的特定版本。 如果這是阻礙評估的概念，則可以克服該挑戰的最佳人員就是主題專家。
您可以使用它進行一些訓練。
如果潛在客戶端絕對必須顯示系統使用其人員所使用的資料，我們會協助將資料載入託管系統，然後盡可能盡可能地依照用戶端的需求設定系統，並訓練將參與的人員。 我們強烈希望帶入公司來協助示範本身，但如果不可能這麼做，我們會要求檢閱相關人員將使用的腳本或示範，並要求協助調整或訓練人員進行傳遞。
當您需要試驗時，試驗在哪裡？
那麼試驗專案呢？ 這樣更好，對吧？ 可能是。 如果系統要求您建立企業時程表或企業專案管理系統的試驗部署，您應該從判斷目標開始。 如果目標全都與概念證明有關，則您完全不在試驗計畫中。
試驗專案是實際的生產中即時部署。 它通常牽涉到系統評估所考慮的總使用者基底子集，因此試驗計畫可能需要一些時間。 雖然從一開始會考慮完整目標使用者基底的需求，但試驗計畫著重于為試驗使用者執行實際的實作。 他們實際上會管理其專案，或實際使用新系統填入其時程表。
試驗實作也會面臨完整生產部署所面臨的相同挑戰，但資料的數量或複雜度除外。 我所見試驗專案最常見的挑戰包括缺乏贊助、預算不足、時間和資源不足，而且可能最糟的是，缺少清楚的目標來判斷試驗專案是否成功。
這並不是說試驗專案不正確。 進行試驗可能非常合理，而且可以降低對整個組織造成影響的風險，因為部署的部署不完整或設定不正確。 但讓試驗專案成功需要一些思考。
最近，我們開始為公用部門組織進行大量部署。 此練習令人滿意的是，組織已花費一切時間完成評估。 他們已選擇企業系統。 幸好，這是我們的。 我們在過去一年與評估小組合作，確定其技術問題已獲解答，但現在焦點會轉移到對組織中人員日常程式的影響。
他們建議我們在 6 個月期間內使用群組，而群組雖然可調整大小，但仍只占整個群組的 10% 左右。 有足夠預算，試驗支援最資深層級的管理，而且我們有足夠的時間可確保我們可以協助我們通常在像這樣的部署上執行的所有作業。 將放入此專案追蹤和時程表環境的群組將會在生產環境中，于可預期的未來使用它，因此它不只是測試。 這更類似于部署的第一個階段，而不是「試試看，我們將會看到其運作方式」練習。 在所有這些因素都已就緒之後，我們預期今年末會成功產生結果。
總結
試驗和概念證明專案是企業軟體的生命事實，但如果您未來有試驗和概念證明專案，您可以協助您成功向所有相關人員指出一些重要的成功因素：
首先，請確定您已清楚表達目標。
接下來，請確定管理部門瞭解您需要什麼，並且在金錢、資源和時間方面支援您，以達成這些目標。
最後，請務必製作專案計劃，並像在組合中的任何其他專案一樣加以管理。
關於作者
Chris Vandersluis 是 Microsoft 認證合作夥伴、加拿大 HMS Software 的副總裁和建立者。 他擁有 McGill University 的經濟效益學位，以及超過 30 年的專案控制系統自動化經驗。 他長期隸屬于 Project Management Institute (PMI) ，並協助您找到 Microsoft Project Users Group (MPUG) 的多倫多、多倫多和魁北克章節。 Chris 撰寫的發行集包括《大報》、《重度建構新聞》、《計算加拿大》雜誌、PMI 的 PMNetwork 和 Project Times。 他教授 McGill University 的進階專案管理，並經常在北美洲全球各地的專案管理關聯函式上進行討論。 HMS Software 是 TimeControl 專案導向的計時系統發行者，自 1995 年起一直都是 Microsoft Project Solution Partner。
您可以透過電子郵件連絡 Chris Vandersluis：： chris.vandersluis@hms.ca
如果您想要閱讀 Chris Vandersluis 的更多 EPM 相關文章，請參閱他的 EPM 指引部落格 (https://www.epmguidance.com/?page_id=39) 。