【背景】
公司銷售談了一個重要的項目，與我們正在研發的一個產品關系比較大，可惜前期由于種種原因，耽擱了很長時間，等到我們研發部門知道消息的時候，已經很晚了。9月中旬啟動，11月下旬要求上線，按常理，這么短期的項目是沒法做的，不過出于完善我們產品的考慮，我們還是咬著牙硬著頭皮上了。由于產品還不成熟，交付工作只能我們自己上。
【現狀】
按照計劃，下周就要開發完成，進入測試階段，可是我們還沒進行過一次完整的提交，客戶比較著急。而我們是原本是出于想把事情做好的想法，不希望把尚不完善的東西提交出去，導致進度看上去延后了。現在的情況是，客戶產生了一些懷疑，而我們很被動。
目前我們擬定的方案是，趕緊先把目前做好的版本做一次提交，讓客戶看到現階段的成果，再逐步修改完善。
【反思】
話說有些事情，不自己親手做，永遠都體會不到。之前我們一直是在做產品的項目，習慣了先思考設計->代碼->改善設計->代碼的方式，當我們把這種習慣帶到交付項目里面后，發現兩個項目的做事方式完全不一樣，得出幾點結論，供大家參考：
1、項目的首要目標是做的“沒錯”，項目的終極目標是“上線”：
這一點乃所有結論的最高前提。
在跟客戶直接打交道的交付項目中，一定要時刻牢記，你做的事情，可以做的不好，但是一定不能“做錯”。你可以做的不夠好，但是一定要能“上線”。實際上，做的不好有多方面的原因，比如需求糟糕，時間緊急，第三方環境準備不充分等等，但是一定不要做的“有錯”。就目前這個項目而言，由于項目時間非常緊急，客戶的需求本身很不完善，交互設計不合理，風險點考慮不完善，需求中存在自相矛盾的地方。在這種情況下，我們犯的最大的錯誤是，沒有按時提交版本。對需求進行細致分析沒錯，希望做一個好的東西出來沒錯，但是沒有做到最基本的按時提交，就是做錯了。先做好基本需求，再說錦上添花的事情。
其實現在看來，正確的做法應該是，按照客戶給出需求先實現一個版本并提交，再去跟客戶分析討論如何完善需求。的確，這么做的話，可以想到的是，第一個版本的東西一定非常不好用，問題百出，會被罵的體無完膚，但是，這樣做，達到了“做的沒錯”的目標。我們是按照客戶給的需求做的，我們并沒有做錯，按照需求來做，不會延期。不好用是因為需求不完善。我們出了一個版本之后，因為要完善需求帶來的時間成本和工作量，是由我們和客戶共同承擔。而成本共同承擔的結果很有可能有意外的驚喜，比如需求被拆分，部分放到二期實現。而現在我們試圖先做“完善需求”，再做開發，帶來的額外時間成本和工作量都由我們自己承擔了。
同樣的問題還有加班。加班是大家都不喜歡的，但是在這種情況下，加班是一種態度。不管怎么樣，我辛苦的加班，不會是做錯。
項目的終極目標是上線，如果不能上線，其他一些都是浮云，做的東西再完善，如果不能按時上線，就是屬于交付失敗。此乃終極目標。不完善的東西，可以留到下一期再做。什么？跟客戶說延期是因為我們需求給的不完善嗎？客戶是不認的，因為我們一直沒有提個版本出來，現在只好吃這個啞巴虧。
關于最重要的這一點，請各位仔細體會。
2、需求變更其實是一把雙刃劍，要看怎么樣能用好：
話說需求變更是所有開發者的噩夢，但是在一定條件下，需求變更可以用來做對自己有利的事情。還是上面的情況，我們先提交代碼，然后叫客戶過來進行初步的測試，這時候客戶肯定會提各種各樣的意見，需求變更的噩夢就要開始了。但是，在目前項目情況下，其實這些變更是可以作為我們爭取有利條件的砝碼的。
首先，這個項目時間很緊急，客戶其實自己也清楚，在時間這么緊急的情況下下，肯定不會有大規模的需求變更，我們可以借此機會將變更范圍縮小，對于一些無法確定的變更，可以引導客戶放到二期再做。同時，由于東西先出來了，再進行的需求變更，客戶感覺自己參與進去了，一般到后面，他就不會輕易否定你的做的東西了，因為反駁你等于反駁他自己。
其次，如果有確實需要變更的地方，跟客戶提出工作量和時間的要求，借此加大客戶對我們工作的認可。我們現在做的也很辛苦，其實做了很多客戶看不到的事情，但是這些在客戶眼里無法有效的體現為我們的工作量，反而是成為客戶懷疑我們工作能力的一個質疑點。如果我們能先快速提交一個版本，至少客戶會認可你的能力，對于需求變更帶來的工作量，他們才會認為是有意義的。
最后，如果需求變更導致真的做不完，項目可能出現延期，這個問題也不會落到我們頭上（牢牢記住第一條，只要沒有“做錯”就OK），客戶反而會變成有求于你，如果能加把勁幫他們解決這個問題，收獲的是他們的感謝，當然，還有下一期的項目。而現在，付出的工作量并不少，卻是我們有求于客戶，希望客戶能多給點時間，簡直虧大了。
3、所有人都是你的盟友
在跟客戶討論需求的過程中，我們發現一個有意思的現象，客戶其實是分撥的：
第一撥，跟我們一起實際做事的，科技部門的，關注的是這個事情好不好實現，有沒有現成的東西，需要新增還是改動，他們有多大工作量；第二撥，關注運營的，關心功能是不是夠用；第三撥，關注風險的，關注設計中有沒有遺漏的風險點；第四撥，關注界面點，專注于交互設計合不合理，給用戶用起來順不順手。
所以，到后來，我們在提出我們的觀點時，如果期望得到誰的幫助，第一句話一定會跟他相關，比如：“從風險管控的角度講，這里xxxxxx”，好了，那個做風險的就會幫著你開始balabala………
記住，不要直接反駁別人的觀點，一定要拉上他們當中的一個幫你說，到最后的結果就是，所有人都覺得你說的不錯，因為所有人都覺得自己的意見得到了重視。
4、針對需求中的問題提出自己的想法時，直奔目標，不要用設問句
之前漏了這一點，補充上。
之前做產品研發的時候，我們對一個問題進行討論時，經常使用設問句。比如：“這里有一個重新打印最多只能做一次的需求，這個需求對客戶來說是否有點不合理？”，然后，大家就會balabala針對這個問句來思考，提出自己的看法，最后我們會提出自己的看法共大家參考云云……其實，這種設問句大部分都是我們已經有了方案，只是為了引起大家的注意和思考，所以會先拋出一個問題。
這次在跟客戶討論需求的過程中，我們一開始也習慣性的用這種方式跟客戶討論需求，結果發現客戶思維在問句拋出之后立馬開始發散，往往會偏離我們預想的方向。而當我們試圖再拋出自己的方案來糾正這個方向的時候，客戶會認為我們是在反駁他的觀點，是在躲避需求。
發現這個問題之后，我們改了交流的方式，對于需求中有疑問的地方，不提問句，上來之后直奔主題，直接拋出我們的方案，“對于需求中提到的xxx，我們認為xxx，我們設計了一種方案是xxx，大家看看有沒有什么問題？”猜猜客戶的反應是什么？在大部分情況下，客戶的第一反應往往是圍繞你的方案來提意見，基本能保證方案按照我們的來走，然后修正其中一些不合理的地方，最后客戶還覺得自己做了不少工作……
小結，討論需求不是在做產品研發的頭腦風暴，討論需求是為了定下一個結論，一定要牢牢把握住方向，避免思維的發散性。
PS：其實仔細回想一下，有時候領導想讓你做一個事情，而你又覺得這個事情不是很合理，不太想做的時候，往往領導會轉移話題跟你探討這個東西怎么實現，然后你的注意力就不知不覺被轉移到這個東西怎么實現，而不是應不應該實現上去，因為程序員一聊到具體的技術實現就興致勃勃了……有木有！！哈哈
文章列表
留言列表
