今天不聊技术，聊聊如何成为一个靠谱的软件从业人员

开发

一个开发靠谱不靠谱，有一个简单的评判标准：estimation[估点]是靠谱的。
如果估点是靠谱的，这个开发就是靠谱的。
我给你一个需求，你说三天做完。那好， 三天你能做完就可以了。
只要你说的这个数，偏差不太大，那么你最终和你实现出来的偏差不太大，而且拉平均水平看你的数不是很低，中上， 那这个员工就是一个很合理的员工。
为什么使用estimation来作为判定标准？
因为只有当这样的时候，你跟我说你的时间，我认为是可控的，我可以基于你的信息，去做我的计划。

估点是项目推进的一个基准。
缺乏合理的时间进度是造成项目滞后的最主要原因，它比其它所有因素的总和影响还大。
良好地烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

estimation准确，是一件不容易的事。能做到这一点的员工，他需要有良好的工作习惯。

1. 拿到任务后，先做tasking[分解需求]。
   在没有理解清楚需求是什么的时候，不去进行工作。
   因为去工作是对时间的浪费，他的任务可以分解地很细，所有的东西加在一起，给出你一个相当靠谱的评估。
   当你给他这个时间的时候，他可以把这项工作大致地做完。

我们不要小看tasking这件事情，这是一项非常困难的技能。
需要经年累月的训练，你才能够做出一个非常完整并且是有效的这样的一个划分。
当你得到非常完整并且有效地划分，我们就可以进行下一步，你每一项任务的时间不能超过一小时或者四十五分钟。
那么在这之上的时候，通过累加放在一起的时候，就说好，我大概这么长时间做完。

由于编程人员通过纯粹的思维活动来开发，我们期待在实际过程中不会碰到困难。
但是，我们的构思本身是有缺陷的，因此总会有bug。
关于进度安排，我的经验是1/3计划、1/6编码、1/4构件测试、1/4系统测试。 计划、编码、构件测试、系统测试的时间比例是4：2：3：3

作为一门学科，我们缺乏一套普世的数据估计标准。
我们对自己的估计技术不确定，因此在管理和客户的压力下，我们常常缺乏坚持的勇气。然后管理者会错误的认为编程人员的估点是有水分的，要时不时再压一压。

2. 工作习惯就是我不清楚我现在干什么，我就不做。
   做到一半，如果有问题，超出我的时间了，求助。
   求助，我多没面子，好像我不会做一样。但是这是建立在你尊重公司、尊重客户、尊重团队其它人的时间的基础上，形成的工作习惯。
   那么你在这样的时候，我认为这样的人是可以合作并且是值得依赖的。

一个不靠谱的团队，连累开发也不靠谱。
人月神话对估点的描述及时间比例。

管理者

靠谱的管理者各有各的靠谱技能，但不靠谱管理者的特征是一样的：只会管理工作时间

我们在管理的时候只能管理一个三角：

• 管理工作的产出物
• 管理你的way of thinking【工作方式】
• 管理工作时间

1. 管理工作的产出物
   对于知识型工作的产出物需要一个周期。就软件开发而言，就是你上线发布的周期，那么它可能是以周，如果是理想情况下。甚至是以月和年为单位。
   那么这时候以月和年为单位，对于管理者来讲，他很难去控制其中的具体的内容。

2. 管理工作方式
   管理工作方式需要把你的工作从一个黑盒化的状态打开，变成白盒，看到里面是如何工作的。这个过程需要大量的现场管理经验。
   这对管理者有以下两个要求：第一是非常有经验，第二是他仍然能够进行一线管理。
   这就需要这些管理者， 他本身也是一个专家，然后有很深的一线经验才可能对他的工作方式进行管理。
   而这两个方法通常都不具备，一个是周期太长，一个是这个管理者，如果他本身是个无能的管理者的话，他本身既不专业，他也已经丧失了一线管理能力。
   那唯一剩下的就是只能去管理工作时间了。

所以当我们看到某企业或者是某个团队，把重点放到对于工作时间的管理上的时候呢，那其它我们已经知道了，我们的管理者已经处在这种无能的状态了。
因为他既不能有效地以更短的时间以一个有效的周期去管理工作的产出物，又不能打开工作方式里面，去明确的管理我们的工作方式，进行有效的一线管理，
那他只能把所有的希望寄托于对于时间的管理。
所以这是软件开发是知识型工作的一个很自然的推论：无能的管理者只会管理时间。
因为对于知识管理者来讲，只有专家级人物才能去管理，才能去管理你的工作方式，只有专家级人物才能够明确地控制你的知识的消费，让你的产出物在一个有效范围内能够拉动的工作方式的这样一个改变。
而这两个方面都不具备的人，他才会把他的注意力和时间，集中在时间管理上。
所以这是一个非常简单的判断，任何你在的公司，当它强调时间管理的时候，
那对不起，你碰到了一个无能的管理者，

当然，这个推论也适用于其它的对知识型工作的管理，譬如父母对于孩子的管理。无能的父母只会管理孩子用于学习的时间。

黑盒：你使用一项功能，会用但是不知道怎么实现的，原理如何。你把它看成盒子，里面对你而言不可见，用黑色表示。黑盒复用其它是功能复用。
譬如消费手机，就属于黑盒使用场景，你不需要知道手机由那些零件组成，以及这些零件是如何协同工作的。
譬如Office办公软件，也是黑盒，你不需要word、excel、ppt这些软件内部是怎么工作的，只要学会使用功能就可以了。
白盒：你知道功能的原理逻辑和流程，内部对于你可见，用白色表示。白盒复用其实是知识复用。

团队leader

一个团队的Leader到底是不是靠谱，有一个非常简单的判断方法：
有办法保证团队成员在85%以上时间，focus在各自实际产出价值的工作上。

首先这个leader需要明白自己的定位：你的存在是最大化团队的生产效率和最大化团队的这个价值。
他的第一个出发点就是他是否尊重团队成员的工作时间，这是一个非常简单的判断标准。
如果你作为一个团队leader，你没有办法保证团队成员在85%以上时间是在他们自己实际产出价值上的时候，那这个leader就是完完全全地失败。
那么大家可能会很疑惑，那我怎么判断是不是95%以上呢？
很简单，对于一个开发团队而言，如果以一个星期40小时工作来判断。
如果你的leader不能保证你的团队成员有32个小时以上的时间是工作在他实际写代码产生价值的工作上，那这个leader就是不成功的。

BA

以终为始，能够区分有效性和效率，聊需求时，先聊有效性。

知识型工作的效率和有效性是不能区分的，你首先要有效，之后才有效率。
有效就是一个被消费的时候，才能够验证你是否是有效的。
举一个例子，我一个BA，你给我按照他一天写100个story，你说你效率更高吗？
不会，因为他写出100个story，然后上线,这些feature可能根本没有人使用。
所以谈效率，先谈有效性。