在這篇文章中，本文作者介紹了自己的產(chǎn)品開發(fā)經(jīng)驗和使用的工具。他們的做法是以周為單位，不斷與利益攸關(guān)者進(jìn)行溝通，進(jìn)行一次次的“沖刺”（sprint）。當(dāng)然，我們也可以比較一下項目管理軟件公司Basecamp 的做法。

之前我們討論了定義產(chǎn)品的藝術(shù)，這是把產(chǎn)品推向市場之旅（或者說實現(xiàn)夢想）邁出的第一步。在你定義了MVP（最小可行產(chǎn)品）之后，你就得開發(fā)這個東西了，否則的話它不過就是被扔到四維空間的又一個想法而已。

我們的團(tuán)隊一共開發(fā)了數(shù)百款產(chǎn)品。以下就是我們的開發(fā)做法。

首先，你需要記住一個很簡單但非常重要的概念：產(chǎn)品會演變。不，我說的不是上市產(chǎn)品第一版和第二版之間的區(qū)別；我說的是你開始開發(fā)產(chǎn)品前所定義的東西與你想要發(fā)布的東西之間的區(qū)別。

我們就拿房子來舉例：

要造房子你首先得制圖，包括立面圖、平面圖以及水電圖等。既然房屋房間這些都是司空見慣的東西，所以準(zhǔn)確定義你想要什么應(yīng)該不難。我們往往會這么描述需求：

我去過Claire的家，我想要其中的一張餐桌，但是我想放到餐廳去。

很簡單對不對？都不需要測試。如果某張桌子可以放到廚房的話，大概放到餐廳也沒什么問題。但是如果你要創(chuàng)建的是此前從來沒見過的東西并且想把你見過的東西放到里面去改怎么辦？

我看了CNN的網(wǎng)站，我希望把其中一個好看的新聞消息框放到我賣水果的網(wǎng)站。

等一等……把一個新聞消息框放到賣水果的地方？

也許可以吧，但有些事情需要先確認(rèn)一下：

• 想要它是因為必要還是好看？
• 它跟設(shè)計和信息結(jié)構(gòu)適配嗎？
• 它可以給網(wǎng)站增加價值嗎？
• 這么做對于用戶來說有沒有意義？

這聽起來有雞蛋里面挑骨頭的味道，但是已有研究表明，用戶對你的網(wǎng)站產(chǎn)生第一印象只需要不到1秒鐘的時間，而且僅僅是從美學(xué)的角度來進(jìn)行評判。你需要讓他們享受到美感，而網(wǎng)站需要專注于完成目標(biāo)。幼稚的產(chǎn)品業(yè)主認(rèn)為自己可以讓他們的產(chǎn)品“好看”，然后用戶就會自動愛上它，卻無視了體驗之糟糕幾乎并不可能使用的事實。

為了匯總所有的產(chǎn)品需求，我們首先用Trello把主要信息收集起來：

這些被稱為是史詩（epics）?；旧蠈儆诜浅挿汉喍痰莫毩⒐δ苊枋觥Ｊ菍ξ覀冏詈螽a(chǎn)品所需的所有功能的高級視圖。史詩使得跟產(chǎn)品主管的對話更容易些，雙方的交流可以涉及更多的細(xì)節(jié)，比如：

• “你希望保存哪一個產(chǎn)品字段？”
• “用戶應(yīng)該怎樣編輯頁面外觀？”
• “搜索功能應(yīng)該查找哪些字段？”

……

只要我們做完了這些，我們就會通過客戶來加以驗證。并且開始編寫用戶故事，也就是每一個動作的特定步驟。許多用戶故事都由一個史詩組成。這一階段至關(guān)重要。用戶故事讓我們可以講述故事，這往往能讓我們捕捉到之前僅僅列舉高層功能（又叫史詩）時未曾想過的問題。最重要的是，它讓我們可以從用戶的角度審視產(chǎn)品。這幫助我們識別用戶可能遭遇的問題或者一開始未必明顯的邊緣情況。然后我們就可以跟產(chǎn)品主管和客戶一道評審用戶故事，確保我們已經(jīng)準(zhǔn)確理解了這一愿景。作為一個初創(chuàng)企業(yè)的孵化器，在產(chǎn)品和軟件方面我們是專家，但客戶帶來了他們的專業(yè)知識，他們知道哪些東西是產(chǎn)品上市需要的。

現(xiàn)在，我們對所有的需求都進(jìn)行過驗證了，我們添加了讓這事兒發(fā)生的必要之物：有用的庫，數(shù)據(jù)結(jié)構(gòu)，API接口，部署策略，服務(wù)器配置等等。等我們把所有任務(wù)都組織好了之后，再在預(yù)先確定好的時間內(nèi)（通常是每周一次迭代）把它們分拆到一次次的迭代里面——或者稱之為sprint。

下面這個是Kanban工作流軟件的Trello看板：

然而，估計時間永遠(yuǎn)都是困難的。這需要一定的科學(xué)與藝術(shù)的結(jié)合：

1）甲：啊啊啊??！我實在是太不擅長估算項目要花多久時間了。

2）乙：別慌——有個簡單的做法可以幫你算，就是做出最現(xiàn)實的估計，然后乘以2。甲：好的，可是——；

