有成效的工作

 从开始上班起，听到过工作是做不完得。

大概的意思，现在的工作做完了，就会分配新的工作。所以总也做不完。

如果是做不完的，那么是不是在一个岗位上就一直干着呢。既然这个很难成立。那其实工作是可以干得完的。

一个岗位的终结，是已经在此岗位上没有新的获得了。报酬不在这个获得之内。毕竟，对于知识型工作。不是求得一个报酬而已吧。

每天除了活，更是贡献，是成长。 

有一次，我说今天要给谁讲什么，要跑什么，这是对一个问题的回答。怎么让时间利用。

但是，这好像没有形成共鸣。跑了什么，讲了什么，其实都是可以重复的。

如果不重复，那么是，这次，怎么讲，下次怎么讲，这次怎么跑，下次怎么跑。

怎么做，胜过做什么。怎么做是体现唯一无二的价值的地方。做什么，那其实每个人都一样。

做什么，是被告诉的，怎么做，是自己要做什么。 

上午要给人讲那个，等会要学习一下。下午跑一个仿真出结果。晚上再讨论一下另一个事情。

从这些安排里面，真的，就是满满当当了。

好像没有任何可以下岗的理由。

后来看德鲁克的卓有成效的管理者。发现，最重要的是要有成效。担任一个职务，履行正常的职责，与创造业绩并不一样。

业绩应该是可以看到效果的。而非看到行为。行为必然作用在一个客体上，使得客体的行为发生改变。这是效果。

将流程跑完，有了结果，非常好。

将代码写出来，有了结果，非常好。

但是这种非常好是自己的感觉而已。

回过头来，这是流程，代码，产生了何种效果，是否有人利用该流程，这些代码做出一些什么来。如果流程生成的结果，给到下游，产生了很好的反馈。如果代码，经下游验证，发现没有什么问题。我想，这是真的好。

进一步来讲，这个出来的成果，放到市场那边的人看来，是何评价？如果帮助提高了竞争力。那么很好。

有些评价，是专门说的本人做了多少代码，发现多少个bug。但是，如果还有一个关键bug没有发现，如果写出来的代码并没有好的收敛，都不是好的成果。

首先谈效果，没有明显的bug被发现，代码交付流畅。然后再来谈工作量，难度如何。

我想这才是有益的评价。

所以，干事，不能先想干了多少，而不想干了何用。应该顺序上反一下。

不只是先后的问题，往往，在难度上，满足它人的需求，是比自己的工作量提高更有难度的。

满足它人要求，首先考虑一下形式。

一个平台，也许可以洋洋洒洒讲很多遍，但是却不一定让人知道怎么用。也许，怎么用，对人来讲是最重要的。

一个优化项目，优化的原理也许可以说很多，但是优化要做的事情，却可能一件都做不成，因为时间上，复杂度上，别人会觉得不能接受。

所以，首先考虑交付的条件，别人的需求，从这出发，才好决定哪些地方投入多一些，哪些地方投入少一些。

因此，所谓做事，应该还是多多从外部出发好。

开会，讨论，为了解决对方的一个问题，或者困惑。

debug，为了尽快交付。

搭建平台，为了易用，功能更强。

如此，主要还是从别人的问题出发的。