現在大概是以一次看一章，每週看一章的速度來進行的，工作日自己太懶，沒有花時間去思考和行動。
這次看的是第二章，開發過程。
作者講了很多，但是基本都是以乙個開發人員的視角來描述的。
我很詫異的是，感覺很多國外開發人員寫的開發流程的書。你是感覺不到產品經理和設計師的存在的。
需求分析是由需求分析人員完成的。
這一點可能和現在的網際網路圈差異較大。
需求一般都是產品經理來提的，設計師是要看公司的資源支撐，如果不充足的話，一般產品經理也要完成設計的事情。
需求要到多細，這個其實也是很難細化的。這個需要每個團隊的磨合，需要業務場景的適合。
我自己本質是乙個產品經理。
但說實話，我對於需求分析是做的很爛的。
第一，我很難理解使用者需求。
第二，在基於不是特別準確的使用者需求理解上，我和開發人員溝通，經常會被問倒。導致要重新回去問使用者。
第三，使用者的使用場景我並不是特別熟悉。
簡單的需求好做，中間我只起到了乙個傳話筒的作用。
複雜的需求，我對其中的幫助並不大。
我現在還比較缺乏設計一套解決方案的能力。
另外乙個我比較頭疼的是互動設計。
互動設計我也覺是乙個應該屬於設計師的活，當然不是說產品不管，只是產品包掉互動設計這確實有些超綱了。
但是小公司都是這樣，就算是鵝廠，大多數互動設計也確實都是產品經理自己完成的。
還有乙個產品的規劃。
這個對我來說，可能是最難的了。
使用者對這個基本是沒有感知的，他給不了你答案。
我有時候會抱怨這個，但想想不應該，產品經理你應該去挖掘。
做產品的規劃，我也認為是乙個有點虛的事情。
本身需求多變的情況下，做產品規劃到什麼程度，可能又是只能以平衡的藝術收場。
另外就是迭代的節奏。
因為說實話，我對版本的控制沒有啥的強的概念，迭代也是亂七八糟。
這周到底該幹啥，下週該幹啥，哪些更緊急，哪些可以延緩。
我認為複雜性都好高。
以前說的人人都是產品經理，我也是信了邪了。
人人都可以不是產品經理，可能更恰當些。
因為別人對產品的期望是，除了**細節你可以不了解外，理論上關於產品的任何事情你都應該一清二楚。
但是事實上，你回顧一下，發現你只有乙個開發同學。
然後，很多事情你估計就gg了！
UML精粹讀書筆記（1）
我決定每次讀一下書，還是來說說一些想法的好。漫畫就先算了吧，等我把火影補完再說吧。如果什麼時候我的主站建好了的話，我會在我自己的主站上去更新。今天終於把這本書的簡體中文版搞到手了，有幾個小插曲 1.這本書是盜版的，從 買的。就是那種圖書館影印出來的書，我發現乙個有意思的點是，影印的書都會把封皮做乙個...
UML讀書筆記（1）
uml的定義 unified modeling language 統一建模語言。在系統的開發過程中，最關鍵的一點是要用一種系統分析員，客戶，程式設計師和其他系統開發所涉及到的人員能夠理解和達成一致的方式來組織系統的設計過程，uml就提供了這種組織方式。uml的組成包括類圖，物件圖，用例圖，狀態圖，順...
JavaScript 語言精粹讀書筆記 第三章
在物件字面量中，如果屬性名是合法的標示符那麼時候用引號擴起來是可選的，相應的在訪問屬性時可以使用兩種方式，中括號或者點。否則定義時引號是必須的，在訪問時也只能使用括號形式。每個物件都會被鏈結到原型物件，可以通過原型物件實現繼承，所有通過物件字面量建立的物件都會被連線到object.property，...