這本書寫的內(nèi)容質(zhì)量還是不錯的特別是互聯(lián)網(wǎng)相關(guān)行業(yè)的朋友推薦閱讀，書種令我印象最深的就是Lean UX的與敏捷開發(fā)相同的幾個原則，以人為本的溝通、小版本持續(xù)迭代、讓市場驗(yàn)證是否可行。

對于大部分企業(yè)來說，擁有設(shè)計(jì)的思維，能夠跨越部門協(xié)同向前這種需求所帶來的體制改變、管理難度的提升是何其艱難，沒有陣痛，沒有高層的真正認(rèn)識與強(qiáng)力支持，沒有人員上的大批量換血，基本上不可能得以實(shí)現(xiàn)。或許只有初創(chuàng)型的公司才更合適從一開始就走這一條路。

從組織架構(gòu)上來說，人數(shù)不多，協(xié)同作戰(zhàn)，快速響應(yīng)，務(wù)實(shí)的小團(tuán)隊(duì)確實(shí)是比一般的分工明確，部門森嚴(yán)的大團(tuán)隊(duì)有太多的優(yōu)勢，如果現(xiàn)有公司仍然不能認(rèn)識到這一點(diǎn)，那真的就可能遲了。

另外精益設(shè)計(jì)方法的幾個觀點(diǎn)：用戶訪談是一個持續(xù)性的過程，可能要花上一個月才能驗(yàn)證一個結(jié)論。不要丟棄異常數(shù)據(jù)，留著慢慢觀察說不定后面會發(fā)現(xiàn)類似的情況。用戶訪談和sprint需要整個團(tuán)隊(duì)的參與協(xié)作，更清楚目標(biāo)是什么，結(jié)論是什么。交錯式sprint模式意味著設(shè)計(jì)先一個sprint，這樣開發(fā)資源不會閑置。但需求評審、設(shè)計(jì)評審環(huán)節(jié)，產(chǎn)品經(jīng)理、開發(fā)、設(shè)計(jì)、測試都參與，也是為了減少后續(xù)信息不對稱帶來的額外溝通成本，并且提前溝通可以盡早發(fā)現(xiàn)問題。scrum敏捷開發(fā)模式下，會有各種小會，但它是有效的，可能一個會議上只有10%的信息與你相關(guān)，但你能知道結(jié)論是如何形成的，可以節(jié)省后面的溝通時間。如何避免管理層干擾迭代節(jié)奏：積極溝通（進(jìn)展、規(guī)劃）。和管理層尋求目標(biāo)一致，避免與管理層溝通具體需求。用MVP快速測試，速度第一美化第二并不是說降低質(zhì)量保證速度而是選擇費(fèi)時最少最容易講清楚的方案，快速執(zhí)行修正。在需求驗(yàn)證階段，小團(tuán)隊(duì)效率比大團(tuán)隊(duì)高。不要要求設(shè)計(jì)一步到位（big disign up front）。