你讨厌公司什么样的“节约”行为？

它不是宝典，它教会我们在团队中在千变万化的一个个项目中发现问题，做出判断，解决问题。每一个项目中人都可以从中受益。

老板盯着考勤记录看，就会有人代打卡，直到换成指纹机。代不了了，还会“在上班时间剃上班时间长出来的头发”。

整体可打4星。适合作为手册，遇到问题时查阅。

整理此书每章参考文献。

沟通是很简单的事儿吗？

怎样帮助他而不被当作是“歧视”。

备选名字。

用数据、量化来考核绩效是一种管理者无能的表现。

20分的默认值已经用了很多年，现在提高默认分值，客观上造成专家分的“通货膨胀”。

这样一个版块或者空间是很有用的，利用好了，可以从用户那里得到很多有帮助的信息。

上周五，在公司里搞了“交换圣诞礼物”活动。

面对沟通障碍，与其花费大量精力让自己的表达更加傻瓜化，其效果远不如提供一个傻瓜工具（这里工具可以是一个方法、方式，step-by-step的步骤），让对方很容易地按你的想法做，达到你的意图，既然你已经把他当做“傻瓜”了。

在圣诞节即将来临的时候，这样一个小游戏也许能够使你的团队凝聚力更强，关系更融洽。

来自51testing的一个讨论。

http://topic.csdn.net/u/20090723/11/a51ddd7c-d76d-4df7-986c-d75b1bdbbe66.html

从事软件研发，现诚聘嵌入式开发C程序员若干。

工作性质：全职
工作地点：上海

职位描述：
1 嵌入式系统的应用层设计开发。
2 了解客户的需求，配合客户对UI进行调整。
3 解决系统中存在的问题，优化调整提高效率。

职位要求：
1 对学历还是有要求的，本科是必须的。专业最好是计算机及相关专业，不排斥任何专业的，只要你
2 对C语言编程有一定的掌握度。光学过一学期是不行的，考试得满分也不要很当回事。至少要做过一定数量的小玩意，经历过费解、抓狂、和解决后的痛快。具备一定的调试能力。
3 良好的表达和沟通能力。能用简单的语言把问题说清楚。会聆听。
4 团队精神和合作精神，对工作有热情。
5 较强的学习欲望和学习能力。要知其然，也要知其所以然。打破砂锅问到底，还要问砂锅在哪里。
6 不怕看英文SPEC，不怕和外国人说英语。

有意者请联系我。

青润发调查法帖关于如何看待日报周报，很多程序员的看法是日报很扯，周报也是流于形式，这是用来鉴定管理者无能的一个标准。正好javaeye上也有这么个讨论，摘选一些赞同的意见过来。

每周一次是不可行的，周五你能记得清周一干了什么？

虽然没硬性要求。我也每天都写。反正不怎么费事。

你确定你写周报的时候能回忆起这一周做什么事、花了多少时间？

认真写，促使你认真思考明天作些什么，上司可以粗略的安排任务，程序员应该精化工作，但一下子精化一周的任务有难度。

工作日记本身是个不错的方式，可以让自己自省每天都干了什么事情。我们有多大程度上了解自己每天都在干点什么呢？

坚持更重要。不能持久也比没有强。能坚持的管理肯定问题不大。太忙不是写不了日报的理由。

对自己的总结都写不出来，你还能证明你做了很多事情吗？

这证明很多程序员不做时间管理，做事情不愿意去思考如何更高效的完成，而只是低头去做，一个优秀的程序员，应该是能够高效把控自己的时间的。做好了时间管理，日志自然就出来了，没什么难度的。

日报不是乱报。

不要流于形式就没什么问题。

本不打算摘选反对日志的观点，但看到一个回帖里列举了不写的好处和写日志的坏处，挺有趣：
1.节约员工工作时间
2.避免员工把精力花在酝酿工作内容上面
3.节约管理层查阅日志的时间
4.节约存储空间节约电能
5.写更少的日志做更多的事情
6.降低员工的工作的兴趣
7.降低员工的工作热情
8.容易打断技术人员的思考
9.通过日志会错误了解员工工作情况而导致管理层做出错误判断
10.日志不如周志，周志不如月志，月志不如年志，年志不如不志
11.写日志意味着要在显示器面前呆更多的时间，遭受更多的辐射，加速员工衰老速度
12.空洞的日志，不如实际有效的工作
13.与其让员工自己写日志，不如管理者每天为员工的工作做评价
14.写日志更容易造成泄密，不利于公司内部竞争
15.世界500强中没有几家要求员工写日志的，只是一些学院派的人指定制度让员工写日志
16.写工作日志能提高写作水平纯粹是鬼话，每天都写那些套话空话怎么能提高写作水平
17.最后一句，喜欢写日志的人绝对不是什么好人，提倡写日志的人必然是黑心肠的
18.企业管理者，爱员工的表现之一就是不让员工写什么工作日志，当然不让员工写日志的企业管理者更容易受到员工的尊重

也有不少人觉得，每天早上有个10分钟到15分钟的stand meeting比日志更有效果。

很多时候，人们并不打算为其口头的表述承担责任。因为“说得轻巧”，往往就脱口而出。

事后如果出了问题，可能确实记不确切自己曾经是如何说的，也可能不承认的效益更大。

而人们对于必须写下来的东西，会慎重很多。其程度是纸笔写下 > email/电子文档 > 口头表述。

所以在承担责任的扯皮中我建议无论接受上级的任务指派，还是和其他同事关于工作内容的交流，使用email。

重要事宜，打印，签字。

如果同事不愿意回复email，只是口头传达。告诉他口头之外，再发一封email，以免你遗忘。发给他的询问email同时cc给你的上级和他的上级。

组织结构：

Z是内容部员工，B是技术部员工，A是B的上司，同时也是总管。就是说，A也是Z的上司。

事例：

一个特殊任务，A口头告诉Z可以使用免费代码，具体代码问B。

Z口头问B，B口头告知是F代码。

Z使用了F代码。

次日，发现出错了。

A追究是Z做错了，先声称自己从来没说过可以这样做。

Z回答B告知使用F代码。

A说B称从未说过。B事后称其说的是FX代码。

怎么办：

1）与B当面澄清，是否有曾去询问一事。有则是如何回答的。

2）以后，对于上司口头交代的任务，听完后说：“好，我知道了，请你再发一封email给我。”如果不愿意发email，就把接受到底任务写一封email发给上司，问他是这样吗。发出后电话或口头告知。

3）对于在和其他部门同事合作中，任何需要对方确认的事，务必使用email。记录下合作过程中每个人对自己的工作内容所做的判断和选择。