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

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

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

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