Contents
前言: 這篇是翻譯自 26 Lessons From Being a Developer at a Startup
感謝作者 Stephan Behnke 授權翻譯
三年來，我在柏林的一家小型 B2B 新創公司工作。 我是這家公司第一個後台( backend )開發人員，加入後經歷了從 200 到 720 個商業客戶的成長旅程，年收入從 20 萬美元增至 320萬美元，僱員人數從 5 人增長至 25 人。
下面是我個人在那段時間所學到每堂課的簡單分享。 沒有多的，也沒比較少，希望你覺得受用 !
1. 回顧會議( Retrospective )至關重要
我們經常在最後一次迭代時整個團隊坐在一起做回顧會議 ( Retrospective )。 回顧和評量的重要性再怎麼強調都不為過。 首先每位參與者都被要求思考自己進展順利和需要改進的事情。 小組討論要在每個人提出他們的想法之後才開始。 通過這種方式，每個人都能提出重要的事項——這比由聲音最大的人佔主導地位的會議要好得多。
2. 花時間做定期的 1:1s(一對多) 會議
在一個繁忙的創業環境中，可能很難證明每週和你的經理談上一個小時是否有用。 但這正是我們所做的，而且效果非常出色。 你可以深入、即時地討論問題，而且作為一名員工，你會感到自己更有價值。 沒有別的可以替代這一種方式。
3. 只要有幫助，請為開發工具付費就是了
對於電腦系統，每個 GB 或者 MHz 都有助於更快地完成工作。 對於軟體，每樣有用的工具，只要能使你更有效率都能發揮效應。 給開發者一個快速、現代的工具集( toolset )也表明公司重視他 / 她。 不應該為這問題大費周章討論，就這樣。
4. 與你的客戶面對面
我們定期拜訪當地客戶，並且每年都會到客戶熱區 (例如，紐約和舊金山) 與客戶見面。 這讓一切變得不同了。 與客戶交換電子郵件是一回事，但是和他們見面，聽到他們的痛苦和成功是完全不同的經歷。 當你重新回到開發時，這幫助你對你的用戶著想的方式有著強大且持久的影響。
5. 不要讓建構( build )變得緩慢
你知道，當緩慢的建構成為辦公室裡持續登場的玩笑時，你已經反應太慢了 (XKCD 有人知道嗎?) 。沒有什麼比反饋週期緩慢更令人沮喪的了。 我們後端用 Java 和前端用 Webpack，兩者都一週一週變得越來越慢。 最後，它讓我想要用頭撞牆。 從長遠來看，購買更快的機器無法修復緩慢的建構問題。 你需要考慮重構你的應用程式，例如模組化，以解決問題，沒有快速的解決辦法。
6. 跨職能團隊 FTW( For The Win )
在我們組建跨職能團隊之前，我們只能有效地處理小型專案。 一旦我們有了一個由設計師加前端和後端開發人員組成的團隊，事情就開始有進展了。 它使我們能夠進行更大、更有影響力的功能。 它雖因此也帶來了一系列挑戰，但總的來說，這是新創公司進化的關鍵一步。
7. Trello 無法好好擴展為瑕疵或專案管理工具
我們使用了 Trello 來管理我們的瑕疵，我喜歡 Trello，但是我總覺得它有無法達標的時候。 它很難搜索，且只能擴展到某個程度，在做專案管理上也有類似的問題。 到某一時點，使用的簡單和易用性逐漸消失，它變得過於令人難以駕役和低效。 我更喜歡目的專注的工具，這些工具實際上支持和促進你正在努力實現的目標。
8. 負起責任，否則就等著凋零
要在任何公司取得成功，你需要先負起責任。 責任越大機會越大。 新創公司環境的不同之處在於這麼做是很容易的 : 角色不是固定的，而且很容易抓住無人認領的或不想要的責任。 你必須成為一個能提高你的地位的人。 你需要積極主動地塑造自己的形象——否則別人會替代你這麼做。 如果你把這個和公司的目標聯繫起來，就會得到額外加分。 你可以成為一名很棒的程式架構師，但是當公司只看重功能開發時，你就賭錯了。
9. 適應或者離開…或如果你需要的話就去爭取
在某些事情上，你可能不同意你的上層管理。 在這種情況下，你需要決定這些問題對你有多重要。 如果它非常重要，你可以接受挑戰，為你認為正確的事情奮鬥。 但通常情況下，這將是一場艱難的戰鬥。 如果你周圍幾乎沒有人支持你，或者更糟糕的是，他們甚至不會分享你的觀點，那麼你需要問問自己這樣做是否值得。 你可以選擇忽略它，一起玩下去，也可以尋找另一份工作。
10. 辨識真正重要的福利
許多創業公司都吹噓給員工很多福利。 有些為他們的乒乓球桌感到自豪，有些以在週五晚上有免費酒吧引人注目，還有人炫耀他們提供高果糖玉米糖漿糖果。 這是個陷阱！ 尋找有意義的利益，比如午餐和學習、教育預算補助或健康福利。
11. 首席執行官( CEO ) 應該能夠度假
當一個創業公司成長時，CEO 不得不下放越來越多的責任，因為一個人不能隨之擴大規模。 基本上，CEO 必須一步一步地找人擔待自己的責任。 如果這個方法有效的話，一個好的指標就是他 / 她決定度假去了。
12. 團隊需要一個即時的訊息傳遞策略
我們使用 Slack，雖然它有時很有趣，我認為它殺死了很多的生產力。 對於如何使用這個工具，我們沒有一個共識。 很重要的是要清楚地定義哪些應該在聊天軟體( chat )溝通，哪些最好留到電子郵件，或面對面的對話或放入公司的維基( wiki )共筆平台。
13. 你可以影響人們對你的看法
首先，你說什麼做什麼將影響人們對你的看法。 如果你週末工作，你就會被視為“工作狂”。 如果你想出一些新的功能，你可能會被視為’神奇小子’。 問題是: 這會牢牢地嵌入。 通常，早期的印象是最重要的。 隨著時間，周圍人對你的看法將變得越來越難以改變。
14. 平衡團隊的資淺和資深人才
在後端，我們幾乎只有資深的開發人員，全部加起來開發年資超過 55 年。 但令我驚訝的是，這導致了過多時間做討論，很少產生很好的結果。 那些討論非常激烈。 有時候我在想是否每個人都能活著走出會議室。 另一方面，在前端，每個人都是資淺的。 他們表現出極大的熱情和創造力，雖然這很好，但經常會看不到全景，缺乏高層次的最佳實踐。 這顯出資淺和資深人才的正確組合很重要。
15. 在開始寫程式前，呈現視覺模型是必要的
一個新功能有許多利益相關者，例如專案經理、設計師、產品所有者、 CEO、開發者和客戶。 他們都有自己的期望和議程。 傳達新功能最佳方式似乎是盡可能接近最終結果的視覺呈現。 這一次又一次地幫助我們防止誤解，讓每個人都達成共識。
16. 一個團隊一個辦公室
一次又一次、一次又一次、一次又一次證明開放空間是個很糟的想法。一個公司通常希望在辦公室租金上省錢，並宣稱這是個協作和充滿創意的天堂。 根據經驗，我可以告訴你，你需要一個安靜的環境來完成工作——但是你仍然需要能夠輕鬆地與隊友溝通。 我發現 ”一個團隊一個辦公室“ 的規則能夠很好地保持平衡，如果你可保持團隊規模小的話。
17. 外向者主導每一個討論，除非有協調者
對於一個像我這樣內向的人來說，工作場所是很有挑戰的。 外向的人喜歡說話和寫作——很多。 內向者通常無法與之競爭，我們處於一個非常不利的地位。因為外向的人可以更快、更自信、更精心地做出反應。 任何公司如果不解決這個問題，就會失去它的 “沈默的少數” 的偉大想法和貢獻。
18. 開發團隊的成員需要有共識
一旦你從一人開發到團隊開發，就會有衝突發生。 每個人都是不同的。 這就是為什麼對於程式碼樣式、架構、開發和瑕疵處理、程式碼檢查等等達成共識是非常重要的。 在 wiki 中簡單地寫下規則是行不通的。 當環境需要時，它需要被生活化、理解和改變。 沒有什麼可以替代經常地談論它。
19. 定期更新狀態激勵人心
知道在第二天的站立會議時，我的整個團隊都會傾聽我做了哪些事令我受到鼓舞，對於每週的狀態更新也有同樣的感覺。 當我們的新創公司還很小的時候，每個人都會用幾句話分享上週的成功和失敗。 當公司變得更大，只有團隊的共同努力被展示出來，就感覺不再那麼有動力了。
20. 給員工時間型的學習預算補貼而非金錢型的
雖然我們有被承諾給與學習預算補貼，但除了參加研討會外，幾乎用不到。 工作坊可能有用也可能沒用——經常沒有最新的技術。 但是就像我和我的許多同事，我們能夠從部落格、書籍和視訊影片中學到新東西。 所以我建議允許開發者每年投入一些特定的日子來學習他們自己需要的東西。 無論如何，這是我們必須做的——通常是在週末——不過如果這麼做，公司就可以直接支持員工這些努力。
21. 配對程式設計被低估了
在團隊成員之間甚至團隊之間分享知識的一個很好的工具就是配對程式設計( Pair Programming )。 就我個人而言，我覺得它比程式審查更有效。 寫程式過程中的互動和討論是無價的。 這種方法的好壞往往取決於兩位開發者能否相處融洽，我可以說，把不同的人放在一起實際上可以產生最好的結果。
22. 如果沒有正確的發佈過程，功能開發就會停滯不前
這一點看起來很明顯，但很容易被忽略。 我親眼目睹了一些功能開發卡住且打入冷宮幾個月，只因為沒有人真正清楚如何使用一個放入分支的完成功能進行開發。 最重要的是，我們必須清楚地瞭解誰有哪些責任，或者，更好的是，有一個人的工作就是處理好這件事。
23. 自主狀況下會發生偉大的事情
當有自主權時，偉大的事情就會發生。 讓開發者有機會做正事外的發展，將會是一個強大的創新源泉。 當一家公司支持這種優秀的開發者所擁有的自然動力時，偉大的事情就會發生。 如果不這樣做，最專注的開發者無論如何都會自己創造機會 (例如加班或者週末工作) ，從長遠來看，這會導致不快樂甚至倦怠。
24. 當你想要鞏固一條信息，就請一遍又一遍地地說
你有一個重要的信息，你希望每個人都能理解、分享和記住。 你不能只說一次，或者只是把它放在一張幻燈片上，用粗體字。 你需要一遍又一遍地重復它。 它需要非常清楚。 你必須毫無懷疑地說這些話。 想要更多的建議請閱讀這方面很優秀的書 Make it Stick。
25. 駭客是新創文化的重要組成部分
新創公司總是有比目前所有資源還多的事情要做。 優先排序是必不可少的。 這通常意味著快速地把一個幾乎不起作用的解決方案組合出來。有時候是出於好的理由，比如做一個功能的原型看看它是否能堅持下去。 但是如果這樣的話，你很少有時間回到過去，把事情變得更好。 然而，我一直發現懊惱的是一個駭客行為可以讓我們高興多久，我總覺得這像是在作弊。 但是我已經接受了: 在任何創業公司，駭客行為都是必要之惡。 但請不要做得太過火。
26. 設最後期限是愚蠢的
在今天瞬息萬變的世界，最後期限( deadline )是過去的產物。 最後期限只會讓管理者感覺良好，但是會扼殺軟體開發的所有優點。 最後期限越是被強調，它就變得越荒謬和危險。 只會更糟糕的是截止日期再加入一整組的要求，這讓我們回到了軟體開發的古老起點，陷入沒完沒了的最後期限。(譯者著: 在原文下方有多人針對這項有意見，相關建議是以敏捷 Agile 的觀點，產品所有者 product owner 永遠不會給開發團隊一個大期限。 相反，產品所有者將產品分解為小功能並考慮它們的優先順序。 團隊以增量區塊的形式建構和交付，產品所有者決定何時完成。這是一種更加成熟和富有成效的工作方式。作者補充“ 軟體開發很難且一路充滿驚喜。”)
感謝你的閱讀。 我很快就會加入另一家新創公司，這次是在多倫多。 我確信我將在那裡學到許多更新的課。
你可能會有興趣
- 人生成長相關線上課程
- 創業相關線上課程介紹
- 軟體專案管理相關線上課程
- 歡迎加入 Soft & Share 團隊管理資訊分享
- 使用 e-mail 訂閱 Soft & Share 內容發布 – 透過 e-mail 提早收到 Soft & Share 發布的好康訊息！
- Soft & Share 特價課程與學習資訊分享 加入這個社團追蹤我們的特價課程與學習訊息