《软件随想录(上)》读书笔记

一 、乔尔测试

1.你们用源代码管理系统吗?

git 神器

2.你们能一键编译吗?

这个要去研究一下

3.你们做每日编译吗?

这个要去研究一下

4.你们有bug数据库吗?

5.你们在写新代码前修改以前的代码吗?

在做开发规划的时候,要预留修改以前代码的时间,而不能只是考虑到不断叠加新功能。

6.你们的进度表是最新的吗?

每周的进度更新是必要的,这样才能知道每月的计划能否顺利完成。我们有最新的每周进度。

7.你们有软件规格书吗?

就是我们的产品设计文档。产品设计文档,原型修改5遍,也好过代码开发出来了再推到重来。
没想清楚产品细节之前,不要开始开发!

  1. 程序员的工作环境安静吗?

远程工作者可以选择自己的工作环境

9.你们使用了能买到的最好的工具吗?

可以有

10.你们有测试人员吗?

3.1以前都是产品经理同时负责测试,3.2以后要引入专业的测试人才,提升测试完整度。

11.你们面试时会要求应聘人员写代码吗?

可以有。

12.你们做过走廊可用性测试吗?

在做,且必须做。每次要提供不同版本让用户来比较体验,并给出反馈。

感觉上,乔尔十多年前提到的这些,已经逐步成为开发团队的标配。

二、软件功能规格书

  1. 为什么要写:
  • 提高研发效率:能够在开始研发之前设计好软件,在设计的时候就暴露所有可能的逻辑问题可用性问题从而调整,而不是在研发的时候,从而大幅度提高效率,降低研发损耗。
  • 提高对合作伙伴的沟通效率: 便于设计,测试,运维,客服,运营等等合作伙伴来学习和了解软件,而不用把所有内容都用一遍同时还要打扰程序员不断追问,才知道这是什么,该怎么用,有什么效果。而合作伙伴会面向用户,告诉用户这个软件该怎么用。
  • 没有规格书,就无法制定进度表。
  1. 什么是规格书?
    • 概述: 这个软件是做什么用的
    • 使用场景:产生需求的经典用户场景是什么,软件如何帮助用户解决问题。
《软件随想录(上)》读书笔记_第1张图片
场景

书摘:
从你产品的使用者中,选取积累代表性的目标用户群,为每一类虚构一个想象中的、但完全典型的用户。场景越生动,逼真,你设计出的产品就越适合用户使用。(http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html)

思考:
这于我而言是新颖的部分。以后可以考虑在产品文档里面也加上场景说明部分。

有用户场景的需求才应该被重视和开发。
如果一个需求仅仅是个人臆想出来,找不到现实场景,那么不应该投入开发计划。

比如说尝试给ping这个功能写一下用户场景:

开发者Jack经历了3个月的紧张工作,总算如期交付了公司要求的新产品。接下来是测试,运营推广的事情了。预计会有差不多2周到1个月的相对空闲的时间,于是他到了客栈上,想看看最近能不能接到一些不错的兼职。
他会尝试去联系客栈的客服,标明自己现在比较有空,想要接单。
同时,由于团队是按周来规划任务的,他对于一周后会不会有新的开发任务并不是特别有信心,因此他希望这个最好是本周内可以接到比较短期快速的小任务。
因此,他可以使用Ping这个功能。
点击Ping, 他可以登上当天程序员列表的首页,让潜在的雇佣方有更多机会看到他;第二天他如果依然有空,可以继续Ping;如果没空了,可以不再操作,甚至点击“接单”按钮,切换到不接单状态。
另外,Ping也会影响自动对接排序,他的排序马上会靠前,而这个影响因子会在未来七天衰减,到第8天衰减为0.

《软件随想录(上)》读书笔记_第2张图片
Ping功能
  • 非目标:本软件本次不计划做什么

这个我们目前也没写过。目前只写了要做的内容,不做的内容不写,放到待规划不分区,留待以后规划。

  • 流程图
  • 每个页面的功能规格说明(概述,细节)
  • 本次不解决的问题:这些一般都是基于已经考虑到,但降低了优先级的问题。
  • 多角度注解:技术注解,营销注解等。

