软件外包项目，软件外包公司，在国内十分常见。但这种模式只能是软件公司在培养核心竞争力之前采用的模式。软件外包项目一个很大的特点就是利润低，且周期大多数比较长。如果没有核心功能，核心竞争力，那么整个项目的利润将会十分可怜，甚至没有利润。这篇文章想到哪里写到哪里，抛出的都是一个个的观点。这些观点不一定靠得住，但从反常识的角度上来看具有一定意义。
欢迎给我发送邮件，通过讨论我们来沉淀出好的东西。
大型软件项目
对于大型的软件项目或者长期产品研发，
不同的模块应该不同的负责人。违反常识的一点是，责任人应只负责模块，不负责具体的业务。保证模块的准确性，提高模块的性能和易用性。模块采用率应该作为一个指标去考核。如果可以的话，模块的设计应该有一个经验老道的工程师负责。这个工程师就像是了解程序员的产品经理。
尽可能让每个人都考虑自己范围内的事情。能够同时考虑多个事项的工程师相对能力较强，但不是大多数人。在小型团队和小型的公司，大多数工程师无法做到这一点。除非给个人较高的薪酬待遇，否则，依赖架构师做出的模块划分执行任务，是一个更好的选择。
在软件开发方面，由新手来完成具体的业务需求，或者让同时具备产品经理和工程师能力的人负责业务需求。业务代码中应存在部分代码可以沉淀到技术框架或者新的代码组件中。这个过程也是考核老工程师的关键部分。
预算和费用
软件外包项目应该按照时间进行计费，且工程+验收时间不应该超过3个月。这样作为上层管理者，可以更加有效的控制成本以及验收工程。
甲方应该提出相对明确的需求，要求乙方在某个时间段内完成某项需求
- 如果需求没有被完成，双方协商解决问题
- 甲方如果发现乙方的工作不令人满意，甲方应该在下一次合作中拒绝与乙方合作
- 乙方应该在一定时间内，尽可能满足甲方的要求。
外包软件项目不应该按照金额+宽需求的模式进行付费。大量失败的项目都是因为需求不明确且频繁变化导致的。
基于频繁变化这个前提去设计项目很难。先贤们提出采用敏捷开发方式来应对，采用最终交付功能来付费，这个模式对于初始团队非常危险。因此，软件项目创业在国内环境相对恶劣。国内大部分是强甲方弱乙方。
需求相关
作为需求方，不要有不切实际的幻想。
- 不应该考虑在软件已经完成后再次大量的调整软件，这样往往会导致
- 如果内部的工程师本身具有较高的技术素养，能够明确提出很多种不同的技术指标，那么在财务充足的前提下，可以对外包团队提出更高的要求。
技术相关
话说回来，如果技术真的卓越，在市场上已经形成竞争优势，还会去做软件外包吗？
- 这个技术如果是效率相关，领域无关的，那么这是一个软件公司的核心竞争力。
- 这个技术如果是效率相关，领域相关的，那么这个公司应该是一个行业性质的软件公司。
内部利益分配
解决利益的问题应该采用哪种方案？
- 项目制。保证基本薪资的前提下，提供充足的项目奖金。
- 充分识别团队内成员的能力，确保项目能够按期完成，从而控制成本。如果一个项目在三个月内完成，团队内工程师应该具备使用软件框架的基本能力，对于需求具有基本的了解。通过有梯度的需求来验证成员是否具备能力。
内部软件框架和已有代码是有学习成本的。成本不应该被转嫁，而是更好的控制。让团队成员享受这个过程的同时掌握代码。