我作經營分析專案。
專案施工中最難的就是需求的界定。以前我作營帳系統的時候，什麼叫做需求，就是要你作的事情。需求的滿足有時能提高客戶的滿意度，但是也不是絕對的。
2023年開始施工的專案，做到現在已經累計了600多張報表。局方改制，使用統一的報表接入口（說實話，除了及其個別的省份，經營分析系統就tm乙個實實在在的報表平台），這個概念可不是portal那麼簡單拉，就是所有資料需要我們系統出，包含明細級別的查詢。那麼增加150張報表。總共報表750多張，kpi1100多個（我一直在懷疑，1100多個kpi，本身就把kpi的意義給湮沒了）。2023年新開三期建設。需求界定必須做好。
1、對於整個專案週期內的需求確定作那些，只作哪些。
2、確定專案各個階段（上線，初驗。終驗）的需求界限。
3、對於新增需求的處理。可以採用收取服務、維護費用或者增補合同方式。不錯，作了東西就是要收錢滴。
4、工單傳遞和扭轉必須規範流程。
暈啊，現在正在確定需求界定需求界限
不斷進化的分支和需求管理
這幾個問題在 敏捷下的需求和 分支管理 一文中其實已經給出了答案，時隔兩個月，管理方式又有了些調整和改進。我覺得還是有必要單獨寫一寫。總體的流程沒有大的變化，還是使用tapd來管理需求和缺陷，使用gitlab來管理 的分支，但有幾個小的調整 之前是以一周做為乙個迭代週期，實踐中發現，以週為單位，粒度...
需求分析的介面需求 需求分析
本篇不是為業務分析人員寫的，不會細緻講解需求分析的方方面面，業務分析師可以看徐鋒的 軟體需求最佳實踐 或者王海鵬翻譯的 掌握需求過程 本篇立足於架構師視角，講解需求分析過程中應了解的過程和方法，以及需要特別關注的點。開發者拿到的往往是乙個個的方案，方案來自於需求，那麼開發者拿到的需求是怎麼來的？乙個...
需求，還是需求
所有軟體開發都是構建在需求的基礎上的，脫離需求，與現實需求脫軌的開發都不具有商業意義。許多成熟的軟體開發過程學都非常重視需求，傳統開發模型比如瀑布模型會要求編寫非常規格化的軟體需求說明文件 敏捷開發過程比如xp則更注重在開發過程中，通過高質量的溝通，在客戶及開發方之間形成資訊的良性迴圈，以漸進發展的...