怎樣在撕X過程中保持清醒的頭腦

為了提高大家看文章的效率，我決定還是先把觀點拋出來：

在產品開發過程中，一方找另一方溝通時，往往會直接替對方提出一個Solution，而這個Solution背後的Question 往往在爭論中被忽略了。導致問題不能被很好解決。n

首先，場景還原：

場景1.

程序：針對需求R，你這個設計A不好，你這裡不如加個彈窗B。你看如果有了彈窗B會多爽多爽。【先提出一個自認為很好的解決方案】n

交互：我不覺得B的體驗更好，因為1. 用戶心理balabala 2. 用戶路徑balabala 3. 我們設計組已經討論過了balabala【急於反駁新方案】n

程序：可我覺得。。。n

交互：我不覺得。。。n

（二人度過了不愉快的一個上午）n

其實，程序的真實想法是：你這樣設計，我有一處代碼會十分麻煩，兼容性也會變差。交互的真實想法是：在用戶體驗方面，你懂得又不多，還要我解釋這麼多。於是，我們發現，兩個人開始就新方案是否是好方案進行了激烈地辯論。事實上，溝通重點已完全跑偏。

我們來理一下思路，一個需求可能有多個解決方案，而一個解決方案在實施過程中會遇到多個問題，結構如下：n

場景1中，程序員往往由於方案A的某個question，直接向上游提出方案B。而場景中的Designer，又急於反駁方案B。於是討論的重點跑到該不該採用方案B 上。

事實上，一個需求可能有無數種Solution，而一個Solution下，也可能會出現很多個Question。每一個Solution的得出，多少會經歷一些推導過程，而由於某個Question 的出現就急於轉向另一個方案，顯然是欠考慮的。我們應該做的是定位這些Question，解決他們，使得方案更完美。

於是，在業務上下游撕X過程中，更有效率的故事情節應該是這樣的：

場景2.

程序：你對需求R設計的方案A，可能在代碼上出現某種問題，想想看能不能改進。【提出Question】n

交互：這個問題是怎麼出現的呢？【進一步了解問題】n

程序：是因為。。。出現的，是否可以借鑒方案B的思路？【描述問題，提出可能的解決方案】n

交互：那可以這樣調整一下，採用方案A』 ，如何？【調整到最好的解決方案】n

程序：Perfect！n

正好找到一句slogan 作結尾，共勉！n

推薦閱讀：