接到需求任務,我們需要做哪些事情?

張飛洪[廈門] 發表於 2021-10-21

你好,我是張飛洪,本文共2094字,預估10分鐘讀完。

衝突是怎麼產生的?

我們見過很多類似的場景:

小飛:流程引擎做得咋樣了?(和顏悅色)

小洪:做完了,我給你演示一下。(心情愉悅)

小飛演示了一遍自己做的功能,小洪看上去很滿意。

小飛:不錯。不過,怎麼沒有支援流程稽核?(質疑)

小洪:為什麼要做這個?(質疑)

小飛:這不就是流程的一部分嗎?(不舒服)

小洪:哪裡規定要做流程稽核了?(不舒適)

小飛:現在做流程哪有不用稽核的?(火藥味)

這個時候如果雙方都不能很好地控制自己的情緒,那接下來一場體力的較量可能就一觸即發了。

接到需求任務,我們需要做哪些事情?

分歧

為什麼會出現這種分歧呢?其中一個重要的原因是,開始實現這個需求之前,任務雙方都沒有清晰地定義好邊界,沒能把需求描述清楚。

需求規格

不知道大家接受的需求說明文件都長成什麼樣,有沒有固定規格。我這裡先羅列我見過的需求文件大綱:

接到需求任務,我們需要做哪些事情?

需求大綱

我們再看看部分截圖:

接到需求任務,我們需要做哪些事情?

功能描述

大概總結一下,有幾個核心內容是我們重點要關注的:

  • 業務流程圖(資料流圖)

  • 介面原型圖(靜態和動態)

  • 原型圖功能描述

有些文件還會提供使用者故事或者用例圖來輔助說明,總之對開發者來說,保證核心內容的基礎上,需求越規範當然是越好的,我們最不希望看到的是模稜兩可、碎片化的需求清單,因為,通常這種功能列表只是一些簡單的描述,你並不能看到全域性。

使用者故事

除了關注流程、原型和描述之外,使用者故事(User Story)是我喜歡的一種方式。它是站在使用者的角度來描述了一個使用者希望得到的功能,關注使用者在系統中完成一個動作需要經過怎樣的路徑。既然它是“故事”,它就需要一個完整的場景。

相比較需求列表清單,不知道你對使用者故事的感受是什麼?列表是一種碎片化的內容,內部邏輯和全景圖都是不清楚的;而使用者故事有角色,有流程,有因果鏈,邏輯性更加強烈。

在前面的例子中,小張和小王之所以會對需求是否完成產生分歧,是因為大家對於需求完成的定義不同。

使用者故事採用的是以終為始的交付方式,使用者故事的核心是驗收標準,它清晰地定義出產品的邊界。

驗收標準非常重要的一環是異常流程的描述。大部分程式設計師都擅長解決正常流程,而異常流程則是最容易忽略的,也是產生扯皮的關鍵環節。既然容易扯皮,我們就在一開始把它定義清楚。怎麼才算做完需求呢?驗收標準說了算,達不成就不算任務完成。而且驗收標準可以由開發、測試、產品共同使用而不會產生歧義。

如果你的團隊採用使用者故事的格式進行需求描述固然好,如果不能,在功能列表中,補充驗收標準也會極大程度地改善雙方協作的效率。

接到需求任務,我們需要做哪些事情?

使用者故事

角色定位

也許你會感慨需求規格和使用者故事很好,但是“臣妾做不到啊,我們是小公司”。首先我們要明確自己的定位,我是一個產品經理還是開發人員,還是無所不能的全棧人員,不要做越界侵權的事情。

產品和開發是兩種不同的角色,但是對一些小公司可能分得不是那麼清楚,開發會兼職產品經理的角色,產品經理也會兼職開發。對一些大公司來說,產品經理也會有技術背景。總之,這兩個角色分分合合,統一於軟體的生命週期。

使用者故事的驗收標準主要是業務上的,程式設計師最後不要越界,徒增浪費,我們的發揮空間應該是在技術實現上。

然而,在現實情況中,很多團隊做不到這種程度。

假如你們團隊沒有產品經理,使用者故事驗收標準來寫?

沒辦法,答案只能是你自己。雖然你名義上是程式設計師,但當拿到一個需求的時候,你要做的事不是立即動手寫程式碼,而是扮演產品經理的角色,分析需求,圈定業務範圍。相信我,事前分析絕對比你拿一個寫好的系統給老闆,而他卻告訴你這不是他想要的,好太多了。

另外我想提醒你注意的是,扮演不同角色的時候,我們的思考模式是不同的。產品思考的是做什麼(方向),開發思考的是怎麼做(手段)。

另外,如果你要兼顧兩個角色,建議你先扮演好產品經理,多花點時間把驗收標準制定好,再回到開發人員的角色上去寫程式碼。畢竟,最容易維護的程式碼是還沒寫出來的程式碼

接到需求任務,我們需要做哪些事情?

角色定位

總結

最後,我們總結一下:接到需求立刻開工是不成熟的表現,因為你可能會南轅北轍,交付的產品是有歧義的,最後導致的結果是扯皮和爭吵,白白浪費資源。

在向目標行進的過程,我們要先想清楚自己想做什麼,先明確需求規格和使用者故事,特別是驗收標準,最後還要知道自己的角色分工和定位,避免該越界的不越界,不該越界的亂越界的混亂。

如果今天的內容你只能記住一句話,請記住:在做任何需求或任務之前,先定好驗收標準。最後,我想請你回想一下,在實際工作中,你接到需求後是如何開展工作的,或者你希望的需求規範應該長什麼樣?歡迎在留言區寫下你的想法。

感謝閱讀,我是張飛洪,如果你覺得這篇文章對你有幫助的話,也歡迎分享給你的朋友。