博客园_Silent River

Programmer，Developer，Engineer——软件从业人员的职业规划

2011-08-30T13:33:00Z

Programmer

Programmer是软件开发的初学者，在这一层，掌握2~3种常用的语言，了解SDK常用的部分，有过2~3个正式的项目经验，产出代码行在1万左右（平均每个项目3000左右），能够独立胜任常见的开发任务。

Developer

Developer在团队中跨度较大，从Lead Developer到Code Robot，承担设计、编码、单元测试、代码审核、评审；都是这类好手级人物。Lead Developer是系统中的核心模块开发者，而Designer特质的Developer可以辅助评审设计，Code Robot类人物是最高效的开发者。Developer通常有3年以上的开发经验，有过项目失败的先例，在许多Why和How的问题上不会像新手般不停追问和执着。他们会主动修饰和优化自己和团队的代码，让整个系统变得更加有机；也会评估和尝试更好的开发方式和代码工具和框架，来改进系统开发效率和通用性。

Engineer

Engineer是一个专家级Developer，他的专长不仅仅体现在程序上，而是整个软件。即应用领域、行业参考、业务……等等一切让软件“可用性”更强的方面。他不仅能够设计出有效的系统方案，还能够从业务层面直接解决问题而提出最优的技术方案，重要的是他有足够的沟通技巧与不懂得技术的人谈话并解释他的方案。Engineer一般有5~8年的经验，有过跨行业经历，并且是他自己选择在这个行业继续停留下去。

本文链接

Scrum之成败——从自身案例说起，仅供参考

2011-05-17T02:16:00Z

从07年中初次接触Scrum的概念到其中几年项目中逐渐实践CI、TDD，到亲自掌握项目实践Scrum近一年，最终我们放弃了Scrum这个框架和所谓的“自组织”。原因为何？

1.成员放弃了Scrum所“赋予”的“权利”

比如领用任务、评估工作量、自组织协作、决策等。在第一次Scrum计划会议上排出任务让大家领用时，成员的态度可以用“反感”来形容。在经历四个Sprint后成员依然坚持认为，应为PM完成这些工作，故放弃。

2.团队成员能力参差不齐

我很主观地认为，现在国内的开发团队都会是一部分高级工程师搭配一部分初、中级工程师，这种搭配本身就决定了领用任务时的混乱，尤其是团队中一部分成员极度渴望去做那些自己没有经验的任务。结果造成一部分人一直搞不清楚自己在团队中的定位，一直处于“费力不讨好”的挫折中。高级工程师对另一些成员的效率、成果也颇有微词，对团队分工非常不满。

3.没有清晰的设计阶段是造成上面第2个问题的另一个因素

众所周知，敏捷倡导演进式架构，其本质是，在目标不确定性极大的情况下，通过一次又一次短周期的反馈修正来不断接近目标，固在敏捷中，每项任务、剩余工时、成本燃尽，控制得如此之细，CMMI根本扛不起这样恐怖的基线变化次数。取消清晰的设计阶段，以及采用大量并行的测试，可谓敏捷的一种取舍，赢取更短的发布周期。也正因为如此，在任务分解时，无法清晰地定义设计任务，而将其混杂在功能化的任务中，事实说明，这里有大量的重复工作并且交付良莠不齐。

4.高估了工程师的成熟度

敏捷对工程师的心智有过高的要求。为什么说是过高？其实，在公司里担任高层管理人员的，恐怕都不具备成熟的心智，何况处于一线年轻又尚轻的程序员？现在的程序员，从学校或从培训班子里出来，人际圈子小，知识面狭窄，遇事仅能从自身考虑，常常因生活中一些事情影响情绪和工作，遇到难题就放弃，全力投入到项目开发中来的，并不多见。所以，在项目和开发过程中，监控、管理，催促、激励甚至批评，是必须的！

5.Scrum缺乏领导者

Scrum把团队想象得太完美了，如果有完美的团队，开发方法根本就不重要。工作、项目在进行的过程中，必须会遇到困难、遇到卡壳、团队发生冲突和争吵，这时候，必须有一个人挺身而出，作出决定，解决问题，为大家指明方向，平息争端，警告不利分子，这个人只能是领导人物，能力、权力和职位比团队成员高的人。扁平式组织，想象得太完美了，团队里各种性格的人都有，不服你不爽你的也总有人在，吵个没完没了，各做一套，家常便饭。

