設計師,如何做好項目管理?

3 評論 11030 瀏覽 67 收藏 17 分鐘

當你成為一個項目的管理者的時候,你應該如何去做好項目管理呢?

工作中有時難免會遇到團隊部分職能缺失、人手不足等問題,為了整體項目能夠更好的推進。我們除了完成本職工作以外,還會主動去承擔一些其他職能的工作,如產品經理、運營、項目經理等角色以便目標達成、想法落地。

前段時間,本人有幸為自己之前負責設計的產品擔任項目經理&產品經理&體驗設計師,進行產品“體驗改版”。該產品屬于「后臺運維監控」產品,負責大規模、批量化的集群運維及服務部署、服務升級等操作,是在企業中銜接基礎硬件與上層服務的高復雜性、高專業性產品。改版內容則集中在前端框架與技術的重構、產品結構與信息的組織、交互流程與界面視覺的優化上。

首先介紹一下常見的改版方式:

(1)老版正常在線上使用,起過渡作用,重新搭建框架建立一個新的平臺。功能逐步建立、完善,完成后遷移用戶。

  • 前提:需要有相對整體和成熟的設計方案,讓大家對未知結果的投入達成一致;
  • 風險:風險大,耗費資源相對較大,時間周期較長;
  • 優勢:可以從頭思考、梳理,能從根本解決一些問題,優化的體感更強。

(2)在老版的基礎上進行優化,整體架構保持不變,局部體驗優化。

  • 前提:業務合作中常見的設計合作模式,局部功能優化,跟產品同步迭代;
  • 風險:較難從根本上解決遺留的體驗問題;整個產品體驗較差,局部體驗改善容易被忽略;
  • 優勢:風險小,投入的資源相對較少,結果可控,見效時間快,較容易達到預期。

本次我所負責的產品改版選擇的是「第一種方式」,風險相對較高。前期設計側通過用戶調研、痛點分析等設計方法的數據收集,已具備相應的數據支撐,明確改版的必要性;然后通過產出一版整體優化的設計demo來詮釋設計思路,與業務方對目標達成一致,明確本次改版的關鍵內容和為用戶解決哪些痛點。

鑒于業務內容的保密性,這里不對設計過程做過多講解,本文旨在以設計師角度,如何看待項目管理的工作、職責,以及在整個過程中的收獲和對設計本身的價值。

一、項目管理需要做什么?

一般項目經理(PM)在一個項目中的職能主要包括以下:

  • 負責項目時間管理與進度把控;
  • 協調資源來推動項目進度按計劃進行;
  • 平衡和適當的策略調整解決時間成本、資源間的相互制約;
  • 確保項目干系人之間的順暢溝通。

當承擔多個角色時,工作職責和協作的范圍邊界就會被擴大。一般體驗設計師需要重點關注在“需求對接”、“設計輸出”、“前端開發配合”這三個部分,同時參與“項目計劃”、“測試走查”這些環節。當站在PM角度,設計師除了關注本身的設計工作外,還需要關注整個流程中各環節參與者的配合與產出。

前期負責項目的用戶調研與數據分析、項目落地的節奏計劃、用戶需求的收集與對齊整理;中期實現階段關注設計、前端、后端的交付時間及質量;后期對測試bug的優先級進行規劃與解決方案確定,直至完成上線交付。

作為設計師還要負責所有需求的設計產出。由于在這個項目中設計師身兼多職,因此會將需求PRD、交互&視覺的設計在一個demo中同時產出,節省前端的需求了解和查看成本,也縮減設計者多文件輸出需求的時間。(當然具體工作分配要看項目投入的人力情況)

挑戰對設計師來說是一定存在的,但是這樣的機會確實也需要具備相應的前提:

(1)業務理解與熟識程度

  • 對你所負責的產品、業務具有較深入的認識和了解;
  • 了解用戶使用中遇到的問題,并能針對問題提出有效的核心解決方案,而非單純的美觀。

