《科技創業週報》是由 Star Rocket 於每週三發送的免費電子報，內容涵蓋創新故事與觀點、產品開發技術與經驗的分享、值得一聽的 Podcast 節目與歷久彌新的經典好文。
每則選文都會加上編輯精心撰寫的引文，非常推薦給工程師、產品經理、設計師，或者是所有對科技產業感興趣的讀者訂閱。（訂閱連結附於文末）
| 哈囉讀者 身為一名工程師，你會為了追求好的寫扣工具，發揮多極致的 Maker 精神？ 拍張照，分享給我們你的鍵盤、寫 code 桌面，或是提升你寫 code 體驗的心法或利器！ by Maxine 💻 |
| [中] 李松錡／即將到來的鍵盤 作者是一名軟體工程師，他動手打造了符合自己需求的鍵盤（長得…非常非常特殊？）本文記錄了他自行開發鍵盤的一些過程和細節，包含 3D 列印、自行焊接線路、改造開源的軟/硬體。 如果你也是非常注重鍵盤的工程師，可以看看作者對於自製鍵盤的說明，還有他對各種細節的研究。我們本來想說「身為一名工程師，自己做一組鍵盤不為過吧？」但想想覺得實在是太 hardcore 了 XD 想看更多作者對於鍵盤的研究，可以看這篇。 |
| [Podcast] 《星箭廣播》ep.17： 原來工程師認為的 No Code，跟我想的有些不同？ 這集《星箭廣播》有些特別。我們邀到國內新創公司 Ragic（ragic.com）創辦人郭家甫（Jeff），請他跟大家聊聊 No Code 這個議題。 No Code 指的是不用寫程式、透過圖像化的開發環境，讓一般人也能做出符合自身需求的應用程式，而且可以做到近似工程師寫程式才能開發出來的功能，例如 Ragic 就是一個讓人不用寫程式，就可以在類似 Excel 的介面上建立資料庫的線上工具。 有趣的是，Jeff 對 No Code 觀點，讓主持人 Titan 跟 Maxine 感到意外，例如兩位主持人很驚訝地發現，他們原本以為可以算是 No Code 工具的東西，對工程師而言很可能不是這麼一回事… |
| [中] 有些 Bug 在工程師眼裡，其實是 feature：用 User Story 的方式寫 Bug Report 🕷 工程師的腦袋就是跟大家的腦袋不一樣（咦）。 本篇由重出江湖的偽編輯 Venetia 所選的文章，也是發生在他本人身上的一個活生生的案例。過往在上線前，不少團隊都會有例行性的內部測試。不測試還好，一測試驚為天人，常常出現一堆「其實是需求沒開完整」的 bug report。 而本篇則是描述這類的測試回報，可以採用 user story 的方式來和工程師溝通。而要怎麼寫，內文有詳細的解釋。 最令曾經擔任過 PM 的編輯感到認同的是，本文作者提到：「規格就算寫再細，工程師解讀時，都還是有可能漏東西的。而用 User Story 來描述，不但容易閱讀，也可以在不需要把所有細節都說完的狀況下讓開發者可以自動補完規格。因為 User Story 闡述的是一個『動機』，只要你明白一個人的動機，就很容易可以預測他的行為。」 |
| [英] 關於產品開發正確姿勢 🙆♀ 「一個產品成功是因為它幫使用者解決問題」。這句話應該是所有開發產品的人——工程師、設計師、PM——都同意的話。但為什麼實際做起來這麼不容易？ 本文是 Facebook 產品設計副總裁 Julie Zhuo 的長青好文。文中她從「定義問題」、「執行」、「評估成效」，以及「團隊」四個面向，分享她認為產品開發過程中，必須培養哪些正確姿勢，又有哪些是「紅燈」。 編輯尤其喜歡作者談論團隊應該如何合作，以達成目標。她認為，協作開發產品的過程中，要盡可能拋棄「我是工程師」、「我是設計師」的角色框架，因為那可能造成貢獻與參與上的限制（可能是你自己認為不適合，又或是別人認為你不適合）。同時，她也認為，在乎與關注要解決的「問題」本身，比糾結「解決方法」更重要。因為問題是開放式、持續性的，它永遠有很多解決方法，也可持續激勵團隊不停實驗。 |
| [英] 什麼狀況適合 agile，什麼時候不適合？🙅♂ Quora 上網友發問，為何許多大型科技公司的工程師認為 agile 根本不適用開發？ Google 前工程總監 David Jeske, 認為，這取決於你產品開發的複雜性，以及客戶對你的互動需求。如果你的開發過程需要客戶參與，也時常面臨客戶臨時提案的變動，或是產品介面擁有大量 customer visible feature，那麼 agile 的「短線思維」就可因應這種需要快速調整的工作狀態。 但 Google 這類公司提供的軟體及雲端服務，需要縝密的設計與規劃，產品必須有一定的成熟度與完整度，才能讓客戶使用，不然產品本身可能根本無法運作。 David Jeske 的回答雖然獲得最多的 upvote，但建議讀者還是可以去看看其他人的回覆：agile 是一種精神原則，還是只是做事方法，又或只是風氣？ |
| [中] SaaS 是門好生意？為何不是每種 SaaS 都容易規模化？ 過去我們分享過數篇與 Slack 成功相關的故事，也分享過由 Hustle Fund 合夥人 Cjin 所分析的，什麼是 SaaS 服務最重要的營運指標。在軟體吃掉世界的年代，SaaS 看起來是門好生意。但本文作者嘗試以不同的切入點，解釋為何他認為 SaaS 產品其實不如我們看到矽谷成功案例那樣容易「規模化」？ 他認為， COGS（Cost of Goods Sold）——在銷售服務給客戶中所產生的所有產生的支出），例如網路頻寬、託管費用、產品開發／營運成本、薪資——是重要的關鍵。而仰賴客戶成長的 SaaS 服務，跟屬於「自我服務型（DIY）的 SaaS（如 Slack）不同，前者 COGS 吃重，因此限縮規模化的可能性。 文中作者有自製營收／成本曲線圖，顯示何為完美指數型成長的商模、營效不佳的商模，以及大部分 SaaS 處在的狀況。 |
| [英] 個人電腦是心智的腳踏車 我們可能都聽過賈伯斯的一句話：「個人電腦是心智的腳踏車。」本文對這句話做了一番考據，藉此我們可以回顧當時賈伯斯對於個人電腦（PC）的理解，以及他為了推廣 PC、使之得以大眾化所做的思考。 原來賈伯斯本人很喜歡腳踏車的類比，甚至想把當時正在開發的「麥金塔」（Macintosh）專案代號改叫「Bicycle」。作者 Steven Sinofsky 從一些過去的影像紀錄、華爾街日報廣告、電視節目片段（當時賈伯斯曾經作為來賓參加新聞台節目），最後再到一篇賈伯斯署名的雜誌文章，你會發現原來賈伯斯早就用過那個很有名的「卡車 vs. 轎車」比喻，當時他把大型主機（mainframe）比喻成火車，個人電腦則是福斯的金龜車。 這篇文章原本是一系列的推文，所以閱讀起來可能會有點不自然，但無損於這篇考據文章的內容。作者 Steven Sinofsky 是前微軟高層，領導過 Office、Windows 7 和 Windows 8 的開發。 |
| [Podcast] 誰說一定要擴張？—— 少的好、小的美的經營方法 凡事都要成長、擴張、規模化嗎？如果你最近有去書店，可能會注意到《一人公司》這本書。除了出書，作者 Paul Jarvis 也有經營 podcast，內容也很極簡，本集才 10 分鐘，極簡到一點廢話都沒有（咦？xD） 有人說，《一人公司》是質疑成長，但編輯認為比較精確說法，是質疑「多就是好」，並學習「減少不必要選項」，只專注真正有價值的事。更多客戶就是更好嗎？更多營收就是成功？更多曝光就是贏？ 更多客戶可能意味著更繁忙的客服支援與客服人力支出；更多營收可能只是更多投資人資金人挹注，但本質不賺錢；更多曝光可能排擠掉你最重要的用戶… |
