許多公司的產(chǎn)品經(jīng)理都兼任了項目管理的工作，這就需要對需求排期和技術(shù)的時間表進(jìn)行把控。但不少同學(xué)并不是很了解技術(shù)，如何正確對工時進(jìn)行評估？這篇文章，我們看看作者分享的經(jīng)驗。

不同公司對產(chǎn)品經(jīng)理的職責(zé)定位不盡相同，產(chǎn)品經(jīng)理這個崗位本身職責(zé)范圍也比較寬泛，本文主要針對的是那些被認(rèn)為是產(chǎn)品OWNER的產(chǎn)品經(jīng)理們，簡單點說就是產(chǎn)品的第一負(fù)責(zé)人，就像是一個總統(tǒng)對于一個國家而言，而這個總統(tǒng)還只有背鍋的責(zé)任，沒有指揮造鍋的權(quán)力！

前些年曾有過產(chǎn)品經(jīng)理要不要懂技術(shù)的套路，很多人是偏向懂技術(shù)不是產(chǎn)品經(jīng)理的必備技能，只是加分項。可如果你是被定義為產(chǎn)品的第一負(fù)責(zé)人時，你不懂技術(shù)，往往在工作推進(jìn)中，會有諸多障礙，比如你的產(chǎn)品方案是否具備技術(shù)可行性、實現(xiàn)起來的復(fù)雜度又決定了經(jīng)濟(jì)可行性，在與研發(fā)伙伴進(jìn)行battle時，你是否能說服對方，甚至研發(fā)小伙伴會不會故意刁難你。今天我以曾經(jīng)產(chǎn)研團(tuán)隊leader的身份，告訴產(chǎn)品經(jīng)理們?nèi)绾尾鸾猱a(chǎn)品的研發(fā)工作，防止研發(fā)同學(xué)信口開河漫天要價式的工時預(yù)估。

開始具體內(nèi)容之前，說一個哲學(xué)性的問題，如果一個工作不知如何下手時，記得一定要做分解！就像我們初高中學(xué)習(xí)數(shù)學(xué)那樣，多元多次方程，向一元一次方程去簡化，然后各個破解。

一個項目的研發(fā)工時預(yù)估，一般分前端、后端兩塊工時，我們也分開拆解預(yù)估方法。

一、前端工時拆解

前端工作量的大小，最簡單的判斷方法就是頁面數(shù)量，一般頁面數(shù)量多的工程，前端需要的工時就會越多；當(dāng)然，越簡單的判斷方法，判斷誤差就會越大，這個簡單的方法有個前提，就是頁面實現(xiàn)復(fù)雜度相似的情況下才成立。所以接下來我們再拆解頁面復(fù)雜度怎么去判斷。

一個頁面前端的工作內(nèi)容可分三大塊：頁面元素制作和排版，效果實現(xiàn)、數(shù)據(jù)嵌套，這三個維度都是內(nèi)容越多越耗時間。

一）頁面元素：

就是指這個頁面的組成由多少區(qū)域塊，區(qū)域塊越多、縱橫交錯越多，復(fù)雜度就越高，但這個相對而言，工時還是比較容易估算的，畢竟就是排版，確定性還是比較高的。

二）效果實現(xiàn)：

最難的是效果實現(xiàn)這塊，它的模糊邊界最大，不同人給出的工時可能差個幾倍都是有的。效果實現(xiàn)指的是動畫效果，布局效果，自適應(yīng)效果等等，一般要基礎(chǔ)編程來實現(xiàn)，這也是前端工程師比較值錢的地方（現(xiàn)在純頁面制作的職位基本消失了，頁面制作是純使用標(biāo)記性語言，如html,而帶效果的頁面一般是要用編程語言完成的，如Javascript）。

這一塊的工時預(yù)估，主要看要實現(xiàn)的效果是否為常見的，也就是網(wǎng)上能找到開源實現(xiàn)的，如果是新效果，這個就別和研發(fā)去爭論工時了，能不能實現(xiàn)都會是個問題。如果是比較成熟的效果，比如說輪播圖、日歷、瀑布流排版等等，這些基本網(wǎng)上一搜一大把，他再給你要個1~2天的工時，你就可以懟他了。

三）數(shù)據(jù)嵌套：

是指頁面有動態(tài)數(shù)據(jù)，需要與服務(wù)端交互來讓頁面數(shù)據(jù)活起來，這個一般也比較耗時，需要與服務(wù)端進(jìn)行聯(lián)調(diào)；一般的實現(xiàn)方法就是前后端定義好接口，前端開發(fā)的時候會用假數(shù)據(jù)先實現(xiàn)頁面，等服務(wù)端開發(fā)好了，直接替換就行。這塊工作一般也比較確定，評估就按接口數(shù)量多少進(jìn)行預(yù)估就行。

二、服務(wù)端工時拆解

