編者按：本文作者Berwin，W3C性能工作組成員，360導(dǎo)航資深前端工程師?！渡钊霚\出Vue.js》作者。

今天想談一談關(guān)于“需求分析”和“開(kāi)發(fā)時(shí)間”這兩個(gè)話(huà)題，工作這么些年還是頭一次公然討論這個(gè)話(huà)題，今天聊一下我對(duì)這兩個(gè)話(huà)題的淺見(jiàn)。

需求分析

早些年在我剛開(kāi)始工作時(shí)，我認(rèn)為“需求分析”就是聽(tīng)一聽(tīng)產(chǎn)品經(jīng)理提的需求，評(píng)估下開(kāi)發(fā)可行性和難度，把實(shí)現(xiàn)不了的需求砍掉。

這么多年過(guò)去了，我發(fā)現(xiàn)這是最Low Level的需求分析。

原因在于當(dāng)時(shí)的我完全不知道產(chǎn)品經(jīng)理為什么要提出這個(gè)需求，我甚至壓根沒(méi)有關(guān)注過(guò)這個(gè)問(wèn)題，當(dāng)時(shí)的我只關(guān)注這個(gè)需求如何實(shí)現(xiàn)，難度如何。所以我很難理解產(chǎn)品經(jīng)理，甚至經(jīng)常站在技術(shù)的角度認(rèn)為產(chǎn)品經(jīng)理提出的這個(gè)需求好傻啊，他是智障嗎？

但其實(shí)產(chǎn)品經(jīng)理和工程師不應(yīng)該是敵對(duì)關(guān)系，應(yīng)該是“搭檔”，現(xiàn)在我和我們的產(chǎn)品經(jīng)理一直是搭檔關(guān)系，我們的關(guān)系很融洽，因?yàn)槲覀兊哪繕?biāo)是一致的：讓我們的產(chǎn)品，滿(mǎn)足用戶(hù)的需求。

但有時(shí)候產(chǎn)品經(jīng)理提出的需求可能不是很正確，這個(gè)時(shí)候需要工程師進(jìn)行輔助。這里面有很多原因：

產(chǎn)品經(jīng)理可能對(duì)技術(shù)的邊界不是很了解，所以無(wú)法充分利用技術(shù)解決用戶(hù)需求

對(duì)用戶(hù)原始需求的理解是很難傳遞的

產(chǎn)品經(jīng)理對(duì)用戶(hù)需求的理解有誤

其他

我們先討論第一點(diǎn)：“產(chǎn)品經(jīng)理可能對(duì)技術(shù)的邊界不是很了解”。

產(chǎn)品經(jīng)理可能對(duì)技術(shù)的邊界不是很了解

優(yōu)秀的產(chǎn)品經(jīng)理是需要有技術(shù)廣度的，他不一定要深入了解技術(shù)的原理，但一定要理解技術(shù)的邊界。某個(gè)技術(shù)能做什么，不能做什么，最近是不是又有新技術(shù)了，和我的產(chǎn)品有關(guān)系嗎？

但通常大多數(shù)產(chǎn)品經(jīng)理都比較缺乏技術(shù)廣度，所以這個(gè)時(shí)候需要工程師去補(bǔ)位。

但工程師去補(bǔ)位有一個(gè)前提，那就是工程師真的理解產(chǎn)品經(jīng)理，理解他在想什么。這就要談到第二點(diǎn)：對(duì)用戶(hù)原始需求的理解很難傳遞。

對(duì)用戶(hù)原始需求的理解很難傳遞

很多時(shí)候，產(chǎn)品只是發(fā)了個(gè)產(chǎn)品文檔過(guò)來(lái)，然后就拉著技術(shù)做“需求評(píng)審”，但其實(shí)這份需求文檔，是產(chǎn)品經(jīng)理對(duì)用戶(hù)需求理解的二次加工。工程師在這份需求文檔里是很難看清用戶(hù)的原始需求的。

