软件公司不只有程序员,我十年没怎么写过代码

每次和新朋友聊天，听说我是做软件的，第一句话基本都是：

“那你头发还好嘛？”或者“你穿格子衬衫嘛？”

我总是打着哈哈解释：我不是程序员。

对方就懵了：做软件的，还不是程序员？

还真不是。一款软件从想法到真正用起来，中间要过很多关：有人要弄清楚客户到底想要什么，有人设计功能，有人写代码，有人检查问题，还有人要把系统装到客户现场、教会几百个用户使用。

写代码，只是其中一关。

我在软件行业干了十年，前几年做实施工程师，后来做项目经理，接触过医院信息系统，也参与过其他类型的软件项目。这十年里，我见过很多不写代码、但同样把事情做得很好的人。

这篇文章想告诉你：软件公司里到底有哪些岗位，他们每天在干什么，以及一个不写代码的人，是怎么在这个行业立足的。

一、软件公司不只有程序员

很多人对软件公司的印象是这样的：一群程序员坐在电脑前，敲代码、改Bug，然后开发出一个软件。

这只是软件项目中的一部分。

拿医院信息系统（HIS）来说，一个医院要用上一套新系统，并不是开发人员把程序写出来就结束了。

从最初了解医院需求，到设计系统功能，再到开发、测试、部署上线，最后让医院工作人员真正用起来，中间需要很多不同岗位的人一起配合。

一个比较典型的软件项目，大致会经历这几个阶段：

1. 需求调研

软件公司要先了解客户想解决什么问题。

比如医院希望优化门诊挂号流程，就需要有人去医院了解现有流程、工作人员的实际操作习惯，以及他们希望系统解决哪些问题。

这项工作通常由产品经理、项目经理或业务顾问参与。

2. 产品设计

了解需求之后，需要把客户的想法整理成具体的功能。

比如挂号页面应该有哪些信息、收费流程怎么走、不同角色能看到哪些功能。

产品经理会整理需求、绘制原型，让客户和开发人员知道最终要做成什么样。

3. 软件开发

开发人员根据需求和设计，把功能真正写出来。

这也是大家最熟悉的程序员工作。

4. 软件测试

功能开发完成后，需要测试人员检查系统有没有问题。

比如挂号能不能正常提交、收费金额是否正确、不同操作之间会不会冲突。

测试人员要尽可能在系统交付前发现问题。

5. 实施交付

软件开发完成，不代表客户就能直接使用。

还需要安装部署、数据初始化、系统配置、用户培训、现场测试，以及最终上线。

我最早做的就是这部分工作。

6. 运维和迭代

系统上线之后，还要处理使用中的问题，维护系统稳定运行，并根据客户需求持续优化。

一个软件项目从开始到结束，需要很多岗位共同完成。程序员只是其中一个环节。

二、不写代码的人，在软件公司做什么？

如果你暂时不会编程，也完全可以在这行找到自己的位置。下面这几个岗位，就是不写代码或很少写代码的人在做的事。

1. 产品经理

主要负责理解客户需求，并把需求转化成软件功能。

比如医院提出：希望医生能更方便地查看患者的历史检查结果。产品经理就要弄清楚医生真正想解决什么问题，设计功能流程、页面原型，再和开发、测试沟通。

需要较强的沟通能力、逻辑思维和业务理解。不要求会写代码，但要理解软件是怎么工作的。

2. 测试工程师

主要负责检查软件有没有问题。

比如患者缴费后系统是否正确记录？退费之后，金额和数据是否恢复正常？测试人员根据需求设计测试场景，反复操作系统，记录问题并跟进修复。

需要细心、有耐心，也需要一定的逻辑分析能力。

3. 实施工程师

负责把软件真正部署到客户现场，帮客户用起来。

以医院系统为例，可能要到医院安装系统、配置环境、整理基础数据、培训医生和护士，还要处理上线过程中的各种问题。

这个岗位通常需要出差，要和客户频繁沟通。不要求很强的编程能力，但要愿意解决问题，能适应现场。

4. 项目经理

负责推动整个项目按计划完成。

从启动、需求沟通、任务安排，到进度跟踪、问题协调、客户沟通，再到最终验收。项目经理不亲自写代码，但要知道每个环节在做什么。

开发进度落后了怎么办？客户临时加需求怎么办？测试发现问题影响上线怎么办？这些都是项目经理的日常。

5. 运维工程师

系统上线之后，负责日常维护。

服务器是否正常、数据库有没有问题、故障怎么排查、数据有没有备份。

这个岗位需要学习操作系统、数据库、网络等知识，部分岗位还涉及脚本和自动化工具。所以即使不做开发，也要不断学习技术。

这些岗位并不是没有门槛，只是对技术的要求和使用方式不同。

三、干了十年交付，我经历过的三件事

