現在大概是以一次看一章，每周看一章的速度來進行的，工作日自己太懶，沒有花時間去思考和行動。

這次看的是第二章，開發過程。

作者講了很多，但是基本都是以一個開發人員的視角來描述的。

我很詫異的是，感覺很多國外開發人員寫的開發流程的書。你是感覺不到產品經理和設計師的存在的。

需求分析是由需求分析人員完成的。

這一點可能和現在的互聯網圈差異較大。

需求一般都是產品經理來提的，設計師是要看公司的資源支撐，如果不充足的話，一般產品經理也要完成設計的事情。

需求要到多細，這個其實也是很難細化的。這個需要每個團隊的磨合，需要業務場景的適合。

我自己本質是一個產品經理。

但說實話，我對於需求分析是做的很爛的。

第一，我很難理解用戶需求。

第二，在基於不是特別準確的用戶需求理解上，我和開發人員溝通，經常會被問倒。導致要重新回去問用戶。

第三，用戶的使用場景我並不是特別熟悉。

簡單的需求好做，中間我只起到了一個傳話筒的作用。

復雜的需求，我對其中的幫助並不大。

我現在還比較缺乏設計一套解決方案的能力。

另外一個我比較頭疼的是交互設計。

交互設計我也覺是一個應該屬於設計師的活，當然不是說產品不管，只是產品包掉交互設計這確實有些超綱了。

但是小公司都是這樣，就算是鵝廠，大多數交互設計也確實都是產品經理自己完成的。

還有一個產品的規劃。

這個對我來說，可能是最難的了。

用戶對這個基本是沒有感知的，他給不了你答案。

我有時候會抱怨這個，但想想不應該，產品經理你應該去挖掘。

做產品的規劃，我也認為是一個有點虛的事情。

本身需求多變的情況下，做產品規劃到什麽程度，可能又是只能以平衡的藝術收場。

另外就是叠代的節奏。

因為說實話，我對版本的控制沒有啥的強的概念，叠代也是亂七八糟。

這周到底該幹啥，下周該幹啥，哪些更緊急，哪些可以延緩。

我認為復雜性都好高。

以前說的人人都是產品經理，我也是信了邪了。

人人都可以不是產品經理，可能更恰當些。

因為別人對產品的期望是，除了代碼細節你可以不了解外，理論上關於產品的任何事情你都應該一清二楚。

但是事實上，你回顧一下，發現你只有一個開發同學。

然後，很多事情你估計就GG了！

UML精粹讀書筆記（2）