3）乙：接下來再乘以2，加5分鐘，然后再乘以2。甲：好的……

4）乙：30秒鐘過去了你除了把想象的數(shù)字翻番以外什么都沒做！你一點進(jìn)展都沒有也永遠(yuǎn)完不成！甲：啊啊啊啊！啊啊啊??！

每一位開發(fā)者都有自己估算開發(fā)時間的辦法。我們也嘗試不過不同的辦法，各自都取得過不同程度的成功，不過這些是后面要討論的事情了。

估算會變更MVP的功能，因為某個功能就會花費很大一部分比例的資源，所以需要小心處置。

在計算機(jī)科學(xué)里面，是很難解釋容易與幾乎不可能之間的區(qū)別的。

產(chǎn)品：用戶拍照的時候，app應(yīng)該可以知道自己是否在國家公園內(nèi)；

開發(fā)：當(dāng)然，簡單的GIS查找就行。給我?guī)仔r。

產(chǎn)品：然后還應(yīng)該可以知道拍的是不是鳥的照片。

開發(fā)：這我需要一支研究團(tuán)隊和5年的時間。

現(xiàn)在一切都已經(jīng)組織就緒了，我們需要開始實施了。

正如我之前提到過一樣，我們的sprint持續(xù)一周。在這段時間內(nèi)，我們打算開發(fā)包含在本次沖刺內(nèi)的所有功能，但有時候并不能如愿。為什么？其實答案很簡單：我們無法預(yù)測未來。任何一位軟件工程師都不能。我們唯一可與預(yù)測的就是未來的不可預(yù)測性。功能的實現(xiàn)也許會比預(yù)期要長，設(shè)計/內(nèi)容/項目經(jīng)理那邊也許給你制造了難題。有一次我們必須用網(wǎng)關(guān)來實現(xiàn)支付系統(tǒng)，但在實現(xiàn)的過程中我們發(fā)現(xiàn)他們改變了API的工作機(jī)制，卻沒有更新一些依賴。結(jié)果：我們需要中斷開發(fā)到一半的進(jìn)程，重新跟另一套支付系統(tǒng)進(jìn)行集成。

在創(chuàng)新領(lǐng)域做往往意味著在未知水域航行。挫折應(yīng)該是可想而知的。計劃就是用來打破的，很少會有項目是最后按照原來計劃和“規(guī)范”進(jìn)行的。歷史上變化來自各個方向，無論是內(nèi)部的還是外部的。對我們來說關(guān)鍵點是盡快調(diào)整自己來適應(yīng)這些情況，并且對這個過程保持透明。

然而這并不意味著永遠(yuǎn)都不應(yīng)該給遭遇的潛在挫折預(yù)留估算時間。當(dāng)我們的確遇到意料之外的問題時，我們會馬上跟團(tuán)隊溝通，試圖識別出對時間表的影像。調(diào)整時間表并不意味著我們就不能滿足最后期限要求，而是意味著我們要不斷維持這現(xiàn)實期望。

另一個變化來源很有可能就是客戶本身?？蛻?，尤其是牽涉其中的那些，回想看到自己的產(chǎn)品愿景是如何推進(jìn)的。這意味著他們會經(jīng)常提出不造原來項目范圍內(nèi)的變更請求或者新功能要求。說出“是的，我們可以做到這個”是很容易的，尤其是如果“那個”東西很小的話。但是小的東西很容易就會累積起來。

這絕不意味著我們就對所有的客戶請求說“是”了。我們給這個領(lǐng)域帶來的價值之一正是我們的經(jīng)驗和專業(yè)知識。如果我們的確推掉了某個請求，那一定是因為我們已經(jīng)研究過了，找到了它的一些例子，并且能夠給出專業(yè)的客觀理性的反對理由。當(dāng)客戶往往是出于個人喜好而提出變更請求時這一點尤其重要。

跟客戶的良好溝通可以讓這一過程有效。每一周我們都會打一次電話，解釋以下事情：

• 完成的有哪些事情，未完成的又有哪些
• 我們面臨的問題
• 下周預(yù)計要完成的事情
• 如果我們遇到任何障礙的話新的時間表如何

這樣的話我們就不需要給我們的時間表增加任何“緩沖”了。

這個每周進(jìn)行的系統(tǒng)對于驗證一些可視化功能、流等來說也是非常重要的。還記得我說過產(chǎn)品正在開發(fā)中的變更嗎？這往往就是變更發(fā)揮作用的地方了。一旦你看到自己想法成形時，你可能就會發(fā)現(xiàn)有更好的辦法去做某事，或者發(fā)現(xiàn)一開始看似很絕妙的點子其實并沒有那么好。這一路上進(jìn)行短的沖刺和驗證可以有巨大的好處，因為有了不斷的驗證和輸入，讓產(chǎn)品主管、客戶、工程師最后都會產(chǎn)品感到滿意。

我們在 Codelitt 就是這樣來處理產(chǎn)品開發(fā)的。當(dāng)然，要處理的還有很多東西，比如QA流程，與客戶驗證，把產(chǎn)品發(fā)給產(chǎn)品部門等，將來我們還會在新的文章中討論這些東西。

原文作者：Kaio Magalhaes

原文地址：www.codelitt.com

譯者：boxi

譯文地址：http://36kr.com/p/5058701.html