從精益軟體到精益思想

說起精益軟體開發，這絕對算是一個老生常談的話題了。是以在這裡，我不想去談論諸如“精益軟體開發的幾大原則”或是“精益軟體開發的最佳實踐”等陳詞濫調；隻是最近在同僚的推薦下，拜讀了一本有關IT運維方面的書籍(《鳳凰項目》)。書中的故事十分有趣，同時又引人深思，細細品味後頗有感悟，對工作和生活上有了許多新的想法，于是便按耐不住寫下此文。

寫在前面

布倫特是一個有着十年以上開發及運維經驗的進階工程師，無論是伺服器當機，釋出失敗還是線上出現bug等緊急情況，他總是第一時間着手處理，雖然有時并不按照公司的正常流程去送出變更申請，但他總能在大家一籌莫展時漂亮的完成任務。于是整個IT部門的上司和同僚都非常的喜歡他，甚至其它和IT相關的部門有需要幫助時，也很願意找他，布倫特也照樣能夠快速并且出色的完成。直到有一天，問題堆積的越來越多，布倫特終于忙不過來了，而除了他，在沒有其他同僚知道問題的來龍去脈，導緻許多一級緊急事故無法及時處理，進而讓公司損失慘重。這時，大家的态度驟變，都将矛頭指向他，認為他沒有盡力，并且開始抱怨他總是不按公司流程處理問題進而引發了許多其他問題。老闆也不在賞識他，甚至覺得應該在他身邊安排幾個同僚去取代他，而後辭退他。

什麼是制約點

開篇的故事來源于《鳳凰項目》，其實不難看出，故事中的布倫特對于整個IT部門來說極其重要，由于他掌握了大多數人所沒有的資源，技術以及處理問題的上下文，并且沒有及時與他人分享，進而讓自己成為了問題的核心，事故的焦點以及部門的制約點。

而事實上，布倫特就是布倫特，他一直都在出色的完成任務，他一直都獨享着所有一切的上下文，是“一直”讓他變得無法取代，也是“一直”讓他成為了那個制約點。

制約點總是那麼的讓人琢磨不定：一開始，它必定是一個舒适點，大多數人并不會在意它，因為總有那些或那個人去悄悄的關注它；慢慢地，你也許很需要它，你才發現束手無策，不得不求助于你身邊那些悄悄的人，它又變成了一個痛點；最後，你還是在舒适點和痛點之間選擇了前者，随着時間的沉澱，它終于成為了一個制約點。

尋找制約點

忘記是什麼時候，耳邊聽到了一句“其實一切的一切，隻是我們（devs）做的不夠快，不夠好”，此話雖然有些極端，但細細想來，似乎也頗具有幾分道理。

但我覺得這不僅是一個個人問題，同時也涉及到了一個團隊的運作方式。是以我也時常在想: 如果你是一名身處Agile Team，并且保持求知欲，富有激情，喜歡激辯的dev，那麼怎樣才能把傳遞做的又快又好呢？

問題的答案肯定不是諸如“多看書，多學習”等唐塞之言，因為我相信一個能問出如此問題的dev，并且“保持求知欲，富有激情，喜歡激辯”，那麼他一定遇到了自身難以察覺的制約點。

是以，不妨從發現身邊的痛點開始，學着在組内尋找自己的制約點吧。

解決制約點

如果将制約點看做是一個樹根的話，那麼起初它隻是一個點，而後慢慢成長，具有枝幹，漸漸的新的枝幹上又有了其他的分枝，直到枝繁葉茂時，你才發現無法從根部去找尋任意一片葉子的路徑，因為，它的層級已經太深。

是以解決它的最好辦法就是将層級扁平化：當你發現并且解決了一個隻有你知道的問題時，不要讓自己成為那個制約點，學着share出去；當你發現在你所處的團隊裡有你的知識盲區時，不要讓它成為你的制約點，主動求助，消除盲區；當你發現組内有共同的痛點時，及時的提醒，集思廣益，避免它成為大家的制約點。

尋找下一個制約點

但我并不認為有制約點的存在就是壞事：人與人本身在能力偏好友善面就有差距，這就決定了每個人的知識體系大相徑庭，所謂“術業有專攻，技術有偏好”是也。是以，制約點某種程度上代表着你的一個目标或者方向，解決制約點的過程就是拉平它對你的制約層級，彌補自身的不足，這就是進步。是以沒有制約點就是原地踏步，為了更進一步，就得尋找下一個制約點。

是以，解決完“所有”（也許你認為的所有）的制約點并不意味着萬事大吉，你應該繼續尋找下一個制約點。

寫在最後

受“精益軟體開發”所啟發，個人覺得所謂的精益思想，XP（極限程式設計思想），Agile（靈活思想）都隻是一種方法論，甚至可以說由它們衍生出的所謂的最佳實踐也都是方法論。畢竟，具體到每一公司，每一個項目，每一個團隊，這些準則都不可能完全比對和适用，但若以此作為思想參考，就會不僅在工作中，而且在生活中感受到它的導向價值作用，進而事半功倍。

原文請戳