專屬客服18376668806 在線咨詢 留言/需求提交

創業公司的個人“可伸縮性”方案


小編說:創業公司最有吸引力的地方就在于其指數級增長的可能性。快速高效地增長讓投資人和創業者都能獲益。為了實現這種指數級增長,你也需要具有快速的成長性。你需要變得更高效,能為客戶為公司創造更多價值。

本文選自《互聯網創業核心技術:構建可伸縮的web應用》,下面我們看看在一家創業公司工作會面臨的主要挑戰,如何實現個人成長,使工作績效和工作樂趣都最大化。了解更多詳情請點擊閱讀原文


  • 加班不是一種伸縮性方案

在巨大的壓力、有限的資源、壓縮的工期、嚴重的不確定下工作會讓人神經緊張,而這正是創業公司工作的常態。創業公司是一杯讓人情緒爆發的雞尾酒,引人入勝又讓人筋疲力盡,同時又收獲滿滿,不過也要小心不要讓創業變成一場無目標的比賽,讓工作變成一種無思考的沖動。

工作時間越長工作成果越多似乎是一件自然的事。給自己多一點壓力,每天都工作很長時間,甚至周末都在工作,你精力充沛、目標明確、充滿希望、相信未來,看起來這是正確的做事方式,似乎做出的犧牲也并不大,而且那種被需要的感覺也很贊,感覺自己就是一個英雄。

問題是這不是一個長久之計,加班工作是實現個人生產力伸縮性的一種非常糟糕的辦法。超過正常工作時間的加班時間越多,精神狀況就越差,創造力越低,注意力越分散,眼界和決策力都會退化。另外,你還會漸漸變得多疑、暴躁、易怒。你會討厭那些工作時間比你少的人,面對越來越多的工作你會變得無助和沮喪,甚至會開始厭惡那些你曾經摯愛與渴望的事業,只有一種方式可以壓抑這種焦慮,那就是更瘋狂的加班。這是一種病,被稱為過勞癥。

過勞是創業公司工作的大敵,它會偷偷地占據你,使你變得盲目,最后被它控制。就像一個死循環,你越努力工作,就會越累,就越不能找到高效的工作方法,你就越需要更努力的工作。每個人都或多或少有過過勞的體驗,就我自己而言,真是一種糟糕透了的感覺,花了好幾個月的時間才完全恢復過來。我的體會是,3~9 個月的高強度工作(在極大的壓力下每周工作45 到60 小時)就可以體驗到相當程度的過勞了。

上圖所示為加班對勞動產出的影響。開始的時候,勞動產出會隨著加班時間增加,但是用不了多長時間,加班的勞動產出會逐漸下降,然后隨著加班情況的持續,勞動產出

會變得和正常工作一樣。再往后持續加班只會導致更少的勞動產出,直到最后受不了以閃人告終。

提示

如果你在一家創業公司工作,那么很有可能你已經或正在體驗過勞癥的感覺。壞消息是沒有一種快速簡單的方法可以從這種癥狀中恢復。少一點工作,多一點鍛煉,多花一點時間陪陪朋友和家人,即使這樣,要完全恢復還是要花幾個月的時間。還有一種較快速的方法是休個長假(3 到6 個星期),或者干脆離開這個項目換一個輕松一點的工作。在你的職業生涯中一定會經歷幾次這樣的過勞癥,然后才會學會如何在這些癥狀的早期就發現它并通過自我管理的方式避免。

不要讓自己陷入超級能干然后不久崩潰的循環之中,以一種更有效更健康的方式將努力程度維持在一個可持續的水平上。每個人的情況都不相同,動力不同,干勁不同,個性不同,職位不同,我個人的經驗是,每周工作超過50 小時就很危險,每周工作超過60小時大概1 個月左右就會出現過勞癥。

