開頭先留個問題哦，現(xiàn)有畫正方形的兩種方法。

方法A：：一個邊一個邊畫。

方法B：畫完四個點再連起來。

問：那種方法你覺得畫的正方形又快又好。

以下是正文，這個題目和正文有關聯(lián)的哦。

—-

創(chuàng)業(yè)公司有一個很突出的特點，就是內(nèi)部的業(yè)務溝通流程還不清晰，或者即使流程清晰，執(zhí)行過程里也允許較高的自由發(fā)揮。這是創(chuàng)業(yè)公司的優(yōu)勢，因為機動性強，能更好的應變突發(fā)狀況。

但是流程的模糊也會帶來一系列問題，最典型的就是“緊急需求”的出現(xiàn)（大公司也會出現(xiàn)，但因為流程的嚴格，能很好的阻擋掉）。在創(chuàng)業(yè)公司做產(chǎn)品的同學一定經(jīng)常遇到臨時插進來的優(yōu)先級特別高的需求。而它之所以優(yōu)先級高，可能事實如此，也可能只是源于老板的突發(fā)奇想。大多數(shù)情況下，你并沒有議價的權力，所以救火的任務往往就會落在你頭上。我們當然可以義正言辭的找需求方進行需求駁回，但我們同時也要提高自己處理“緊急需求”的能力。

自己近期剛好遇到了兩次這樣的情況，“緊急需求”突然出現(xiàn)，打斷了原本的任務。接著我就必須立刻開始需求調(diào)研和分析，立刻完成方案設計、ui跟進，然后給到技術部門。如何保證短時間內(nèi)不出錯且較高質(zhì)量的完成任務是一門學問啊。

首先基本的需求處理原則不能亂，針對需求提出方產(chǎn)品是優(yōu)勢部門，應該盡可能多的來回溝通，確保信息無誤。針對技術部門，我們是弱勢部門，應該盡可能確保需求不變更的前提下再把方案給到技術。然后就需要確保你能迅速的理解清楚需求了，這里我在觀察老大的工作習慣時，發(fā)現(xiàn)了一個不錯的思維方法：

如果我們把一個需求看做一個系統(tǒng)，它一定是由幾個子系統(tǒng)組成的，我的做法是先考慮子系統(tǒng)之間的“聯(lián)系”，但因為聯(lián)系是網(wǎng)狀且異常復雜的，我居然花了數(shù)小時還不能把這個需求理解清楚T-T T-T T-T T-T T-T。

然后老大來幫忙了，他建議我先不考慮子系統(tǒng)之間的關聯(lián)，優(yōu)先將它們簡化成獨立且不相關的個體，分別考慮。那要怎樣將子系統(tǒng)區(qū)別呢？？關鍵在于設立隔絕條件，比如現(xiàn)在存在任務A和任務B，它們之間有相當多的交集（就是需要互相判斷的一些前置條件，比如任務A要進行下去，你要先考慮任務B里存在的特殊情況），我們現(xiàn)在設定條件將任務A和任務B的關系撇清，單獨的先理清任務A，再單獨的理清任務B。

我猛然發(fā)現(xiàn)自己的梳理速度加快了，因為之前梳理的慢很大程度是因為我花費了過多時間去考慮任務A和任務B之間特殊“聯(lián)系”，一旦還存在任務CDEF…的時候，這樣的理解成本是巨大的。

現(xiàn)在我們繼續(xù)深挖一下這個需求系統(tǒng)。我們把子系統(tǒng)獨立開來并分開考慮，很快就梳理清楚了它們各自的邏輯，這樣理解確實加快了，但要完成需求系統(tǒng)，我們還是必須要考慮子系統(tǒng)之間的“聯(lián)系”。這個方法并不是要我們放棄考慮“聯(lián)系”，而是在真正理解子系統(tǒng)的邏輯之后，再去思考“聯(lián)系”能讓思維更加有條理。比如我們畫一個正方向，大家可以試試，是一個邊一個邊的畫，還是把四個點固定好后再連起來畫的形狀比較快和精準？？

如果用人話來說呢，就是在創(chuàng)業(yè)公司，因為“緊急需求”特別多，一個產(chǎn)品如果要高效高質(zhì)的完成這些任務，就必需改變自己的思維方法。而這個方法有兩步，首先簡化，找出你能想到的最簡單的理解方式和解決方案；其次，再去將其復雜化，考慮這個需求內(nèi)部和外部的矛盾，比如它會給公司的其它產(chǎn)品帶來什么樣的影響。

這個思維不一定人人都會習慣，但它的好處至少有兩點：一是你的理解變快了，你有更多時間和需求提出方去討論細節(jié)；二是你的文檔也簡單了，有利于其它閱讀人員的理解速度。

#專欄作家#

烏木，公眾號：wumuwizard，人人都是產(chǎn)品經(jīng)理專欄作家，簡書@烏木。喜歡搖滾和吉他，喜歡騎自行車，喜歡用Sketch，自學編程中，對交互比較敢興趣。希望做個全面又有夢想的產(chǎn)品人，夢想是做一款自己喜歡用戶也喜歡的產(chǎn)品。

本文系作者授權發(fā)布，未經(jīng)許可，不得轉載。