这些年，也有不少人会把盛安德定义成一家“软件外包公司”。
我不觉得这个说法完全错。从业务形态上看，我们确实长期为客户提供软件研发服务，也和客户一起做系统、做产品、做团队协作。把我们归到软件服务或者外包这个大类里，并不奇怪。
但问题是，这个定义太窄了。
它只能说明我们大概在做什么，却说明不了我们为什么这样做、怎么做，也说明不了我们真正想为客户和程序员创造什么。
所以，我并不是反感“外包”这个词。我更在意的是，如果只用这个词理解盛安德，大家很容易把我们放进一套并不属于我们的逻辑里。
我们不想被带进“传统外包逻辑”
在今天的行业语境里，“软件外包公司”背后经常默认着一套逻辑：
客户提需求，供应商接任务；需求写清楚，团队照着做；项目交付完成，合作基本结束；程序员主要负责执行，真正的判断由前面的人来做。
这套逻辑不能说完全没有效率。在一些边界清楚、目标明确的项目里，它是成立的。
但如果软件合作长期建立在这套逻辑上，项目看起来可能做完了，价值却未必真正留下来。
因为在这套逻辑里，软件容易被理解成“需求执行”，而不是“问题解决”；项目容易被理解成“交付终点”，而不是“价值开始”；程序员也容易被理解成“执行资源”，而不是“价值创造者”。
这些，恰恰是我一直想避免的。
软件不应该只是“按需求完成”
很多软件合作的问题，表面看是技术问题，实际上是理解问题。
如果一开始就把软件看成“客户提需求，我们来执行”，那合作的起点就已经偏了。
因为客户提出来的，很多时候只是当下看见的需求。真正影响结果的，往往是需求背后的业务问题、场景限制、优先级变化和长期目标。
如果这些东西没有被真正理解，只是把需求翻译成任务，再把任务翻译成代码，最后当然也可以交付，但很难说那就是价值。
所以我一直认为，软件不是从需求开始，而是从问题开始。起点没站对，后面的流程再完整，也容易得到一个看起来没问题、实际上价值有限的结果。
程序员不是执行资源
传统外包逻辑里，还有一个很大的问题：它很容易把程序员放到过于靠后的位置。
需求别人理解，业务别人分析，优先级别人判断，程序员最后负责把任务做完。
这样的分工看起来很成熟，但时间久了，程序员就会越来越像一个执行单元，而不是价值创造者。
这对程序员不好，对客户其实也不好。
因为程序员一旦离问题太远，就很难真正理解自己在做什么，也很难真正对结果负责。反过来，一个理解业务、理解问题、理解客户的程序员，才更有可能持续创造价值。
所以在我看来，程序员不是工具人，不是螺丝钉，而是价值创造者。
我们更想帮助客户建立能力
“外包公司”这个标签之所以不够，还有一个原因：它很容易让人把合作理解成一次性交付。
但企业真正需要的，往往不是一次性把某个项目做完，而是逐渐建立起一种持续通过软件解决问题的能力。
一个系统上线了，不代表能力就建立起来了；一个项目交付了，也不代表未来的问题不会再出现。
业务在变，组织在变，市场在变，客户自己的判断也在变。真正能长期创造价值的，不是某个阶段性的交付结果，而是持续响应变化、持续解决问题的能力。
所以，盛安德一直更看重长期合作。因为只有在长期关系里，软件才能真正跟业务一起演进，客户也才有可能把一部分能力沉淀下来。
我们不是在否定外包行业
我写这篇，不是为了简单地说“外包不好，我们不一样”。
行业里当然有很多认真做事的公司，也有很多合作场景本来就属于服务外包范畴。
我真正想说的是：如果只用“软件外包公司”这几个字定义盛安德，就会把我们最核心的东西抹平。
它会让人看不到我们为什么坚持长期主义，为什么强调程序员成长，为什么在意程序员是不是直接面对问题，也看不到我们为什么始终认为，软件合作真正重要的不是项目结束，而是价值能不能持续发生。
所以，我们不是急着摘掉某个行业标签。我们只是希望，大家理解盛安德的时候，不要只停留在最表面的分类上。
如果一定要说我们是什么
如果一定要说盛安德是什么，我当然不会否认我们是一家软件服务公司。
但更准确地说，盛安德是一家以程序员成长为驱动力，以长期合作为方式，以客户价值为目标的软件能力建设公司。
我们提供软件研发服务，但我们想做的，不只是承接任务、完成交付。
我们更想做的是，让程序员在成长中创造价值，让客户在长期合作中建立能力，让软件从一次性的项目结果，回到它本来应该有的位置——一个持续解决问题、持续创造价值的过程。
这就是为什么，我们不想只被定义为“软件外包公司”。
不是因为这个词让人不舒服，而是因为它太轻了，轻到装不下我们真正想坚持的那些东西。
什么是 Founder’s Note？
Founder’s Note 是盛安德创始人张纪伟的思考笔记，记录他对程序员价值、客户合作和软件公司经营方式的长期思考，帮助大家更直接地理解盛安德为什么会成为今天这样一家公司。