你的時間是你最珍貴、最難以轉換的財富之一。你的一個小時就是恒定的60 分鐘,沒有辦法對時間進行伸縮。與其試著工作更長時間,不如尋找一些方法在每周的40 個小時里為客戶為公司為同事創造更多的價值。這句話聽起來有點像一句空洞的口號,不過真的要學習一下如何更聰明地工作,而不是更努力地工作。

  • 自我管理

使自己生產力最大化的方式是將自己當作一個項目來對待,自己的任務就是項目的任務。項目管理的時候,有三個杠桿對項目進行平衡:范圍、成本和時間

任何時候,增加或者減少范圍、成本或者時間中的一個,其余兩個變量都必須調整以達到新的平衡。如果你增加工作量,就必須投入更多資源或者延長項目時間。如果你想減少時間以提前交付項目,就必須縮減工作范圍或者增加資源。如果減少了投入的資源,就必須砍需求或者延期。


上圖所示為項目管理三角,并且加了一些額外的說明以幫助記憶這些應對策略。首先,需要接受的事實是項目管理是一個關于權衡的藝術,花更多的時間和金錢卻做更少的事情。當你用這種方式思考工作的時候,就會發現一些其他的辦法去平衡項目而不是加班加點。

提示

管理三角里必須考慮質量這個因素。我建議構建自動化測試,確保高質量的代碼是功能范圍的一部分。質量不是可以權衡考慮的方面,如果你想保持一個長久的高效率,就不要試圖通過降低質量縮減范圍。犧牲代碼質量就像是跟TonySoprano(《黑道家族》的主角)借錢。當你工期倉促壓力巨大的時候,犧牲質量似乎是個好主意,但是或遲或早,你都要償還這筆高利貸(周末加班就是貸款的利息)。

我們進一步看看如何影響工作量、成本及工期,從而使工作負荷更具可持續性。

1. 影響工作范圍

“沒有數據支持,觀點不足采信。”——W.Edwards Deming

工作范圍通常是最容易平衡工作負載的方式,也是最有調整空間的地方。要更好地管理工作負載的第一步就是要意識到,當你有一個新的任務,或者現有任務需要增加內容的時候,你需要重新評估完成時間,增加可用的資源或者砍掉一些需求范圍。

做任何事情都要花費時間,因此再分配給其他任務的時間就會變少。這似乎是顯而易見的,但是學習如何基于成本和價值區分任務優先級是管理工作范圍最重要的技能。畢竟,一個創業公司想要生存下去最重要的事情就是做正確的事。要想高效地區分任務優先級,需要知道它們的成本和價值,然后基于相對成本價值率劃分優先級。

任務優先級=(任務價值)/(任務成本)

等式里面的任務成本部分通常可以用完成任務需要的時間來估計。雖然大一點的項目包含了財務成本(買更多的服務器或者要使用第三方的服務),但是估算起來并不困難,真正困難的是估算任務的價值。大多數時候,人們估算價值僅僅是基于個人的直覺感受,而不是過往的經驗或者實際數據。

這種評估價值能力的缺失導致大多數公司開發的東西根本就沒什么人用。我見證過人們僅僅根據某個人的直覺感受產生的愿景,沒有任何數據方面的驗證,就拼命做了很多沒有意義的事。事實上,根據一個沒有經過驗證的愿景進行創業,可能是創業公司失敗最主要的原因之一。這也是為什么精益創業運動提倡收集數據并基于經驗進行決策。根據經驗收集數據,根據數據做出決策,從而減少開發那些沒人用的東西的風險。

提示

如果你是喬布斯或者巴菲特,追隨你的直覺也許是一個不錯的主意,可惜我們大部分人都不是。所以我們的決策應該基于數據,而不是直覺。

改變創業公司的決策模式也許會比較困難,而且也超越了本書的范圍,不過我強烈建議你閱讀有關精益創業哲學的書。即使你不能改變企業現在的決策模式,你也應該收集一些數據,做一些客戶訪談,搞一些A/B 測試,試著幫助你的合作伙伴,確保自己不是在做無用功。

