hi，我是熵減，見字如面。
對於技術團隊來說，開發軟體產品，是一項長期的工作。
就如同馬拉松一樣，要完成這樣的遊戲，需要的多個迭代週期和很多衝刺的不斷地積累。
在遊戲的過程中，需要持續的、有節奏的向著目標前進，並在此過程要不斷地做出調整和改變。
然而，在現實中，今天有不少的團隊，是無法如此有效的開展工作的。
其背後的原因是：團隊將衝刺（Sprints）的數量和週期作為了目標。
將短期的衝刺做為團隊的目標，就是將開發產品的工作，看為了一項短跑遊戲。它的本質上就變成了一種浪費，因為團隊會最終陷入一些毫無意義的工作任務之中。
尤其是在今天，在網際網路增長神話消失後，唯快不破的方式，已經不能給產品或業務帶來太多的意義。
所以，及時的調整團隊工作的節奏，對團隊和業務的長期發展是更為有價值的。
短跑的“敏捷”
在衝刺（Sprints）的數量和週期成為團隊的目標後，整個團隊的動作就會悄然發生改變。
現實中，大多數團隊都採用一些類似敏捷的方法，在這種方法中，開發工作會在迭代中開展。團隊會計劃一些 Sprints ，會評估如何完成這些任務，並在完成後進行任務過程的回顧。而對於Sprints的背後的要交付的產品價值，要解決的實際問題，研發團隊是很少討論，也不太願意去關注的。
同時，為了增加衝刺（Sprints）的數量，或減少完成衝刺（Sprints）的時間投入，團隊會做出很多沒必要的拆分，從大的資料上來看：所有的事情都在不斷的進行，Sprints的完成量和完成時間投入也非常的合理。
但其實呢，產研團隊可能在玩一個短跑衝刺的遊戲，來迎合管理層的考核目標。在短跑遊戲中，團隊往往就會偏離了業務價值的交付的目的。
短跑衝刺的傷害
其實，這種空洞的短跑衝刺遊戲，會給團隊造成多方面的傷害：
首先，團隊的稀缺的研發資源被浪費在了很多無意義的衝刺（Sprints）之上。從表面上來看，團隊是完成了很多的任務，交付任務的效率也很高，但真正交付的業務價值是多少，是很少有人去關心的。
第二，團隊的衝刺（Sprints）回顧，成為了一個形式化的步驟。回顧，更多的只停留在第一層的任務完成的過程上的覆盤，而未能在向前推進一步，對於衝刺（Sprints）的業務價值，方向上的問題，團隊總是視而不見的。
第三，工程師們逐漸喪失了價值感。工程師們逐漸成為了任務完成的一個終端，而無法真正參與到問題的解決之中，長時間的參與感缺失，就會對工作失去了價值感和意義感，穩定性也就成為了一個問題。
總之，對於技術團隊，最稀缺的資源就是工程團隊的時間資源，如果我們如此任性將時間浪費在空洞的短跑衝刺遊戲上，是非常可惜的。
迴歸意義
要解決空洞的短跑遊戲問題，其辦法也是非常簡單的：那就是讓衝刺（Sprints）有意義。
讓團隊有全域性的視角，找到一個健康的節奏，將有效的時間資源，儘可能的投入到有業務價值的功能交付之上。
具體如下：
首先，在管理上，不只是單一維度的去考核團隊的衝刺數量和交付時間週期的指標。
第二，要讓產研團隊一起去設定每一個“衝刺”的業務價值，讓每個人(包括他們自己)都理解朝著這個價值前進的重要性。
第三，團隊要能根據實際的情況，動態的調整“衝刺”的重要性和優先順序，任務範圍的大小、交付週期的計劃等，不在追求虛假的指標。
第四，在團隊的“衝刺”回顧中，要向上有深挖假設的有效性，譬如，問題是否定位準確，方案設計是否有效，交付的業務價值是否符合預期等。而不只是任務完成過程中的研發效率那一小塊東西。
數字產品研發和交付，是一個如同馬拉松一樣的長跑遊戲。
在此過程中，要找到合適的短期目標，控制好整體的節奏，不斷做出有意義的回顧和調整，讓團隊看見真實的意義和價值，是持續發展的關鍵。
寫在最後
軟體產品的開發過程，不是一項短跑衝刺的遊戲，而是一項持續的馬拉松專案。
如果將研發過程簡化為只有衝刺數量和交付週期的短期任務，而忽略了團隊內人員內在需求，資源的浪費就是必然的事情。
回顧到敏捷和衝刺（Sprints）的本質之上，要讓團隊將更多的精力和能量，用在交付更有業務價值的迭代之上，才是更有意義的。
好的目標，會帶來好的結果，所以小心你的考核目標。
閱讀，思考，練習，分享，日日不斷之功。
嗯，寫完了。
新的一天，加油哦 (ง •̀_•́)ง