敏捷開發，到底「敏捷」在哪里

編輯導語：“敏捷”一詞看起來簡單，實際操作起來卻不容易。作者將敏捷與團隊工作結合在一起，分享了一些自己做產品團隊合作的經驗。

從初次接觸“敏捷”到現在已經差不多1年了，在初期還做了一個PPT在團隊內部分享，不過當時的理解比較粗淺。

經過1年的工作實踐與認知升級，對于它的理解也從當初的概念性理解，到了現在可以將其與團隊工作結合在一起。

一、對敏捷的解讀

敏捷的定義是：敏捷是一種創造產品或服務的能力，可定期獲取價值，并在不確定中動蕩的環境中迎接變化。

注意其中一些關鍵詞，如能力、定期、價值、不確定等，現在來進行逐一解讀。

首先，敏捷是一種能力，它不是一種方法論或者工作方式，是一種可掌握的能力。

除項目之外，敏捷會滲透到產品或服務的中，它是伴隨生命周期而存在的，并不是在某一段時間存在。

敏捷是定期的，不是一次性的，我們都會經歷產品或服務的迭代優化，因為市場在變化、用戶需求在變化。

所以對于團隊來說，與其努力創造完美的產品或服務，不如通過版本的迭代來不斷改進。

關于價值，敏捷專注于客戶（也就是最終的利益相關者）的滿意度，這一點也與敏捷的價值觀之一（客戶合作高于合同談判）相對應。

最后一點，關于不確定、動蕩與變化，敏捷提倡在靈活應變中穩定計劃，但同時對于外來插入的緊急任務，也可以適應變化。

雖然后者具體任務內容不可預知，但是對團隊敏捷來說，需要提前為此類情況預留可應對的空間。

二、敏捷的價值觀

第一部分有初步提到敏捷的價值觀，第二部分來詳細介紹下敏捷的4個價值觀，也可以理解為指導團隊敏捷的4個標準。

1. 個體和互動高于流程和工具

強調的是再好的協同辦公工具都不如團隊成員之間的即時溝通，無論現在是在用飛書、企業微信、釘釘這類面向協同辦公場景的產品，還是直接使用微信、QQ這類集合日常生活交流的產品，亦或者使用OA這類流程產品。

工具和流程可以在一定程度上提高工作效率，但這些流程和工具是一個“保底”的效用，在遇到一些重大事情或者比較緊急的事情，亦或者面對面溝通成本低于使用工具進行溝通時，多進行個體互動且形成這種習慣，是更佳的選擇。

2. 工作的軟件高于詳盡的文檔

在日常工作中，大家都會看到產品經理的需求文檔、設計同事的設計文檔、開發同事的技術方案文檔……

這些文檔的一種重要作用就是進行信息的傳達，盡可能減少低效的溝通成本。

那產出這些文檔，大家都有著對應的工作軟件，如產品經理常用的Axure。

對于文檔來說，使用何種工作軟件的意義更大于詳盡的文檔。

早期需求文檔其實都是word文檔形式的，但是現在隨著行業的發展，一些工作軟件逐步進入了人們的視野。

這些工具類似于工業時代的蒸汽技術，本質上解決的是同一類問題，但是可以大幅提高工作效率。

從成本、效益角度來說，最終得出的投入產出比更高，因而更得用戶認可和信賴。

3. 客戶合作高于合同談判

賺錢，或者說取得經濟效益回報，是每個企業都要追求的目標，甚至可以說是大部分企業的首要目標。

但是從企業的可持續發展來看，想要持續性的取得經濟效益回報，就不能只關注合同的談判，即不能只關注于某次合作帶來的經濟回報，而要將重點放在與企業合作的客戶身上，要關注如何才能與客戶取得長期合作。

例如SaaS產品，其重點是客戶的續費，而不是首次購買。

如果只關注單次合作，而不注重長期合作，不提供優質的產品服務、售后服務。

不僅不能獲得客戶的持續合作，而且企業口碑也會因此受損，在整個行業中都會受到不可估量的負面影響。

4. 響應變化高于遵循計劃

最后一點，其實大家會感受比較深刻。

每次在迭代開始前，產品經理都會跟技術、測試負責人制定產品迭代計劃。

但是在項目迭代過程中往往會有一些“突發情況”，例如老板又插需求了、市場商務同時又提緊急的“可以賺錢”的需求了。

這種現象的發生仿佛成為了一個客觀事實。

但是既然發生了，那產品經理就要想辦法解決。如何解決？

其實在敏捷開發的思維里，每個迭代都會留一個“buffer期”，即創建了sprint之后，并不是按照時間要求，將所有的人力都進行排滿，一般會預留20%的人力去響應一些變化的需求。

最后還要提醒的一點是，響應變化高于遵循計劃，并不是說不做初始的產品計劃。初始的產品計劃還是非常重要的，而且需要遵循執行。這樣能保證項目的有序進行。

三、當心“假敏捷”

前面介紹了敏捷定義的解讀，以及敏捷的價值觀。

但想要在團隊中將敏捷真正推行起來，或者要將團隊“轉型”到敏捷的方式，可并不簡單。

對于敏捷，也不是僅僅了解了上述介紹，就可以獲取敏捷的“能力”。

造成“假敏捷”的原因有很多，在不同的團隊中原因也不一樣，這里簡單羅列幾種可能的情況。

1. 對參與感的忽視

敏捷是針對整個團隊的，而不是其中一個或某幾個角色的，因此團隊中每個成員都要變得敏捷，這樣才能確保團隊對于敏捷的認知，處于同一認知水平。

如有的同事作為產品支持角色，覺得敏捷只對產品經理、開發，跟自己毫無關系，因此工作中只管維護好自己的用戶指南，而不注重敏捷的參與，最終會導致團隊敏捷能力的缺失。

2. 不想改變

對于團隊敏捷來說，sprint每日站會是很重要的一個環節，團隊成員即使同步項目進展與遇到的困難。對于已經有舊的工作習慣的團隊來說，也許并不容易很快接受這種方式。

3. 害怕

工資績效都是職場人非常關注的點，但有的管理者習慣靠施加壓迫和恐懼的方式來管理團隊績效。

這種方式會降低團隊的信任感，而互相信任是敏捷來說是非常重要的。此類管理者會害怕敏捷帶來的挑戰，挑戰他的權威。

4. 流于形式

任何的理論只有投入實踐，且帶來效益才是有實踐價值的。對于一些已經有成熟工作模式的團隊而言，如果只是在原先的工作流程中“插入”敏捷，讓團隊工作看起來具有了敏捷的流程，而不是讓敏捷發揮其應有的價值，則對于團隊價值來說，收效甚微。

5. 不注重客戶的反饋

做產品或服務的不斷迭代很重要的一點就是不停接收用戶的反饋，當然不是全盤的無腦接收。而是基于自己的判斷和用戶的反饋做分析取舍，這樣才能不斷通過用戶的反饋來優化產品或服務。

過于傲慢的團隊往往容易閉門造車，最終產品做出來了，可是卻沒有用戶買單。

以上介紹的是幾種會導致團隊“假敏捷”的可能，還有其他的原因也會導致“假敏捷”，這個就要針對具體團隊情況具體分析了。

 

本文由 @Bruce·K 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。