另外一個減少工作范圍的方式是遵循二八法則,知道什么時候停下工作,而不是為了一點邊際效益強制工作。二八法則是說 80%的價值由 20%的努力創造。神奇的是,二八法則在軟件開發的很多地方都有體現。

-- 80%的功能花費20%的時間

-- 80%的代碼需要20%的時間

-- 80%的用戶只使用20%的功能;事實上,研究顯示,很多系統有一半的功能從未使用。

-- 80%的文檔價值在20%的內容上

-- 80%的BUG 來自于20%的代碼

-- 80%的代碼變更集中在20%的代碼上

雖然二八法則很簡單,但是真正理解了它,可以避免花費時間去做那些錦上添花的事,讓你在事情“剛剛完成”的時候就停止工作,而不會為了達到所謂的100 分無休止地投入。

二八法則是一種實用主義哲學。在很多地方都會用到二八法則,運用二八法則減少工作量的思路有:

-- 和利益相關者一起討論,將新特性的范圍縮小至80%,延遲最困難(代價最大)的部分功能的交付時間。在實現完整功能之前,盡早實現一些最基本的功能,以進行A/B 測試,收集用戶反饋。這種最小可用產品的方法適用于任何特性,有些時候,這個最小可用產品就是真實用戶所需要的全部。

-- 盡可能保持功能最小化及簡單化。添加新特性的時候使用A/B 測試,確保這些特性有用并能產生期望的價值。根本不會被調用的代碼是某種形式的技術債,不會被使用的功能應該被刪除以降低技術債務。記住,少即是多,特別對于一家創業公司而言。

-- 確保只實現那些絕對必要的代碼,不要添加那些“有也不錯”的參數、類和方法。所有這些“然而并沒有什么卵用”的代碼都需要測試、文檔、理解和管理。少即是多。

測試覆蓋到85%~90%的代碼即可,而不是100%的代碼測試覆蓋。有些代碼塊比其他地方更難以測試,測試這10%的代碼可能有些得不償失。

-- 創建文檔的時候,關注主要信息及高層視圖,不必為所有方面創建文檔。多畫架構圖,一圖真的勝千言。如果你覺得你的文檔是完整的,那么你極可能浪費了80%的時間。

-- 如果不出故障就不要試圖修復代碼。需要修改代碼的時候順便重構這些代碼。老代碼如果不需要修改就不要動它。你為什么想要重構一個幾個月都沒人碰的類?就是為了感覺更好一點?我知道這句話聽起來有點刺耳,不過這么做看起來真的有點強迫癥,對創業公司而言是徒增負擔。

-- 將手頭的任務區分為“我必須要做的”和“我想要做的”,后者會產生大量額外的工作量。工程師們愛學習也愛開發——這樣會產生一種偏見,就是只喜歡開發新的而不愿意復用舊的,喜歡嘗試新技術而不是用自己熟悉的技術開發。結果就是,在工作中,我們總是追逐最新最酷的技術、框架及模式,而不是用最好的工具。此外,我們又足夠聰明,總是能想到辦法證明自己的選擇對公司而言是最好的。看穿這種偏見可以幫助你減少大量的不必要的工作。

-- 不到萬不得以不要去做伸縮或者優化。記住,即使你認為自己必須要做,也依然可能落入“我想要做”的陷阱。你不需要對你參與的每個項目都進行水平伸縮,大多數時候這都是浪費時間。據統計,90%拿到種子投資的創業公司都倒閉了。這個統計數據也適用于各種孵化器里的創業公司。剩下10%的幸存者,絕大多數永遠也不會伸縮到幾十臺機器的規模,不需要考慮水平伸縮。如果你在一家創業公司工作,你可以規劃伸縮性,但是要盡可能地推遲實現而將精力集中于最緊急的需

求上,比如確保你開發的產品是用戶真實需要的。


