談如何讓開發者聽懂你的需求

 要做客製化,說出需求、找對人很重要!

所有的軟體影片都是在展示開發者能做出"類似功能"的產品,要100%適用在你的日常業務,基本上不可能,因為每個使用者的使用情境、業務邏輯、報表格式,都會有所落差,細微落差也是落差。

所以,敬告所有不明白產品是否合適的你,一定要把你的需求具體的、完整的說出來,沒有說出來,絕對不會有人知道合不合適,每個人都跟我說他有需求,但光聽到這一句,我真的不知道你的需求是什麼,如果連自己的麻煩事都不想說,我也幫不上你的忙。

如果,你不是不想說,而是你不會說,那歡迎你跟開發者預約一場會議,讓開發者透過問題來引導你該怎麼說你的需求,這樣才有幫助,我非常願意花這個時間協助你節省時間。

我想關於溝通這件事情,值得我好好發一篇文告訴大家,應該要怎麼講出具體的需求是什麼。

即便你看過我的影片並且跟我拿到產品,如果後續沒有經過調整以及被人帶著學習程式中對有幫助的功能,我敢跟你保證,此舉完全就是浪費你的時間也是糟蹋我的作品而已,產品必須要可以解決你的日常業務,才是好的產品。所以很多軟體下載下來之後,無法解決問題就丟資源回收桶了。

因為有麻煩的事情才會有程式的出現

人可以處理的事情,電腦才能處理,你都做不到了就別奢望程式可以。程式是人寫出來的,畢竟程式就是一種腳本,讓電腦乖乖去做人類指派的事情,而且通常是繁瑣、大量、簡單的事情,這也是為什麼程式沒辦法做到100%的原因,人終究還是有它存在的價值,總會需要處理那些程式無法做的事情,或替他排除問題。

程式很單純,資料進來=>處理邏輯=>資料出去,你會覺得麻煩的地方就是在處理邏輯,而這正是我能為你帶來的價值,有邏輯就可以程式化,原本花費很大量的時間會瞬間被完成,省下來的時間你就可以做更多更有產值的事,就算不做事單純在那邊滑手機也會感到身心舒暢,重複的動作就讓電腦去做,他做得比你快又比你準,為什麼不讓他做就好?

所以到底我要怎麼描述我的需求,開發者才"可能"聽得懂?

要讓開發者聽得懂需求,有幾個重要的原則。

一、把使用者情境完整重現

需要你把資料來源呈現出來,跟我說你看到什麼東西做什麼事情,最後成品應該長怎樣。

二、找出麻煩事發生在哪個階段、頻率如何

找出在處理邏輯上的步驟是最麻煩而且最繁瑣的,發生的頻率有多長,會消耗多少時間。

開發行為是一個成本,要能省下大量時間的步驟才是值得開發的。

三、希望問題會按照什麼邏輯被解決

完整的描述,當你遇到麻煩的事情的時候,你怎麼利用你現有的方式去解決。

開發者可以從旁推測並提供可能的步驟,告訴你現有的方式可以如何被精簡化、程式化,只要他可以讓你省下時間,達成正確的結果就好。

所以只要我說出來就好了嗎?不,你還要找到聽得懂的人

做工程的人很多,做程式設計的人也很多,同時做工程又做程式設計的人很少,所謂隔行如隔山,沒有在這個產業經歷過的人,不能深深感受到實際使用上的困難點,你說出你的業務邏輯,對沒有相關背景的人來說,他只會跟你說蛤,所以當今天你想開發的程式是跟營建管理有關,那你應該要找有營建管理背景的人並且具備程式設計能力的技術。他會根據以往的經驗反饋給你,這樣的邏輯有沒有辦法實作,效益高不高,有沒有什麼替代方案可以暫時處理這些問題,有時候你想批次列印很多存在於不同工作表的施工日誌,他會根據以往經驗告訴你可以用列印整本活頁簿處理就好。

最重要的是,他能理解你的需求,而且還聽得懂,又能跟你一起把整個適合你的業務邏輯搭配個人的經歷實作的更加精緻,這麼貼心誰不愛。所以如果你想要簡化施工日誌、監造報表、查驗表、施工照片等相關流程,你不找我要找誰,在我部落格裡,所有的專案都是我在實戰遇到的麻煩事才做出來的作品,因為我是一個很懶的人,我完全不想浪費這些時間。

懶惰,就是一名好的程式設計師所必備的靈魂,最好懶到可以按一下按鈕就做完所有步驟


留言

Popular Posts

Excel VBA @ 監造日報表、查驗表 -2

ExcelVBA@施工照片整理的應用範例

Excel VBA@ 監造日報表、查驗表