(文字稿) 談談『做了被罵，不做也被罵』- 把利害關係人的心，都拉到你身邊

[ 也可以用聽的 (podcast) ]

R 同學上周拋了個問題：柚子爸，我想對產品做個改善優化，可以得到什麼什麼效益...

沒等到說完，我就丟出了一串問題：來自於客戶嗎？主管知道嗎？認同嗎？改善效益和原先預定目標一至嗎？KPI能涵括嗎？...

看著一臉矇的情況，又聽到了嘟囊著說：我又不是沒在做事....

----------------------------------------------------------------------------------------------------------------

對的，這就是工作生活的微縮影。你的老闆真的會不挺嗎？還是沒有走在好的聊天基礎上？

到底該怎麼說，才能讓整件事沒人受委屈呢？你，又該用什麼方式讓老闆支持呢？

-----------------------------------------------------------------------------------------------------------------

Hello 線上的軟工夥伴好， 

其實，並不是說客戶建議的不對，或R同學判斷功能要納入產品不對。整件事在技術面都是沒問題的。問題在於：

沒有事先進行組織內完善的溝通，讓相關的關係人清楚你的意圖，就不會往期望的方向發展。再簡化說，就是『程序不正義』

我們在重新審視一下情境：
客戶提了優化的建議到 R同學身上，R同學經過快速分析後發現加入是更好的，回報了客戶也提給了我，唯獨缺少了他的領導。
或許，歲末年終之際，領導已經，或是正想要請 R 同學支援火燒眉毛的專案呢？

我們當然清楚的理解，當案子已經走到『既重要又緊急』的時候，想必主管恨不得期待你如同 7-11 或土地公般的隨伺在側，24小時服務吧。此時你告訴他說：我想做另一個案子... 他應該會毫不猶豫的製造一條社會新聞出來吧？

肯定不能這樣。那該怎麼做？

首先，應該取出日常工作任務清單，確認一下是不是有 on-going 的任務再走，探詢一下同組內其他同學有沒有十萬火急的事情正在燒？

诶~~  為啥要看其他人？您覺得同組其他人能忍耐大家在救火，而你在對岸割草忙別的事嗎？肯定不~~~

這坎能過，那建議接下來要把『需求方』的想像搞清楚，依照我們上一集介紹的手法，把任務換算成老闆能理解的『需耗用的開發時數』。

帶著客戶的建議，和你的努力，跟盤點清理過的時間表，解釋一下內容。我相信接下來，絕對很快會聚焦回到『功能的討論』。

而老闆的心理應該開始有一點點認同你了

在『專案管理』上也有說過：看透關係人，產出管理真策略，負面被動轉支持，專案組力會變少。

任何大小事，我們都可以視為專案來管理，要依據這些環繞在周遭的人他們的利益、需求，以及若『專案成功時可能會有的影響』來進行

鋪陳和說明。你的客戶是關係人，你的老闆自然也是。哦，對了，別去談若失敗會怎樣，聽起來繪有威脅的感受，這樣的談法是有害的

怎麼樣能讓老闆持續增加對你做這件事的信心呢？答案是：持續報告。當然，決不會是大小是鉅細靡遺的說，更不是東家長西家短的說，

而是講會影響到對方的：例如你的已完成事項、預定本周或本期的進度、有沒有需要他幫忙的部分。以之前我的老闆提點我的話來說：

其實老闆們可能對你所說的技術或目標並不是很懂，可是透過有結構的表述，他可以從這裡面做想像，感受到有沒有可能存在問題，或是

需要事先提醒的點。如果我們說明的零零落落，那老闆們敢信任嗎？會願意授權嗎？肯定很難 !!

透過結構化的工作分解結構進行報告，甚至能把客戶有疑問的討論，分門別類地做成議題管制表，最好的狀況是以終為始，反推是否存在風險的地方，寫入風險紀錄表，並且以你的專業，先評估是不是有可能發生。

相信在這些文件的輔助之下，所有的老闆都繪感受到：你是有能力完成這項任務的。

今天我們主題聊到這邊

祝福大家有一個平安順利的軟件人生。

(文字稿) 『取得規格，到開發完成』中間該注意的事

 