工程師是一群充滿激情樂觀向上的人,這樣的人做范圍管理會格外困難。我們想要把所有的事情都搞定,想要所有的事情都做到完美,相信明天下午就能完成所有的事情。我們希望我們的UI 是漂亮的,后端是優化的,數據是一致的,代碼是干凈的。不幸的是,除非你有無限的資源或者無窮的時間,否則你總要犧牲某些方面為更重要的事情讓步。

2. 影響成本

還有一種方式可以平衡工作量允許創業公司進行伸縮:增加成本從而減少工作量。你可以將任務和責任委派給其他人或者第三方公司,從而減少你自己的工作范圍。如果你的工作太多自己做不完,所有的工作又真的需要做,這些工作也沒辦法用自動化工具完成,截止時間也不能推后,那么你應該考慮將工作委派出去。

將任務委派給團隊里的其他人,你就增加了你的部門的伸縮性。如果你是完成某項任務的唯一人選,那么你就會成為瓶頸并存在單點的風險。針對一項特定的任務讓團隊里的多個人都擁有處理的能力,這個工作就可以分配給多個人,而不會讓自己或某個人成為瓶頸。另外,同一個任務讓多個人參與,這樣在這個領域獲得突破和創新的概率會更大。例如,你的搭檔可能會發現一個針對工作流程的自動化或者優化的方法,而你可能永遠都不會想到。

為了能更容易地將任務和責任分配給團隊的其他成員,你需要確保人們對不同的任務和應用的不同部分都熟悉。因此,你需要讓團隊成員積極的彼此分享知識并更緊密的合作。

這里,給出一些實踐,有助于項目內部分享知識和責任。

  • 結對編程

兩個工程師針對一個任務合作工作。雖然這種做法看起來有點低效,但是結對編程可以實現更高質量的設計、更少的BUG,以及更緊密的合作。我并不是推薦所有時間都采用結對編程,但是每周有一天進行結對編程也許是一個分享知識、理解系統、互相學習的好辦法。這也是指導團隊新成員的一種非常好的方式,新成員可以直觀地看到老員工如何思考問題,如何解決問題。

  • 臨時討論會

臨時組織,用白板或者紙和筆,討論問題,頭腦風暴,獲取更好的方案。

  • 持續代碼審查

團隊成員彼此交叉審查代碼。代碼審查不但可以提高代碼質量,同時也是增強合作分享知識的好辦法。彼此交叉代碼審查讓工程師之間彼此提供反饋,落實最佳實踐,同時也可以促使工程師不斷做出改變,持續進步。

增加成本降低工作負荷的另一種方式是購買第三方服務或者商業工具。通過第三方服務增加團隊處理能力有一個非常好的例子,就是使用第三方的監控和報警工具。如果你想自己開發一個監控報警系統,你可能需要花費幾個月的時間才能得到一個可用可伸縮的系統。但是,如果你決定部署一個滿足同樣需求的開源系統,你只需要數天的時間就可以讓系統運行起來,但是后續你還要花時間去維護它。如果你決定用第三方的工具,你就可以用花錢的方式節省開發維護這些系統的時間。通過使用第三方的監控服務,持續的金錢投入可以顯著代替初始的時間成本及后續的維護時間。類似地,也可以使用各種成熟的商業工具、數據存儲、緩存、工作流引擎、視頻會議服務,從而降低工作負荷或者增加生產效率。

提示

工程師喜歡開發軟件。這種喜歡開發新東西的特點讓我們產生一種偏見,就是熱衷開發勝過復用。開發監控服務、分析報警平臺,甚至數據存儲系統只是重復發明輪子的另一種形式。建議你在投入開發之前,先檢查一下有沒有已經存在的東西可以免費用,或者可以花錢買。

增加成本從而降低工作量的做法通常超出了工程師的權力范圍,這些情況要匯報給相關的業務領導。完全不必做這類工作是改善伸縮性的一種手段,可以讓你百分百地關注用戶的需求。

3. 影響計劃