这个也很新鲜。目前我的产品文档里面,只有产品注解。
技术注解,营销注解都没有做过。

7.如何招到靠谱的项目经理

  • 不把程序员提拔为项目经理:优秀的项目经理需要具备的素质:文笔清晰,外交手腕,市场嗅觉,用户视角,以及优秀的界面设计能力。和优秀程序员的能力发展路径不一致。

从描述来看,这个其实是产品经理和项目经理职责的融合职位。不仅仅是目前我们理解的项目经理而已。

  • 不要让营销人员做项目经理

不让程序员听命于项目经理:项目经理应该通过证明项目本身值得去做而赢得程序员的支持,而不是靠地位优势,行政命令。

8.轻松掌握项目进度

  • 只有最终写代码的人能够预估需要多少时间
  • 适当细分任务,保持合适的颗粒度(小时):通常的规则,任务的颗粒度应该在2小时-16小时之间
  • 如何提升项目预估精准度:只做开发人员的预估/实际开发时间对照表,斜率越小,误差率越高。最好是斜率为1.把节假日,调试代码的时间,集成的时间,缓冲的时间都考虑在里面
  • 永远不要让开发经理压缩程序员的时间
  • 开发Excel5时,为了保证上线时间不得不把一些功能暂时延后到了以后版本。然而之后回顾,发现暂缓的那些功能在之后的几个版本也都没有精力去实现,被证明是看起来重要但实际上对核心流程没有关键影响的功能。 所以,每次当时间和任务量冲突时,保证时间,删繁就简,反而能确保你一直专注于关键事务上。

三、bug

  1. 修复bug这件事情,只有当收入大于付出的时候,才值得去做。
    三明治厂超频小bug的故事,是让机器带着bug运转3天,按照正常速度修复- 72个汉堡损失,还是加急现在修复但是机器要停机三天-4.5万美金的损失?

2)大部分时候,bug还带来隐形损失:公司和产品的名声。因此,还是值得去修复的。

3)修复bug的步骤:

1-尽可能地收集bug相关的所有信息
2-衡量修改bug的成本和收益
3-算出修复所有bug的价值
4-不要断章取义

4)忽略只出现一次的bug

四、干扰射击

1)步兵战中只要记住一条:干扰射击。不断一边前进一边射击,开火迫使对手多笔,这样他就不能向你射击;同时你不断越来越靠近,来离敌人越近,就越能打中目标。

2)如果你不断进取,不断写代码改代码,时间就会站在你这边。
3)当竞争者朝你开火的时候要留神,他们是不是在干扰射击,希望借此来降低你的速度?

所以,要关注的,永远是用户价值。不要被市场竞争或者媒体宣传,资本要求等等迷乱了视线。
产品经理,要做的事情便是掌握人性,带着善意去成就它。

4)对于我们这样的小公司,干扰射击意味着两件事情:一是一定要抓紧时间,把开发的主动权掌握在自己手里;二是必须每天进步。这样迟早会胜出。

五、针对开发者的非正式面试指南

1)简历上有语法错误的不接受
2)给候选人打电话,就某个编程问题聊上半小时 (想起培根的那句话,讨论使人敏锐)
3)现场真人面试:6人中,5人应该是他未来的同事。6人中有2人不同意,那么就不该过。
4)在面试中要避免将那些可能适合的程序员招进来,只能招“程序员中的巨星”。

这个会成为技术为核心的团队的要求,对于大部分企业而言,这个比较难。
软件行业瞬息万变,你需要的是有超强学习能力,什么开发任务都能胜任的人。

5)如何在面试中发现一个人是否聪明?你不需要向面试者重复解释一件事情,沟通进行得十分顺畅,候选者经常会妙语连珠,显露出独到的见解,深刻的思维或敏锐的直觉。面试官的作用是问开放式的问题,创造环境,让被面试者能够充分发挥。

问哪些问题:
1- 介绍
2-最近做过的项目
过程中,要关注:1.是否有激情;2.是否能将复杂的问题讲得深入浅出;3.在团队项目中努力寻找领导潜质
3-不可能问题 :比如,纽约有多少调琴师,重点考思路。
4-编程问题 面试的大部分时间都应该花在这个环节
5-你对自己的表现满意吗
6-你有什么问题吗?

