软件外包的启示 - 项目管理系列文章

  今天是2014年11月28日星期五,本人谨为庆祝个人博客6周年而写此文。

  软件外包在软件项目业界早已是家常便饭的事情了。很多公司都将一些项目外包给其它软件公司来做;或者专门接一些其它外包项目来给其它软件公司来做。

  这里说说软件外包的好处。我们知道,在软件业界,最繁琐的软件编码方式,就是重复编码。虽然现在有不少公司已经开始重视起软件重复编码的事情,但是仍然无法在短期内解决这种事情。软件的重复编码也是程序员们的诟病。其实整个团队都讨厌软件的重复编码问题(其实很多时候编码就是CRUD)。所以这时候代码生成器出现了,它解决了我们重复编码的上一层问题,但是它的作用也仅仅是将一些类似的代码进行了封装和简单处理,基本上很多时候程序员对代码生成器的作用就是复制、粘贴的作用。很多时候软件的重复编码就是复制和粘贴,所以这就是繁琐的所在。然后,到了高一个层次,我们就把代码抽象出来,将它们提升出去,变成代码模块,以代码模块的方式解决软件重复编码的问题,就象控件一样,很多时候都用到它,所以就抽象出来形成一个代码模块,以便重复使用。

  为什么我们这么讨厌软件重复编码呢,其实就是软件的耦合性太高了,导致了一些代码无可避免的要进行编写。我们以前一直强调代码要高内聚,低耦合,为的就是让我们的代码能够比较松散,不被其它代码模块所左右,而是专心做好自己的本职内容。软件外包的作用,就是专心做自己的事情,其它的都外包出去。

  我喜欢的一句话是:做自己感兴趣的事情,其它的都随风飘散吧。这句话用在软件外包里,那就是:做自己喜欢做的软件项目,其它都外包出去。我们知道,做自己喜欢做的事情是一件多么愉快的事,所以即使是该事情很复杂、很繁琐,我们也仍然乐此不彼。让自己的团队专心做公司自己核心的内容,提高团队以及公司的核心竞争力,那才是我们主要做的事情。而不是一味的要做软件项目,什么都做,做到最后连自己的关注点,自己的专业,自己最强大的一面给抛弃了。

  外包的好处上面已经描述得比较清楚了。其实外包的作用不仅仅是将一些复杂的、自己本身无法实现的功能模块外包出去;同样的,外包还能够节省公司和团队自己的时间,让公司和团队能够做自己的核心产品类的项目。这里再提到产品的问题。软件产品不是一个项目做完就完了,也不是短期内能够搞定的。它需要整个项目团队,产品运营团队的支持,通过长期的努力和经验的积累沉淀而形成。

  这里再说说笔者本地的软件外包公司的问题。笔者对本地外包公司不是非常了解,但是从人员招聘上可见一斑。本地这里有不少公司都是做软件外包的,一部分是针对本地市场,一部分是针对国内市场,一部分是针对日本,美国的国外市场的都有,可谓是跟大城市如北京上海等地的外包公司一样,基本的外包模式都齐全了。而且,本地也成立了软件园,对小公司的软件项目提供软件孵化等提高本地软件水平化的工作,这方面政府也是下了很大的力气。笔者的第一家公司也是外包公司,到现在仍然在做外包,把自己一些相对中、小型的项目外包出去,然后开发公司自己的产品进行销售,这个也是典型的外包公司的模式。

  软件外包给我们的是便利的软件开发模式,笔者以前想过开公司的念头,也曾想过做软件外包项目,这个在本地已经很成熟了,但是由于资金和团队未到位,而且商业模式没完全成熟的情况下,笔者暂时搁置了该内容。其实,这里笔者也将软件外包归结为商业模式的一种,就是开软件公司的一种盈利模式吧。有兴趣的朋友不妨也从软件开发外包开始做起。

  最后,仍然引用那句名言,做自己核心的软件产品,其它的都外包出去吧。软件外包给我们带来的不仅仅是利润上的提升,更是一种成熟商业模式的标志。

 

 

Ps.今天是星期五,也是本人博客在博客园的6周年庆,谨以此文致以祝贺吧。同时也祝大家周末快乐。

时间: 2024-11-05 10:15:38

软件外包的启示 - 项目管理系列文章的相关文章

IT软件人员的技术学习内容(写给技术迷茫中的你) - 项目管理系列文章

前面笔者曾经写过一篇关于IT从业者的职业道路文章(见笔者文:IT从业者的职业道路(从程序员到部门经理) - 项目管理系列文章).然后有读者提建议说写写技术方面的路线,所以就有了本文.本文从初学者到思想者的四步方面对IT从业者的技术路线做了阐述(见笔者文:IT从业者的学习规划 - 学习者系列文章开篇),从浅到深的对技术路线需要学习的内容做了叙述,后续会对学习者系列文章进行书写,本文就当做该系列文章的一个版图吧. 对于技术路线,笔者认为,在工作之余,就该自我主动的去学习技术和业务方面的知识.一方面是

4、项目组人员工作安排 - 项目管理系列文章