影響項目管理的三個杠桿的最后一個是影響計劃。和影響成本類似,決定某個功能何時發布通常不在工程師的掌控之內,但是你還是可以通過向業務領導提供某些反饋在某種程度上影響計劃。大多數時候,截止日期和功能發布的命令都是可以談判的,也會根據成本進行考量。某些特別的情況下,比如公司需要應對一個激烈的市場競爭,或者公司簽了合同需要按時交付產品,那么你可能就要面對一個難以變更的截止日期,不過大多數情況下,事情總是可以商量的。

需要澄清一下,我不是說你應該不遵守截止日期。延期發布通常都是糟糕的,對公司也會有傷害。我是說,在創業公司工作,你和決策者的距離會比較近,你可以在決策上影響交付的成果和時間。不是消極地聽從指令,而是積極地向業務領導者提供反饋,讓他們知道哪些功能是比較容易快速開發的,哪些功能是比較困難有風險的。這樣,領導者就可以更好地理解成本,正確地評估任務的優先級。

為了持續提供反饋,我建議發布節奏更快速,每次發布的東西少一點,這樣可以更快速地獲得用戶反饋,決定是否還要繼續原來的開發計劃,是否有必要變更開發方向做點別的什么。快速學習是精益創業方法論的精髓。你頻繁發布、收集反饋和數據,然后決定下一步的動向,而不是提前做好全部的計劃。將產品開發分割成較小的迭代,可以減少風險降低出錯的成本,風險和出錯對于創業公司而言幾乎是不可避免的。

比如,如果要擴展一個電商平臺允許外部供應商開通他們自己的在線店鋪,可以將所有的需求都列出來,制訂計劃,然后基于這個計劃開發3 到6 個月,最后將新功能發布上線。開發的這幾個月期間,沒有任何用戶反饋,感覺像懸在真空中開發。既沒有辦法知道用戶是否喜歡你開發的這些功能,又沒有辦法知道用戶想要的其他功能。一次發布需要的時間越長,開發出的東西不符合用戶需求的風險越大。

更好的開發方式是將需求按照類似分鏡頭劇本那樣的方式進行分割,將發布控制在一個盡可能小的范圍內,每一次發布都基于上次發布的用戶反饋進行開發。通過更加快速的發布,你有機會和用戶進行頻繁的互動,進行調查,收集A/B 測試的數據,基于這些信息,可以重新定義待開發的功能列表,而不是按照事前的規劃全部開發。將一個大的功能分割成小的功能,依然遵循二八定律,你會發現已經開發出來的功能對用戶而言通常已經足夠用了,待開發的各種功能其實并沒有特別強烈的需求。

此外,將功能分割成小塊后,你可以使用mock 的方法,特別是在創業公司的早期。

mock 是指并不會真正實現的功能,但是這個功能會呈現給用戶,以此判斷用戶是否感興趣進而決定是否要真正實現這個功能。

比如,你想實現一個人工智能算法,可以自動給賣家上傳的商品圖片打上標簽,但是這個功能可能需要幾個月甚至幾年的時間才能開發完成。那么就可以用mock 的方法試驗一下,先在數據庫里隨機選擇一些商品圖片作為例子,然后讓員工在沒有人工智能算法的情況下對這些圖片手工打標簽,最后通過A/B 測試的方法分析賣家的行為及對搜索引擎優化的影響。通過這種mock 的方式進行數據收集,創業公司可以以更快的方式(只需幾個星期)獲取關于這個功能更多的有價值的信息,基于這些信息,你再決定是否繼續開發這個功能,還是去做點別的。

根據公司的情況及你的職位,你可能很容易就控制范圍、成本或者計劃。通過各種權衡及向業務領導進行反饋,你可以更好地平衡工作負荷以避免過度工作。



 

博文視點

您閱讀的專業智庫

喜歡請分享至朋友圈

了解更多本書詳情請點擊閱讀原文

長按二維碼輕松關注


點擊閱讀原文,即可快速抵達本書詳情頁!

99久久香蕉国产线看观看