中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者根據(jù)自己的創(chuàng)業(yè)經(jīng)歷，分享了項目管理以及產(chǎn)品版本迭代的相關(guān)經(jīng)驗。

18年3月份，接到一位創(chuàng)業(yè)兄弟的邀請，加入團(tuán)隊負(fù)責(zé)項目管理流程的規(guī)范，他表示：

現(xiàn)有項目的開發(fā)流程太亂，項目交付太慢。

剛開始接到這個需求，我的內(nèi)心是很虛的，只有一年工作經(jīng)驗的PM Dog，哪有能力搞這么高大上的東西。

雖然顧慮重重，但想體驗創(chuàng)業(yè)快感的我，還是硬著頭皮上了，畢竟，萬一失敗了，虧的又不是我的錢……哈哈（奸詐臉）！

由于該公司扎根的垂直領(lǐng)域圈子太小，為了隱私起見，下文對該公司簡稱為：A公司。

背景

A公司是在某個垂直領(lǐng)域做專業(yè)的解決方案供應(yīng)商，目標(biāo)客戶群體是大集團(tuán)企業(yè)，項目周期一般是1年左右。

需求調(diào)研（用戶訪談)

接手這個團(tuán)隊的時候，團(tuán)隊有20來號兄弟，其中市場部主要負(fù)責(zé)項目的同事有三名，大概了解了團(tuán)隊架構(gòu)之后，我就詢問市場部同事當(dāng)前的項目管理流程。

他們是這么說的：

跟客戶拿需求過來，如果自己無法評估技術(shù)的可實現(xiàn)性，就拿回來給研發(fā)，實現(xiàn)性沒問題，就做……

然后我又去問了研發(fā)，研發(fā)的兄弟們是這么說的：

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

最后是技術(shù)部的兄弟們，他們是這么說的：

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

通過一輪的訪談下來，需求的流向看似很健康，由：市場->研發(fā)->技術(shù)->市場，其實幸虧兄弟們關(guān)系鐵，不然早就拔刀相見了。

需求分析

第一、開發(fā)流程問題：沒有對客戶的需求進(jìn)行“反饋式確定”，由開發(fā)人員直接做邏輯設(shè)計兼開發(fā)工作。

比如客戶說，我要做庫存管理。這一句話需求，有可能出現(xiàn)什么情況呢？

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

1. 增：有新品種貨物進(jìn)庫，新增該品種庫存；
2. 查：品種太多，我加個查詢框，便于快速找到該品種，查看其庫存；
3. 改：庫存數(shù)量有誤，需要修改；
4. 刪：該品種不做了，刪除掉避免產(chǎn)生信息垃圾。

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

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

更多的可能有：臺賬是否具有排序功能、臺賬是否需要庫存預(yù)警、庫存預(yù)警閾值是否可自定義設(shè)置等等。

很多細(xì)節(jié)性的功能就這么忽略了。

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

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

正確的做法是：

新增原型圖評審環(huán)節(jié)：

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

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

這樣做的好處是：

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

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

第二、項目迭代節(jié)奏的問題。

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

在這個背景下形成的項目經(jīng)理，有以下特點：

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

基于這點，我覺得職責(zé)需要明確，所以就以公司的名義發(fā)了封正式的公告，任命其為項目經(jīng)理，對項目負(fù)責(zé)，需要把控項目的迭代節(jié)奏。

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

協(xié)調(diào)各方資源，設(shè)計（包含了埋點設(shè)計）、開發(fā)、V1版本上線

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

1. 發(fā)文任命項目經(jīng)理；
2. 梳理出開發(fā)流程，為全員做相關(guān)培訓(xùn)，項目經(jīng)理主責(zé)落地跟進(jìn)；
3. 制作甘特圖，反映我司人員在項目上的具體投入，以了解項目的收入成本比。

關(guān)于埋點分析，來源于老板的訴求：大家看起來都很忙，但項目交付太慢，導(dǎo)致回款出問題；

上圖是我之前做產(chǎn)品時的項目管理經(jīng)歷，就想把它借鑒過來，記錄下項目人員的投入分布圖。

另外，給新入職產(chǎn)品/項目管理的童鞋一個建議：好好管理產(chǎn)品/項目的迭代歷程，便于自己總結(jié)回顧并針對性地提升自己！

產(chǎn)品上線后

產(chǎn)品上線以后，跟進(jìn)用戶反饋、埋點數(shù)據(jù)分析，以便更好地進(jìn)行下個迭代版本的設(shè)計，不斷靠近產(chǎn)品的目的。

關(guān)于埋點數(shù)據(jù)的采集，我是讓每個人以日報的形式發(fā)給我，我再進(jìn)行整理，歸納到項目管理表中，最后得到了以下分布圖：

慢慢的，我覺得不太對勁：我都沒有接到需求，但研發(fā)的同事一直在開發(fā)的路上。

更加奇怪的是：研發(fā)一直在不停的開發(fā)，但項目驗收情況依舊不容樂觀。對于一個初創(chuàng)團(tuán)隊來說，研發(fā)是一個比較重的開支，所以必須得搞清楚里面是什么原因，達(dá)到開源節(jié)流的目的。

于是我就梳理了一下記錄，發(fā)現(xiàn)很多的工作都是在：修改、修復(fù)、優(yōu)化，而且極其碎片化。

