大头
Table_bottom

标签云
Table_bottom

分类
Table_bottom

日历
二月
28293031123
45678910
11121314151617
18192021222324
252627282912
Table_bottom

评论
Table_bottom

留言
Table_bottom

微博
Table_bottom

热门文章
Table_bottom

随机文章
Table_bottom

豆瓣上谁关注这里
Table_bottom

链接
Table_bottom

搜索栏
Table_bottom

RSS
RSS Link
Table_bottom

功能
Table_bottom

页面
Table_bottom

计数器
462735
Table_bottom

访客统计
Table_bottom

存档
Table_bottom

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

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

阅读全文

镜子

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

阅读全文

有意思吗

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

阅读全文

《项目经理应该知道的97件事》读后评论

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

阅读全文

《门后的秘密》参考文献列表

整理此书每章参考文献。

阅读全文

怎么问为什么?——团队里的Y君之二

沟通是很简单的事儿吗?

阅读全文

一件小事引发的辞职——团队里的Y君

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

阅读全文

项目起名

备选名字。

阅读全文

关于量化考核绩效

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

阅读全文

说说CSDN的发帖默认分值调整

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

阅读全文

说说CSDN个人空间的“客服”群组

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

阅读全文

交换圣诞礼物

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

阅读全文

傻瓜式沟通

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

阅读全文

团队游戏——交换圣诞礼物

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

阅读全文

关于自动测试工具

来自51testing的一个讨论。

阅读全文

看一个项目经理是如何协调与测试团队的关系的

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

寻找C程序员

从事软件研发,现诚聘嵌入式开发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。记录下合作过程中每个人对自己的工作内容所做的判断和选择。