(2)信任

  • 在平時的合作中與業務方建立的信任;
  • 合作同事間的信任與配合意愿。

(2)機遇

  • 一般團隊會有專業的pm和產品經理,但有些產品團隊,人員配備不足;
  • 產品體驗方面得到上層重視,自上而下推動.

(4)老板支持

  • 老板給予后盾與配合(自己的老板和業務方老板)。

二、經驗教訓

在設計師擔任項目管理和產品工作的過程中,初期遇到很多挑戰。本身開發技術對設計師來說就存在門檻,由于知識背景、工作內容的差異,以及前后端工作配合流程的不熟悉,導致工作評估不準確、項目延期等現象。

總結下來,以下四點「經驗教訓」希望可以給有相似經歷的設計師以借鑒。

2.1 經驗:規則制定,“丑話”說在前面

前期確定統一的“完成”標準和項目合作規則,這點很重要,不妨先把“丑話”說在前面。比如我們項目組在啟動時就確定好了各參與者都需要遵守的合作方式,以確保進度的把控和必要的風險溝通。

但是,項目第一周期(根據需求優先級整個項目的開發周期分4個周期)完成后,就出現了延期現象,雖然延期在很多項目中不可避免,但還是期望能夠及時的發現問題、總結問題、反思工作,讓問題不像滾雪球一樣越滾越大,因此就第一周期的問題進行深度分析與解決方案的思考。

延期的原因主要有:

(1)工作評估不充分,計劃太理想

  • 現象:計劃時間無法完成計劃的工作,評估的時間不夠準確
  • 結果:計劃的時間起不到約束作用

(2)“完成、進度100%”的標準定義不明確

  • 現象:了解工作進度時,可能統計已完成,但又會占用時間去測試、優化、調整;實現效果與需求不完全一致;
  • 結果:進度評估不準確。

在充分了解需求后評估工作以及明確了“完成”的標準后,項目管理者會對整體環節的把控更加心中有數,也對可能會出現延期的部分留有空隙。

2.2 經驗:策略及時調整,有限時間內干更有意義的事

承諾的交付時間是確認的,因此,我們只能以deadline倒推。在剩余的時間內,我們能完成什么,從而有針對性的做排兵布陣。如果把時間比作一個盒子,當盒子空間固定,若要塞進更重要的東西,則需要將不那么重要的東西去除,否則盒子會爆裂。

同樣項目管理中需要及時調整計劃,在有限的時間內干更有意義的事,否則工作一直做不完,一直延期,產出的質量和項目目標都不如人意。

我們需要及時根據優先級調整策略,對需求區分主次,甚至在某個需求中再拆解,如高級功能暫緩,先保證基礎功能的使用等。

2.3 經驗:核心體驗提升才是對用戶更有價值的事情

看了那么多改版產品的反饋,第一時間的不適應必然存在,尤其對中后臺運維產品來說“穩定”是用戶的訴求之一。但緊抓核心體驗,從功能層面解決用戶問題,最后一定是正向的評價與結果。如果新體驗的價值不足以掩蓋舊體驗的缺憾和切換成本,那么對用戶的價值也就微乎其微,甚至毫無價值,就如下面的價值公式。

雖然「老版」用戶使用具有一定的熟悉度,也有“小眾”“臨時性”的功能,但是「新版」可以從以下5個核心亮點出發,解決用戶使用中的體驗問題,從功能層面解決使用問題,這些優化對用戶是更有價值的。

2.4 經驗:積極協作,配合協調

  1. 當項目出現風險,要及時找相關人甚至是上級尋求幫助,及時溝通、主動匯報;
  2. 過程中遇到分歧及時溝通,避免問題越滾越大,影響效率;
  3. 一定要在充分理解需求的前提下展開工作(設計理解PD需求,后端理解前端需求),否則后期返工代價很大。

三、成長收獲

我承擔這項工作的意義是什么?設計師能做好項目管理及產品工作嗎?

