• <acronym id="gvoe3"><meter id="gvoe3"><address id="gvoe3"></address></meter></acronym>
  • <pre id="gvoe3"></pre>
    <p id="gvoe3"><strong id="gvoe3"><small id="gvoe3"></small></strong></p>

  • <pre id="gvoe3"><label id="gvoe3"><xmp id="gvoe3">
      axure商城

      項目從開始到上線經歷的一些事情和總結

      簡單的寫一下項目從開始到結束的一些經歷,并對各個階段我們做的一些工作進行簡單的闡述。

      1. 項目歷程

      XXXX項目終于上線了,下面就簡單的寫一下項目從開始到結束的一些經歷,并對各個階段我們做的一些工作進行簡單的闡述,以此來分享或者展現一下遇到的一些事情和經過,以及對項目現階段做一個總結。

      1.1規劃

      2019年初,項目經理、產品經理、研發經理與項目相關業主進行了一次次的例會討論之后,然后確定了項目的目標,我們根據他們給出的概念性信息進行方案的制定,為他們勾勒所需的藍圖,然后給出了規劃方案、基礎需求文檔和一些圖例,以及匯報PPT,并在此期間搜集相關的資料進行基礎數據的建構。

      期間經歷了重重的調整和完善之后,這才得到業主的認可,然后制定下個階段的工作計劃,并進行階段性會議的匯報。

      1.2調研

      2019年夏季中旬,我們在對這個項目進行了一系列的規劃準備之后,開始針對于項目方面進行線下調研的工作,調研之前首先針對于在規劃階段不清楚和不明白的地方制定了調研問題表和根據業主的需求應該調研那些方面的方向計劃表,然后到項目部駐場。

      1.2.1調研準備

      我們選擇的調研項目主要有三個,分別為XXXXX、XXXXXX、XXXX,在項目部駐場至少有兩周的時間,整體下來差不多花了一個半月的時間完成,調研期間我們除了對整個項目部的核心數據進行梳理和整理之外,還根據規劃中制定的需求方向進行了功能、數據、設計和邏輯方面的一一印證,期間也會和項目部的成員進行例會或者一對一方方式的交流,在獲取項目部成員建議和結合項目部管理數據的情況下,查漏補缺,調整和完善方案。

      1.2.2階段調整

      每從項目部駐場結束之后,我們小組成員都會開一次總結性的會議,根據整理的數據和從項目部成員那里得到的問題進行梳理,并結合原先的規劃制定解決方案,并根據最新的規劃方案和數據與業主溝通。

      整個調研階段結束之后,我們會根據已經調整和完善的數據與業主進行一次階段性的匯報。

      1.3需求整理和分析

      1.3.1需求整理

      以規劃和調研兩個階段為基礎,結合兩者之間得到的所有數據進行系統性的整理,并在需求說明書的基礎之上進行拓展,使得需求明確,根據業務的發展方向制定合理的解決方案,另外我們都會與業主進行交流找出一些需求的盲點,進行分析之后細化新的需求,然后與老的需求進行整合。

      1.3.3繪制圖例

      在需求基本確定下來之后,繪制相關圖例,我們繪制了思維導圖、功能模塊圖、關系流程圖、功能流程圖、用例圖、結構數據圖等,圖形繪制完成之后并及時與業主進行確認和溝通,不妥的地方調整,認可的地方進一步的細化和完善。

      1.3.4需求規格說明書

      在規劃階段需求說明書的基礎之上,結合所畫的圖例和數據撰寫需求規格說明書,以功能模塊內的每個功能為維度進行全面的解讀相關需求內容,包括功能和數據之間的邏輯關系,模塊與模塊之間的關聯點,以及整個架構方面的具體設計方向,在此期間原型設計也已經同步進行。

      1.4權限分析

      1.4.1權限的確認

      由于這個項目涉及到的用戶權限比較多,權限維度也比較復雜,所以針對于這方面我們專門找了時間和業主進行了長達幾輪的例會討論,除了從調研那里得到的權限數據之外,也經過一些方式從業主那里要到了一些關于用戶權限的內容,包括組織架構方面的內容。

      1.4.2權限的整理

      對僅有的一些權限數據進行分析和整理,制定了基礎的權限清單,然后和業主頻頻確認,之后又和相關的產運部、安全部等集團部門溝通,從中進一步的細化權限。

      1.4.3權限清單的制定

      以需求為基礎,根據PC端不同的端口(管控端和項目端)制定不同維度的權限表單,然后將確定下來的功能模塊內的功能一一列出,與對應的用戶權限進行關聯,并進行明確的標注和說明。

      通過權限清單的制定之后,最后與業主進行匯報和確認。

      設計方面也以權限清單為參考,盡量設計成有利于權限分配的方向。

      1.5 UE/UI設計

      1.5.1 草圖設計

      規劃階段的時候就已經進行草圖設計,主要是用來是印證基本需求,這樣也有利我們與業主進行交流,因為這個時候業主只有一些概念性的東西,所以對于自己想要的功能還沒有一個深刻或者全面的認知,只是從業務的角度進行闡述,所以我們根據他們的需求和要求,對所提的基本功能模塊進行草圖設計,然后在例會中(事實上和不懂技術的業主進行溝通也只能利用這種方式,用其它方式(比如數據表、流程圖、思維導圖)幾乎起到的效果不是很大),其實每次溝通他們要求看的也只有設計,他們會根據設計來確認這些是不是自己想要的。合理或者認可的地方我們會將這些保留下來,不合理或者不認可的地方他們也會提出修改的意見,我們會將他們提出的問題先整理成文檔,然后根據這些問題對草圖設計進一步的調整和完善,接下來會在找業主進行確認,直到他們認可為止。

      如果在需求確認的過程中他們提出了新的需求,我們會將新的需求加入進去,并在原型中進行標注。

      當然,期間出現的需求變更和新需求的加入我們也都會在需求規格說明書中進行同步,并對有關的圖例和數據表進行更新,或者整理成需求變更或者優化點文檔。

      1.5.2 高保真設計

      在草圖設計所涉及的所有需求都進行了確認之后,我們會將其進行系統性的整理,加入必不可少的動態交互效果和高保真的靜態布局,與真正的系統做成一比一的逼真模擬,然后來印證其中的可行性和邏輯性,不容易或者不能表現的出來地方我們都會進行標注說明,這樣有利于其功能性的拓展,然后將高保真原型和業主進行更加深入的交流。

      通過高保真的原型,業主對整個系統有了一個全面和深入的認知,然后結合提出的需求就會有更深的想法,我們從頭到尾系統性的進行查看,從他們那里得到不足的地方和沒有考慮到的方面,然后進行深入的調整和細化。

      經過一次又一次的確認,高保真原型也經過了一波又一波的調整和完善,得到業主認可之后,我們結合前面所說的權限清單,根據高保真原型來印證系統中關于權限分配的內容,從中發現一些問題,繼續優化。

      1.5.3原型說明書

      高保真原型完成之后,我們根據原先備注的說明和對一些復雜性的功能進行描述,從而形成與其相匹配的原型說明書,兩者結合在一起,讓后面研發人員有一個很好的支點,這樣更有利于理解和開發。

      1.6數據建模

      根據需求和設計,我們對平臺中所出現的各個實體的屬性進行整理,使其形成數據詞典,以此作為后繼研發過程中數據結構設計、數據庫設計、數據庫表結構設計的主要參考來源。并說明對數據要求的制約。逐條列出對進一步擴充或使用方面的考慮而提出的對數據要求的限制(容 量、文卷、記錄和數據元的個數的最大值)。

      對于在設計和開發中確定是臨界性的限制更要明確指出。

      1.6.1內部數據

      我們對內部數據及項目現場的業務數據進行了整理。

      業務數據來源于項目過程管理,包括項目的籌劃信息、進度數據、質量數據、安全數據、施工風險數據、報表數據等。

      1.6.2外部數據

      對外部數據包括來自既有信息系統(如XXX主數據系統、XXXX系統、XXXXXX平臺、XXX管理系統、XXXXXXXX系統)的工程基本信息和專題信息,以及通過離線方式導入的地理信息數據及其他數據。

      以上數據均在平臺數據標準的約束下進入數據中心,通過中心數據庫與應用系統形成數據交換,并在此基礎上開發標準化數據接口,將數據共享給其他需要的外部系統。

      1.6.3數據邏輯

      對數據進行邏輯描述時可把數據分為表態數據和動態數據兩種。

      把各數據元素邏輯分成若干組,例如函數、源數據或對于其應用更為恰當的邏輯分組。給出每一數據元的名稱(包括縮寫和代碼)、定義(或物理意義)度量單位、值域、格式和類型等有關信息。

      1.7風險評估

      我們邀請公司比較權威的相關人員對需求、設計、數據字典等各方面從技術和業務兩個角度進行了風險分析,對實現的可能性評估,并結合他們的建議,對其中容易出現風險或者風險比較高的方面進行深入的審查,整理成風險評估清單,將出現風險的地方進行一一的記錄,并對其劃分高低等級,同時細化這些內容,與業主進一步的確認,并提出相關解決方案。

      1.9研發項目

      1.9.1項目研發計劃書的制定

      研發經理根據項目的需求量和出現的風險量,對整個項目需要投入多少工作量和人力物力資源進行整體評估,和產品經理一同指定項目研發計劃書,并找相關領導進行報備,待確認下來之后在進一步細化項目研發計劃書的同時,開始著手研發的準備。

      1.9.2 開發環境搭建

      • 對XXXX3.0 PC端的環境進行搭建;
      • 對XXXX3.0 APP端的環境進行搭建;
      • 在此期間根據業主的要求,對PC端和APP端的項目端與管控端進行劃分;

      1.9.3 研發過程管控

      • 對開發各階段所需的研發人員(前端和后端)進行調配;
      • 與項目經理及產品經理進行深入式的需求溝通,并對需求的輕重緩急進行區分,制定合理的階段性、月、周工作計劃;
      • 對于風險評估中出現的技術風險進行研究,并找出解決方案;
      • 分析XXXX2.5上的歷史數據,結合最新的數據字典設計進行數據結構的設計;
      • 與產品經理和項目經理結合需求針對于原型設計深入式溝通,并每周與業務部門進行例會溝通需求;
      • 與產品經理和項目經理深入式溝通系統所需權限清單,根據整體架構來制定權限研發結構;
      • 開發任務分配及把控,開發過程中遇到一些問題,并及時進行項目組人員任務的分配;
      • 對于PC端和APP端布置兩個應用環境,一個是測試環境,主要用于我們內部進行出去查看、測試、復測和印證用的,另一個為正式環境,主要提供給業主和相關用戶使用的,每天都會對著兩個環境進行維護;
      • 與產品經理和項目經理每周進行開發任務狀況的跟蹤,上線期間每天召開晨會進行項目組開發任務的進度確認及任務調配,開發問題搜集及解決方案溝通確認;
      • 出現需求變更的時候,根據項目經理和產品經理制定的變更方案及時調整研發人員進行處理,并與產品經理對其印證;
      • 期間出現的問題以線上文檔的方式記錄下來(記錄提出人,提出時間,問題描述,相關圖片、完成情況,印證情況、備注等內容),每天實時跟蹤解決的情況;
      • 每當階段性計劃完成之后我們內部會進行一次總結性的匯報會議;
      • 每隔一段時間我們會給部門領導、公司領導和業主進行一次匯報;

      1.10項目測試

      需求的分析及挖掘隱性的需求,依據是需求文檔、設計、圖例、內部上線系統、進行測試用例的撰寫,在產品經理和研發經理的參與之下溝通具體的需求。

      1.10.1測試需求分析

      從項目部拿到軟件的需求規格說明書后,開始對項目的需求進行分析,通過分析、理解,整理成為測試需求,清楚分析出被測試對象具有哪些功能。明確測試用例中的測試集用例與需求的關系,即一個或多個測試用例集對應一個測試需求。

      1.10.2業務流程分析

      分析完需求后,明確每一個功能的業務處理流程,不同的功能點作業務的組合,以及項目的隱式需求。如遇復雜的測試用例設計前,先畫出軟件的業務流程。

      從業務流程上,應得到以下信息:

      • 主流程是什么?
      • 條件備選流程是什么?
      • 數據流向是什么?
      • 關鍵的判斷條件是什么?

      1.10.3測試用例設計

      • 編寫完成測試用例后,自我檢查以及與測試組長評審;
      • 測試用例的更新與完善;
      • 執行測試用例;
      • 禪道中提交執行測試用例時發現的問題(bug);
      • 研發修復問題后,再次執行測試用例進行回歸測試,關閉禪道中已修復的問題(bug);
      • 根據測試情況編寫測試報告,對整個測試過程和版本的質量做一個評估;

      1.11培訓過程

      1.11.1用戶操作手冊

      根據業主的要求,項目經理和產品經理制定出版級別的用戶操作手冊,修改程度涉及到了圖片規格、文字大小字形、段落間距、標題標準、封面的美觀度、頁眉頁腳與內容的同步性、每頁圖片和文本之上水印的設置、表格規范化等細節,并裝訂成彩色紙質手冊,直到業主的最終確認才終止。

      制定出來的用戶操作手冊一共有PPT、WORD、PDF三個版本。

      1.11.2視頻培訓教程

      除了制定用戶操作手冊之外,根據業主的要求還要制定整個與系統流程相關的視頻培訓教程。

      產品經理與項目經理共同撰寫錄制視頻的腳本,然后由相關領導審查,根據領導的建議進行調整和完善。

      根據腳本,產品經理對新系統進行視頻的錄制,然后對錄制的視頻進行細節剪輯、效果處理、格式編碼、存儲大小的壓縮和字幕的嵌入。

      將已經處理好的多個小視頻根據內容進行區分成五組,然后進行合成,生成五組主視頻。

      根據腳本錄制音頻,然后對錄制的音頻進行細節剪輯、效果處理、格式編碼、聲調的設置和語速的調整。

      將已經處理好的多個小音頻根據內容度也進行區分成五組,然后進行合成,生成五個主音頻。

      合成主視頻和主音頻,將五組視頻教程掛到系統上面,并以二維碼的形式展示,用戶只需要用手機掃描二維碼就可以進行查看。

      1.11.3培訓座談會

      我們以座談會議的形式與相關用戶進行培訓,首先講解系統項目端及管控端的功能,使用人群,如何開賬號,如何查看報表,如何填報等,然后宣講集團管理要求,考評要求等,并針對系統上線后的填報要求(比如2月25日之前全部填報完成等)。

      1.12維護與穩定

      1.12.1解答問題

      根據使用用戶的不同職位和公司,建立多個學習交流群,用戶在群內反應問題,我們則在群內解答集團、各子、分公司管理員、分管領導、項目經理操作過程中遇到的問題。

      1.12.2整理QA問題單

      解答問題期間,用戶反映的系統操作不熟悉或者不知道應該怎么使用新系統的問題,我們會整理成QA問題單,將問題相關的圖片和操作流程以及使用步驟都會針對應的轉寫下來,然后每天在各個群里面更新一次,這樣不同的用戶就不會問相同的問題,結合QA問題單會更快的上手新系統,也用來補充在制定用戶操作手冊期間漏掉的內容。

      1.12.3處理并優化問題

      解答問題期間,用戶反映的在操作系統過程中遇到的BUG,我們會整理成線上問題表,然后將提出人、提出時間、BUG描述、相關截圖、完成情況等字段在表內清晰的標出,項目經理和產品經理每天跟進,由研發經理主導項目組研發人員進行BUG的及時處理,BUG處理完成之后,我們會進行一次復測,完成一一印證之后,沒有問題的情況下及時反饋給相關用戶,有問題的話會與研發人員進一步的溝通,并將出現的問題修復。

      1.12.4維護數據

      • 上線前:XXXX2.5歷史數據的遷移,并進行腳本的編寫、測試、臟數據或者測試數據的清理;
      • 上線期間:XXXX2.5歷史數據的遷移,組織結構、人員、角色、權限等數據的整理和導入;
      • 上線后:XXXX3.0數據的整理,歷史欠缺數據的維護,垃圾數據的清理;

      2. 遇見的問題

      由于這個項目存在多個甲方經理,期間并有許多部門(安全部、產運部等)的領導參與,因為他們之間沒有溝通,提出的需求不統一,所以才會出現需求變更頻繁、要求混亂和新需求后面層出不窮的情況,再加上集團那里也沒有一個與我們進行業務對接的固定人員存在,導致整個項目一直處于不穩定的環境下,從而造成了不停往后延期的后果。

      3.總結

      在以上各種環境因素的影響之下,經過我們合理和靈活的調整,XXXX項目在磕磕絆絆中也算走上了正軌,從2019年1月份開始,到2020年12月份底正式上線,期間歷經幾番周折,整個項目組可謂歷經了九九八十一難,這才取得真經。

      經過將近兩年的合作,我們項目組除了之間的默契越發的緊密之外,從其他方面也都有不小的收獲,不管是相互之間的溝通、團隊合作能力、工作任務執行力和對負責工作的責任感都越來越好,越來越順利,還是在技術交流和相互學習方面頻次非常的高,可謂有了長足的進步。

      當然金無足赤,人無完人,何況是一個團隊,通過這次XXXX項目的研發,我們從中也認識到了一些不足之處,不過在發現之后都進行了有效的彌補和學習,隨著項目的深入,我們隨時保持自省的能力,在發現問題之后會第一時間給出解決方案,然后加班加點也要解決。

      時間在走,回顧雖然讓我們能更加的看清曾經走過的路,但是從中吸取教訓走好未來的路才是最重要的,看著2020年就這樣成了歷史長河中的一部分,2021年就這樣悄無聲息的來了,我們整裝待發,期待在新的一年里打出一個好成績!

      全部產品所在的店鋪地址:https://www.axureshop.com/shop/303

      –寫于2021年5月5日

      給TA買糖
      共{{data.count}}人
      人已贊賞
      產品經理

      產品需求文檔:如何撰寫一份適合敏捷迭代開發的PRD文檔?

      2020-11-3 13:51:04

      產品經理

      產品需求文檔:如何撰寫一份敏捷的PRD?

      2021-5-25 12:38:46

      axure商城
      0 條回復 A文章作者 M管理員
        暫無討論,說說你的看法吧
      ?
      個人中心
      購物車
      優惠劵
      今日簽到
      有新私信 私信列表
      搜索
      俄罗斯videoxxxoo
    1. <acronym id="gvoe3"><meter id="gvoe3"><address id="gvoe3"></address></meter></acronym>
    2. <pre id="gvoe3"></pre>
      <p id="gvoe3"><strong id="gvoe3"><small id="gvoe3"></small></strong></p>

    3. <pre id="gvoe3"><label id="gvoe3"><xmp id="gvoe3">