软件开发的人文关怀
- - 博客园_知识库 几年前，我从温伯格的《技术领导之路》中学到一点：技术人员往往更喜欢和机器打交道，因为他们“认为”自己更适合和机器打交道；但是，优秀的技术人员必须（也必然）具备好的沟通能力. 所以，温伯格鼓励各位技术人员多加练习和其他人打交道的能力. 温伯格的这个观点我是非常赞成的，好的技术人员一定需要“勇敢”面对他人，不能被“自实现的预言”局限在机器的世界里.
软件开发的人文关怀
标签：
软件开发
人文关怀
| 发表时间：2013-02-27 14:02 | 作者：黑板报值日生
出处：http://www.geekpark.net/
作者： 黑板报值日生 / 产品观察家
我是极客公园黑板报认证值日生。搜罗好内容，分享给大家。
[核心提示]软件可以没有活力，而软件开发却不能没有活力；程序可以像机器一样，程序员却不能像机器一样。要改变这种状态，就应当增添更多的人文关怀，把开发人员当成活生生的人，而不是视为程序或者工具。
编辑注记：本文来自余晟的博客 乱象，印记。作者从自己的经验出发，提出了一些给软件开发人员提供人文关怀的可行措施。
几年前，我从温伯格的《技术领导之路》中学到一点：技术人员往往更喜欢和机器打交道，因为他们“认为”自己更适合和机器打交道；但是，优秀的技术人员必须（也必然）具备好的沟通能力。所以，温伯格鼓励各位技术人员多加练习和其他人打交道的能力。温伯格的这个观点我是非常赞成的，好的技术人员一定需要“勇敢”面对他人，不能被“自实现的预言”局限在机器的世界里。
不过我也发现，“技术人员（当然我主要说的是软件开发人员）不适合跟人打交道”的负面影响不止于此，它还成了一种刻板印象（stereotype），进而影响到开发团队之外的人。这个问题其实很严重，它会导致其他人和开发人员沟通时自觉或者不自觉地切换到“和机器沟通”的模式上来， 比如单纯依赖邮件而避免见面沟通，比如“你只管这么做出来就好了，别管我用来干什么”。以面向机器的模式来与人沟通，结果往往是完整的项目（而不是狭义的“软件项目”）割裂开来，皆不欢喜。
这种情况我一直在思考，究其原因，一方面是组织不够完善，另一方面，软件开发也缺少人文关怀——软件可以没有活力，而软件开发却不能没有活力；程序可以像机器一样，程序员却不能像机器一样。要改变这种状态，就应当 增添更多的人文关怀（这里要多解释一点，“人文”其实也可以叫“人性”，它与“文”并没有太多关系，只是“人性主义”约定俗成翻译成了“人文主义”而已）， 把开发人员当成活生生的人，而不是视为程序或者工具。
当然，做到这一点并不容易，因为许多人印象里，软件开发人员就是“闷瓜”（充其量是“闷骚”），不好捉摸也不好打交道，那么干脆把他们当成工具来对待好了，“人性化”这样高难度的处理还是免谈为妙。但是事情并没有这么简单，因为不善于沟通，并不意味着开发人员不在乎人文关怀，想法，绝大多数人内心其实是愿意接受而且认可这些关怀的。只是因为许多开发人员不善于表达，因此并没有太多资料研究和论述软件开发中的人文关怀（或者开发人员真正在乎的人文关怀），所以这个话题值得一说。
按照我的经验，以下几个方面都是软件开发人员比较在乎，而往往被其他人所忽视的，所以要增加软件开发的人文关怀，不妨多注意。
开发环境
这里说的“开发环境”不是指的IDE，而是开发人员所使用的软硬件。这类设备是大多数开发人员唯一的生产工具，它们的好坏直接决定了开发人员的生产效率。可惜，许多人似乎并不理解这一点，很多公司只给开发人员配备普通的办公电脑，于是开发人员也只能贡献出普通办公人员水平的程序。目前来看，硬件上有比较大的内存（8G以上），多台显示器（最好其中一台可以很方便地旋转），有用起来顺手的键盘鼠标（这点非常重要），软件上有无障碍访问Google的线路，健全开放的代码库等等，应该是必须的配备。提供这些条件，一方面可以切实提高工作效率，另一方面，可以大大改善开发人员工作的心情。后一点看起来无关紧要，却体现出对开发人员的尊重，其影响甚至超过前一点。
内部交流
我见过许多开发人员，即便是与旁边或者对面的同事交流，也不愿意说话，而喜欢在IM上打字，这样的效率非常低，更厉害的是造成隔膜——上班时间都没话说，下班时间就更没话说了，想要形成有凝聚力、配合默契的团队，就始终只能是美好的愿望了。所以，日常工作中一定要鼓励面对面的交流，（尤其是多人参与的讨论，可以专门安排地方交流），以逐渐形成面对面交流的行为习惯。
不少开发人员即便自己比较闷，内心也不排斥甚至渴望活跃热烈的工作气氛。我曾经遇到过一名水平不错的程序员，他虽然不擅言辞，却不喜欢大公司内“死气沉沉”的技术部，更愿意呆在人人都愿意说话，人人有话说的小团队。现在，我们部门的开发人员经常会为了一些问题三五成群地交流，并不影响其他人的工作，这种气氛还很受大家喜欢。这些例子都说明，对开发人员而言，当面对话其实是非常必要也非常合适的交流方式。
工作意义
我曾说，程序员职业素养的体现之一就是对业务的了解。现实中，确实有不少一些程序员对业务不够了解，不过程序员对业务没有足够的热情只是一方面原因，另一方面，业务部门不愿意让程序员详细了解也是常见的情况。
许多公司的业务部门需要开发力量时，既不描述项目的背景，也不介绍项目的意义，只生硬地扔过来几份文档（而且很多是粗制滥造的文档），就完成了对接。究其原因，有时候是这些人将程序员视作简单的“码农”，认为他们不需要了解业务，只需要写代码即可；也有写时候是因为程序员思维比较严谨，遵守逻辑，而不少业务部门的人缺乏这类训练，表达想法和需求时如不够严谨细致，更习惯“看一步算一步”的野路子。
前一种情况是态度上的不尊重，后一种则是能力上的欠缺（或懒惰）。但无论是哪种情况，都会给开发人员造成非常不好的影响，最终结果就是项目的支离破碎，大家都龟缩在自己的地盘上，“铁路公安，各管一段”。
其实按照我的经验，绝大多数开发人员并不排斥理解自己所开发的软件的实际应用和意义，以此为基础，大多数人甚至有兴趣去提出改进方案，这其实是非常好的状态，其前提是，需要为给程序员提供足够多的空间和机会去理解自己工作的意义，而不仅仅是告诉他们“你只管这么做就好了，别问我为什么这么做”。
个人成长
“一个人要怎样才愿意呆在一家公司？”一位前辈告诉我的是：如果这个人觉得公司有前途，自己也有前途，就会呆下来。这个答案我非常认可。但是在实际工作中，后一个“有前途”往往被忽略了。
在软件开发中这个问题更严重。一方面，开发人员经常被视为生产代码的机器，大家只关注他提交的程序，而不关注他是如何提交程序的，在工作中有什么收获；另一方面，很多开发人员对于前途常有持续的焦虑，又得不到解决。常见的结果就是开发任务显得冷冰冰、硬邦邦，开发人员也感觉自己做的都是简单重复劳动，产生倦意甚至抗拒情绪（我知道许多人会说，要想成为一名好的开发人员，就应当在简单重复劳动中精益求精。这个道理确实没错，但也需要有合适的切入点，换句话说，应当让开发人员认可精益求精的价值，并真切体会到它带来的好处）。
其实，有许多开发人员对自己的未来是有所打算的，比如有些人可能希望更了解业务，有些人希望更深入钻研技术。技术团队的领导平时应当能抽时间了解这些设想（如果能加以建议或指点就更好了），在 安排新工作时有所照顾和侧重，这样，开发人员就可以感觉到自己的成长，觉得自己的工作是有前途的，工作起来也更有积极性。
许多年前我读到董乐山先生翻译的《西方人文主义传统》，心里从此深深打上了“人文主义”的烙印（也由此知道了“人文主义”其实和“文”没什么关系）。经过这些年来的工作和思考，我又认定软件开发和其它工作并没有迥异的差别，既然其它行业可以提倡人文关怀，引入更多的人性化因素，软件开发也可以这么做。因为软件开发的特殊性，找到开发人员认可的“人文关怀”可能难度更大一些，但并非不可能，而且相当有意义。
极客观察均为极客公园原创报道，转载请注明原文链接。
原文地址： http://www.geekpark.net/read/view/173178
关注极客公园，即时获得最新内容： Twitter | 微信：极客公园 | 新浪微博 | 花瓣网 | 人人小站 | Google+ | 点点
相关 [软件开发 人文关怀] 推荐：
移动搜索的人文关怀
- - 百度MUX人文关怀是指尊重人的主体地位和个性差异，关心人丰富多样的个体需求，激发人的主动性积极性创造性，促进人的自由全面发展. 移动设备作为用户私密化的产品，其中的app更像是一个个亲密的朋友，它们能友好的帮助你获得信息，陪你玩游戏打发无聊的时间，失眠时还能唱歌助你入眠，及时提醒你需要完成的工作计划，方便的让你与远在天边的好友亲密沟通…你的这些好“朋友”里是否有移动搜索呢.
软件开发的核心
- - 博客园_知识库 「我们一直这样做开发，时间做久了，便忘了当初的本意. 有关软件系统开发，我们谈些什么. 我们谈过程，编码规范、开发流程、同行评审、结对编程、持续集成，从瀑布到敏捷再到极限编程. 我们谈架构，企业级、J2EE、容器化、SOA（面向服务架构）、Microservices（微服务化）. 我们谈规模，大容量、高并发、大数据.
软件开发的“三重门”
- - 酷壳 - CoolShell.cn自从上次写了“ 程序员技术练级攻略” 以来，就觉得似乎还有很多东西没有谈到，但当时没有继续思考了. 而春节前有人问我，是做底层技术，还是做业务. 这问题让我思考了很多，不由自主地回顾了一 下我这十多年的软件开发经历，并顺着整理分类了一下自己解决过的若干问题，还发散想了很多，经过了一个春节假期的发酵，产生了下面这篇文章.
软件吞噬软件开发
- - PingWest中文网软件蚕食世界，自互联网特别是移动互联网连接线上线下服务后，已成为不可逆的趋势. 每一项实用的服务可以由小团队来完成. 以WhatsApp为例，这款被高调收购的IM应用，拥有4.5亿月活跃用户，70%的日活跃率，至今还保持每天新增用户1000万的速度. 但这些服务居然由32名工程师支撑下来了，所以有了业界八卦“每位员工价值20亿”的说法.
软件开发中的两种态度
- - 外刊IT评论网一种态度认为，应该对程序员在软件开发中的行为进行约束( DirectingAttitude). 持这种态度的人认为大部分的程序员水平都不高(谣传说有50%的人低于平均水平)，所以应该对他们所做的事情进行管教约束. 要防止他们做一些可能会给他们正在开发的系统带来危害的事情. 通常，这种态度体现在一些系统设计和工具中时，你会发现它们会试图阻止程序员去做某些事情，限制程序员的一些做法，以此避免他们陷入过于复杂的境况.
软件开发模型综述
- - CSDN博客推荐文章
软件开发模型概述. 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型. 软件开发模型(Software
Development Model)是指软件开发全部过程、活动和任务的结构框架. 软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段.
防火长城内的软件开发
- - Solidot对于软件开发者来说，防火长城不只是屏蔽网站过滤流量这么简单——它是痛苦之源，尤其是如果你想开发针对中国市场之外的软件或想利用广泛使用的服务和软件库的话. 上海聊天机器人创业公司Rikai Labs的创始人DC Collier认为，中国的软件开发者写代码的时候一只手是绑在背后的. 防火长城的屏蔽范围日益扩大，这意味着越来越多的服务被永久性或不定期的屏蔽.
自上而下的软件开发和自下而上软件开发
- - 外刊IT评论网自上而下(Top Down)开发模式是指从一个应用的最高点开始开发. 从最高点逐步往下层编码，直到开发完所有的任务. 一旦写完了最下层的代码，开发任务就完成了. 使用这种方式，你需要设计、编写出所有你需要的但还没有实现模拟接口、服务、伪代码. 自下而上(Bottom up)开发模式是指从一个应用的最底层开始开发.