900字范文,内容丰富有趣,生活中的好帮手!
900字范文 > 体力劳动?脑力劳动?

体力劳动?脑力劳动?

时间:2023-09-11 14:22:42

相关推荐

体力劳动?脑力劳动?

在开始之前,首先我要说明一下,体力劳动和脑力劳动并不是绝然分开的。体力劳动中也需要脑力劳动,并且很重要,一个例子是中国足球,按说足球运动是典型的体力劳动,但人们还是批评中国足球运动员不会用脑子,常常犯匪夷所思的错误。而脑力劳动中有体力劳动,这应该是不用多说了,以前设计人员常常带个板尺,铺开一张白纸开始画图,那一天下来是腰酸背疼的。现在有电脑了,打键盘,移动鼠标也是体力活啊。所以这里讨论的是哪个量多一点,哪个占的比率高点。

会议记录

我们先拿一个最简单的工作,也与IT领域关系不大的,会议记录员。在开会的时候把那些有价值的东西记录下来,这听起来简单,但并不容易。如果你只把会议结束时某个人总结的那几点记录下来,这只能是平庸的工作业绩。会议中有价值的东西非常多,包括那些达成共识的,暂未达成共识的,某个人瞬间闪现的灵光,互相激发的创意。有心人会在会议中拾到很多财富,把它们记录下来,那就是公司的财富。这些工作需要你动脑子,用心去做。你必须听得懂它们的发言,可能某些地方还需要事后的沟通,甚至在会议中你也可以插上一两句提问的话。这样你的价值就得到体现,一篇伟大的会议记录就出来了。

写代码

言归正传,我们讨论软件开发以及软件公司里各种职位。先讨论一个名词:代码工人,相关的还有软件工厂等。在我们的观念中,工人从事的是体力劳动,工厂是流水线作业。那么软件工人就可以理解为干体力活。是这样的吗?软件工人只需要按照设计文档来写代码,不用怎么耗费脑细胞吗?如果真的能这样,我相信马上就会有公司开发出一套工具,把软件设计中的符号转化为代码,或者把一些基本的功能做成最底层的模块你只要把设计翻译成一种配置文件即可。这样的趋势很明显,最新出来的开发工具,模块框架已经把那些需要重复劳动的工作压缩到最小。他们总是声称:剩下的你只要关注业务逻辑即可。也就是说,那些业务逻辑是需要你动脑子思考的。

一种可以说是“常识”的事实是,需求分析人员和设计人员不可能把所有底层的东西给你弄出来,就算弄出来了,也不可能清晰的表达出来。除非你的设计不用那些人类语言或者图形符号,直接用编程代码写出来。因为,编程代码是最准确的。但是,这样还需要代码工人吗?

文档撰写

我们经常犯的毛病是把脑力劳动做成了体力劳动。自我调侃,我那破工作,其实就是打杂的。你不能体现你的价值,自然就是“打杂”的了。那些需要写文档的,最会产生这样的想法。一个文档呼哧呼哧写出来后没几个人看,看的人也是一目十行的就结束了。特别是按照某种软件工程理论制作出来的文档,写的人也烦,看的人也累。真正价值高的文档,甭管是什么类型的文档,就如论文质量以被引用次数来衡量一样,看的人越多,越频繁,价值就越高。

Ivar Jacobson博士他的”Be Smart!”演讲中给出的方法是“只写重点”。那些大家熟悉的,可以自己想象出来,或者推理出来的内容可以砍掉。这就是为什么十年前有很多介绍操作系统的书,比如《Window xx指南》,《Window xx入门》类似的书,现在却少见了。那是因为大家对计算机操作系统很熟悉了,用不着看帮助文档了。谁还会打开WindosXP中的帮助中心,来看看怎么复制一个文件夹呢?

文档需要能够做到“增值”。“增值”就需要文档撰写人员的用心,也就是脑力劳动。把不能产生价值的东西删减,把主要精力用在人们容易糊涂的地方,或者容易忘记的地方。比如你觉得这个地方需要再三强调,就用粗体字显示。你甚至可以把最易犯的错误给写到下面,或者画个小人,套个黑边。这些创意会让看的人很开心,印象深了,自然收获就多了。

代码注释

注释也需要“增值”。好的代码注释并不容易写出来。不要以为写注释是辛苦劳作后的休闲运动。我看过很多淡而无味的注释,看与不看没什么区别。我也看到过优秀的注释,看后基本不用看代码就一清二楚了。常见的好的注释方式是:举例子,原因分析,实现原理以及阅读和维护建议。这些分别适用不同的情形。有些地方你不用废话,直接写个例子就OK, 看的人会非常感激你的。当一个地方的代码变化多的时候,你可以讲故事,把这里的需求变化历史给叙述出来,加上必要的引用链接,它的价值将相当的高。是不是有些涉及到认知和心理方面的学问了呢?

软件工程理论的应用

中国教育体制下的学生们,不太爱好动脑子,不太适应创新思维。我们很多人承认这点。一种典型表现就是对理论的生搬硬套。Ivar Jacobson在他的博文中批评了某些人在项目中关注“某种软件工程理论的标榜”胜于“一个伟大的软件产品”。这说明国外也有这些现象。但毕竟大多数的理论都来自于国外,比如敏捷,比如RUP,这说明了他们还是敢于质疑别人,还是在不断的思考。

那些流程工程师犯的常见毛病是对具体项目状况的漠视和对最后产品的漠视。他们坚持按照理论去执行,去要求别人。他们不去思考理论推理的各种假设。一个项目涉及到的东西绝不仅仅是软件工程理论。它还要涉及各种各样人的因素,技术因素,文化因素,合同,利润,老板的目标和对目标优先顺序的考虑。照搬理论等于放弃思考。那些顶着完成任务巨大压力的人是有真实苦衷的。

需求调研

还有一种职业的人容易产生认知错误,那就是做需求的人。初入行的人,最容易把需求分析做成体力劳动了。他们把时间花在需求文档和频繁的客户沟通上,而忽视了本身对需求的分析,自己可能的价值就没有了。完全让客户拿主意做决定,实际上也是放弃了思考。客户忙的时候会觉得很烦,就算客户有大把的时间,替你想出一个解决办法,但当最终证明这样做有问题时,客户虽然对自己的错误不能说什么,但还是不太舒服的。那何不自己在第一时间去想出更好的办法,去提醒客户,或者去让客户参考,从而做到双赢,让时间更短,代价更小。最提倡的做法是,你去想出几种方案,让客户选择;在没有多少疑问的细节方面,只要让客户过目批准即可。懒得动脑子,乃人之共性。客户省心了,自然满意度就高了。你耗费了一些的脑细胞,收获的却是更有价值的经验和知识。

大牌的分析师都有一个助手或者秘书,他们自己思考,提供解决方法和创意,秘书们负责记录和整理出来。我们最终的目标是做那个分析师,而不是秘书。

想想现在的软件系统吧,想想现在人们的工作方式吧,二十年前,人们还在用无数的纸质文件工作,而现在每人前面都有一台电脑了。这种改变不是非IT人员能想象出来的。IT可以贡献出效率更高的工作方式,IT可以创造和引导客户的需求。谷歌的邮件系统并没有来找我们调研,但它出来后我们还是喜欢上了。

总结

IT的目的就是用来消灭重复劳动,提高生产率的,所以在IT行业里,你要是觉得自己的劳动是体力劳动,重复劳动,那是很讽刺的。在IT行业里工作应该是有趣的,灵动的和不断进步的。

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。