經(jīng)過深入了解，原來都是在補(bǔ)之前的坑。比如之前給客戶做了一個功能，主功能能跑通，但忽略了其他的異常情況，客戶到現(xiàn)在才發(fā)現(xiàn)，就得進(jìn)入緊急修復(fù)狀態(tài)。

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

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

另外，我發(fā)現(xiàn)了研發(fā)同事有一個問題：沒有進(jìn)行版本管理；

個人覺得沒有版本管理，會有以下缺點：

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

綜上所述，我總結(jié)下問題：

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

V1版本上線后

V1版本上線后，通過數(shù)據(jù)、用戶反饋發(fā)現(xiàn)問題，就得設(shè)計一個新版本，來解決V1版本出現(xiàn)的問題，我把它定義為V2。

針對以上問題，我做出了以下措施：

1. 協(xié)助項目經(jīng)理組建自己的小團(tuán)隊，由項目經(jīng)理一個人主責(zé)變?yōu)轫椖拷?jīng)理主責(zé)、團(tuán)隊成員擔(dān)責(zé)。

之前是項目經(jīng)理跟研發(fā)同事提需求，有時候無法具體到給哪位研發(fā)同事提需求，造成溝通成本的浪費及事后推責(zé)等問題。

現(xiàn)在我就為每位項目經(jīng)理都配了一名研發(fā)、技術(shù)同事，這樣從項目經(jīng)理、研發(fā)、測試、運維整個落地閉環(huán)就形成了，形成了N個作戰(zhàn)小部隊。該作戰(zhàn)部隊，由項目經(jīng)理掌舵，其他成員積極配合，如果該團(tuán)隊負(fù)責(zé)的項目出現(xiàn)了問題，項目經(jīng)理擔(dān)擔(dān)責(zé)，其他團(tuán)隊成員擔(dān)小責(zé)。

2. 為了保證需求的流轉(zhuǎn)記錄，推出項目管理工具：禪道。

之前對于需求的流轉(zhuǎn)，項目經(jīng)理疲于督促管理，口頭的流轉(zhuǎn)存在很大的扯皮隱患，需求的流轉(zhuǎn)記錄急需立字據(jù)。

經(jīng)過項目管理工具的調(diào)研，大家對禪道的應(yīng)用比較感興趣，所以選擇了禪道作為項目的管理工具，并制定了以下管理流程：

這樣整個需求的流轉(zhuǎn)清晰了，大家有跡可循，避免信息的溝通失真。

3. 版本的管理

在我們的系統(tǒng)上線【版本日志】界面，并全員分享版本管理的好處。

V2版本上線，繼續(xù)跟進(jìn)用戶反饋、數(shù)據(jù)分析

經(jīng)過V2版本的優(yōu)化上線，基本解決了以下問題：

1. 項目管理不再是一個人的責(zé)任，而是一個團(tuán)隊的責(zé)任，營造了團(tuán)隊的作戰(zhàn)氛圍；

2. 需求流轉(zhuǎn)可視化，降低溝通成本，避免信息的傳遞失真；

3. 增強(qiáng)版本管理意識，增加版本迭代日志，建立自己的迭代節(jié)奏。

經(jīng)過兩個版本的迭代管理，基本解決了項目的管理問題，只留下一個問題暫時沒有辦法解決：填之前項目的坑。

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

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

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

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

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

更致命的是，我們的專業(yè)性會慢慢的被磨沒，直至客戶說什么，我們就做什么，客戶不說，我們也不會主動跟進(jìn)。

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

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

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

結(jié)合用戶調(diào)研及需求反饋，設(shè)計V3版本

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

1. 把系統(tǒng)功能框架羅列出來，標(biāo)上對應(yīng)的售價，市場打單用。
2. 針對系統(tǒng)功能框架制作一份功能明細(xì)，后期進(jìn)場調(diào)研時用。在這份功能明細(xì)上做增查改刪，再由甲方簽字，就可以進(jìn)行后續(xù)的原型圖設(shè)計、需求確定投入開發(fā)了。

這樣就確保我們有了驗收標(biāo)準(zhǔn)，有了依據(jù)有了目的地，更好地規(guī)劃我們的迭代節(jié)奏。

版本迭代日志

總結(jié)一下在整個項目規(guī)范流程中的版本迭代日志

V1：

• 施行項目經(jīng)理制，責(zé)任到人；
• 梳理出開發(fā)流程，為全員做相關(guān)培訓(xùn)，項目經(jīng)理主責(zé)落地跟進(jìn)；
• 制作甘特圖，反映我司人員在項目上的具體投入，以了解項目的收入成本比。

V2：

• 組建項目作戰(zhàn)小團(tuán)隊，主責(zé)到人、團(tuán)隊擔(dān)責(zé)；
• 借助項目管理工具，做好需求的流轉(zhuǎn)記錄；
• 制定版本規(guī)范制度，上線【版本日志】模塊。

V3：

• 上線系統(tǒng)功能清單及報價；
• 上線系統(tǒng)功能明細(xì)，確保有驗收標(biāo)準(zhǔn)。

以上三個版本，就是我覺得最有里程碑意義的迭代歷程，它讓項目從需求的來源、落地、驗收整個流轉(zhuǎn)得以規(guī)范?？此坪唵?，其中也走了不少彎路，希望可以給大家?guī)斫梃b意義。

本文由 @銘創(chuàng)優(yōu)品 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議