交付产品是一种怎样的体验

此书的经验，一线人员最有感触。

读书笔记：

1. 设定「目标」告诉别人你要什么，设定「非目标」告诉别人你不要什么。为产品设定「非目标」非常有用。// 诚如乔布斯所说，重要的不是做什么，而是不做什么。

2. 做表格时，将可编辑的单元格设为黄色，以便于识别哪些是预估值、哪些是计算值。

3. 数字模型往往对假设高度敏感，这不是它的问题，而是优点。

4. 努力做「细节帝」。// 亚马逊的 CEO 贝索斯就是如此。

5. 好的 UI 设计师会善用栅格系统来排列元件，以增强产品体验的一致性。// 这就是我常说的，「对齐」是一切设计最重要的元素。

6. 一个界面只有一个主要按钮。

7. 若一个流程有 3 ~ 4 步，要告诉用户当前在哪一步、共有多少步。

8. 与设计师沟通，首先要在某些设计原理上达成共识。

9. 需同时考虑新用户、老用户分别看到什么内容。

10. 通常五天的开发时间里只有三天是具备生产力的，因为有各种变动事项。对生产率估值 60% 是比较合理的做法。// 我的经验，50% 都有可能，但 50% 应是底线。

11. 项目管理，只跟踪剩余时间，其他均无视。

12. 高中蒙羞测试：我能确信当一个高中老同学看到我的产品时，我不会羞愧吗。

13. 调试过劳死，测试嗨翻天。// Debug v.s. Testing，谷歌贴在厕所里的段子。

14. 一流的人雇佣一流的人，二流的人雇佣三流的人。

15. 测试应包括试图破坏你的网站。// 安全威胁，无论怎么过虑都不为过。

16. CEO 经常会遭遇一些别人从未遭遇过的糟糕体验。

17. 感谢每一个 Bug。

18. 讨论每个 Bug 的时间不要超过一分钟：频率，严重性，修复成本。

19. 开箱体验：删掉帐号，重新关注如何创建帐号及为帐号添加信息。

20. 不要让团队冲刺超过 1 个月。

21. 不要选择周五或临近假期作重大发布。// 但现实常常不允许啊。

22. 一个准备充足的产品应当有快捷关闭服务或限制服务速率的软件开关。

23. 产品演示，先从问题和使命讲起。

24. 不要相信面试，要相信背景调查。

25. 面试佳题：讲一个你如何改变别人想法的经历，以及你的技巧。

26. 工程师团队协作的临界数量是 3 人。

27. 离你越远的团队越焦虑。

28. 如果不能将事物简单地表达出来，你就没有真正理解它。// 爱因斯坦说的。

29. 尽可能少开会，但不要不开会。

30. 精确增量表达法：将 xx 增加或减少 xx，即从 xx 增加或减少到 xx。// 重点是后半句必须写出来，在沟通中。

31. 书面表达中，行间距有其深刻意义。

32. 建议比质疑更容易被接受。

33. 团队会议结束之前，给 7 秒钟的安静时间。

34. 多说「Yes, and …」。

35. 会议现场，善用结构化来促进讨论。

36. 会后，立即发出会议纪要。

37. 标准的演示时间控制在 10 ~ 15 分钟。

38. 项目概要：问题，机会，解决方案，成本，时间表。

39. 先寻求理解，再寻求被理解。

40. 当你相信你面前的家伙不一定是个讨厌鬼时，你就能找到问题的根源。

41. 少说「你」或「我」。// 多说角色，保持客观。

42. 记得弄清楚优先级的变化是不是真的。

43. 首先应该做那些只有你能做的事情。

44. 别人越慌乱，你要越镇定。

45. 能交付的软件，就是最好的软件。