这本书写的内容质量还是不错的特别是互联网相关行业的朋友推荐阅读,书种令我印象最深的就是Lean UX的与敏捷开发相同的几个原则,以人为本的沟通、小版本持续迭代、让市场验证是否可行。
对于大部分企业来说,拥有设计的思维,能够跨越部门协同向前这种需求所带来的体制改变、管理难度的提升是何其艰难,没有阵痛,没有高层的真正认识与强力支持,没有人员上的大批量换血,基本上不可能得以实现。或许只有初创型的公司才更合适从一开始就走这一条路。
从组织架构上来说,人数不多,协同作战,快速响应,务实的小团队确实是比一般的分工明确,部门森严的大团队有太多的优势,如果现有公司仍然不能认识到这一点,那真的就可能迟了。
另外精益设计方法的几个观点:用户访谈是一个持续性的过程,可能要花上一个月才能验证一个结论。不要丢弃异常数据,留着慢慢观察说不定后面会发现类似的情况。用户访谈和sprint需要整个团队的参与协作,更清楚目标是什么,结论是什么。交错式sprint模式意味着设计先一个sprint,这样开发资源不会闲置。但需求评审、设计评审环节,产品经理、开发、设计、测试都参与,也是为了减少后续信息不对称带来的额外沟通成本,并且提前沟通可以尽早发现问题。scrum敏捷开发模式下,会有各种小会,但它是有效的,可能一个会议上只有10%的信息与你相关,但你能知道结论是如何形成的,可以节省后面的沟通时间。如何避免管理层干扰迭代节奏:积极沟通(进展、规划)。和管理层寻求目标一致,避免与管理层沟通具体需求。用MVP快速测试,速度第一美化第二并不是说降低质量保证速度而是选择费时最少最容易讲清楚的方案,快速执行修正。在需求验证阶段,小团队效率比大团队高。不要要求设计一步到位(big disign up front)。