项目的进行比预想中还要更糟糕。项目开始了,可是T公司迟迟不能提供数据。这个供应链软件是以T公司的生产数据为基础的,如果压根不知道T公司的供应链设计,开发软件纯属空中楼阁。拖了一个多月才收到数据,可是数据错漏百出,前后矛盾。像T公司这种非IT公司,数据管理的水平往往非常低,数据库设计混乱,还有许多数据只存在于人工记录的excel里。每次收到T公司的数据,都要耗费许多时间清理。而且每次数据的格式都不一样,不能自动化处理。直到项目开始后第三个月,开发才正式展开。 在2026年初的今天,AI是IT行业最热门的议题。一个避不开的问题是:程序员会被AI取代吗?起码就目前来看,这还不太现实。 根据我的经验,实际动手写代码只占程序员工作的一小部分。大量的时间其实花在前期沟通上。无论是面对客户还是项目经理,程序员都需要把那些模糊、带有歧义的商业需求,转化为精确的、可执行的技术需求。 处理客户数据就很难完全依靠AI。举个简单的例子,客户数据经常存在缺失。比如一份产品全年的日销售额报告,偏偏缺了几天的记录。这几天的数据是直接忽略,还是用某个数值(比如当周的平均值)来填补?如果只是简单地要求AI「做一个统计按钮」,而不明确这些细节处理方案,背后隐藏的成百上千个类似的小问题累积起来,就会导致最终结果完全错误。 即便具体的代码逻辑可以由AI生成,但每一个处理细节的审核与决策,始终需要人工参与。除非客户完全不在乎软件的可靠性,否则这种逻辑上的「把关人」角色,目前依然无法被取代。 K在多年工作中认识到了一个真理:客户永远不知道自己到底要什么。在理想条件下,一个软件开发项目在一开始就定义好所有功能需求,然后就不发生变化了,程序员只需要按照合同手册写代码。可是现实中客户的需求总在变。每周和T公司开会时,T公司总是提出新的想法,好像改变功能只要用橡皮把旧代码擦掉,随便改改就行了。因为开发时间极其紧迫,K和L只能用非常急功近利的方式写低质量的代码,只要代码能正确运行就行,没有任何优化,也缺少灵活度,修改起来非常困难。这样不停的修修改改,进一步拖延了开发进度。 T公司的项目负责人员不是一个人,而是一组人,这些人之间还存在着办公室政治斗争。T公司这样的国际企业,每年都会给各个部分分配资金。一个经理P主导了xtech的外包项目,他尽力说这个项目的好话。T公司内部的IT经理Q想要让内部人员开发这个项目,就一直挑刺...