以前写过一个关于项目人员招聘的文(关于项目组人员招聘 - 项目管理系列文章),现在,有了人员,就说说项目组人员的工作安排问题.                                   上面是以前的一个文中的项目组人员示例.以前也写过一个关于项目组人员角色指南的问题:软件项目角色指南-开篇.这次就简单说说上面项目组人员工作安排的问题.   1.  项目经理: 项目经理主要负责项目组人员的工作安排,以及对项目的需求和内容做计划,监督项目组人员进行项目的进度等等.项目管理的二八原则还是很有

8、项目管理基本内容 - 项目管理系列文章

在前面的项目管理系列文章中,笔者已经对项目管理的项目组的相关管理内容做了介绍,从最基本的招聘,到相关的项目组管理方法等都有描述.今天本文就从项目组管理的基本内容出发,对项目的管理内容做个基本介绍. 一.项目业务文档编写: 项目文档是项目的最基本内容,其主要是根据项目经理与项目的业务需求人员进行沟通之后进行编写的内容,就是项目的业务文档,描述了项目的具体功能需求内容,也是项目进行开发的具体内容,项目组与业务人员进行沟通交流的基石.   二.项目的基本原型内容编写: 在进行了项目业务文档记录之后,如

7、项目活动的开展 - 项目管理系列文章

前面写的项目管理类文章,都是工作经验总结,对项目经理在相关方面的工作开展进行了分类总结整理.但是有读者说太理论化了,所以今天就写此文对项目管理过程工作中的内容做一下详细的描述安排.   一.计划: 项目经理一定要做好项目计划,最主要的是要做好范围.时间.质量和风险这四个主要的计划.这里对项目过程中的工具Project的使用做一个介绍(使用Project进行项目管理 - 项目管理系列文章).很多项目管理过程领域项都是通过Project进行的控制管理. 1.  范围计划: 范围计划最主要的是工作分解

项目经理的眼:一切都是项目 - 项目管理系列文章

笔者是技术出身,曾担任过软件工程师等职位,现在已经转型做管理(项目管理,产品管理,部门管理),所以今天就讲讲项目经理对于项目的一些看法.心得和体验. 本文受程序开发,软件工程思想影响,在现在的编码中,最主要的还是面向对象程序分析与设计,简称OOA和OOD.所以,在软件工程师眼中,一切皆为对象.今天,我们这里说的是:在项目经理眼中,一切皆为项目. 我们知道,在最新的项目管理知识领域中,划分成"整体.范围.时间.成本.质量.人力资源.沟通.风险.采购.项目干系人"共10大领域的内容,但是我

6、项目组人员绩效考核 - 项目管理系列文章

上次说了项目组人员沟通交流的事项(项目组人员沟通交流 - 项目管理系列文章),今天就说说项目管理中的一个要点:项目组人员绩效考核的问题.一般的公司都是这种薪资方式:底薪+绩效+工龄+项目提成+年终奖.所以说,绩效是薪资中的一部分,也是公司考核员工经验和能力的一个方面.下面就从项目管理的方式,对员工绩效考核做介绍.   一.人员岗位职责: 项目组人员的岗位是员工进入公司时公司招聘的岗位,已经在招聘的时候对员工的职责和相应的薪资进行了管理和安排.所以说,人员的岗位职责是绩效考核的一部分,当然是与底薪

IT从业者的职业道路(从程序员到部门经理) - 项目管理系列文章

      十年前,笔者还是一个刚毕业的大学生,对IT业只是停留在学校的编程知识领域.刚出社会,有很多需要学习的地方.在这十年间,笔者经历了程序员,技术经理,项目经理,部门经理等职位.本文就是要说说如何从程序员到部门经理的经验.         对于程序员,按笔者在<软件项目角色指南>一文中的称呼,应该称为软件工程师.大家可以去看看该系列中对软件工程师的职责等内容,希望大家能对该角色有一定的理解.软件工程师要做的事情还是比较多的,因为在项目中可能要涉及到很多方面的内容,所以,软件工程师往往身兼

Mindjet MindManager思维导图工具的使用 - 项目管理系列文章

    在项目管理过程中,不可避免的要使用到各种各样的项目管理工具.本文就对我自己使用的Mindjet Manager进行一下介绍,推荐给大家使用.       1.  打开软件   这里使用了2012版       2.  软件的界面   界面很清爽,使用了Metro风格的菜单       3.  下面以"项目组成员"这个例子进行介绍     点击界面中间的输入项.输入"项目组成员"项目.         4.  选中中间的控件输入项,使用快捷键"Ins

2、员工的激励与自我激励 - 项目管理系列文章

         昨天想到项目团队人员激励的事情,所以今天就写一下以进行记录.          关于项目团队人员激励的问题,一直想写点什么,但是提笔又有点退缩.团队人员激励是一个比较矛盾的事情.如果激励得好,那么就能提高团队的士气,进而提高了团队的核心竞争力,这也是项目组的一个好事:如果出现了偏差,那可能导致人员脱离团队,或者离开公司,那这个责任就大了.当然,IT行业人员流动性向来比较大,这个有时候也怪不了项目经理,进而怪不了部门经理了.但是,如果是部门内部的矛盾,或者是项目组内的矛盾那就要重