很多项目的问题，不是技术问题
这些年，我越来越确定一件事：很多软件项目做不好，不是因为程序员技术不够，而是因为程序员离真正的问题太远。
需求经过客户、产品经理、项目经理、业务分析，再传到程序员手里。每一层都很专业，流程也很完整，但真正写代码的人，最后拿到的往往只是一张任务单。
功能做完了，问题却不一定解决。
因为客户提出的需求，很多时候只是他当下想到的一种办法。程序员如果只接收需求，只会思考“怎么做”；只有理解业务，才会继续追问：为什么要做？真正要解决什么？有没有更简单的办法？现在做这件事值不值得？
所以我一直说，软件不是从需求文档开始，而是从真实问题开始。
从“项目监理”到客户的CTO
我们曾经有一个物流行业的项目，最初参与的程序员只是一名“项目监理”。
但进入项目以后，他很快发现，真正的难点不是开发进度，而是客户自己也没有理清业务。
于是，他连续两个月泡在客户公司，观察调度流程，整理库存、财务和箱体流转，把原本零散的业务信息重新梳理出来。
后来，他不只参与系统选型和接口开发，也开始参与业务讨论和重要决策，最后成了客户实际意义上的“CTO”。
他的变化，不是因为突然掌握了多么高级的技术，而是因为他真正理解了客户在做什么、为什么这样做。
程序员不能只站在任务链条的最后
程序员直接理解业务，不等于让程序员同时承担销售、产品经理和项目经理的全部工作。分工仍然需要。
但程序员不能被隔离在任务链条的最后，只负责接收别人整理好的结果。
他应该有机会接触真实问题，直接澄清关键细节，理解自己的工作为什么重要，并且不只对代码负责，也对最终结果负责。
另一个水产养殖项目，客户最初只带来了两页A4纸。
团队没有等一份“完整需求文档”，而是直接去了解养殖流程、传感器环境和养殖户的实际使用习惯。两个月后，第一版系统上线，随后再根据现场反馈持续迭代。
如果程序员没有进入业务，很多真正影响结果的问题，根本不会出现在需求文档里。
这也是程序员真正成长的方式
程序员的成长，不只是掌握更多语言、框架和工具。
真正成熟的程序员，还要能理解业务、判断价值、面对客户，并对结果负责。
只有这样，他才不会一直停留在“别人让我做什么，我就做什么”的阶段，而是能够发现问题、提出方案，帮助客户做出更好的判断。
我一直强调程序员要直接理解业务，不只是为了让项目推进得更快。
更重要的是，让程序员从完成任务的人，真正成长为创造价值的人。
什么是 Founder’s Note？
Founder’s Note 是盛安德创始人张纪伟的思考笔记，记录他对程序员价值、客户合作和软件公司经营方式的长期思考。