最后我想说说Scrum适合的团队，这样的团队需要有一些技术成熟度比较高（五至八年经验）、并且比较稳定地做技术的成员，使用Scrum可以使团队日益默契，并改善技术团队沟通交流不善、积累反思不多的常见问题，基本上，Scrum的正面意义在于，以前的项目管理、开发管理都只注意到了需求、技术、测试等机械性问题，而Scrum把团队管理、团队建设的思路引进到了技术团队。而在这个范畴里，Scrum还比较轻量级，它的回顾会议在工业产品开发中随处可见，可作入门指南，大家会问，进阶怎么走？我想未来软件开发团队的路子会和工业产品相似，渐渐地把决策过程、分析思路引进到团队中，这样子的团队才真正是一个“工程师团队”。

本文链接

基于Team Foundation Server 2010 Scrum 1.0与持续集成的最佳实践

2011-01-06T05:39:00Z

本文适合对Team Foundation Server 2010的部署和管理、模板配置有经验的人员阅读。
在阅读本文之前，需了解Scrum的一些基本知识；其次，需对Visual Studio Scrum 1.0模板有基本的了解。
Scrum的资料：http://msdn.microsoft.com/en-us/library/dd997796.aspx
Scrum 1.0的资料：http://msdn.microsoft.com/en-us/library/ff731587.aspx

每个Sprint正式开始之前的准备

在Scrum 1.0中正式创建一个Sprint之前，要将所有的Backlog填写完成，与团队成员一起分解Task，将Task以“相关”的关系与对应的Backlog进行关联以方便开发人员在浏览Task时查看相关Backlog的描述（Task不能拥有两个不同的父级Backlog，故将关系设置为相关）。

你可以为Task/Backlog创建子级Task/Backlog，但注意父级Task/Backlog的状态、迭代范围的变动无法影响子级，我认为层次关系已失去意义，可以不建。

注：在Task中也有前置关系，没有试过是否有MS Project一样的强制效果（你可以试一下）。

以保守的态度估算每项Backlog的Effort（花费，可代表有效产出），Task的Remaining Work（剩余工作量）。对第一次估算的Task，剩余工作量即总计工作量。

Backlog填写界面

Task填写界面

Backlog的Effort将在Velocity报表计算在对应的Sprint之中，要注意，这份报表只会计算第一次填写的Effort，之后的更新不作计算，所以，对每个Backlog，最好先用Excel等工具记录好Effort，与各干系人确定好后再填入TFS.

Velocity报表

我们采用Visual Studio 2010旗舰版的测试管理工具进行测试计划、测试用例、自动化测试的管理，测试计划的编写是在Backlog评审完成之后进行。在测试计划中需与测试人员约定可测试版本的生成质量，我们的约定是“初次测试已通过”，测试人员可以直接使用这个生成定义来筛选待测试版本，每次的自动化测试都可以生成Bug快照和报表，这里就不详述了。

Sprint计划会议要做的事

准备投影仪，将TFS Product Backlog投放到屏幕上，与团队、产品负责人一起评审每项Backlog和Task：

将评审通过的Backlog/Task状态更新为Approved，不通过项置为Removed。这个操作只有Scrum 1.0项目中Project Administrator、Contributor两个角色中的成员可以完成。
与团队确定交付目标、期限。在TFS上创建Sprint，指定迭代路径、起始时间。
将与团队确定的交付目标相关的Backlog、Task的迭代路径指定为刚刚创建的Sprint。
为每个Task指派开发人员。为每个Backlog指派负责人。

Sprint填写界面

这个事情如果一次会议不能完成，也可以开两次。第一次确定交付目标、计划，第二次对目标细化出来的Backlog、Task进行评审，看时间是否与计划相符，进行裁减或增加。

但要注意，填写TFS的Backlog、Task、Sprint先后顺序，以及要“一气呵成”，否则各种报表会很难看（不真实）。

