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

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

我們的團隊一共開發了數百款產品。以下就是我們的開發做法。

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

我們就拿房子來舉例：

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

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

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

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

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

也許可以吧，但有些事情需要先確認一下：

• 想要它是因為必要還是好看？
• 它跟設計和信息結構適配嗎？
• 它可以給網站增加價值嗎？
• 這么做對于用戶來說有沒有意義？

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

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

這些被稱為是史詩（epics）?；旧蠈儆诜浅挿汉喍痰莫毩⒐δ苊枋?。是對我們最后產品所需的所有功能的高級視圖。史詩使得跟產品主管的對話更容易些，雙方的交流可以涉及更多的細節，比如：

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

……

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

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

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

然而，估計時間永遠都是困難的。這需要一定的科學與藝術的結合：

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

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

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

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

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

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

在計算機科學里面，是很難解釋容易與幾乎不可能之間的區別的。

產品：用戶拍照的時候，app應該可以知道自己是否在國家公園內；

開發：當然，簡單的GIS查找就行。給我幾小時。

產品：然后還應該可以知道拍的是不是鳥的照片。

開發：這我需要一支研究團隊和5年的時間。

現在一切都已經組織就緒了，我們需要開始實施了。

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

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

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

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

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

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

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

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

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

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

原文作者：Kaio Magalhaes

原文地址：www.codelitt.com

譯者：boxi

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