接受這項任務時我也有疑惑,就像工作初期以及一些師弟師妹咨詢的困惑一樣:我現在做的很多事是產品應該做的,本應該產品輸入的信息需要我去協助他們甚至幫他們完成,這正常嗎?我應該這樣做嗎?我做產品方面的工作對我專業有什么價值?

我的答案是:有價值!如果你是用戶體驗設計師,那就需要具備產品的思維,適當的產品工作與思考會幫助鍛煉產品思維,并且隨著工作的深入,設計能力與產品能力的交集會逐步擴大!

在《用戶體驗要素》一書中提到用戶體驗分為五層要素,分別為:表現層、框架層、結構層、范圍層、戰略層,將這五層的工作內容進一步解讀,會發現「結構層、范圍層、戰略層」屬于產品的職責范疇,它們對應的價值目標也存在交集,因此必然有些工作是交織在一起的。

3.1 產品思維

  1. 產品思維讓我保持產品大局觀,從業務的根本去理解當前手頭工作的意義,以業務目標為導向;
  2. 從產品角度拆分功能、流程,明確做什么不做什么,確立最小功能集合,平衡投入產出;
  3. 設計需要價值導向,在專業價值的基礎上結合業務價值,更好的完成價值自證。業務目標明確的前提下,設計的重點會非常明確,知道發力點是什么。

3.2 大局視角

  1. 視角的轉化,從頁面中的一個icon的美觀,一個組件規范、一個合格的頁面到整個項目的質量。
  2. 會把用戶真正需要的價值放在首位,在開發過程中,也會為了產品的性能、時間保障等,犧牲部分體驗的追求。

3.3 組織協調

  1. 項目過程中任何環節出現問題,都需要第一時間站出來解決,或者找別人尋求幫助;
  2. 各方資源的溝通協調,以保障最后的目標實現。

3.4 流程配合

  1. 更清楚前后端、測試的合作流程、以及各個節點的時間配比;
  2. 對一個項目開展的基本要素以及可能遇到的問題也有了更深入的認識,便于以后的工作交流。

四、總結

最后,在此總結一下設計師主導“技術產品”的項目管理工作的優勢和劣勢。

4.1 優勢

(1)交互人性化

  • 站在用戶角度思考交互行為和體驗,而非技術角度。
  • B端產品的體驗要求:高效、安全、簡單,通過設計減少用戶學習成本,簡化交互流程,使界面、信息易懂、易用。

(2)全局考慮,設計一致性

  • 從設計師視角出發,通盤考慮頁面展現形式和層級關系,可以將頁面進行類型劃分,便于產品的一致性與交互統一。
  • 對功能入口及操作設計整合與規劃,而非隨意添加。

(3)體驗意識傳播

  • 在業務中為體驗發聲,關注體驗的重要性,從而進一步驅動技術優化。

4.2 劣勢

(1)業務理解難度大

  • 產品的專業名詞、技術概念理解成本較大;
  • 需求業務邏輯強。

(2)技術了解不足,各角色溝通成本較大

  • 設計本身是一種感受、體驗,可以不是科班出身,都能通過界面或操作感受到好壞;
  • 開發技術對設計師存在門檻,設計師無法評判好壞并真正理解;
  • 溝通缺少共同知識體系,很有可能向技術妥協。

(3)時間把控不準確

  • 設計一般處在需求實現的前部分,會按照要求的截止時間完成工作,盡量節省出時間給后臺開發;
  • 前后端開發的時間不可控,對設計師存在技術黑盒。

以上,是我個人基于本次工作的一些經驗與收獲,期望對有需要的設計同學有所幫助。

 

作者:阿里TXD,公眾號:TXD技術體驗設計(ID:TXD-UED)

本文由 @阿里TXD 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. ??

    來自北京 回復
  2. 很棒哦 ??

    來自美國 回復
  3. 是有經驗的!

    來自上海 回復