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

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

不同公司對產品經理的職責定位不盡相同，產品經理這個崗位本身職責范圍也比較寬泛，本文主要針對的是那些被認為是產品OWNER的產品經理們，簡單點說就是產品的第一負責人，就像是一個總統對于一個國家而言，而這個總統還只有背鍋的責任，沒有指揮造鍋的權力！

前些年曾有過產品經理要不要懂技術的套路，很多人是偏向懂技術不是產品經理的必備技能，只是加分項?？扇绻闶潜欢x為產品的第一負責人時，你不懂技術，往往在工作推進中，會有諸多障礙，比如你的產品方案是否具備技術可行性、實現起來的復雜度又決定了經濟可行性，在與研發伙伴進行battle時，你是否能說服對方，甚至研發小伙伴會不會故意刁難你。今天我以曾經產研團隊leader的身份，告訴產品經理們如何拆解產品的研發工作，防止研發同學信口開河漫天要價式的工時預估。

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

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

一、前端工時拆解

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

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

一）頁面元素：

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

二）效果實現：

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

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

三）數據嵌套：

是指頁面有動態數據，需要與服務端交互來讓頁面數據活起來，這個一般也比較耗時，需要與服務端進行聯調；一般的實現方法就是前后端定義好接口，前端開發的時候會用假數據先實現頁面，等服務端開發好了，直接替換就行。這塊工作一般也比較確定，評估就按接口數量多少進行預估就行。

二、服務端工時拆解

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

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

一）數據控制：

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

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

二）邏輯處理：

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

一般情況而言，常規應用都是有成熟的解決思路的，復雜度也是可以衡量的。比如，一條動態的評論，如果是直接按評論的時間進行排序，這種邏輯處理基本為0，而如果是允許對評論進行回復，這種就會復雜度翻倍，還會涉及到數據存儲表結構的變動。

三）數據存儲：

分為請求數據的存儲和效果，緩存存儲和數據庫存儲。

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

三、總結一下

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

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