專案 vs. 流程

相對於專案管理，我更喜歡看板的主要原因之一就是，專案管理關注的是專案，而看板關注的是流程，是程式。

流程作為精益管理巨大的優勢之一，翻譯到如看板等工具上面就是，它強調的是打造並維護一個可以允許不同的“包(Pakcage)”以相同的質量進行通過的流程。這裡關注的改進之處永遠都是在流程方面，所以在這個過程中所獲得的經驗和教訓都必須是可以應用到整個流程上面，而不僅僅是當前正在通過該流程的某個特定的專案，某個特定的“包”上面。通過這種方式，你在持續改進方面所付出的努力將會在任何時候都能體現出效果。

看板流程的三個重大組成部分：

完成的定義(Definition of Done)

"完成的定義“是每個階段的目標。這是”內部客戶(比如，下一個階段)“希望前一階段所交付的內容。這是你在你的看板流程中為每個階段進行角色設計的一個方法，且，更重要的是，它保證了通過看板流程的所有“包”的質量。“完成的定義”為在專案的進展過程中大家究竟需要瞄準什麼樣的目標提供了指導方針。它定義了團隊在看板流程的每個階段中所要努力達成的目標，卻又不對完成該目標的方法進行限制。

對於打造一個偉大的產品，發現問題並正確的理解該問題是至關重要的。事實上，沒有正確的對問題進行認識往往是一個產品所以失敗的主要原因之一。所以，作為一個不斷迭代迴圈和改進的過程，我們在每個專案中進行學習，對每個階段的“完成的定義”進行改進。通過這種方式，每個“包”通過這個流程時所給我們帶來的知識，都能應用到所有緊跟著的“包”上面來，以確保同樣的錯誤不會出現兩次 -- 

流程的持續改進

說起來天下第一，做起來有心無力！針對流程而非流通這個流程的“包”進行突破，這聽上去是非常反直覺的，但是在精益管理上面，這對你的產品又是至關重要的。

舉個例子，在釋出一個新功能的過程中，你發現大量的使用者生成了大量的需要客服支援的憑證，抱怨說他們不知道如何運用這個新功能。那麼因為一次使用者教育的失敗，這就有可能會影響到使用者的參與度(engagement)。此時你的技術支援團隊應該已經開始著手幫助這些客戶解答他們的疑問，同時你的開發團隊應該也在動手提供一個針對性的更新。但正重要的是，精益管理會迫使你去找出究竟哪個環節出了問題，然後迫使你對這個流程進行改進，這樣才能避免同樣的錯誤不會在其他地方

持續改進是確保其他專案不會犯同樣的錯誤的關鍵，所以請記得將其應用到你的流程上面去。

流程

流程，就是你打造你的產品或完成你的專案的方式。流程的設計很大程度表示了你的團隊如何開發你的產品，同時它也反映了你的團隊及你的公司所宣揚的價值取向。

世上並沒有一個統一的標準來告訴你該如何定義你的看板流程，但根據你的產品的需要，倒是有著不少來自其他地方的值得借鑑的優秀實踐。同時，隨著你的生意的成長和你的產品的日催成熟，你的看板流程也會相應的跟著改變。我們為我們的產品打造MVP時候所用到的看板流程，和現在我們在用的看板流程已經相去甚遠。回首當年，我們那時對產品的的認知還相當有侷限性，且我們當時是一個只有10個人的團隊(相比我們現在，可以說是個小團隊了)，隨著我們對產品的深入學習和認識，團隊成員也隨之達到了200多號人，所以我們面臨的挑戰也是不可同日而語的。

你的流程進行設計和改進應該源於你此前的學習成果，但也需要正確的反映你的公司的價值取向。確保你對你的生意，你的僱員，以及公司的價值取向有正確的認識。通過以提升和加強你希望在你的團隊和產品中看到的價值取向的方式來使用你的流程。這同時還會是一個傳播你的企業文化的非常強大的工具。

以上提到的這些好處只是看板所帶來的眾多好處的冰山一角。看板的使用以及精益管理的原則，對於產品開發以及團隊的持續交付來說，都有著極高的價值。所以我們應該從今天開始嘗試在你的產品打造過程中應用上看板流程，並且確保不斷的在學習的過程中改進你的看板流程。

同時歡迎大家將你的看板 - 精益管理的應用心得在評論中提出來，以便同行們進行討論和學習，讓我們一起進步。