如果是第N个Sprint并且是在有交付品之后，在新的一个Sprint开始之前，需对开发环境进行整理，保持干净，这包括：

使用与交付品一致的数据库脚本重新创建和初始化数据库。
使用上一个Sprint最新的正确版本部署开发环境。
验证各项功能是否正确。

开发开始后马上要做的事

建立持续集成的生成定义。在这里，我们采用的是TFS 2010的生成服务，具体如何配置可见：http://www.justinablog.com/?p=417

给团队成员一个简单的培训，识别持续集成结果列表、报表中各种图例代表的含义（有编译通过、编译通过测试不通过、编译通过代码覆盖率低等几种状态）。

开发过程中要做的事

Scrum Master/Project Manager

时间点	应做事项
每日早会前	检查被标记为In the progress的Task，将关联的Backlog标记为Committed
每日早会中	与团队查看燃尽图，确认每个被标记为In the progress的Task是否需要协助，确认未关闭的Impediment是否需要协助
每日早会后	检查标记为Done的Task，选择前一个工作日最后一个成功的持续集成版本，将生成质量标记为“初次测试已准备就绪”，发布到开发环境上进行功能的验证；如验证通过，将关联的Backlog由Committed更新为Done，如不通过，提交一个Impediment，指派给开发人员将状态为New的Bug进行审核，通过标记为Approved，指派开发人员
每日下班前	检查当日的持续集成生成列表与报表，如有红色部分，与团队一起排除错误，直到最后一次生成变为绿色
每周二、四、五下班前	将最新的一个生成质量为“初次测试已准备就绪”的持续集成版本标记为“初次测试已通过”
测试通过	将持续集成该版本的生成质量由“初次测试已通过”变更为“实验室测试已通过”
交付品β版本发布	将持续集成该版本的生成质量由“实验室测试已通过”变更为“部署准备工作就绪”
用户验收结束	将生成质量由“部署准备工作就绪”变更为“用户验收测试已通过”
上线	将生成质量由“用户验证测试已通过”变更为“已发布”

项目经理检查表

Impediment填写界面

Developer

时间点	应做事项
每日早会前	将计划当天待做Task标记为In the progress，将计划当天暂停的Task标记为To do，两项操作均需再次评估剩余工时，即还需要多少工时来完成这项Task 检查分配给自己的Impediment和Bug，在开始修复之前，将对应的Task状态由Done改为In the progress，填写所需剩余工时
每次签入之后	检查持续集成发起者为自己的生成项，如有错误，进行修复；检查代码覆盖率（我们的要求是关键功能的方法达到100%）
下班前	将已完成的Task状态设置为Done，更新所有状态依然为In the progress的Task的剩余工时

开发人员检查表

注：关于生成定义和代码覆盖率方面，可以看这份资料：http://msdn.microsoft.com/zh-cn/library/bb558973(v=VS.90).aspx

Tester

时间点	应做事项
每周一、周三、周五早会后（功能持续集成测试）	获取生成质量为“初次测试已通过”的最新版本，发布到测试环境，检查状态为Done的Backlog/Bug，验证是否通过；如不通过，将Bug状态重置为Committed，将新发现的Bug提交到TFS
发布任何版本之前（集成测试）	获取最新的生成质量为“初次测试已通过”的版本，发布到测试环境，验证所有的Backlog、Bug是否通过

测试人员检查表

Bug填写界面

燃尽图

燃尽图上展示的是这个Sprint所有Task的剩余工时，黄色部分是正在进行中的工作，蓝色部分是未开始的工作。

Scrum 1.0的燃尽图是每日更新一次，在每个早会，须与团队成员一起查看燃尽图的状态，基本原理就是，面积图在黑色斜线之下，意味着整个团队的进度是安全的，否则意味着延期的风险。

本文链接

平步青云：Windows Azure（二）

2010-07-25T13:12:00Z

现在我们来讲讲存储服务（Storage Service）和管理工具（Fabric）。

存储服务（Storage Service）

Windows Azure为应用程序提供了几种形式的数据存储，如下图所示：

