騰訊一直推廣敏捷開發(fā)，也在強調敏捷開發(fā)，但你會發(fā)現，即便如此，還是會陷入以下情景

• 又丑又長的討論會
• 好像人手永遠不夠
• 不切實際的想法
• 懸而不決的功能點
• 無窮盡的偏好設置
• 越來越多糾纏不清的細節(jié)
• 項目依然延期

我們如何構建一個更輕巧的開發(fā)流程，讓我們更快更好的交付結果？作為一個設計師，如何成為敏捷的一分子？以下是一些心得方法，希望和大家分享

1 界面先行

作為設計師，最簡單能讓大家明白你的想法就是先把它畫出來，不要用晦澀的語言和結構圖，畢竟不是所有人都能把你的語言轉化為圖像。而且界面（視覺，交互）設計是相對輕量級的，修改起來也簡單，成本也低。但修改程序就遠不是那么回事了。保持界面先行可以讓你非常靈活，至少在開始開發(fā)之前可以隨意修改。

界面先行另一個最重要的原因就是，對于用戶來講，界面就是你的產品，界面可以幫助你從用戶角度看待自己的產品，如何展現，如何操作，給人感覺怎么樣，是不是易用。只有當你面對真正界面的時候才能回答這些問題，文檔概要并不能幫你解決實際用戶體驗問題。

2 初期不需要太關注細節(jié)

雖然大家總說，成功來源于細節(jié)，當然，這非常對。但前期過分關注細節(jié)的同時也會令你止步不前。先把大框架確定下來，而不是一直糾結于

• 這條提示怎么寫更合適？
• 文字字號用16還是14？
• 要不再往左挪1像素？
• 這里加個高光把
• 把2像素的描邊變成1像素

你需要關注細節(jié)，但不是現在。所有事情都要從大到小的去做。先把他做出來，把該放的東西放上去，然后實際去用一下。

細節(jié)是你在使用的過程中才會慢慢顯露出來，只有在使用中你才會發(fā)現哪些更值得關注。如果你有足夠的時間，當然可以面面俱到，如果沒有，請先把精力放在最重要的事情上。

3 不要糾結那些還沒有成為問題的問題

“當我們的用戶用了這個功能以后還想跟另一個功能配合使用怎么辦？”

如果想快速推出版本，就先解決當下。不要花太多時間去考慮還沒有成為麻煩的問題。別擔心，你還有后續(xù)版本。

而且你就真那么確定用戶想跟另一個功能配合使用么？如果不是，就先放一邊，等問題真正浮出水面的時候再去快速解決。

4 幫助產品經理精簡功能

好像大家都在弩著一股勁，比誰做的多。競爭對手的產品如果做了**，我們就要做***，他們有4個功能，我們就要做5個。如果不做，拿什么跟他們競爭？

這種方式是行不通的，因為你會發(fā)現，永遠是趕超，永遠沒有自己領跑的那一天。怎么辦？

做少

通過做少來打敗他們

做的功能越多，功能間的交互就會越復雜，用戶的學習成本就會越高。而我們的用戶真的用的上那些高深的功能么？他們會不會已經被那些多如牛毛，但我們自以為高明的設置搞得疲憊不堪？試著少做一點，讓自己的產品更加輕巧而更具備親和力——沒有人會喜歡使用顯得自己很笨的軟件。

5 功能間更少的牽扯

把一個功能點做的盡量獨立，能保證需求改變時更為快速，更為靈活。

如果功能間的牽扯太多，就如同你身上沾滿了蜘蛛絲，每做一點改變，其他的都要進行改變，從設計，到開發(fā)，到測試。當你發(fā)現改變的代價太大時，你就會放棄，然后依舊背負著帶有缺陷的功能一路走下去。

為什么不開始就盡量少牽扯呢，這樣更加來去自如

6 要有自己的主張

雖然交互設計通常都會處在不黑不白的階段，因為沒有絕對的對與錯。但我們還是需要堅定自己的主張。也許果斷的觀點看起來目中無人，但總比那些“嗯……其實這樣也成……”模棱兩可要好的多。敏捷開發(fā)中需要的就是快速做決定，而不是唯唯諾諾和稀泥。

————————————————————————————————

也許并不是所有的項目都適合，畢竟初期不考慮細節(jié)必然要考慮后期更改的成本。但對于一個新產品，快速觸達用戶，讓用戶來使用，驗證，反饋，得到的數據更加真實有效。根據這些反饋作出的調整總是比自己拍腦袋來的簡單，更加符合用戶需求。

敏捷，并不只是站立晨會，迭代總結，理論，文檔，更需要的做的是，把它做出來。

原文：http://wsd.tencent.com/2010/08/smaller_faster_and_smarter%e2%80%94%e2%80%94how_could_we_make_a_agile_workteam.html