比如：用戶(hù)需要一個(gè)消息提醒。產(chǎn)品經(jīng)理可能是不知道有Web Push Notifications這項(xiàng)技術(shù)，也可能是對(duì)用戶(hù)需求理解有誤，總之最終提出來(lái)的需求是在網(wǎng)頁(yè)的最頂部添加一個(gè)消息通知功能。

所以工程師應(yīng)該主動(dòng)去了解用戶(hù)的原始需求是什么，當(dāng)工程師能理解用戶(hù)的原始需求是什么時(shí)，也就能理解產(chǎn)品經(jīng)理為什么提這個(gè)需求了，就可以在這個(gè)時(shí)候成為產(chǎn)品經(jīng)理的搭檔，提醒他，有一項(xiàng)技術(shù)叫做Web Push Notifications，它的能力邊界是什么。

一個(gè)好的需求，應(yīng)該是技術(shù)深度參與，而不是產(chǎn)品經(jīng)理單方面輸出一個(gè)產(chǎn)品需求文檔，因?yàn)楫a(chǎn)品經(jīng)理有時(shí)候也會(huì)犯錯(cuò)，這就是我們要談?wù)摰牡谌c(diǎn)：產(chǎn)品經(jīng)理對(duì)用戶(hù)需求的理解有誤。

產(chǎn)品經(jīng)理對(duì)用戶(hù)需求的理解有誤

有時(shí)候用戶(hù)反饋需求，或者產(chǎn)品經(jīng)理在推測(cè)用戶(hù)想要什么的時(shí)候，往往得到的答案是不正確的。因?yàn)橛袝r(shí)候用戶(hù)自己也不知道他需要什么。有一句話(huà)非常有名：你如果問(wèn)用戶(hù)想要什么，他的回答是“一匹更快的馬”，而不是汽車(chē)。

所以工程師要理解用戶(hù)的原始需求，并且有自己的看法，這樣不光可以給產(chǎn)品經(jīng)理提出建設(shè)性意見(jiàn)，并且還可以對(duì)技術(shù)方案進(jìn)行“預(yù)判”，如何設(shè)計(jì)項(xiàng)目的架構(gòu)？最重要的就是要對(duì)產(chǎn)品未來(lái)的發(fā)展方向進(jìn)行“預(yù)判”，一方面要對(duì)未來(lái)的改動(dòng) “做足準(zhǔn)備”，另一方面也要避免 “過(guò)度設(shè)計(jì)”。

小結(jié)

總之需求分析不是簡(jiǎn)單的聽(tīng)一聽(tīng)產(chǎn)品經(jīng)理提的需求，評(píng)估下開(kāi)發(fā)可行性和難度，把實(shí)現(xiàn)不了的需求砍掉。而是去理解用戶(hù)的原始需求，和產(chǎn)品經(jīng)理成為“搭檔”，在產(chǎn)品經(jīng)理因?yàn)槿狈夹g(shù)廣度或其他原因?qū)е绿岢鰤男枨髸r(shí)，給出提醒并提供建設(shè)性意見(jiàn)。

所以你會(huì)發(fā)現(xiàn)我的標(biāo)題叫做“需求分析”而不是“需求評(píng)審”，因?yàn)椤靶枨笤u(píng)審”的潛臺(tái)詞是：我不知道用戶(hù)需要什么，我只知道如果產(chǎn)品提出了很傻的需求，我就把這個(gè)需求砍掉。

討論完需求分析，接下來(lái)討論下“開(kāi)發(fā)時(shí)間評(píng)估”。

開(kāi)發(fā)時(shí)間評(píng)估

工作這么些年，直到今天我依然無(wú)法“準(zhǔn)確”評(píng)估開(kāi)發(fā)時(shí)間。

