陕西快乐十分开奖预测|陕西快乐十分今日开奖结果查询
  • 如何用產品思維迭代項目管理流程?

    /2019-04-15 14:55:29/

  • \

    本文作者根據自己的創業經歷,分享了項目管理以及產品版本迭代的相關經驗。

    18年3月份,接到一位創業兄弟的邀請,加入團隊負責項目管理流程的規范,他表示:

    現有項目的開發流程太亂,項目交付太慢。

    剛開始接到這個需求,我的內心是很虛的,只有一年工作經驗的PM Dog,哪有能力搞這么高大上的東西。

    雖然顧慮重重,但想體驗創業快感的我,還是硬著頭皮上了,畢竟,萬一失敗了,虧的又不是我的錢……哈哈(奸詐臉)!

    由于該公司扎根的垂直領域圈子太小,為了隱私起見,下文對該公司簡稱為:A公司。

    背景

    A公司是在某個垂直領域做專業的解決方案供應商,目標客戶群體是大集團企業,項目周期一般是1年左右。

    需求調研(用戶訪談)

    接手這個團隊的時候,團隊有20來號兄弟,其中市場部主要負責項目的同事有三名,大概了解了團隊架構之后,我就詢問市場部同事當前的項目管理流程。

    他們是這么說的:

    跟客戶拿需求過來,如果自己無法評估技術的可實現性,就拿回來給研發,實現性沒問題,就做……

    然后我又去問了研發,研發的兄弟們是這么說的:

    市場部那邊,老是一句話需求,剩下的自己腦補,真讓人吐血。有的時候,突然就來了個需求,明天就要上線,措不及防又是一頓熬夜趕工,交出一個應付性版本……

    最后是技術部的兄弟們,他們是這么說的:

    上線的版本老是不穩定,有的時候還沒有測試就上線了,功能都跑不通,一臉懵逼。產品體驗太差,運維壓力太大,頂不住……

    通過一輪的訪談下來,需求的流向看似很健康,由:市場->研發->技術->市場,其實幸虧兄弟們關系鐵,不然早就拔刀相見了。

    需求分析

    第一、開發流程問題:沒有對客戶的需求進行“反饋式確定”,由開發人員直接做邏輯設計兼開發工作。

    比如客戶說,我要做庫存管理。這一句話需求,有可能出現什么情況呢?

    我方:哦,庫存管理,那就做一個臺賬,顯示客戶的庫存,再加個“增查改刪”,OK,搞定。

    1. 增:有新品種貨物進庫,新增該品種庫存;
    2. 查:品種太多,我加個查詢框,便于快速找到該品種,查看其庫存;
    3. 改:庫存數量有誤,需要修改;
    4. 刪:該品種不做了,刪除掉避免產生信息垃圾。

    看似考慮得挺周全,其實還是有可能與客戶的想法有出入的,比如:

    1. 增:新增品種庫存時需要輸入哪些字段,哪些字段是必填的等等;
    2. 查:需要對哪些字段進行條件查詢功能;
    3. 改:哪些字段可以修改,哪些字段不可以修改;
    4. 刪:在什么情況下可以刪除,是否需要權限限制等等。

    更多的可能有:臺賬是否具有排序功能、臺賬是否需要庫存預警、庫存預警閾值是否可自定義設置等等。

    很多細節性的功能就這么忽略了。

    如果你說,我們多替客戶考慮,把我們能想到的功能都做上去,這樣很容易造成開發資源的浪費。

    如果做不到位,就會造成返工,客戶對我們不信任,為后續的合作埋下隱患等等。

    正確的做法是:

    新增原型圖評審環節:

    就客戶提出的需求,根據我們的理解及專業性判斷,輸出原型圖,跟客戶一起評審確定。

    如果我方對功能的設計有疏忽之處,在原型圖階段就進行修改,直至滿足甲方真正的需求,完成簽字確定,再投入開發。

    這樣做的好處是:

    1. 更好地將客戶的需求還原出來,對比下我們的理解跟客戶的需求是否有偏差。如果出現了偏差或者客戶有需求變更,也只需要修改原型圖,不需要修改代碼,降低修改的成本。
    2. 客戶充分參與了設計,有了參與感,對后面開發出來的產品,也會比較有認同感,一般就不會有大的改動。畢竟,誰都不愿意打自己的臉。
    3. 將開發人員進行邏輯設計的工作釋放,由產品經理進行設計,再輸出開發文檔,開發人員只需要將文檔語言轉化為系統語言即可。避免出現開發兼設計導致邏輯考慮不足,功能跑不通的情況出現。

    這樣就解決了一句話需求研發腦補、返工、功能跑不通、體驗性太差的問題。

    第二、項目迭代節奏的問題。

    創業公司人少事多且繁瑣雜亂,現在的市場部同事并非純真的項目經理。只是他們把東西賣給客戶了,客戶有什么訴求,第一個找的肯定是他們。所以慢慢的,他們也就成為了所謂的項目經理。

    在這個背景下形成的項目經理,有以下特點:

    1. 沒有主動深入了解客戶的使用情況,只會被動接受客戶提過來的需求。
      這個是很多緊急需求的本質來源。沒有站在整個項目的高度上做一些開發的規劃,非得等客戶真正需要用到了,發現沒有這個功能,然后就找到了我們的項目經理,項目經理把需求帶回來,做好了再更新到客戶那邊,事情完結。
    2. 沒有做一定的項目總結及系統價值的提煉。
      在整個項目的跟進過程中,項目經理充當了一個傳話筒的角色,沒有總結,就沒有進步。沒有價值點提煉,就沒有存在感。最后導致我們的客戶,對我們產生的印象是:我們說怎么樣,你們就做成什么樣,我們不說,你們也不會站在你們專業的角度來替我們思考。

    基于這點,我覺得職責需要明確,所以就以公司的名義發了封正式的公告,任命其為項目經理,對項目負責,需要把控項目的迭代節奏。

    這樣也就解決了緊急需求的問題。

    協調各方資源,設計(包含了埋點設計)、開發、V1版本上線

    基于以上的問題,我就做了以下三點措施:

    1. 發文任命項目經理;
    2. 梳理出開發流程,為全員做相關培訓,項目經理主責落地跟進;
    3. 制作甘特圖,反映我司人員在項目上的具體投入,以了解項目的收入成本比。

    任職公告

    \

    \

    \

    關于埋點分析,來源于老板的訴求:大家看起來都很忙,但項目交付太慢,導致回款出問題

    上圖是我之前做產品時的項目管理經歷,就想把它借鑒過來,記錄下項目人員的投入分布圖。

    另外,給新入職產品/項目管理的童鞋一個建議:好好管理產品/項目的迭代歷程,便于自己總結回顧并針對性地提升自己!

    產品上線后

    產品上線以后,跟進用戶反饋、埋點數據分析,以便更好地進行下個迭代版本的設計,不斷靠近產品的目的。

    關于埋點數據的采集,我是讓每個人以日報的形式發給我,我再進行整理,歸納到項目管理表中,最后得到了以下分布圖:

    \

    慢慢的,我覺得不太對勁:我都沒有接到需求,但研發的同事一直在開發的路上。

    更加奇怪的是:研發一直在不停的開發,但項目驗收情況依舊不容樂觀。對于一個初創團隊來說,研發是一個比較重的開支,所以必須得搞清楚里面是什么原因,達到開源節流的目的。

    于是我就梳理了一下記錄,發現很多的工作都是在:修改、修復、優化,而且極其碎片化

    經過深入了解,原來都是在補之前的坑。比如之前給客戶做了一個功能,主功能能跑通,但忽略了其他的異常情況,客戶到現在才發現,就得進入緊急修復狀態。

    我也回訪了一下各部門的同事,得到以下信息:

    • 項目經理:工作量比較大,市場打單已經耗費了我很大精力了,又要跟進項目管理,有點兼顧不過來。有時候跟研發的同事在溝通需求,約好了時間節點,我去忙其他的了,研發的同事就忘了時間節點,導致任務的延期。
    • 研發同事:任務太多太雜了,而且總是有新的需求插隊,所以經常會先把那些催得緊的需求先做了,導致其他需求的延期。有些需求沒人催,久而久之也就忘了。
    • 技術部的同事:運維占了我們很大的一部分工作量,又沒有專職的測試,所以只能借著運維的間隙測一測功能是否能跑通。有的時候客戶催得緊,沒有辦法,來不及測試,只能直接上了。

    另外,我發現了研發同事有一個問題:沒有進行版本管理;

    個人覺得沒有版本管理,會有以下缺點:

    1. 增加同事間的溝通成本:研發更新了新版本,負責測試的技術同事沒注意,還在測老版本。
    2. 開發戰線拉得比較長,團隊成員心理負擔會較大。
    3. 在客戶面前沒有主動權。如果我們有做版本管理,我們可以說明版本上線的時間節點以及版本更新的內容,給我們自己喘息的時間,也顯得我們有計劃,比較專業。而不是客戶說什么我們就做什么,而且是馬上做。

    綜上所述,我總結下問題:

    1. 項目經理精力有限,無法做到項目的有效管理;
    2. 研發同事忙于補之前沒有項目管理留下來的坑,而且還有很多隱形的坑有待發掘;
    3. 研發工作比較碎片化,項目迭代沒有節奏,導致需求插隊等,造成有些任務的延期;
    4. 由于有些bug沒有辦法及時修復,造成運維工作壓力較大,沒有精力測試新上線的版本,從而形成惡性循環;
    5. 版本管理需要建立。

    V1版本上線后

    V1版本上線后,通過數據、用戶反饋發現問題,就得設計一個新版本,來解決V1版本出現的問題,我把它定義為V2。

    針對以上問題,我做出了以下措施:

    1. 協助項目經理組建自己的小團隊,由項目經理一個人主責變為項目經理主責、團隊成員擔責。

    之前是項目經理跟研發同事提需求,有時候無法具體到給哪位研發同事提需求,造成溝通成本的浪費及事后推責等問題。

    現在我就為每位項目經理都配了一名研發、技術同事,這樣從項目經理、研發、測試、運維整個落地閉環就形成了,形成了N個作戰小部隊。該作戰部隊,由項目經理掌舵,其他成員積極配合,如果該團隊負責的項目出現了問題,項目經理擔擔責,其他團隊成員擔小責。

    2. 為了保證需求的流轉記錄,推出項目管理工具:禪道。

    之前對于需求的流轉,項目經理疲于督促管理,口頭的流轉存在很大的扯皮隱患,需求的流轉記錄急需立字據。

    經過項目管理工具的調研,大家對禪道的應用比較感興趣,所以選擇了禪道作為項目的管理工具,并制定了以下管理流程:

    \

    這樣整個需求的流轉清晰了,大家有跡可循,避免信息的溝通失真。

    3. 版本的管理

    在我們的系統上線【版本日志】界面,并全員分享版本管理的好處。

    \

    V2版本上線,繼續跟進用戶反饋、數據分析

    經過V2版本的優化上線,基本解決了以下問題:

    1. 項目管理不再是一個人的責任,而是一個團隊的責任,營造了團隊的作戰氛圍;

    2. 需求流轉可視化,降低溝通成本,避免信息的傳遞失真;

    3. 增強版本管理意識,增加版本迭代日志,建立自己的迭代節奏。

    經過兩個版本的迭代管理,基本解決了項目的管理問題,只留下一個問題暫時沒有辦法解決:填之前項目的坑

    本來想著該問題只能隨著時間的推移慢慢得到根治。

    不過隨著時間的推移,我覺得問題,并沒有那么簡單:來自舊項目上的需求源源不斷,驗收卻遲遲沒有進展,項目款回收比較困難。

    經過了解,原來之前簽的項目,需求顆粒度是很粗的,后續進場開發也沒有進行詳細的需求調研、需求確定等,都是跟客戶口頭確定大概要做成什么樣子,再根據自己的判斷做出來,交付給客戶。

    客戶試用,有問題,提,我們改,一直如此的重復。客戶也不會輕易簽字,畢竟一簽字,再開發就需要另外付錢了。

    這就造成了之前提到的問題:需求不斷,開發很忙,項目交付卻很慢,而且需求極其碎片化,用戶一會需要加這個字段,一會兒需要新增判斷邏輯等等。

    更致命的是,我們的專業性會慢慢的被磨沒,直至客戶說什么,我們就做什么,客戶不說,我們也不會主動跟進。

    目的地都無法確定在哪里,漫無目的地走著效率是最低

    我就跟各方同事確定,最后在市場部的同事那里得到了本質信息:手頭沒有“菜單”,所以客戶要什么,我們就答應做什么,項目虧不虧我不管,我們的任務是把項目簽下來就ok。到時候做到什么樣再去走“商務”,也就是靠關系。

    這個讓我大為驚訝, 我覺得我們做生意是平等的,你給我錢,我為您提供服務,必須要把賬算清楚了,而不是靠走后門、刷老臉來驗收項目。

    結合用戶調研及需求反饋,設計V3版本

    于是我就著手開始制作“菜單”:

    1. 把系統功能框架羅列出來,標上對應的售價,市場打單用。
    2. 針對系統功能框架制作一份功能明細,后期進場調研時用。在這份功能明細上做增查改刪,再由甲方簽字,就可以進行后續的原型圖設計、需求確定投入開發了。

    這樣就確保我們有了驗收標準,有了依據有了目的地,更好地規劃我們的迭代節奏。

    版本迭代日志

    總結一下在整個項目規范流程中的版本迭代日志

    V1:

    • 施行項目經理制,責任到人;
    • 梳理出開發流程,為全員做相關培訓,項目經理主責落地跟進;
    • 制作甘特圖,反映我司人員在項目上的具體投入,以了解項目的收入成本比。

    V2:

    • 組建項目作戰小團隊,主責到人、團隊擔責;
    • 借助項目管理工具,做好需求的流轉記錄;
    • 制定版本規范制度,上線【版本日志】模塊。

    V3:

    • 上線系統功能清單及報價;
    • 上線系統功能明細,確保有驗收標準。

    以上三個版本,就是我覺得最有里程碑意義的迭代歷程,它讓項目從需求的來源、落地、驗收整個流轉得以規范。看似簡單,其中也走了不少彎路,希望可以給大家帶來借鑒意義。

<
上一篇: 一篇AI打麻將的論文,理科生眼中的麻將是這樣的 下一篇: 4個要點,緊抓用戶洞察玩轉裂變

聯系我們

一個新的需求,從這里開始。歡迎填寫表格或發送合作郵件至: [email protected] [email protected] 加微信: 13765801787

13765801787
在線留言
陕西快乐十分开奖预测 长城汽车股票 棒球比分网 幸运飞艇全天六码三期计划 新疆18选7历史数据 篮球比分直播捷报比分网 1zplay电竞比分 麻将外挂作弊器 百度知道 奇葩脱口秀app真的可以赚钱吗 海王捕鱼猫大爷攻略 竞彩足球比分 哪里可以玩时时彩 老虎机电子游艺平台 体彩11选5稳赚技巧 捕鱼来了弹头价格表 足球即时参数s2即时指数 雪缘园比分