Shengnan的《构建之法》读书笔记
作者：互联网
大家好，我是Shengnan，来自西安交通大学自动化专业，正在读大四。目前感觉自己是一个刚转行的技术萌新，希望在MSRA实习的一年里逐渐入门，为读博士打一个好的基础。
由于最近回学校事情比较多，知识抽空大概浏览了《构建之法》这本书，整体的感觉是，这本书能用一些生动的例子去解释一些概念或者技术，即使我这种技术小白读起来也不会觉得枯燥。在读的过程中，我记下了一些比较有意思的点和一些疑问，暂时就先一股脑地列在这里，之后假如有时间再系统的整理一下。
疑问：
全局问题：书中讲的内容感觉更偏向工程一些，但是如果是做research的话，有些环节（比如繁重的测试任务）是否可以在实际操作中精简一下？
P92：“主治医师模式”似乎会逐渐变成“抱大腿模式”（就像在学校做小组作业一样）。要如何避免出现“大腿”承担所有工作而其他人只在一旁喊“666”呢？
P105：MVP可以用来征集用户意见，但假如MVP的反馈很差，是否意味着这款产品没有做下去的必要了？
P145：微软提倡Learning By Doing，这确实是上手工作的最好方式。但是，是否会存在“揠苗助长”的问题呢？
P160：谷歌团队争论41中蓝色哪种更好，看上去很荒唐，但到底是什么引发了这种荒唐事？该如何避免？
P185：书中说PM要负责管理项目进度，可是PM该如何管理？
P256：那个学者师承关系树，似乎关心的问题不是“用户会每天都来看这个动画么？”，而是“用户在搜索时会来看这个动画么？”似乎仅仅当做微软学术搜索的小彩蛋，还是挺能吸引人的？（比如谷歌浏览器在没网的时候可以玩的那个小恐龙）
P339：“扁鹊三兄弟”的问题怎么解决？似乎功劳与“锅”分配不均是一个团队内很大的不稳定因素。
P345：让人喜欢的创新是与现有系统兼容的，但是很多好的创新之所以好，不正是因为其颠覆性么？
P359：AI技术是否已进入高科技炒作的迷茫期？
个人想法：
P66：用abCd的形式命名变量很有用，但是个人更习惯ab_cd的形式。
P87：“三明治”式的反馈确实更容易让人接受，但假如两个人已经很熟了，也许直接提问题能加快沟通效率。
P128：在不确定沟通效率和沟通范围时，宁可过分沟通，也不要省略沟通。
P141：在执行任务时，全局任务为核心，可以暂时放弃额外的诱人目标。
P155：“秋千图”感觉是全书最真实的图了orz解决这个问题，我认为关键在于有一个思维清晰的全局规划者（比如组里的大老板）。
P165：似乎强调“杀手功能”和新木桶原理的长板效应很类似。
P194：会议结果得到行动后，一定要强调行动的负责人。
P235：在实现整体功能前，局部的小bug是可以容忍的。并且不要过早的优化。
P243：“新员工上手问题”真的很有实际意义。
P250：谷歌的搜索界面感觉很干净，用户体验就很好（对本人用户而言）。但是hao123感觉就很凌乱，体验很差。
P260：有时候，用户体验比产品质量更重要，就像论文里的可视化有时候比数据结论更重要。
P341：灵光的出现需要有两个基础：前人工作的基础与自身积累的基础。
P348：外行人之所以能发现内行忽略的创新点，大概就是因为“只因身在此山中”吧。对住在南方的同学来说，再普通的一片雪花，也能激起极大的探索热情。
标签：沟通,读书笔记,谷歌,用户,问题,构建,感觉,似乎,Shengnan 来源： https://www.cnblogs.com/ShengnanAn/p/11460171.html