我認(rèn)為是我的問(wèn)題，是我沒(méi)有掌握某些評(píng)估開(kāi)發(fā)時(shí)間的方法論，為此我找了組內(nèi)的技術(shù)專(zhuān)家和我的Leader請(qǐng)教他們是如何評(píng)估開(kāi)發(fā)時(shí)間的。技術(shù)專(zhuān)家告訴我，可以用自己估算出的時(shí)間，乘以一個(gè)系數(shù)。我的Leader告訴我，可以根據(jù)以往的經(jīng)驗(yàn)，來(lái)評(píng)估某個(gè)需求需要開(kāi)發(fā)多少個(gè)“工作日”。

比如評(píng)估了5個(gè)工作日，但實(shí)際開(kāi)發(fā)可能需要一個(gè)10個(gè)工作日。因?yàn)槊刻觳灰欢ㄒ徽於荚陂_(kāi)發(fā)，還會(huì)去開(kāi)會(huì)和處理其他雜事。

我評(píng)估的不是自然日什么時(shí)間完成，而是這個(gè)需求要多少個(gè)“有效工作日”可以完成。

評(píng)估好了有效工作日數(shù)，就可以根據(jù)工作日看需求的類(lèi)型，有些需求是絕對(duì)不允許延期的，比如618，雙十一這種需求都是不可能延期的，對(duì)于不可以延期的需求，如果評(píng)估出的有效工作日已經(jīng)超出Deadline，那么這時(shí)候需要讓產(chǎn)品經(jīng)理把這個(gè)需求需要完成的所有功能的“重要程度”列出來(lái)，優(yōu)先開(kāi)發(fā)最重要的功能。如果評(píng)估后發(fā)現(xiàn)連最重要的功能都無(wú)法在Deadline之前完成，那么解決方案有兩種，一種是尋求更多的資源，另一種是這個(gè)需求就整個(gè)砍掉。

聽(tīng)完之后，我學(xué)到了很多知識(shí)，“除了預(yù)估開(kāi)發(fā)時(shí)間，別的我都學(xué)會(huì)了”。無(wú)論是“用評(píng)估的時(shí)間乘以一個(gè)系數(shù)”還是“根據(jù)經(jīng)驗(yàn)評(píng)估有效工作日”，都沒(méi)有正面回答如何準(zhǔn)確預(yù)估開(kāi)發(fā)時(shí)間的問(wèn)題。

后來(lái)我又看了一些書(shū)，得出了一個(gè)結(jié)論：沒(méi)有人可以準(zhǔn)確估算出開(kāi)發(fā)時(shí)間，準(zhǔn)確估算開(kāi)發(fā)時(shí)間是不可能的。

即使是特別簡(jiǎn)單的需求，也是無(wú)法準(zhǔn)確評(píng)估開(kāi)發(fā)時(shí)間的，例如：我可以準(zhǔn)確的評(píng)估出我用一個(gè)工作日可以封裝一個(gè)JSONP，但我無(wú)法準(zhǔn)確評(píng)估幾個(gè)小時(shí)能完成。

這不是抬杠，這是一個(gè)道理，我雖然不知道我?guī)讉€(gè)小時(shí)能完成，但是我知道我一天可以完成，我雖然不知道幾天可以完成，但我知道一個(gè)星期肯定可以完成。

既然結(jié)論是評(píng)估的時(shí)間根本不準(zhǔn)，那就不評(píng)估了么？和產(chǎn)品經(jīng)理說(shuō)我不知道需要多久，開(kāi)發(fā)完了我再找你？肯定不行，產(chǎn)品經(jīng)理一定會(huì)要一個(gè)開(kāi)發(fā)時(shí)間，必須得給一個(gè)，哪怕不準(zhǔn)。

既然開(kāi)發(fā)時(shí)間是無(wú)法準(zhǔn)確評(píng)估的，而我們又必須給一個(gè)開(kāi)發(fā)時(shí)間，那么我們要做的事就不再是如何評(píng)估開(kāi)發(fā)時(shí)間了，而是變成了“風(fēng)險(xiǎn)管理”。

風(fēng)險(xiǎn)管理

風(fēng)險(xiǎn)管理最常用的方法叫：留點(diǎn)余地。