上面介绍的是岗位和流程。但如果只看这些，你可能还是想象不出软件项目究竟是什么样的。

分享三件我亲身经历的事。

第一件：第一次参与医院系统上线，我们整整忙了一个通宵

第二件：项目经理答应了客户第二天上线，却发现开发排期已经满了

后来做项目经理，我也犯过错。

有一次，客户提出一个上线时间要求。我没有充分确认开发的实际排期，就答应了第二天上线。

等到真正协调资源时才发现，开发的任务早就排满了。

这下麻烦了。客户那边已经承诺了时间，开发这边确实有自己的安排。

当时我只能想办法协调，晚上请了两位开发吃饭。

饭桌上，我没有把责任推给别人，直接承认：

“兄弟帮帮忙，我已经答应客户了。这次是我的问题，以后我注意。”

其中一位开发说：

“谁都会有失误的时候，互相体谅吧。”

后来，两位开发还是帮忙连夜处理了问题，第二天上午完成了上线。

这件事让我记了很久。

做项目经理，不能只想着让团队帮自己完成任务，更不能随意答应客户，再把压力转嫁给开发。

项目经理要对自己的承诺负责，也要尊重团队的工作安排。

现在回头看，那次虽然把事情解决了，但本质上是一次不应该发生的临时救火。

项目管理不是靠团队一次次加班，来兑现自己没有确认过的承诺。

第三件：医生在医院大群里说，这个系统还不如原来那套

还有一次，系统上线后，一位年纪比较大的医生在医院工作群里发了一句话：

“这系统还不如原来那套。”

当时院长也在群里。

看到这句话，我心里一下就紧张了。

系统刚上线，医院领导都在关注使用情况。如果医生不满意，很可能会影响整个项目的推进。

但光在群里解释，解决不了问题。

我直接去找了这位医生，了解他具体觉得哪里不好用，再陪着他实际操作，把问题逐一梳理。

操作不熟的，就一步一步教；确实需要协调处理的，就记录下来，和团队沟通。

这件事让我认识到：系统上线只是交付的一个节点，真正重要的是客户能不能用好。

有时候客户说系统不好用，不一定是系统真有问题，可能是操作习惯变了；当然，也可能确实存在功能或流程上的不足。

作为项目交付人员，不能一听到客户抱怨就急着解释，更不能简单认为客户不会用。

先听清楚问题，再想办法解决，这比急着证明自己没错重要得多。

四、如果你也想进入软件行业，应该怎么准备？

在讲具体建议之前，先说说什么样的心态干不了这行。

我带过新人，最怕两种：一种到了客户现场一问三不知，另一种在现场什么都敢答应。

第一种，客户很难对你建立信心。

第二种，可能要整个团队为你的承诺买单。

所以不管做哪个岗位，先记住一个词：确定性。客户问你能不能做到，你要么给出准确答案，要么给出一个明确的确认时间。不能猜，更不能为了让客户满意就随便承诺。

在这个基础上，再谈三件实际的事。

第一，不要一开始就认定自己只能做程序员。

喜欢研究业务、和人沟通，可以了解产品、实施、项目管理；比较细心、愿意分析问题，可以了解测试；对计算机基础感兴趣，可以往运维、数据方向发展。

先了解岗位，再判断自己适不适合，不要因为不会写代码就直接否定自己。

第二，至少要具备基本的软件和技术认知。

不会写代码，不代表可以完全不懂技术。

你至少要知道数据库是什么、服务器是什么、接口是什么、软件是怎么部署和运行的。

不需要达到开发的深度，但这些认知会直接影响你和技术团队沟通、解决问题的能力。

第三，尽量找机会接触真实项目。

课堂上的知识、书本上的概念，和真正的软件项目之间有距离。

有机会就参加实习、跟一个真实的项目，看看需求怎么变成产品、产品怎么交付给客户。

哪怕只是做测试、整理需求、协助实施，也能帮你建立对这行的真实认识。

最后想说几句

我在软件行业工作了十来年，从实施工程师做到项目经理，接触过不同的客户，也经历过不少项目里的坑。

这十来年让我越来越觉得：软件行业不是只有会写代码的人才有机会。

一个软件项目能不能成功，除了技术，还需要有人理解业务、有人设计产品、有人测试质量、有人协调团队，也需要有人把系统真正交付到客户手里。

当然，不写代码不等于没有门槛。你依然需要学技术、懂业务、攒经验。

如果你正在考虑进入这个行业，我想说：先别急着给自己设限。

多了解几个岗位，多看看真实的软件项目，再决定自己想走哪条路。

我会继续分享这十年在软件行业的真实经历，也会记录自己学习AI、探索新技术的过程。不制造焦虑，只分享真实的行业认知。

如果你对软件行业还有什么好奇或疑问，欢迎在评论区留言。也许你想知道的问题，正是别人也想问的。