最简单的数据存储是使用Blobs，它是一个层次数据存储。如图所示，一个数据存储帐户包含一个或多个容器，每个容器中包括一个或多个blob，blog用于存储二进制格式的数据，容量可以很大，并且，它们还可以关联元数据，如JPEG图片的拍摄信息和MP3文件的歌手信息。Blobs用于XDrives，一种查看本地磁盘数据的工具）的数据存储。

但Blobs并不能用于所有的存储场景，Windows Azure为应用程序提供了另一种方式：Tables，但它并非关系数据库中的表。实际上，Table中存储的是一组包含属性的实体（听起来更像对象数据库）。应用程序可以直接使用ADO.NET Data Services就可以访问Table，而不是用SQL.之所以可以直接进行对象访问的原因是，Tables允许scale-out存储——将数据散列在几台服务器上进行存储——这远比关系数据库更加高效。实际应用中，一个Table可以存储上亿的对象。

Blobs和Tables都应用于数据的存取，Windows Azure提供的第三种存储机制，Queues，却有所不同。它应用于Web role实例与Worker role实例之间的异步通信。举个例子，当一个请求发送到Web role实例时，Web role将会在Queue中写入一条消息，描述应该怎么做。一个等待消息的Worker role实例读取到消息并执行操作，执行结果将被返回到另一个Queue或以其它方式进行处理。

Blobs，Tables和Queues，所有的数据在Windows Azure中会被存储三份，但我们不需要关心具体实现。这些拷贝可以容纳错误，一个拷贝的丢失不至于造成灾难。Windows Azure会自动为所有数据进行备份，一但主数据丢失，备份将变得可用。

Windows Azure存储数据在已授权的条件下，可以被Windows Azure应用程序、托管应用程序、其它云平台应用程序访问。三种数据都可以用REST机制进行认证和读取数据，Blobs、Tables和Queues都将以URIs的形式被HTTP操作请求，一个.NET客户端可以使用ADO.NET Data Services去访问数据，也可以直接使用HTTP去直接调用。

除此之外，Windows Azure应用程序也可以选择其它的存储机制，例如，Windows Azure Platform还提供了SQL Azure Database，它是一种访问上类似于SQL数据库的组件，可以在云平台上进行关系数据的存储。

管理工具（Fabric）

Fabric为所有的Windows Azure应用程序和存储提供了管理工具，它管理的对象包括计算机、交换机、负载均衡器等等，它也可以浏览存储的数据、监控应用程序每分钟的操作并记录。你还可以在Fabric中决定应用程序运行在哪台机器上，通过一个XML格式的配置文件进行管理。

本文链接

平步青云：Windows Azure（一）

2010-07-22T14:40:00Z

本系列将系统地介绍Windows Azure，包括基本名词、编程以及Windows Azure的应用，并探讨Windows Azure可能给我们现行模式带来的变化。

先把晦涩的关于云计算的概念放到一边，来看看我们在“平步青云”之前的一些处境。

大量数据实时处理、计算时，用户不得不等待，我们不得不在编码中考虑是否采用缓存并通过性能测试，同时我们还要编写一些代码保证缓存的更新与擦除；
采用异步编程去解决用户等待问题；
各种应用程序、Web Service统一的集成平台与五花八门的交互方式，每一次发布都让你头痛；
海量数据存储的问题；
公共模块如日志记录。

然后我告诉你，Windows Azure为我们提供了上面五个问题的解决方案，也许你就有兴趣来了解它了。

这就是Windows Azure的一个典型应用：它在Windows Data Center的一台机器上运行，以服务的方式为用户提供商业应用程序的使用和数据存取。

Windows Azure能做什么

软件服务商可以在Windows Azure上为特定的商业公司创建应用程序，然后以SaaS的方式提供给商业公司。
软件服务商可以为特定用户创建应用程序，如需要扩大市场为顾客创建的商业站点，Windows Azure都能够支持。
企业为内部员工创建应用程序，Windows Azure也是一个好的选择。

接下来，让我们看看Windows Azure的组成：

计算服务（Compute service）负责运行应用程序，存储服务（Storage service）提供数据存储。第三个组件，Fabric，是一个管理和监控云平台上应用程序的工具。本文中将介绍第一个组件。

