產品開發

關於技術債的溝通與管理

產品開發

關於技術債的溝通與管理

某次在一個技術社群中分享關於敏捷的議題,演說後有一位年輕夥伴問了我一個問題:「公司內有很多 legacy code,架構疊床架屋,時常改A錯B,跟老闆溝通了很多次,但始終排不進去工作中,永遠都被業務的需求排擠,在這種公司工作,很無奈,怎麼辦?」 我告訴他:「這是很棒的一件事,技術債是屬於活下來的公司,而技術債會愈來愈嚴重,某種程度也代表公司還在成長與發展,正面來看是一件好事。」 我也跟他分享了我看過的各種可怕技術債,但這些滿滿技術債的公司,它們卻是逐年在成長,而且活得還不錯。如果技術債是不好的,那為何這些公司沒有因此而倒閉呢? 「你怎麼看待『債』這種東西?它一定得償還嗎?」 如果你跟銀行借款,當你手上有錢的時候,你會立刻一次還清嗎?還是你會逐月逐月還,然後留些錢在手邊作其他用途呢?我相信多數人會選擇後者,留一部分的錢在身邊。為什麼呢?很大一部分原因是因為那些債並沒有立即償還的迫切性,也就是說選擇負債,但讓手邊有充足現金,對自己來說,有時是相對聰明的選擇。 對產品團隊來說,開發資源就如同手上的現金,這些資源是投入在償還技術債,或者開發新的需求,一樣也得從價值的角度來思考。 債

By gipi
One-Person Unicorn,一人獨角獸的時代來臨?

職場與工作技巧

One-Person Unicorn,一人獨角獸的時代來臨?

2024 年 4 月份 Sam Altman 提出 One-person unicorn 的時代來臨了,他強調的是在不久的將來,可能會有一些公司只有一位 CEO,其他的工作全部都由 AI 來完成。而且這樣的公司不見得就是傳統小規模的一人公司,而是有機會成為一家獨角獸公司。 經過這半年多對 AI 的學習之旅,自己天天用 AI 工具,並用 AI 工具來解決具體問題。也聽了許多公司如何使用 AI,並參與了一些公司的開發團隊使用 AI 做軟體開發的過程。 我想藉由這篇跟大家分享一些我對 AI 融入工作與生活的想法。 相信 AI 做得到 我相信現在還是很多人在探討 AI 「做得到什麼」與「做不到什麼」。而這種想法的背後,往往是為了找到不使用 AI 的理由。 例如透過 AI

By gipi
從 20 哩行軍的故事,看如何面對不確定性

產品開發

從 20 哩行軍的故事,看如何面對不確定性

幾年前吉姆柯林斯出版了《十倍勝》這本書,書中談到了 20 哩行軍的故事。後來這個故事被廣泛地拿來作為商管的教材,多數的觀點談論的是關於紀律,部分則更著重於探討不確定性。 多年前我在講專案管理課程時,我也會以 20 哩行軍作為開頭的案例,鼓勵大家思考,從這個案例中,我們到底能學到些什麼。今天我想用這篇文章,再次深入探討這個故事所能帶給我們的啟發。 不過因為年代久遠,許多的史料以不全然可考,我僅就我能收集到的部分做了考究,內容肯定不完整。加上歷史往往是成功者撰寫的,所以真相是否真如往上文件所陳述我也不得而知,但我們姑且把這當成一個半虛構的案例來討論,試著從這個案例中有所學習。 關於背景 19 世紀末至 20 世紀初,隨著科技的進步和地理知識的擴展,探險成為一種流行的活動。許多國家對於探索未知的極地地區充滿了熱情,尤其是南極點被視為人類尚未征服的最後邊疆。 與此同時,探險也被視為國家實力和民族自豪感的象徵,成功抵達南極點不僅能為國家帶來榮譽,也能吸引資金和支持。 而在當時,有兩支比較知名的南極探險隊,他們的領隊分別是: 羅爾德·阿蒙森(Roald Amundsen)是挪威探險

By gipi
馬斯克談產品研發過程可能犯的錯誤

產品開發

馬斯克談產品研發過程可能犯的錯誤

今天下午看到一個 2021 年 Elon Musk 接受專訪的影片:https://www.youtube.com/watch?v=t705r8ICkRw 裡頭提到蠻多產品開發的觀念,包含需求、分工,以及工程師的職責,我個人認為非常值得一看,以下我幫大家摘要了部分我有感觸的內容。 讓你的需求更簡潔 簡化需求,而非複雜化需求,許多工程師會傾向於增加需求或規格,但真正好的做法應該是減法。這個減法理論從 Steve Jobs 到 Elon Musk 都非常推崇,我個人也認為是很關鍵的議題。 在一個產品中,增加東西是容易的,但往往會增加複雜度,當我們總想著增加時,思考解決問題方法時,我們往往只有「增加」這個方向,而不會想著「減少」與「重新設計」。這其實也是所有技術債的成因之一。 而習慣用加法的產品,很容易模糊了產品的焦點。 當產品核心功能不具備競爭力時,很多產品團隊會開始想給客戶更多,而更多經常意味著失焦,

By gipi
讓 AI 生成程式,後續維護至關重要

產品開發

讓 AI 生成程式,後續維護至關重要

近期因為研究 Github Copilot,也一併看了 Figma to code 相關的服務,因為我想生成式 AI 會影響的並不單純是寫程式本身,而是直接影響了整個軟體開發生命週期。 釐清需求,我會考慮直接用 Figma 或其他設計工具搭配 AI 模組直接跟使用者溝通,然後若有雛型可以直接使用應該是非常快的。設計,Figma 應該就夠好用了,Figma to code 還能直接轉出前端程式碼跟 UI flow,也可以省下一些功夫。 Canva 或 Adobe 的工具也能轉成 html,也能省下一些功夫。Pseudocode to code,將虛擬碼轉成程式碼,目前還沒找到其他可以將規格直接轉成後端程式碼的工具,但合理來說,一些做軟體設計、UML 或者 pseudo code 相關的工具應該能做到。 程式撰寫、code review、

By gipi