如何做好一個需求

fattyCoder發表於2020-12-05

目錄

作為一名後臺開發同學，做需求開發不可避免，無論是產品需求還是技術需求，需求雖然在變，但做事的方法是相同的，這裡簡單總結下從接到一個需求開始至需求上線的整個過程，以及其中需注意的點，避免後續踩坑

1. 明確需求

以產品需求舉例，接到一個需求之後，首先要做的是搞明白這個需求，而不是一上來就是開始擼程式碼，這樣很有可能導致最後上線的功能不符合產品預期

怎樣明確一個需求？

  1. 為什麼做這件事，收益在哪裡，讓需求方來即產品經理講，如果這個都講不明白，這個需求可以直接拒掉，畢竟做了也沒什麼收益，這個道理在哪裡都說得通
  2. 明白1之後，產品一般都會提出自己的方案，但是這個方案是否合理 也需要我們開發自己來思考，不當工具人，有不合理的地方應該直接提出來和產品討論
  3. 需求預期上線時間以及驗收標準

重點： 產品需求清晰後要追細節，避免一句話需求，凡是方案涉及到的細節點都需要在tapd or 企業微信中同步出來，避免後續返工

2. 開發

需求明確後，一般會開始排期，評估工作量，工作量拍腦門可不行，需方案明確後才能給出相對準確的排期

這裡評估工時

  • 工作點拆分的越細，一般評估的工時會更加準確
  • 可以請有經驗的同學幫忙評估，自己再留一定buff也可

拆分工作這裡建議 寫設計文件，之後排期也可以很明確的給出來，下邊列下開發中要注意的點

  • 設計文件

    • 需求描述，架構圖，細節流程圖，監控點，測試點等等，可以參考這裡就不展開講
    • 方案選型和涉及建議要有和業界或者公司內部部門的比較
    • 整體架構和方案指定後需評審，可以找組內小夥伴或者leader或者總監，都可以，查漏補缺

  • 編碼

    • 編碼階段注意寫單元測試
    • 編碼種碰到問題及時反饋出來討論，技術問題或者產品邏輯問題都可以， 或者寫入todo項也可

  • 自測

    • 前提是單元測試已ok
    • 針對介面或者邏輯進行測試，後臺開發一般需看日誌來確認邏輯正常
    • 需測試到異常分支，這裡最容易出問題

  • 聯調

    • 需求如果涉及到多方，需和上下游服務進行聯調，此時更應該看服務端日誌確認自己的邏輯正常才可以

  • 監控

    • 需能看到異常or關鍵邏輯的監控是否正常

  • debug

    • 需要有debug能力，比如可以針對單個使用者染色，接入天機閣，可以很方便看到此使用者日誌，要不然排查問題成本太高

  • 效果驗收

    • 需讓需求提出放在測試環境 驗收，符合預期後進入下一步

  • 效能驗收

    • 壓測當前服務，給出QPS，分位耗時等資料

  • CR

    • 強烈建議 程式碼走讀，前置查漏補缺，總比線上上發現問題好

這裡要注意

  • owner意識，自己承諾的時間點儘量要達到，如果有插入需求或者編碼中碰到問題會影響進度，需及時反饋出來，而不能等到最後一天了才說沒完成
  • 追求效率，30min法則，如果一個問題自己google和思考30min還沒解決的，及時反饋給導師or高T，再解決不了再向上反饋，不能死撐著
  • 口頭溝通基本無效，關鍵點需同步出來

此時開發側基本工作已完成，下一步需在正式環境部署服務上線

3. 上線

  • 資源評估

    • 建議前置，我廠資源申請還是比較麻煩的
    • 服務上線需要使用多少資源，cpu，mem，底層儲存（redis，dcache）等等 需要前置評估出來
      • 這裡根據之前的QPS資料，再結合預估的峰值流量 即可預估出需要部署多少節點
      • 這裡要注意線上節點的負載不能過高，需要有一定冗餘，線上負載建議在40-50%之間

  • 資源申請

    • 一般是向運維同學申請，需說明需求背景，收益，資源推導公式 便於運維同學審批

  • 資源部署

    • 部署在正式 和 灰度節點即可

  • 壓測

    • 之前壓測使用的是自己構造的client，req和線上使用者是不同的，這裡建議使用線上旁路流量指定後端某一個節點進行壓測，資料最為準確

  • 釋出流程

    • 灰度釋出

      • 釋出灰度節點，使用者量比較小
      • 產品需在此環境驗收功能是否正常
      • 開發需在此環境驗收邏輯是否正常，通過日誌確認

    • 旁路驗證

      • 因之前機器資源是根據壓測結果推導而來，假如結果不準 會導致線上服務異常，這裡建議可以 先旁路線上流量至新服務上，對線上無影響，又可以驗證服務效能，提前發現問題 提前解決

    • 正式釋出

      • 這裡建議使用 白名單+灰度百分比方式放量，風險最小
        • 產品開發先使用白名單體驗，通過日誌確認，功能正常之後再開始按百分比放量
        • 放量中注意觀察服務負載和之前的監控等資料，有異常及時處理

這裡多說兩句，後臺開發需對釋出有敬畏之心，釋出要灰度上線，邏輯都驗證到才可以，切記不可釋出完事就完事了，要對自己的釋出負責，畢竟我們寫的可不是玩具程式，是真的會影響上億使用者的體驗的

4. 後續

  1. 功能上線之後，還需關注上線之後效果如何，是否符合預期，可以和產品討論是否有後續的優化點
  2. 系統是否便於debug，如果不是 這裡也是優化的點，畢竟開發同學有大部分時間都是在查case，這裡效率一定要提高
  3. 如何處理線上問題，建議看這篇，以恢復線上為第一原則
  4. 開發側是否為了趕工期 有挖坑，比如有臨時的解決方案，該填的坑也得填了
  5. 總結。方案架構設計的對比，思考等等，持續總結才能提高自己的架構設計能力
  6. 專案中使用的上下游元件是否瞭解其原理，比如使用 redis or kafka 是否真的瞭解了，都是可以學習的點

歡迎大家一起交流學習：
qq：564790073
github：https://github.com/hashyong

相關文章