计算服务（Compute service）

Compute service支持多种多样的应用程序，它的首要任务就是，解决大量用户并发请求的瓶颈问题：此前我们采用硬件不断升级的方式，而现在Compute service支持应用程序以多个相同代码版本的实例运行在多个服务器上，并且，还支持虚拟机，我们可以通过Hyper-V的操作界面对每个虚拟机进行管理。需要运行程序时，开发人员从浏览器使用Windows Live ID登录，然后自定义应用程序的托管帐户以及数据存储的帐户。拥有托管帐户的开发人员就可以在Windows Azure平台上上载他的程序并定义其配置了。

Windows Azure提供了两种运行应用程序实例的方式：Web role实例和Worker role实例。

如名称所示，Web role实例可以接收HTTP和HTTPS请求，它必须运行在IIS 7中。开发人员可以创建ASP.NET、WCF或其它可运行在IIS上的.NET应用程序；也可以创建非.NET的应用程序，如PHP和部署在Tomcat上的Java程序。图三中我们可以看到，Windows Azure内置了硬件负载均衡（load balancing），以为每个服务器上相同的应用程序实例分配Web请求，并管理这些实例的生命周期。因为Windows Azure并未为应用程序的每个实例建立关联，所以无法保证同一用户的一系列请求只被发送到唯一的一个实例上。因此，Web role实例是无状态的，所有客户端特定的状态都会被写入到Windows Azure存储上并在请求完成时发回客户端。

Worker role实例与Web role实例的不同之处在于，它不需要配置也不运行在IIS中，大多数时候，他们是以后台工作的方式运行。我们还可以在Worker role中运行Web server，如Apache Web server。

开发人员可以只使用一个Web role实例、一个Worker role实例，或将两者结合起来使用。如果应用程序的性能下降，他可以通过Windows Azure增加Web role实例，或增加Worker role实例，或两者同时增加。如果性能超过要求标准，他可以降低这些实例的数目，开发人员可以通过关闭所有的实例来停止应用运程的运行。Windows Azure还提供了API，允许通过编程方式动态改变Web role、Worker role实例的数目，但无法自动关闭应用程序。

进行Windows Azure开发时，开发人员并不需要在自己的机器上运行云平台，而是向运行的云平台上载、配置和调试自己开发的程序，可以使用日志API对平台上的应用程序进行调试，也可以使用配置工具来监控应用程序，如性能计数器、CPU占用、存储错误等等。这些应用程序都是以用户模式（User mode）运行，Windows Azure自己管理自身的系统更新，所以不必担心应用程序带来系统级（System level）的破坏，这在目前的企业平台上，是经常发生的：一些应用程序集成之后，影响到众多其它程序，甚至给平台造成破坏。

光是运行代码功能，显然不是Windows Azure的全部，在下一篇，我们将讲讲存储服务（Storage service）。

本文链接

如何招到优秀的程序员（第二版）

2010-07-22T02:19:00Z

根据大家的反馈，我发现在第一版中对优秀程序员的定位有一些偏差，因此作出改进，希望大家继续拍砖！并慎重声明：此处是讨论如何招到优秀的程序员，如果你认为自己是优秀的，请说出你自认为优秀的地方，这会给HR的工作带来帮助。大多数程序员抱怨公司不识泰山，这不正好是可以改善双方选择的方式方法吗？

笔试考察

模式和架构的掌握：根据所给出的业务场景和系统架构图，简单阐述你的理解和认为有待改进的地方。
功能实现能力：根据现有的系统架构图，选择一个最能表现你编程能力的项目，说明你的实现方案和预计花费工时，试画出一组类的静态视图。
代码规范的掌握：重新考虑第二题中类的名称，试为其中一个类写出最能表现你编码风格的二至三个完整代码的方法。
代码审查能力：审核几个类文件，找出所有你认为不合适的地方。
笔试时间为一个小时。

面试考察

现行项目特点方面：你如何理解和实施对于现有系统的重构？如有类似经历，请简述，考察求职人员的描述是否连贯、清晰有条理。
业务技术理解和目标方面：是否有过BPM（业务流程管理）方面的工作经历，请简述；对此类项目是否有兴趣？
合作稳定性方面：求职人员自身的发展目标。