不要问哪些问题:
1-违法
2-带有歧视/偏见的问题
3-脑筋急转弯问题

六、奖励有害论
1-成员对于尽责,自我成就,价值认同等方面的需求,会被误导量化为简单的奖励。
而物质奖励,是最没有忠诚度且边际效应递减的刺激。

七、揭开冰山之谜

  1. 用户界面只占开发工作的5%,而用户能感受到的,只有这5%。

一定要平衡好 这5%和剩余95%的进度关系,让用户能看到的,和实际开发完成的进度匹配。

  1. 把展示在用户面前的部分做的漂亮非常重要。有了漂亮易用的界面部分,用户才有可能来使用。

  2. 做产品演示的时候,唯一起作用的就是产品截图。一定要让截图100%完美,而不是让用户去想象产品。

4.掌控人们对于开发的预期:每周更新进度

八、吃自己做的狗粮

  1. 作为用户来使用自己的产品,找到不足,然后改变

九、凡是没有看上去那么简单,一定要先做好设计,再开始开发。

十、企业发展战略:

1)小而美,还是靠资本快速推动壮大至市场领导地位?

1.小而美:竞争对手多,没有网络效应,较低的用户粘度,用时间慢慢累积金钱,如本杰瑞
2.靠资本快速推动壮大至市场领导地位:竞争对手少,有网络效应,强用户粘度,用金钱换时间,如亚马逊

互联网企业的价值,和其用户的平方成正比。

所以第2类型公司,时间是关键。尽早覆盖尽量多用户并黏住,才能获得竞争优势。

最不可取的发展模式,就是在两者中摇摆。

2)先有鸡还是先有蛋:提供某种向后兼容的模式,要不提供很多鸡,要不提供很多蛋,先专注于做大一端,通过这一端来吸引另外一端。

3)转化竞争对手的用户成为自己的用户:找到所有转化障碍,并解决。

4)膨件和二八法则:

一般用户只会使用到20%的功能,可是每个人的20%都是不一样的。

5)开源软件:从微观经济学的角度来看,开源软件的发展并不是来自于企业的善心,而是降低配套产品成本,从而提升本身产品的销售量。

比如:对旅游景点的机票降价,刺激更多人到旅游景点消费,促进了景区经济增长。

6)微软是如何输掉API战争的:
雷蒙德。陈,旧闻新知博客( https://blogs.msdn.microsoft.com/oldnewthing/),披露了很多微软对于向后兼容(兼容更低级的版本,以及为这些版本操作系统所 开发的第三方软件)而做出的努力。

而MSDN派推出的longhorn,以及之后的版本,因为丧失了这种信仰。导致用户不愿意再来升级产品,开发者也渐渐不愿意再基于不断变化的windows来开发。

网络应用成为新的潮流,而不是windows 操作系统。网络成为了新的API。

十一:问答
1)强大的竞争对手推出了和自己一样的功能怎么办?

答:不用管竞争对手,只用关心用户的想法。

  • 一定有用户不知道竞争对手的
  • 尽快上线,通过用户的反馈来不断修正提升自己的产品,让用户愿意买单。(实际上,用户如果已经买了你的单,是不愿意再转移到其他产品上去的。)
  • 在产品上提供尽可能多的反馈途径,让用户很容易能反馈意见。(比如,在每个地方都能看到反馈入口)

2)关注“我不用是因为你们不能xxx“的问题,而不是我希望你们能够xxx。前者说明了使用障碍,后者可能只是一些与决策无关的想象。

3)预留缓冲时间时,需要考虑的几种情况。

  • 临时想到的新需求
  • 竞争对手带来的新影响
  • 把不同开发者的代码集成起来
  • 在测试中寻找并修复bug.
  • 雇员必须履行的与开发无关的行动
  • 由于时间预估不足而引起的缓冲
  • 某些任务没有提供预计的时间,所以需要缓冲

你可能感兴趣的:(《软件随想录(上)》读书笔记)