[ 也可以線上聽哦 (podcast) ]  

Hello 線上的軟工夥伴好， 

我們今天的主題來談一下『軟體開發時間怎麼做預估』。

通常客戶需求方只會給出名詞、概念。

例如：我想要一個APP可以看出現在還有多少需要執行工作？還有多少貨品沒收到倉庫？成本已經花了多少？之類的。

需求？啥？我怎麼把這鬼東西變成可以放在手機或網頁跑的程式？對~~~  你還早的呢。

就像從台北搭高鐵去高雄，拿到需求頂多只是買到車票吧。
那，桃園新竹台中嘉義，個別又對應到甚麼呢？

1. 首先需要查看一下，需求裡面有沒有特殊需要解釋的名詞：
也就是不容易懂的詞、或是不容易計算數量的詞，有的話，一定要追根究柢的問清楚。
畢竟，大多數提需求的人，在他的那個行業打滾有一定的時間了，我們不是那個領域中，可能就不清楚細節、眉角做到哪。怎麼判斷是否滿足呢？想想看自己能不能通順、不帶迷惑的講出客戶想操作的故事？如果可以，那恭喜你過板橋站了。

2. 要記得問客戶，特別不希望有什麼東西出現：在初期，大多數人的習慣是從正面來訴說，但是這也造成軟體退貨率居高不下的狀況，因為你沒有避開客戶不要的。這點一定要特別筆記下來。

接下來，夥伴該我們上場了。

3. 開始在紙上畫個拆解圖、或是想像的堆疊圖。這些雖然是老掉牙的系統分析步驟，可是是有道理的。透過大部拆解，很方便可以理解：有沒有現成的輪子，場景該怎麼轉彎，有沒有現有資源可以搬來借用的。比較講究的就會開始畫流程圖、畫分鏡圖，這些都好，都有助於更深入的理解接下來的動作。

畫圖沒辦法一下子很細，可是透過動手畫，變相的強迫自己思緒轉了一圈，這是邁向專案經理最重要的動作哦。畫圖的過程，主要就是關注連結和轉折，透過甚麼功能連結等等....

拆解之後，理論上我們已經接近台中，也就是路程的一半了。專案管理這個學科中總在強調一件事：品質來自於設計，不再於QC，意思就是在設計的過程是非常重要的，想通了再寫事半功倍。邊走邊想事倍功半。

拆解後，我們自然會把注目焦點，從全流程降階到每一個重要步驟。人只有再聚焦的時候，品質和效率才會是高的

接下來開始往嘉義台南接近了。

4. 對一些重點段落，可找比較有經驗的人員準備較為粗糙，或說擬真的程式碼。透過這些堆疊，可以方便後面接手的同學做更加精緻的處理，然後串聯，測試，產出客戶需要的操作場景。 

這樣一串的操作，大家應該對於怎麼把漂浮在半空中的需求，落地實現開始長出一些概念。我們可以找一些簡單的案例，慢慢的操作看看，實現並不難哦。

祝福大家有一個平安順利的軟件人生。

補一篇用 Genero BDL 寫 hello world

上一篇 blog 寫在 2015 年，再不來寫可能連 blogger 都消失了吧。

為了歡慶某柚子練習寫 blog ，也來搞一篇如何用 Genero BDL 寫 hello world。

HELLO WORLD分兩種- 有畫面的和沒有畫面的 ....

1) 沒畫面的總是簡單，碼一行 DISPLAY " Hello WORLD!"  就算了事了....

  想來 99.999% 的同學對於那個 hello.4gl 沒問題，但是不會編譯和執行啊。課本上教的是編譯用 fglcomp，照著用卻說沒有 LICENSE !! 用 r.c 卻又說目錄不對~~

此處要用的確實非 r.c ，而是 r.cs 編譯小程式用，編完了再使用 fglrun 直接執行就可以哦。

2) 有畫面的，可以考慮用 MENU 生出來

MAIN
    MENU "Hello World"
        ON ACTION exit
        EXIT MENU
   END MENU
END MAIN

編譯與執行都一樣哦，可以參考一下。

Welcome to THE World !