前言
在軟件項目中，我們會將功能分解爲很多個任務，在執行過程中會存在一個誤區，技術人員往往關注的是任務，一切以完成任務爲中心，就出現違背以用戶爲中心和敏捷開發的思想。
功能和任務它們有着緊密聯繫，又有着根本區別。
聯繫是任務是爲了實現功能而分解出來的具體活動，功能纔是用戶關注的，功能的優先級才體現了用戶對這個功能的關注程度；而任務是技術人員關心的，舉個例子比如有個任務是水平切分數據庫表，這個用戶連是什麼意思都不清楚，他又怎麼會關心呢？那這個任務也許對用戶有意義，也許對用戶的影響微乎其微。
兩種不同的思路最終會影響項目中的決策，採取不同的策略，它的結局是不一樣的。以任務爲中心的決策思路可能會導致這樣的後果：由於做計劃中存在不確定性，因此項目的時間往往是非常緊張的，很有可能不能按照項目計劃進行，那門以任務爲中心的決策會根據技術的方便程度、技術人員的興趣愛好來選取任務，可能那些對用戶價值不大的任務優先開發，到項目快結束的時候發現，一些對用戶最核心的功能早期沒有得到足夠重視，投入的資源不夠，最後要麼降低質量要求趕工，要麼是個半成品，而項目要麼延期，要麼強行交付，最終用戶滿意度可想而知！這就是不以用戶爲中心的後果。
項目實例
下面舉一個我們項目中實際遇到的例子。我們開發的一個消息系統，主要核心需求有兩個，分別是應用提醒和通知提醒，介紹如下：
- 應用提醒。是項目最核心的需求，爲各應用提供消息提醒功能。
- 通知提醒。是項目次重要的需求，提供通知類的消息提醒功能。
下面是兩種不同的思想導致的決策結果。
以任務爲中心的決策結果
經過我們的分解，分爲如下三個主要任務：
1.應用提醒設計和開發。一個人領取該任務開發，該功能技術實現困難、風險非常大，而且工作量較多。
2.通知提醒設計和開發。一個人領取該任務開發，該功能實現相對簡單些，技術風險一般，工作量相對少一些。
3.數據分表方案設計和實現。該任務是根據需求分解出的一個技術任務，主要是對消息的數據表進行拆分，以解決數據量過大導致表查詢效率下降的問題，系統上線初期的意義並不是很大，並且對用戶的使用體驗上沒有太大提升，但是有技術難度和風險，因此有一個人領取該任務，並且所有技術人員都願意去嘗試該任務，因爲能夠學習到更多的新技術，技術能夠有提升的空間，所有技術人員對此都比較感興趣。
當項目進行了1天之後，負責應用提醒設計和開發的技術人員提出，他那邊的風險過大，根本無法按時完成任務，項目風險會非常大，後來我們的經過反思，覺得這樣做下去項目問題會很大，最終的結果可能是這樣的： 上述任務2和3的任務都按時完成了，實現任務3的技術人員覺得這下實踐了一下新技術，感覺很開心，很有成就感，而負責1的工程師可能只實現了一個半成品，還有部分功能沒有實現，有些功能實現得很粗糙，質量不高，最終項目無法按計劃上線，給用戶的承諾無法兌現，用戶滿意度下降，公司可能會損失一些用戶，總之結果是成就了技術學習，失去了客戶滿意。
以功能爲中心的決策結果
那麼我們到底錯在哪裏呢？到底應該怎麼正確的決策呢？下面是我們的一個分析過程。
1.確定需求優和任務先級
確定需求優先級一般是由產品所有者根據需求重要程度定的，一般可以通過定性分析達到，通過最重要的兩個維度來分析就可以，分別是：用戶價值和用戶使用頻率。任務的優先級要根據所屬於需求來定，需求優先級高則任務的優先級也高。使用這種方法，本案例的分析結果如下：
經過分析我們可以得出優先級順序：
1.應用提醒設計和開發。該任務優先最高，保證該任務優先完成。
2.通知提醒設計和開發。該任務優先級中。本項目應該完成。
3.數據分表方案設計和實現。該任務優先級低。項目時間不夠可以不進行。
2.集中資源於優先級最高的需求。
對於優先級最高的需求，項目要足夠重視，幾種優勢資源在覈心需求上，充分降低核心需求實現的風險，確保用戶能夠儘快使用核心功能；項目結束的時候要儘量實現更多的可用的功能，而不是半成品，半成品對用戶毫無價值。
3.最終分析結果。
經過分析後，我們調整了策略，最終調整的策略是：
1.應用提醒設計和開發。將原來執行任務3的工程師調整過來執行該任務，確保該任務能夠按時完成，同時降低了技術難度，去除了一些對用戶影響微小的技術任務。
2.通知提醒設計和開發。按原計劃進行，應該問題不大。
3.數據分表方案設計和實現。暫不開始該任務，若項目提前完成，時間足夠可以執行該項任務。
4.實際結果。
該項目還在進行中，經過調整之後，大家一致同意該意見，而且大家的信心也倍增。可以預見的是用戶的核心需求應用提醒肯定能夠高質量的按時交互給用戶，通知提醒也應該問題不大。在用戶滿意的前提下我們儘量做得更好一點，何樂而不爲！
總結：
我們公司也在提倡以用戶爲中心的思想，很多公司都有着顧客就是上帝，全心全意爲客戶服務，口號誰都會說。說一套做一套的人比比皆是，就像很多官員一樣白天在大會小會上強調廉潔奉公，晚上在家大包小包收禮一樣，到底怎麼樣還要看怎麼做。所以我們在真正做具體事情的時候還要對照和自查一下，你的行爲和決策思路是否真的以用戶爲中心。敏捷開發思想能夠很貼切地符合以用戶爲中心，因此我強烈推行敏捷開發。