這種方法的思想是，我知道自己評(píng)估的工作日不準(zhǔn)，那么為了應(yīng)對(duì)各種意料之外的事發(fā)生，我需要安排一些額外的時(shí)間來(lái)以備不測(cè)。

可能遇到的風(fēng)險(xiǎn)：

這個(gè)功能比我預(yù)期的要難，需要更多的開(kāi)發(fā)時(shí)間

團(tuán)隊(duì)成員有急事請(qǐng)了兩天假

其他

用自己評(píng)估的工作日乘以一個(gè)系數(shù)，就屬于這種類(lèi)型。有一篇文章《我在淘寶做前端的這三年——第二年》里也介紹了一種方法也屬于這種類(lèi)型：

• 需求非常明確而且經(jīng)常這樣做：評(píng)估的工作日*1.5

• 需求不清晰，有可能變，但代碼和技術(shù)方案熟悉：評(píng)估的工作日*2

• 需求不清晰，代碼和技術(shù)方案也不熟悉需要探索：評(píng)估的時(shí)間*2.5

越不確定的事，未知的東西越多，風(fēng)險(xiǎn)越高，所以需要留有更多的時(shí)間以備不測(cè)。

我一般會(huì)問(wèn)產(chǎn)品經(jīng)理一個(gè)問(wèn)題，我會(huì)和他說(shuō)：你想要保守點(diǎn)的時(shí)間還是正常點(diǎn)的時(shí)間？保守點(diǎn)的是我用系數(shù)乘后的結(jié)果，正常點(diǎn)的是我憑經(jīng)驗(yàn)和感覺(jué)認(rèn)為多久能完成。

然后我會(huì)和他說(shuō)：正常的時(shí)間，不一定準(zhǔn)，我不能保證這個(gè)時(shí)間一定會(huì)完成，我只能盡力去完成，但保守的時(shí)間一定會(huì)完成。

通常最終商量后的結(jié)果就是把時(shí)間定到保守的時(shí)間上，然后開(kāi)發(fā)盡量提前完成，但是最晚也不會(huì)超過(guò)保守的時(shí)間。

如果連不準(zhǔn)確的開(kāi)發(fā)時(shí)間都評(píng)估不出來(lái)，上面的方案不就失效了，那怎么辦？

還有一個(gè)非常簡(jiǎn)單粗暴的方法：可以把需求難度分為三個(gè)等級(jí)：簡(jiǎn)單、中等、困難。

• 簡(jiǎn)單需求：需要2~3個(gè)有效工作日

• 中等需求：需要2~3周

• 困難需求：需要2~3個(gè)月

對(duì)于簡(jiǎn)單和中等難度的需求，在需求有DeadLine并且評(píng)估后發(fā)現(xiàn)最重要的功能也無(wú)法在Deadline之前完成，那么可以靠“堆人”來(lái)?yè)Q取時(shí)間，但只適用于簡(jiǎn)單和中等難度的需求。對(duì)于復(fù)雜的需求，人員的數(shù)量根本沒(méi)用，唯一可以讓開(kāi)發(fā)時(shí)間提前兩個(gè)月以上，并且技術(shù)方案和質(zhì)量都有保障的方案是：需要一個(gè)該領(lǐng)域的專(zhuān)家。

小結(jié)

經(jīng)過(guò)我自己的經(jīng)驗(yàn)和我請(qǐng)教的各種專(zhuān)家來(lái)看，結(jié)論是：開(kāi)發(fā)時(shí)間的評(píng)估完全靠感覺(jué)，感覺(jué)是不靠譜的，所以最重要的事是做風(fēng)險(xiǎn)管理。

關(guān)于奇舞周刊

《奇舞周刊》是360公司專(zhuān)業(yè)前端團(tuán)隊(duì)「奇舞團(tuán)」運(yùn)營(yíng)的前端技術(shù)社區(qū)。關(guān)注公眾號(hào)后，直接發(fā)送鏈接到后臺(tái)即可給我們投稿。

總結(jié)

以上是生活随笔為你收集整理的需求分析与开发时间评估的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。