因為今天這樣的會議，讓我睡前一直在想這件事.....
想想，還是起來記一記這類的事情，未來怎麼做較好。
====================
「打鐵要趁熱」
這是對 乙方 較有利的因素。
當一份文件，當下沒有讓甲方看過/驗收時，一但拖太久，過了幾個月、半年的話。
要乙方再回顧當初的狀況，對乙方來說，會是個「額外成本」！
而這方面的立場，甲方相對起來，並不會積極去push 這一件事。
因為.......對甲方來說，驗收時間拖長拖短，對他們來說是不會耗人事成本的。
因此，在安裝好後，出一版文件，並要馬上要求甲方 做Review並驗收。
=====================
另一個部份，就是「文件往返」的成本問題。
為了讓文件往返可以「收歛」，必需要讓「甲方」有壓力，進而認真去Review。
而我想到的方式，應是對雙方來說是有合理性的：
這時就要與甲方討論，並取得彼此共職：
「針對你要Review這份文件，你需要多久的時間？」
「一個禮拜」
「好，那我們就一個禮拜的時間供你進行Review，到時發現文件上有不足/或是不對的地方可以一併提出，那我們到時再針對你的問題做文件修正」
「而這部份，避免我們文件往返太多次造成彼此的時間浪費，還是要先說明我們彼此的運作方式」
「比如，你看完這份文件後，提出十個問題點」
「就我們這邊的理解會是，除了這十個問題點之外，其它的部份就會當作都沒有問題！」
(這樣甲方才有壓力去認真看文件)
那我們就會針對這十個問題做修正，再供你第二次的Review。
依照上述的說明邏輯，在第二次Review文件時，僅會針對上次十個問題的部份再提出，而乙方再做調整。
因此，在第二次Review，甲方不該再提出那十點以外的項目，這樣會對彼此造成事情無限沿期！！
如果一開始可以這樣講清楚，(重點這樣的討論，一定要開正式會議！共同為證)
這樣我們乙方就不會被一直延.....
之後，自已再處理這類事情時，就以上述邏輯來處理吧！
1. 「打鐵要趁熱」！逼他們認真看文件，給甲方DeadLine！
2. 文件往返要收斂！不可讓甲方無限擴張！！
若這對應到「需求確認」是否也相同做法？？這要再思考一下。
=================================================
再來記記所發生的狀況，而這些對話，全是我當時沒有講出來的。
若講出來，是否這份論述合邏輯呢？？
「為什麼我感覺，你們認為我們重新去"安裝系統"是理所當然的事情呢？」
「當初在建置正式機後，所產出的第一版文件，你們是否有Review過？」
「若有Review過，當下都沒有問題嗎？」
「若沒有Review，再來這份文件，又再做一次第二版改版修正，那請問，
當時，做第二版的時候，你們有Review嗎？提出問題修正嗎？」
因為沒有Review，事情又過了半年，
因為你們沒有Review，變成這份內容你們自已也都不知步驟對與否，
而造成我因為這因素，又開始將系統整個重裝，
花了我兩三個禮拜在做這些安裝項目。
最初不是我裝的，因為你們當初沒Review、沒驗收，
造成我投入比別人多的時間，專門去處理這份安裝文件、並架起這環境。
那當時這次做好後，你們有沒有Review文件？？
沒有！
事情又這樣過了半年，才說這份文件步驟有問題，我們沒辦法照著安裝。
若真的是無法按步驟安裝，你們若當初有提出、認真去看這文件，
把該補的地方補上。
一定比我現在還要「回顧」當時狀況來的快很多。
但，現在你們卻把我要重裝，視為「理所當然」的一件事！
你們會這樣做是因為，這狀況跟本沒有花到你們半點成本！
但卻讓我們做了「四次」的重工，我們乙方因而多這「四次」額外的「人力成本」！
好吧，
這些話都是我睡前所想出來的@@，
完全沒有在會議上表達出「我的立場」，現場僅是完全被壓著打。
被一副視為「理所當然」，這就是你該做的事！
自已多學學專案的處理方式，讓整個管理是有「邏輯性」的才是。
再加油吧。
(THE END)
--花我兩個小時的睡覺時間做記錄----
0 意見 :
張貼留言