這算是笑話嗎....我笑不太出來
 

1.程式設計師給系統工程師:

這個專案無法完成，它必須要大幅度更改規格，而我們團隊中沒有人
了解關於這個程式的規格，也沒有人懂得這個應用程式使用的語言。
依我個人的看法，公司絕對不該接下這個專案。


2.系統工程師給組長:

這個專案需要規格的更改，目前我們的工作人員缺乏此種經驗，
使用的語言也還不熟悉，若要接下，則必須接受適當的研習。
依我個人的看法，我們還沒有十足的準備接下這個專案。


3.組長給專案經理:

這個專案必須在系統內更改規格，而我們對此種案件還沒有十足的相關經驗，
並且公司中大多數的人尚未接受過必需的研習。
依我個人的看法，必須花上比平常多的時間才有可能完成。


4.專案經理給部門主管:

這個專案需要將規格重新建構，而我們之中一部份人有經驗，
一部份人了解使用的語言，因此我想只要讓不懂的向懂的人學習就行了。
依我個人的看法，這個專案雖然有隱憂但是必須接下。


5.部門主管給總經理:

這個專案是一個可以向業界展示我們更改系統規格實力的機會。
我們具備足以讓專案成功的能力和人材，其中幾人已經自行完成了研習。
依我個人的看法，無論如何都不該錯過這個專案。


6.總經理給客戶:

我們是處理此種專案的專家，從前早已經歷過非常多數來自其他
大客戶的類似專案，以經驗來說完全多過於其他公司，請一定要讓我們接下。
依我個人的看法，我們絕對能在期限之內完成這個專案。




程式設計師:....

想成為程式設計師該學的第一套語言是什麼?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
英語 :mad:

鵝毛變成鹹水鵝端上桌 沒有放槍千萬不要誤會 :D

這裡有個問題
有多少公司接的案子是在有隱憂的情況下接下來，但結果有完成結案(不管東西好壞)

不好笑但是很寫實 :nonono:

剛剛又看到禁止菊花長花的估狗廣吿跟著我
要來去他們的公司前面舉白旗子抗議 :mad:

有
但是"通常"是程式設計師覺得有隱憂
專案經理無視
結案之後還是被客戶要求改東改西
於是專案經理就要求程式設計師繼續做白工

最近才因為功能規格的問題極度火大 :jolin: :jolin:

公司那位『資深』系統分析師不知道分析甚麼小，寫出來的功能規格畫面文件爛到爆。
裡面只有畫面及欄位說明這兩種東西，文件裡根本就沒有說明邏輯。
這就算了，畫面跟說明還可以對不起來.... :jolin: :jolin:
仔細一看才知道都是剪剪貼貼...連稍微修改一下都沒有....

都已經開過好幾次會直接跟她靠北好幾次了，每次都說文件會再改正。
為了告訴她要怎麼寫，我甚至還拿她的文件修改了一份正確的範本給她看，她娘的到底誰才是分析師。
結果改到現在都要半個多月了還是沒改。

今天還說文件會有小問題很正常，都是我在挑她毛病..........
小拎老木啦!!!照妳的文件功能根本做不出來啦 :tu: :tu:

有的，提出隱憂並非怕事推卸

是當時那個時間點客觀上真的技能不足以成事

業務考量加上客戶資訊不對稱不能判斷成品好壞，硬是接了之後

只得靠第一線人員硬著頭皮用案子練功自學成長承受了

雖然過程中有一些客戶無能發現的瑕疵

最後靠第一線人員的犧牲及客戶的好運氣以好的結果結案了

不良影響是業務單位從此敢於接大案子 @@

還有往後第一線提出的隱憂不太被當一回事，唉...

要看 呆伯特法則 在該公司內有沒有發揚光大
另外 結案是否順利有時跟東西好壞無關... 有沒有打通關係有時才是重點.