服務(wù)端與前端一樣，也可以進(jìn)行分類拆解，對應(yīng)前端的頁面數(shù)量，服務(wù)端就是接口數(shù)量，可以數(shù)一數(shù)工程需要的接口數(shù)。當(dāng)然，服務(wù)端的拆解相對前端要復(fù)雜一些，不同編程水平的服務(wù)端開發(fā)量是有較大差別的，好的架構(gòu)設(shè)計可以減少很多工作量，可維護(hù)性還高，這個不在本文討論范圍內(nèi)，這兒只說普通的應(yīng)用型項目的服務(wù)端。

對于單個接口的工作量，可以分解為數(shù)據(jù)控制、邏輯處理和數(shù)據(jù)存儲三塊。

一）數(shù)據(jù)控制：

主要是指數(shù)據(jù)接入、數(shù)據(jù)輸出，數(shù)據(jù)接入是指前端傳過來的數(shù)據(jù)，包含要存儲的數(shù)據(jù)、查詢的數(shù)據(jù)、上傳的文件等；數(shù)據(jù)輸出，主要是查詢結(jié)果輸出。

涉及文件上傳一般看是否為項目第一次做文件上傳，或者公司是否有共用的上傳服務(wù)，比如使用阿里云存儲服務(wù)等，如果是第一次使用，涉及存儲服務(wù)調(diào)試，時間要長一點，多給個一天時間；沒有特殊的處理，一個普通的查詢接口一般1個小時就差不多，尤其是一類接口放在一起寫，一天能寫完一批；帶數(shù)據(jù)上傳的接口，一般耗時要長一些。

二）邏輯處理：

這塊與前端頁面的效果實現(xiàn)一樣，跨度很大，有些邏輯需要跨表讀取數(shù)據(jù)并有先后順序，邏輯處理的整體規(guī)律，增加一個維度，難度就翻倍，工時也會相應(yīng)增倍。不過在邏輯處理這塊，產(chǎn)品經(jīng)理因為對整體很了解，是最容易參與并能給技術(shù)提供思路的。

一般情況而言，常規(guī)應(yīng)用都是有成熟的解決思路的，復(fù)雜度也是可以衡量的。比如，一條動態(tài)的評論，如果是直接按評論的時間進(jìn)行排序，這種邏輯處理基本為0，而如果是允許對評論進(jìn)行回復(fù)，這種就會復(fù)雜度翻倍，還會涉及到數(shù)據(jù)存儲表結(jié)構(gòu)的變動。

三）數(shù)據(jù)存儲：

分為請求數(shù)據(jù)的存儲和效果，緩存存儲和數(shù)據(jù)庫存儲。

請求存儲用到消息隊列的建立和消費，這塊看是否為第一次實現(xiàn)，第一次多給點時間，項目中已經(jīng)用過了，一般都已經(jīng)是封裝好的方法，幾行代碼就搞定了；緩存層也是類似的，封裝好的服務(wù)挺多的，搭建好了就是幾行代碼就可以實現(xiàn)了；數(shù)據(jù)庫存儲方面，涉及表的結(jié)構(gòu)設(shè)計，一般項目前期，表的關(guān)聯(lián)比較少時，比較簡單，越向后期越復(fù)雜；尤其需要多表聯(lián)動時，表設(shè)計也會復(fù)雜，如上面提及的對評論進(jìn)行回復(fù)，如果是才用雙表設(shè)計時，效果最好，復(fù)雜度相對所有評論按時間倒敘排列，要高出數(shù)倍。

三、總結(jié)一下

看到這不知道你是否有些失望，我并未給出具體一個頁面、一個接口或者一個項目，大概需要多少人天的工時，這兒不給這個數(shù)字，如果你仔細(xì)看上面的內(nèi)容，你可能也就能理解，因為范圍太寬泛，給的值也不能做參考。寫這一篇內(nèi)容，主要是為產(chǎn)品經(jīng)理在和研發(fā)進(jìn)行工期約定時，多一些討價還價的方法，千萬不要越俎代庖，拿自己的業(yè)余去挑戰(zhàn)別的飯碗！

上面的方法，是我有一次實在受不了研發(fā)團(tuán)隊給我的工期，我就拉上服務(wù)端的研發(fā)同學(xué)，把他評估的2天一個接口，現(xiàn)場進(jìn)行分解，接口的controller要多長時間，需要做那些邏輯處理，數(shù)據(jù)庫要建什么表，一一進(jìn)行拆解，最后工時壓縮了一半。但故事并未到此結(jié)束，一旦走到這一步，基本雙方的關(guān)系就很僵了，后面的配合就會很難。希望產(chǎn)品經(jīng)理們靈活并謹(jǐn)慎應(yīng)用，以理解和尊重的態(tài)度去探討，以幫忙和助力的目的去協(xié)商（不少研發(fā)同學(xué)、甚至是研發(fā)leader是不知道如何去預(yù)估工時的），讓他們知道你在這方面不是一竅不通的，不是隨意可以忽悠的就可以了！