业务场景举例

一家健身俱乐部将推出自己的电子商务系统，系统满足会员管理、健身场地展示、教学示例视频付费点播、多种在线支付手段（可与银行或第三方支付接口）、教员管理、课程安排和在线选课几个模块。在未来，该电子商务系统可能还会实现与健身器材提供商和维护商的系统协作，但在此期规划中可以不实现功能。

会员分为两种，购买一种或多种健身课程的会员，他们可以在营业时段免费使用俱乐部的所有器材和在指定时间参与健身教练举办的课程；另一种是按季度或年支付会员费的会员，他们也可以在营业时间免费使用俱乐部器材。

对于课程管理和在线选课功能，包含了场地管理和时间管理子模块，每个课程对应一个或多个场地，但仅对应一个时间段，参与课程的学员在课程时间范围内可能使用健身房的其它与课程无关的器材，这将会影响到未参与课程的会员对器材的使用。针对每个课程，根据场地所能容纳的人数，作为课程最大参与人数，但课程最大报名人数是不限的。

本文链接

如何招到优秀的程序员（第一版）

2010-07-21T14:49:00Z

看过“如何招到烂程序员”，恰好我也正需要招聘一些好程序员，根据自身的经验和“烂程序员招聘式”的反例，我制定了一套招聘好程序员的方法，欢迎探讨，也希望这个方法给新人一个优秀程序员的参考，以成为一个优秀的程序员。

笔试考察

设计模式的掌握：根据所给出的业务场景，使用设计模式的思想进行分析和设计，阐述你的理解。
应用程序的架构：为第一题的场景设计应用程序的分层架构，包括解决方案、项目和文件夹布局，描述项目之间的依赖关系，描述每一个项目和文件夹的用途，描述核心模块中采用的实现技术，如采用何种现成框架、思路等等。
代码规范的掌握：重新考虑第二题中解决方案及项目、文件夹的名称，试为其中一个项目设计和命名类，试为其中一个类写出二至三个完整代码的方法。
代码审查能力：审核几个类文件，找出所有你认为不合适的地方。
笔试时间为两个小时。

面试考察

现行项目特点方面：你如何理解和实施对于现有系统的重构？如有类似经历，请简述，考察求职人员的描述是否连贯、清晰有条理。
业务技术理解和目标方面：是否有过BPM（业务流程管理）方面的工作经历，请简述；对此类项目是否有兴趣？
合作稳定性方面：求职人员自身的发展目标。

业务场景举例

本文链接

离岸经营的启发（二）分拆软件业务

2010-07-21T12:02:00Z

高居软件界前列的巨匠们相信，一切问题可以由技术或技术人自己解决。于是，该由需求分析师搞掂的问题，需要开发人员“拥抱变化”，该由测试人员搞掂的问题，需要开发人员“测试驱动开发”，该由技术管理解决的问题，需要开发团队“自组织”，该由文档工程师搞掂的事，需要开发人员“编写高可读性的代码”。

但现实的问题是，大量软件项目中，无论团队多么优秀，最终都会延期、不合格、转手甚至宣告停止。

现在国内软件外包流行两种模式：项目外包、人力外包；项目外包，目前大多数技术型的公司缺乏业务高手，无法驾驭整个项目的需求实现程度；人力外包，服务商可以采用自身的管理体系、客户关系来操纵项目进展，相对而言也可以比项目外包组建角色上更完整的团队。后者的模式很像在软件开发教科书上描绘的模式：客户公司组成顾问团、研发公司带上开发团队，还有产品经理、用户体验师……大家克服一个又一个的困难，遇上一个又一个不可思议的问题，最后期限到达，项目延期或正式上线（延期一般都是99.9999...%）。软件工程因此发展起来了，各种各样的过程改进、规范完善又到自组织的敏捷团队，但起码到目前，软件项目，it's always been the same old story.

看看离岸经营是怎么做的吧！需求分析师、系统架构师的位置设在客户总部，各个开发团队位于全球任何一个提供比较优势的程序员生活的城市；用文档阐清需求和设计约束，各个开发团队进行编码、测试然后交付清单和文件。在这里，很多时候需求依然是不明确地，变化的，但有专人和时间去做调研并且——比我所知的任何地方都高效和高质量。

