<tr id="yjjbo"></tr>

      1. <ruby id="yjjbo"><option id="yjjbo"></option></ruby>
      2.   
        首頁>項目管理 > 正文

        我們之前在需求評審環節踩過的坑...

        2018-11-09    來源:網易杭研項目管理
              原本覺得需求評審也就那么回事兒,大家應該都差不多這么做的,沒啥好說的。不過前不久有一位同學問起來我們是怎么做需求評審的,然后發現有一些團隊的做法可能還不大一樣,他們也還踩著我們之前踩過的坑,他們還在探索更好的方式,于是決定將我們的“玩法”寫下來,也許能給困境中的小伙伴一些啟發。
              首先,我這里提到的需求包含了:需求,交互,視覺。
              當然在調整到當前狀態之前我們的需求評審也存在很多問題,所以我先來介紹一下比較原始的需求評審的方式以及存在的問題。
        以前我們的做法是:
        需求評審:
              各角色的負責人(包含策劃,交互,視覺,開發,測試,運營等角色負責人)來參與,沒問題的需求全部進入交互階段進行交互設計
        交互評審:
              所有成員(含所有策劃,交互,視覺,開發和QA)參加,所有交互稿均會交付給視覺同學進行設計
        視覺評審:
        基本無
        以上這樣的狀態,給我們帶來了幾個困擾:
        首先
              是所有需求都會進入交互設計和視覺設計階段,但是最終有可能因為開發評估之后做不完而被擱置,形成了設計資源的浪費
        其次
              交互評審全員參與,由于人數眾多,而且分工還未確認,開發并不知道自己負責哪部分,所以參與度很低,一般就是交互在講,開發就在下面聽,也不一定能提出問題,到了后半程,有些同學就開始玩手機,效率很低。
        最后
              視覺評審的缺失,視覺評審由于沒有約定明確的評審流程,所以有一些視覺沒有經過評審就進入了開發階段,直至需求走查的時候才發現有問題。
        基于以上問題,我們逐步對相關的評審機制做了一些調整,調整后的情況如下:
         
        需求評審
        參與人員:
              策劃,交互,視覺,開發,測試,運營等角色負責人
        評審目標:
              評審需求的優先級和價值,以及初步判斷可實現性
        評審形式:
              集中會議。需求評審完成后的一天內,開發對需求的大小進行初步評估。從估算和計劃的角度來看,可以認為這是在需求細節還沒那么明確的情況下的評估,有可能存在50%±的偏差,但是他能將多余50%之外的需求砍掉,不必再進入交互階段。
        調整思路:
              主要增加了開發的初步評估,將大大超出團隊容量的需求提前砍掉,減少了交互的工作量,使得交互稿可以提前交付,同時也避免了不必要的交互浪費,因為當前版本未能開發的功能,在下一個版本可能優先級就又不一樣了,或者早已不符合市場需求了。
         
        交互評審
        參與人員:
              團隊核心成員(交互評審),相關功能的各角色成員(交互說明)
        評審目標:
              評審交互的合理性,以及交互的可行性評估
        評審形式:
              分為交互評審和交互說明。
              整體交互稿的交互評審,在交互評審后一天內,參與評審的核心開發針對交互做一個基本的評估。反饋:哪些需求肯定做不完,這些需求就不需要全部進入視覺設計了。
        在交互和視覺稿基本確認之后,在當前迭代的后期,再分批跟相關功能的開發和測試進行交互說明。此時,開發的基本分工已經確認,大家會更細致來聽,并且能夠提出比較細節的問題,當然此時交互稿需要修改的問題會比較少,基本不影響整體的安排。
        調整思路:
              1.與需求評審一樣,交互評審之后,基本上就能確認工作量,但是只需要核心的開發在交互評審之后的一天內大致評估工作量,定義是否有一些需求已無需進入視覺階段,減少了浪費。
              2.縮小參與交互評審的人員范圍,讓在場的人能夠充分參與;節約未來參加評審的同學的時間。
              3.縮小參與交互評審人員的范圍,可能犧牲了一部分其他人的意見,為了補充這部分人的意見,所以在新迭代即將開始的時候再組織一次交互說明,不僅引入了這部分人的意見,同時也可以將交互做更細致的溝通。
              4.最后的交互說明,不需要所有人同時過來,而是分批進行說明,這樣既能讓具體的執行人員能夠了解交互細節,又不會浪費大家時間。
         
        視覺評審
        參與人員:
              相應的策劃,交互,視覺,以及視覺負責人
        評審目標:
              評審視覺稿是否滿足需求,以及從策劃和交互的角度提出建議
        評審形式:
              當面溝通。視覺設計師會將設計稿郵件發給相應的策劃交互,抄送開發,并且邀請策劃和交互當面溝通意見。
        調整思路:
              1.視覺稿沒有評審,經常出現在后期策劃交互走查時發現問題。但是視覺稿的評審又不適合做的太重,本身視覺設計是一種無法明確定義好壞的問題,不是越多人參與就越好,所以只定義策劃和交互參與,開發只需看實現上是否有困難即可(一般比較少)。
              2.形式必須定義清楚,否則就會容易執行不到位。
        當然調整之后的模型也有一些限制條件:
              交互評審的時候,能夠找得到所謂的“核心開發”,他要對產品整體的業務邏輯都非常清晰,能夠評估新提出的需求大致的工作量。如果團隊中的開發都是獨立負責一塊,項目之間都不了解情況的,那就比較難采用這種方式。
              這樣的視覺評審形式其實也是比較依賴大家的主動性。否則就需要一個人,如視覺負責人來監督,是否所有視覺稿都經過評審。
              本文講的更多還是術的層面,關于評審道層面的講解在《網易一千零一夜》一書有詳細解讀,大家可以按需進行閱讀。
        好文一角
              劣勢與優勢之間,只差一個角度
              或許你只是在表面忙碌——項目經理如何成為時間的朋友
              沖突解決中的對話技巧
              (本資訊于2017-12-02首次發布)
         


        分享到:

        免責聲明:
          1、項目經理人發布的所有資訊與文章是出于為業界傳遞更多信息之目的,并不意味著贊同其觀點或證實其描述。其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請瀏覽者僅作參考,并請自行核實相關內容。
          2、本站部分內容轉載于其他網站和媒體,版權歸原作者或原發布媒體所有。如文章涉及版權等問題,請聯系本站,我們將在兩個工作日內進行刪除或修改處理。敬請諒解!

        關于我們 聯系我們 版權聲明 隱私保護 投訴建議 卓橡資源

        Copyright ? 2021 項目經理人 版權所有 京ICP備17062359號-3 如轉載本站文章,請注明原作者和原發布媒體
        本著互聯網分享精神,本站部分內容轉載于其他網站和媒體,如稿件涉及版權等問題,請聯系本站進行刪除或修改處理
        客服電話:010-89506650 89504891 非工作時間可聯系:18701278071(微信) QQ在線:511524637
        新聞與原創文章投稿:tougao#cpmta.com 客服郵箱:info#cpmta.com(請將#換成@)
        項目經理人——我國項目經理職業發展門戶網站,隸屬卓橡公司

        久久精品99国产精品日本,欧美熟妇黑人ⅩXXXXX,两个小婕子和我做受HD
            <tr id="yjjbo"></tr>

            1. <ruby id="yjjbo"><option id="yjjbo"></option></ruby>