- 博客(20)
- 收藏
- 关注
RSS订阅原创 美女公关
在一些场合，譬如培训会议或者行业论坛这类场景下，你们公司想获得某位知名人物的联系方式，却不知道该如何下手，这时候该怎么办呢？如果对方是个“他”，那么“美女公关”这一招将对你有所帮助：就是你趁他发言的间歇，找位美女去跟他要求合影，一般情况下，当事人都不会拒绝，合影之后再让美女很自然地问他要个联系方式，目标就达到了。这是我上次参加微软技术研讨会学到的。
2011-04-21 18:06:00
855
原创 软件外包公司 vs. 自由职业者
<br /> <br />当你打算进行软件外包的时候，你会面临很多问题和选择，其中之一就是到底把任务外包给软件公司来做呢？还是外包给软件开发自由职业者？本文试图对二者进行一些对比，给您一个参考。<br /> <br /> <br />软件外包公司<br />自由职业者<br />成本比较<br />单价较高，但你个人投入的管理成本低<br />单价低，个人投入的管理时间较多<br />技术实力<br />个体在遇到困难时，会寻求公司的帮助，所以<br />技术实力取决于公司的整体技术水平<br />取决于开
2011-04-19 17:31:00
1614
原创 选择软件外包的五大理由
当今社会，软件外包这块的市场正在越来越大，有越来越多的企业选择将部分或全部的软件开发业务进行外包，由此带来一个简单的问题，他们为什么会这么做呢？根据我在软件外包行业从业多年的经验，认为以下五条原因是企业选择将软件开发任务外包的主要原因降低成本聚焦于核心业务逻辑缺乏资源提高速度提升资本利用率总而言之，就是为了增强企业的核心竞争力。当然，这五条并不是说就涵盖了所有的原因，不排除有很多其它的因素影响着企业的外包决定，你认为除了以上五条原因，还有哪些因素是企业在选择将软件开发外包时的主要考虑呢？
2011-04-18 17:56:00
1097
原创 IT企业人才的选，用，育，留
<br /> <br />人才的选，用，育，留<br /> 如何防止人才流失，是每个企业都面临的挑战，本文打算针对IT企业的常见情况，在如何留住人这个问题上，做些探讨。<br /> 之所以要用“选用育留”来做标题，是因为我认为不能单单从留住人的角度来看待人才流失的问题，应该从一个更加系统、更加全面的方面来说。举个例子吧，如果在招聘环节，招来了一个仅把当前这个公司作为跳板的员工，任何留人措施对他都是无效的；还有一种情况是招聘时应聘者对公司没有一个比较客观的认识，来了以后才发现很多情况跟
2011-01-09 15:14:00
1578
原创 关于企业的薪酬体系之思考
<br /><br />“公平，公正，合理”是一个公司的健全的薪酬体系应该遵守的原则：<br />公平– 是指公司内部员工的薪酬水平要有可比性，比较常见的问题是，同样岗位和级别，两个人之间的薪水却差了一大块，其中一人一旦得知，会产生极大的不满和离职的想法；对其他员工也会造成负面影响。现在很多公司虽然没有公布大家的待遇，但是不少员工在私下里面还是会有交流；<br /> <br />公正– 指员工的薪水要跟他的价值划等号，一个公正的价值并不取决于个别人对他的看法，取决于整个市场对他的认可，要是市场上有多家公司愿
2011-01-09 14:55:00
672
原创 对于客户期望管理的建议
<br /><br /> 在项目中，我们经常会遇到一种情况，就是客户的期望或者要求太高，我们很难满足甚或完全无法达到，在自己付出很多额外的努力之同时，还无法获得客户的满意。这一问题无疑对双方的合作产生了不小的负面的影响，那么有没有办法可以应对呢？<br /> <br /> 今天跟公司一位项目负责人沟通了此问题，有点心得跟大家分享下：<br /> <br /> 首先，我们要有正确的认识<br />* 客户的期望是可以调整的，并非一成不变的。<br />* 让客户越多了解实际情况，就越有助于建
2010-09-24 18:14:00
1851
原创 帮助项目获得成功的法则
<br />1 - 责权对等，让实际完成工作任务的人对该项任务进行评估、执行计划、并对进度负责；不要毫无依据地凭空设置一个最后期限；2 - 设定并维持好节奏，譬如每一个月有一个里程碑，每三周一次迭代，不要过于频繁（譬如每周），也不要过于松散（譬如每三个月）；3 - 主题鲜明，设定明确而一致的风格，形成让人容易记住和把握的特点；4 - 尽量减少你的项目对外部条件的依赖，譬如尽量不去依赖第三方的工具、团体、资源等，即使不得不依赖，也要把依赖性降低，同时要取得对这些外部条件的影响力。5 - 给你的客户安全感，让他
2010-09-17 17:29:00
549
原创 导致项目失败的两大隐形杀手
<br /> 根据个人的项目管理经验和生活经验，我觉得“明枪易躲，暗箭难防”这句话实在是太有道理了。用在项目管理方面，就是指那些相对比较大的、明显的问题往往都容易识别，比较好预防或者解决，项目一般不太容易失败在这些地方；而那些相对较小的，经常发生的琐碎问题，却通常都比较隐蔽，不太容易预防和控制，而它们最终会在无形中杀死项目。就好像一颗大树，在雷电之中都没有倒下，最终却死在一群小昆虫的口里。 言归正传，现在我要揪出个人认为导致项目失败的两大隐形杀手：范围蔓延和过度承诺。 “过度承诺”，最常见
2010-08-31 17:16:00
570
原创 关于软件需求必须知道的事情
<br /><br />“客户的需求在一开始就能被定义好，并且描述清楚，并且在相当长一段时间内保持不变”，这种情况只存在于理想中，现实世界并不是这样。<br /><br /><br />现实是：<br />* 只有非常少的客户能在项目开始时就清楚地知道自己想要什么并定义好细节，绝大多数客户（也许90%以上）只是对项目的需求有个模糊的概念，而且无法想像最终想要的产品长什么样；<br />* 即使客户清楚地知道自己想要什么，其中很多人也无法明确地把这种需求表述出来；<br />* 即使他能够清楚地表达自己的要求
2010-08-31 17:08:00
526
原创 浅析项目失败的原因
在我们的工作和日常生活中，充斥着各种各样的项目，软件开发也好，工地建设也罢，都是由一个个项目的形式构成的。然而在所有这些项目中，往往是失败的比较多，成功者寥寥，这是为什么呢？为什么一个项目会失败？如何才能提高这个项目的成功概率？我认为这是很有意义的问题，所以想跟大家交流下。 既然谈到一个项目的失败和成功，那我们必须对何谓“项目失败”，何谓“项目成功”有个界定，免得在这点上争论不休，这就失去了进一步探讨的意义。另外我还想把这个讨论的范围缩小到软件项目这块，虽然很多问题都具有普适意义，但毕竟个人视
2010-08-31 16:15:00
745
原创 精益方法的原则之延迟决策
精益制造的第十三条原则为 "不急于作决策，以共识为基础，彻底考虑所有可能的选择，并快速执行决策" 说的是不要因为时间紧迫或者人多难以协调，就采取武断式地决策方法比较“快”地做出决策来。而应该在决策前尽量找到所有可能的方案，充分讨论、沟通、评估、甚而试验每种选择，以此达成团队的共识，在共识的基础上再进行最终决策，以确保做出最佳的决定 - “决策”慢。 另一个层面是，一旦决策制定了
2010-01-19 17:46:00
1942
原创 敏捷软件开发最佳实践之-Scrum站立会议
什么是站立会议？站立会议是敏捷软件开发方法论Scrum的相关技术之一，亦可称之为Scrum的最佳实践。具体形式为每天的同一时间，一个敏捷开发团队的所有成员面对面站在一起，进行一个为期15~20分钟的短会。在会议上，每个人要依次回答以下三个问题：1）从上次站立会议到现在，你完成了什么2）从现在到下次站立会议，你将要做什么3）你遇到什么阻碍，需要其它人如何帮你站立会议的意义和作用是
2010-01-13 17:28:00
1802
翻译 精益软件开发七条原则
精益软件开发七条原则 尊重一线人员 工作在一线的人最了解实际情况，他们知道现在发生了什么，知道当前情况下的最佳应对方法； 他们熟知每天使用的工具、流程、规则，因而完全具备足够的知识提出改进意见； 要充分尊重一线人员的意见；消除浪费 任何不增加价值的工作都是浪费； 没有人会去看的文档是浪费，不符合客户使用场景的需求是浪费，开发出
2010-01-08 14:16:00
4124
原创 质量管理策略
越早解决质量问题，代价越低 人们的经验和一些研究机构提供的数据都告诉我们：越在软件开发周期的后期修改Bug，付出的代价将会越高。这个不难理解：后期随着系统规模和复杂性的增加，发现问题和定位问题的难度明显提高；根据学习曲线理论，隔得时间越久，人们对事物所存留的印象越少；在后期回过头来重新思考问题，会比开发刚完成时付出更多的时间；在软件生命周期收尾阶段的每次修改，都会需要大量
2010-01-08 13:58:00
943
原创 关于软件质量的事实
低质量的软件会导致重大的损失 虽然这看上去像是一个常识，然而看起来似乎还有很多人并没有意识到这一点，否则为什么市场上还泛滥着让人担忧的低质产品呢？所以这条显而易见的事实永远有必要强调下去，随便摘抄两个例子给读者增加点映像：1）1999年，NASA在3个月之内，因软件错误先后损失了耗资1.25亿美元的“火星气象观测轨道太空船”和耗资1.65亿美元的“极地登陆者号”探测器；2）Intel曾经因为3
2010-01-08 13:54:00
784
原创 软件开发过程中的7大浪费
1. 额外的功能特性 根据Standish Group的调查报告，传统的软件开发过程制造了大量人们不需要的功能特性（7% always used，13% often used，16% sometimes used，19% rarely used，45% never used）。每个功能的实现，都要经历软件开发的整个生命周期：需求分析、设计、编码、测试、发布和维护，这需要耗费大量的人力、物力和财
2009-12-16 11:44:00
4998
翻译 敏捷软件开发12条原则
敏捷软件开发遵循的原则 1. 我们最优先做的工作是通过尽早地、持续地交付有价值的软件来使客户满意； 2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势； 3. 以几周或者几个月为单位，经常性地交付可以工作的软件，交付的时间间隔越短越好； 4. 业务人员和程序员必须在整个项目周期中，每天都在一起工作； 5. 围绕被激励起来的个体构建项目。给他们提供所需
2009-12-16 11:41:00
906
翻译 敏捷软件开发宣言
http://www.agilemanifesto.org/ 个体和交互 胜于 过程和工具； [注] 以人为本的思想，利用工具的是人，遵循过程的也是人，如果有最好的工具和过程，而个体却没有很好的去利用工具，遵循过程的话，工具和过程也不能发挥预计的效果；另外，流程和工具的一部分作用也是为了团队成员更好地交互；所以个体和交互是跟本，过程和工具固然重要，却是辅； 可以工作的软件
2009-12-02 17:30:00
1131
翻译 敏捷软件开发中的26条金科玉律
l 在开始案例2之前，必须使案例1能完全正常工作这条玉律在厨房里面的说法是：“在开始做下一道菜前，先把当前这道菜上给客户”。软件开发最大的问题是一大堆事情并发进行，因此其中的一些工作就不可避免地会在后期被丢弃，这就意味着努力被浪费。先专注于案例1；使它完全能够正常工作；运行相关的测试；书写与之关联的文档；嵌入所有相关的代码；然后才能开始下一个任务； l 决不要允许构建失败非
2009-10-30 14:21:00
856
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人