离岸经营带给我们的启发是，从管理（宏观）而非团队内部（微观）入手去解决问题。想想吧，这仅仅只是一个开发团队而已，你无法得到更多。如果你是只想着利益的老板，这正是你重新审视赚更多钱方式的机会；如果你是一个只想着忽悠的经理，我建议你要么改进要么走人，因为问题就出在你那儿；如果你是客户，也可以想想这些年你的付出所得是否成正比。

需求、设计、开发、测试、交付、维护，软件项目所涉及六个业务范围，软件工程所研究和提供的仅仅只是调节六大模块交互的时间与顺序，采用什么样的方法论并不重要，重要的是正确的人坐到正确的位置。根据业务范围拆分软件项目为五至六个业务模块，制定模块之间的协作策略（文档、工作流），然后挖掘自己最有价值的业务，其它的进行外包——日本人就是这么干的，如果那么多对日外包的程序员能转换一下立场，我们会从中受益。

本文在开初就说了，我们更多的是需要模仿和学习，因为在这个行业，有太多值得我们模仿和学习的现成的东西；在能够解决开发中一系列难题之后，欢迎在行业中有更大目标的技术人投入到宏观视角和管理视角上来看待我们的处境，这里没有“为国内软件业创造一个美好的环境”的口号，而是去解决我们自身技术所不能解决的问题。

本文链接

离岸经营的启发（一）重组业务和流程

2010-07-20T07:42:00Z

当我们看到富士康打着“一流的客户，二流的设备，三流的管理”口号压榨我们的同龄人时，我们不能再无动于衷。无论从年龄还是处境，都不允许我们再打着“闲话”与“闲谈”的口吻去讨论一些专有名词，我们必须行动起来，学习和模仿所有可以学习和模仿的先进事物，直到组建起我们自己的帝国。

目前，许多外企，尤其是开发类的，在同仁眼里代表着光鲜，代表着良好的组织与流程规范，代表着完善的福利制度，也代表着相对高的薪酬。但我们需要绕开作为一个普通员工的表象诱惑，仔细分析和学习它们的经营之道。

生产、开发基地，尤其是外包产业来到中国，对主体企业来说，是以离岸经营模式组建的子公司。离岸经营实质上就是发挥了劳动力成本的比较优势。

早期国际贸易比较优势发生在原材料和产品总成本的对比，这个粒度相对较粗，也跟当时的交通运输、价值载体有关；信息技术的发展，以互联网为传播途径的高速通道，电子数据所组成的新型价值品，都铺就了全球化的道路。在此时，大量企业通过对职能和流程的重组，促进更高度的分工化，从而分拆和转移各项职能，达到充分利用各种各样的比较优势的目标。

从最初的贸易开放与壁垒的争议一样，离岸经营也曾经引发过相当强烈的争论。但至少在目前，以企业这个个体来讲，实施离岸经营的公司均在受益。可以参考麦肯锡文档《离岸经营：双赢之举？》

现在中国很多国内企业也在采用外包这一模式，但它很多时候显得非常盲目，更像以前的建筑承包商模式，因为外包商自身的成熟度有限，很难发展壮大，从而，交付的产品无论从质量还是进度，都难令甲方满意，于是，许多甲方又将项目移回本公司，甚至无利可图的乙方又将项目转包给成本更低的丙方、丁方，质量进一步下滑，时间进一步延后……

避免这种“双输模式”，其实并不需要有多少革新或创造性的东西。分析离岸经营的特点，不难发现，业务流程重组是第一步。只有将业务梳理清晰、让职能单一化之后，才能对各项业务进行分拆，确定部门A做什么，部门B又做什么，A与B如何协作，这样，A或B就可以由两个组织上不相干的集体协作完成业务了。全部转包除了完整的成本转嫁之外，没有任何可取之处，合作商看不到盈利，也难保障交付的价值。

