一 、乔尔测试
1.你们用源代码管理系统吗？
git 神器
2.你们能一键编译吗？
这个要去研究一下
3.你们做每日编译吗？
这个要去研究一下
4.你们有bug数据库吗？
有
5.你们在写新代码前修改以前的代码吗？
在做开发规划的时候，要预留修改以前代码的时间，而不能只是考虑到不断叠加新功能。
6.你们的进度表是最新的吗？
每周的进度更新是必要的，这样才能知道每月的计划能否顺利完成。我们有最新的每周进度。
7.你们有软件规格书吗？
就是我们的产品设计文档。产品设计文档，原型修改5遍，也好过代码开发出来了再推到重来。
没想清楚产品细节之前，不要开始开发！
- 程序员的工作环境安静吗？
远程工作者可以选择自己的工作环境
9.你们使用了能买到的最好的工具吗？
可以有
10.你们有测试人员吗？
3.1以前都是产品经理同时负责测试，3.2以后要引入专业的测试人才，提升测试完整度。
11.你们面试时会要求应聘人员写代码吗？
可以有。
12.你们做过走廊可用性测试吗？
在做，且必须做。每次要提供不同版本让用户来比较体验，并给出反馈。
感觉上，乔尔十多年前提到的这些，已经逐步成为开发团队的标配。
二、软件功能规格书
- 为什么要写：
- 提高研发效率：能够在开始研发之前设计好软件，在设计的时候就暴露所有可能的逻辑问题可用性问题从而调整，而不是在研发的时候，从而大幅度提高效率，降低研发损耗。
- 提高对合作伙伴的沟通效率： 便于设计，测试，运维，客服，运营等等合作伙伴来学习和了解软件，而不用把所有内容都用一遍同时还要打扰程序员不断追问，才知道这是什么，该怎么用，有什么效果。而合作伙伴会面向用户，告诉用户这个软件该怎么用。
- 没有规格书，就无法制定进度表。
- 什么是规格书？
- 概述： 这个软件是做什么用的
- 使用场景：产生需求的经典用户场景是什么，软件如何帮助用户解决问题。
场景
书摘：
从你产品的使用者中，选取积累代表性的目标用户群，为每一类虚构一个想象中的、但完全典型的用户。场景越生动，逼真，你设计出的产品就越适合用户使用。(http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html)
思考：
这于我而言是新颖的部分。以后可以考虑在产品文档里面也加上场景说明部分。
有用户场景的需求才应该被重视和开发。
如果一个需求仅仅是个人臆想出来，找不到现实场景，那么不应该投入开发计划。
比如说尝试给ping这个功能写一下用户场景：
开发者Jack经历了3个月的紧张工作，总算如期交付了公司要求的新产品。接下来是测试，运营推广的事情了。预计会有差不多2周到1个月的相对空闲的时间，于是他到了客栈上，想看看最近能不能接到一些不错的兼职。
他会尝试去联系客栈的客服，标明自己现在比较有空，想要接单。
同时，由于团队是按周来规划任务的，他对于一周后会不会有新的开发任务并不是特别有信心，因此他希望这个最好是本周内可以接到比较短期快速的小任务。
因此，他可以使用Ping这个功能。
点击Ping, 他可以登上当天程序员列表的首页，让潜在的雇佣方有更多机会看到他；第二天他如果依然有空，可以继续Ping;如果没空了，可以不再操作，甚至点击“接单”按钮，切换到不接单状态。
另外，Ping也会影响自动对接排序，他的排序马上会靠前，而这个影响因子会在未来七天衰减，到第8天衰减为0.
Ping功能
- 非目标：本软件本次不计划做什么
这个我们目前也没写过。目前只写了要做的内容，不做的内容不写，放到待规划不分区，留待以后规划。
- 流程图
- 每个页面的功能规格说明（概述，细节）
- 本次不解决的问题：这些一般都是基于已经考虑到，但降低了优先级的问题。
- 多角度注解：技术注解，营销注解等。
这个也很新鲜。目前我的产品文档里面，只有产品注解。
技术注解，营销注解都没有做过。
7.如何招到靠谱的项目经理
- 不把程序员提拔为项目经理：优秀的项目经理需要具备的素质：文笔清晰，外交手腕，市场嗅觉，用户视角，以及优秀的界面设计能力。和优秀程序员的能力发展路径不一致。
从描述来看，这个其实是产品经理和项目经理职责的融合职位。不仅仅是目前我们理解的项目经理而已。
- 不要让营销人员做项目经理
不让程序员听命于项目经理：项目经理应该通过证明项目本身值得去做而赢得程序员的支持，而不是靠地位优势，行政命令。
8.轻松掌握项目进度
- 只有最终写代码的人能够预估需要多少时间
- 适当细分任务，保持合适的颗粒度（小时）：通常的规则，任务的颗粒度应该在2小时-16小时之间
- 如何提升项目预估精准度：只做开发人员的预估/实际开发时间对照表，斜率越小，误差率越高。最好是斜率为1.把节假日，调试代码的时间，集成的时间，缓冲的时间都考虑在里面
- 永远不要让开发经理压缩程序员的时间
- 开发Excel5时，为了保证上线时间不得不把一些功能暂时延后到了以后版本。然而之后回顾，发现暂缓的那些功能在之后的几个版本也都没有精力去实现，被证明是看起来重要但实际上对核心流程没有关键影响的功能。 所以，每次当时间和任务量冲突时，保证时间，删繁就简，反而能确保你一直专注于关键事务上。
三、bug
- 修复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-成员对于尽责，自我成就，价值认同等方面的需求，会被误导量化为简单的奖励。
而物质奖励，是最没有忠诚度且边际效应递减的刺激。
七、揭开冰山之谜
- 用户界面只占开发工作的5%，而用户能感受到的，只有这5%。
一定要平衡好 这5%和剩余95%的进度关系，让用户能看到的，和实际开发完成的进度匹配。
-
把展示在用户面前的部分做的漂亮非常重要。有了漂亮易用的界面部分，用户才有可能来使用。
-
做产品演示的时候，唯一起作用的就是产品截图。一定要让截图100%完美，而不是让用户去想象产品。
4.掌控人们对于开发的预期：每周更新进度
八、吃自己做的狗粮
- 作为用户来使用自己的产品，找到不足，然后改变
九、凡是没有看上去那么简单，一定要先做好设计，再开始开发。
十、企业发展战略：
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.
- 雇员必须履行的与开发无关的行动
- 由于时间预估不足而引起的缓冲
- 某些任务没有提供预计的时间，所以需要缓冲
网友评论