作为一名西安软件开发行业的老兵，我呆过为数不多的几家软件公司。最近在经过一番灵魂斗争之后离开了自己熟稔的传统软件开发行业，加入了一家互联网公司。趁着闲暇时光梳理了一些感悟，期待能给同样遇到瓶颈的同学带来一些思考。这些软件公司其行业背景几乎截然不同，但其结局大体上可以称为西安传统软件产业的一些缩影。总体上可以分成，项目型软件公司，产品型软件公司，和互联网公司。

作为项目型软件公司而言，也许开一家软件外包公司从来不是老板们的初衷。每位老板心中都充满了开发一款热销产品的美好憧憬。然而，市场如同荆棘林，碰了无数次壁后，终于也得接受现实。利用自己的资源，终于利用有限的资源，杀出了一条血路，承接下各种大小不同风格迥异的项目后，却由于各种原因，只能利用历史项目的简单堆砌，快速搭建框架，快速完成。在这样的情况下，就可能存在一系列问题。

首先当初业务层面的问题。开辟业务之难，难于上青天。往往需要靠软件公司创始人的人脉度过创业早期的难关，在打开局面之后，需要通过多种途径开辟新的业务。然而，软件外包业务往往都是卖方市场，取决于谁拥有最灵通的消息，最快的响应速度和最扎实的人脉，而不仅仅是纯粹的技术因素。甚至许多时候，很多项目都属于内部消化，留给软件公司的，就只是残羹剩饭。

其次是项目越来越难做了。表现出来是项目过程中的需求不可控或需求蔓延。许多中小型软件公司前期接到的许多项目，往往有一个最大的特点，就是功能特别多。有的功能，看起来和主体毫无瓜葛，就是因为某个干系人，或者是业主，或者专家，或者软件公司老板说的一句话，就加到系统中来，而开发者为了完成这个目标就得付出百倍的努力来填坑。而且由于不同的项目行业跨度可能比较大，每个功能具体是实现什么，开发团队是不一定清楚的，是从头开始梳理客户的业务，每个人都成为领域专家么？没有，这往往取决于项目的综合周期。而周期，肯定是不够的。于是拿业主当小白鼠是没有办法的办法，毕竟是按照业主的想法做出来的东西，是对是错？得看业主自己的理解。性能问题就不用讨论了，反正只有那么几个人用，也不需要涉及高并发设计，一个单体应用，一个领域可以搞定的事情，没必要做成分布式部署了。一个项目中，一百个功能，只有二十个功能是用得到的，但是为了履行合同，必须花费最大的精力完成另外百分之八十的功能。有时候，负责任的乙方为了更好的打通业务闭环，在跟客户进行头脑风暴的过程中，往往会主动提出一些想法。然而，用户需求就是笼子里的狮子，一不小心放出来了，就得自己吃苦受累了。拒绝？有一位耿直的小伙伴因为拒绝客户提出的变更而被客户从现场驱逐令人不胜唏嘘。所以往往只能委婉的拒绝，实际上大部分婉拒，客户都会理解成你是一定会做的，只是短期不做而已，于是最终还是得做。在无法控制的需求蔓延之下，项目的开发周期被无限期的拉长，一个合同预期三个月的项目，往往需要延迟到半年或更久，更遑论旷日持久的维护周期了。

其次会遇到的问题是无法对项目进行更加精细化的管理。对于项目型软件公司而言，往往必须建立完善的项目管理流程，通过制度来确保体系的良好运作。做过对日外包的都知道，对日外包项目往往会视合同额有一本非常厚的开发手册。日本人对于工作的细致入微的程度令人钦佩，哪怕是一个简单功能都会实现流程和伪代码等精细到每一行代码。但是对于项目型外包软件公司而言，由于项目周期和合同额的限制，往往没有足够的时间来进行足够的需求调研和文档整理工作。为了快速完成某个项目，往往在既有项目基础上进行迭代。随着时代的变迁，当代开发者所接受的教育背景，已经是极限编程或敏捷建模的思想。这两种编程思想都是明确说明，要抛弃无用的文档，通过代码来保证软件质量。而且，技术人员往往不会关注业务层面的事情，往往倾向于通过技术手段来解决问题。于是变成了四不像的地步，第一点就是，开发者看不懂需求文档，第二点是所谓的领域专家，千金难找，第三点是开发者也看不懂领域专家们建立的统一模型，功能对不对，代码写得是否符合需求，依然取决于开发者和项目经理对于需求的领域和经验本身。而且由于文档的缺失，如果懂业务的领域专家或项目经理的流失，对项目将是迎头痛击。另外由于需求的不确定性，最终导致项目越来越庞大，越来越臃肿，最终成了一个奇葩。

与只能靠接项目为生的外包软件公司相比，产品型软件公司具备一定的优势。他们或一开始已经拥有一个或多个拳头产品，能够面对一定的市场竞争。而这些产品，往往来源