如何确定业务是否外包？依照人力成本的比较优势，简单地说，我们擅长做什么，他们又擅长做什么，我们能够留下什么样的人，他们又能够提供什么样的人。至于业务的核心度和重要度，已经包含在其中了。

对于并不想采取外包模式，规模也较小的企业，个人认为业务流程重组的意义不大。公司转来转去就那么几个现人，老实搞好作坊式生产，建立良好同事友谊更加突显效率。

本文链接

如何适应现代雇佣关系

2010-07-20T02:44:00Z

单方面或双方面的终身雇佣制就像代表它的底特律工业的辉煌，已经一去不复返了。而它所带来的巨额养老金的负担，也间接引发了通用的危机。与此同时，美国西部崛起的硅谷工业，却以另一种方式向我们展示了一种新的雇佣关系，这种新关系可以用一句生动的话来描述：“星期五辞职，星期一上班，连老婆都不用告诉，出门时让车子往新的目的地开就行了。”

在早期的工业社会，工人每天都需要寻找上工机会，慢慢地企业发现，使用熟悉自己生产设备的工人，生产的效率更高，于是，终身制应运而生。

而服务业和工业的不同之处在于，它没有制造链那么特殊化的东西，更没有产品专利权，服务业任何一种模式的成功，都会很快被竞争对手效仿与抄袭。于是，大量服务业的员工们，包括软件工程师，都可以很轻易地在行业内平行更换位置，就像硅谷的工程师一样。

对企业雇主来说，可能很难接受的一点是，现在的员工打心底就不会“忠于组织”，更不会“以公司利益为最大利益”。人员流动性过高是最直观的反映，而部门相互之间的勾心斗角也是同因素下的另一种表现罢了。

那么接下来，就让我们谈谈如何来适应这种新型的雇佣制度，尽管你可能不喜欢它，但你必须接受和适应它。

第一，企业和员工应在一开始就明白，两者的合作是在一个时间期限内的事。在这个阶段保证双方都可以受益，对企业来说，无疑可以保证阶段内的顺利合作，也可以得到这个员工最大的价值。一个例子，软件开发技术日新月异，大多数刚步入职场的新人，却恰恰比工作五六年的老人掌握更多的新技术，他们的竞争力也大得多，这样，老人就显得渐渐地贬值，到最后，甚至发现自己所掌握的，在某天突然完全一文不值了。所以，很多开发人员更愿意选择一家采用新技术的公司。在此情况下，为内部应用系统开发投入成本的公司，保持其应用系统采用最新的开发技术，从另一角度上看，就保持了其开发人员在行业内的竞争力，这远比单一的加薪手段，更能保持团队的稳定性。

第二，了解员工的利益需求，尽可能雇佣和公司目标一致的员工。这里包含了一个企业自身目标和理念的设定，如果一家企业，连目标都不清楚，未来几年的发展战略也没有明晰，会给员工“看不到希望”的感觉，加剧了人员的流失。企业必须在有清晰的目标和发展计划的情况下，去寻找有一致目标的员工，用共同利益将他们组织在一起。

第三，职业上升空间，如果没有，那就必须有良好的培训体系。企业发展的不协调之处在于，很多时候，高层的进步跟不上企业的扩张，底层的进步又远超企业的发展。作为底层，为了职业上升和更好的薪酬，跳槽是最有利的选择。程序员们都知道的一句话是：“工资都是跳出来的。”使用培训，让内部每个岗位都保持合适的储备人选，把招聘保持在初级岗位，那么，人员流失给团队造成的冲击将大大缓解，这也是一种合理的上升机制。

第四，钱，其实是最后的问题——就算你有一亿砸到唐总这样的人，也难保人家没有两亿啊。有一家公司A，薪水在本地很高，但在我看来就像个笑话，因为，他们用两倍还多的薪水雇佣在另一家公司B能力很普通的员工，进去之后，干着在公司B四分之一还不到的活。员工拿高薪却看不到发展，企业的付出也不成正比，这不是傻瓜吗？

准确的目标定位、清晰的发展规划、严格的选拔机制加上不亚于同行的薪酬，足以管理好内部的人员事务；用通俗的话说就是：知道自己干什么样的事，知道自己要什么样的人，知道该给多少钱。

本文链接