由于软件行业的特殊性， 有的开发周期长，有的需要试运行，后期还存在升级维护等，合同对于验收的具体约定不一样，都会影响收入确认时点。在发行人的问询函中，常见的问题如下：

一、 软件这个东西到底是个什么东西？

呃，先说说这个软件吧。这个东西很奇怪。不像你买的那瓶矿泉水，拧开盖子就能喝，喝完了瓶子就扔了。 歇了吧... 软件不一样，它是一种无形的东西。你买了软件，你还得给它装电脑里还得让它跑起来。这就麻烦了。

最终的最终。 然后是开发周期长。真的很长。有时候写个代码，今天能写完，明天就能运行，有时候写个系统，可能要写好几年。这就导致了一个问题：你什么时候开始算钱？什么时候开始算我干活了？这就像是你雇了个木匠给你打家具，你问他什么时候能好？他说“大概吧，看心情”。这种时候，那个工时怎么算？这太难了。

1. 开发周期长是个大坑

开发周期长，意味着钱要分好几年才能拿全。如果工时确认不准，那你这一年到底干了多少活？是不是在摸鱼？ 不妨... 老板看了会不高兴，税务局看了也会觉得你可疑。所以这个周期长的问题，是确认工时的第一大难点。

你想想看， 一个项目，从立项开始，到需求分析，再到设计，然后是编码，再说说是测试上线。这一套流程走下来可能要一年。这一年里程序员每天都在干嘛？有时候在开会，有时候在睡觉，有时候在摸鱼。你怎么证明他那天干了活？难道要数他的头发掉了几根？这明摆着不科学，杀疯了！。

2. 试运行是个什么鬼？

还有一种情况，就是试运行。合同里说好了先装上试试，没问题了再给钱。这个“试运行”就是个大坑。它到底算不算验收？算不算我完成了任务？还是说这只是个预演？如果不算，那这段时间的工时怎么算？是不是白干了，不堪入目。？

　　有些公司规定，试运行期间，只要没出大毛病，就算进度正常。那这期间程序员是不是不用干活了？不他们还得盯着系统，还得改Bug。但是改Bug算不算新的开发？还是算修复？这个界限太模糊了。模糊得就像雾里的花。

二、 合同这东西，有时候比人还难懂

合同。对，就是那个纸或者电子文档。上面写得花里胡哨的。什么“里程碑节点”、 整起来。 “验收标准”、“交付物”。这些词儿听起来很高大上，其实写出来全是坑。

1. 验收标准不一样， 心里没数

不是我唱反调... 有的合同写得特别细，说得好好的，这里要改个按钮，那里要加个功能。后来啊呢？客户一看，哎呀这个功能不好用，不想要了。这时候，验收就没法通过了。那之前的工时是不是白费了？当然不是。但是怎么算？这部分工时怎么确认？是算在“开发阶段”还是算在“返工”里？这就很让人头疼。

说白了... 还有那种“模糊验收”的合同。合同里写着“符合行业惯例”、“达到用户满意”。这个“满意”怎么定义？你觉得你做得好，客户觉得你做得烂。这就是扯皮的开始。扯皮的时候，工时是怎么算的？是按实际工作时间算，还是按争吵的时间算？后者明摆着不划算。

2. 后期还有升级维护等

我是深有体会。 你以为签了合同就完事了？想得美。软件这种东西，就像个婴儿，生下来就不完美，还得天天养。后期还要升级，还要维护，还要修Bug。这些算不算履约？当然算。但是这些算哪里的工时？是算在原来的项目里还是算在新的维护项目里？这账一算，头都大了。

有时候，维护工作比开发还累。主要原因是开发是做加法，维护是做减法，或者是做急救。系统崩了你得赶紧救。半夜三点，手机响了客户说系统挂了。 嚯... 这时候你还要不要算工时？当然要算，不然谁给你钱？但是这种突发情况，怎么记录？怎么统计？这就需要一套非常变态的工时管理系统。

三、 问询函里都问了些什么？

　　在发行人的问询函中，常见的问题如下：

1. 关于收入确认时点的准确性

这是最核心的问题。也就是那个“钱到底什么时候到账”的问题。问询函会问：你们凭什么说在这个时间点确认了收入？你们的依据是什么？是签了合同？还是交了货？还是客户认可了，我不敢苟同...？

　　有时候，合同签了但是货没交。这时候能不能确认收入？不能。主要原因是货没给出去。但是有时候，货交了合同还没签。这时候能不能确认收入？有时候可以有时候不可以。这取决于具体的会计准则。但是对于外行这简直是天书。所以发行人需要解释清楚，为什么在这个时间点确认了收入。解释不好，就会被问得怀疑人生。

2. 关于工时记录的完整性

　　问询函还会问：你们记录的工时真的完整吗？有没有少记？有没有漏记？程序员这种生物，有时候会偷懒的。他们可能会把周末的加班算在工作时间里或者把私人的事情也算在工作时间里。如果记录不完整，或者不准确，那收入确认就会出错。

　　所以发行人需要提供工时记录的明细。比如谁在什么时候做了什么事，花了多少时间。这些记录要能经得起推敲。经得起审计师的拷问。如果经不起拷问，那就完了。审计师会怀疑你的整个财务体系都是假的。

3. 关于项目进度的核对

挺好。 有时候，项目进度和工时记录对不上。比如项目文档里说完成了80%，但是工时记录里只花了60%的时间。这是怎么回事？是文档造假了？还是工时记录造假了？还是效率突然提高了？

问询函会揪着这个问题不放。他们会要求你解释每一个差异。解释不清楚，就会被视为信息披露不充分。信息披露不充分，就是违规。违规的后果很严重，轻则罚款，重则退市，醉了...。

四、 那个工时到底该怎么算？

　　说了这么多，那个工时到底该怎么算呢？

1. 算人头，还是算时间？

一种方法就是算人头。比如这个项目有5个人，做了3个月，那总工时就是5 * 3 * 22 = 330小时。这种算法最简单，但是最不准确。主要原因是每个人的效率不一样。有的人写代码很快，有的人写代码很慢。有的人在摸鱼，有的人在拼命。所以光算人头是不行的，绝绝子！。

另一种方法就是算时间。每个人每天记录自己的工作时间。然后汇总起来。这种方法比较准确，但是工作量比较大。需要每个人都老实记录，不能造假。而且，还需要一个系统来记录。现在的企业都有ERP系统，或者Jira系统，用来记录工时。这些系统要好用，要方便。如果系统很难用，程序员就不会去用，那记录就没有意义了，别怕...。

2. 里程碑法

还有一种方法，就是里程碑法。把项目分成几个阶段，每个阶段完成一个里程碑，就确认一部分收入。这种方法比较符合软件开发的流程。但是里程碑的划分要合理。如果里程碑划分得太细，那就跟算时间没区别了。如果里程碑划分得太粗，那就失去了里程碑的意义，扯后腿。。

算是吧... 比如一个项目分成三个里程碑：需求分析、系统设计、系统开发。每个里程碑完成后确认三分之一收入。这种算法比较简单，但是也有问题。比如需求分析阶段，可能花了半年时间。但是系统开发阶段，可能只花了三个月时间。按照里程碑法，两个阶段的收入是一样的。这明摆着不合理。

3. 凭什么不能拍脑袋？

当然有些公司就是靠拍脑袋。老板拍一下脑袋，说这个项目完成了就确认收入。这种做法最不靠谱。但是有时候也是没办法的办法。主要原因是软件这种东西，很难量化。你很难说这个功能到底值多少钱。只能靠经验，靠感觉，换个角度。。

但是靠感觉是有风险的。万一拍错了怎么办？万一客户反悔怎么办？所以尽量还是要有据可依。要有文档，要有记录，要有凭据。不能凭空捏造，我给跪了。。

五、 一下这事儿真麻烦

官宣。 反正吧，软件履约工时的确认，是一件非常麻烦的事情。它涉及到技术、管理、财务、律法等多个方面。任何一个方面出了问题，都会导致收入确认出错。

　　软件行业很特殊，它的产品是无形的，它的生产过程是不可见的，它的交付过程是动态的。这些都给工时确认带来了巨大的困难。

　　发行人需要建立一套完善的工时确认体系。这套体系要能真实地反映项目进度，要能准确地记录工作时间，要能经得起审计和监管的检验。

冲鸭！ 当然这个体系不可能完美。总会有一些瑕疵，总会有一些差异。但是只要我们能意识到这个问题，并且努力去解决这个问题，我们就能把风险降到最低。

再说说 希望所有的程序员都能按时下班，所有的项目经理都能顺利验收， 图啥呢？ 所有的财务都能安心睡觉。这就是我们最大的愿望。

毕竟写代码已经很累了不要在算工时上再折磨自己了，引起舒适。。

六、 还有什么乱七八糟的补充

哦对了还有一点。就是那个“软件著作权”。这个东西也很重要。有时候，合同里会要求提供软件著作权。如果合同签了但是著作权还没下来这时候能不能确认收入？这也是个问题，让我们一起...。

还有，那个“交付物”。交付物是什么？是代码？是文档？还是光盘？如果只是代码， 给力。 那客户拿到代码后能不能用？如果不能用，那算不算交付？算不算完成了任务？

这些问题，都是没有标准答案的。全看你怎么解释。但是解释权归谁呢？归发行人？归客户？归税务局，实际上...？

大体上... 这就像是一个无底洞。你永远填不满它。你只能在这个坑里慢慢地爬。

　　有时候，我觉得，软件行业就是一个巨大的坑。我们掉进去了就再也出不来了。我们只能在里面拼命地写代码，拼命地改Bug，拼命地确认工时。

　　这就是命。没办法的事情。

　　所以如果你问我怎么确认工时我只能告诉你：凭良心。哦不凭系统。

　　反正，就这样吧。

　　字数好像还不够。那就再写点废话。

　　软件这东西，真是让人头秃。每天面对着电脑，眼睛都花了。还要算什么工时什么收入。脑子都要炸了。

拖进度。 有时候想，如果我不做程序员，我会做什么？也许会去卖烤红薯吧。卖烤红薯多好啊，不用写代码，不用算工时不用面对复杂的客户。只需要把红薯烤熟，然后卖给路人就行了。

但是我现在是程序员。我只能继续在这里敲着键盘，写着那些没人看的代码，翻车了。。

CPU你。 有时候，我也想偷懒。我也想不记工时。我也想直接确认收入。但是不行。

　　主要原因是后面有监管。有问询函。有审计。有税务局。有老板。

他们就像一群狼，盯着我们这群羊。生怕我们多吃了一口草，极度舒适。。

内卷。 所以我们必须小心。我们必须谨慎。我们必须准确。

　　这就是软件行业的悲哀。这就是程序员的宿命。

好了不说了。我要去记工时了。不记工时就没有饭吃，人间清醒。。

　　这就是现实。残酷的现实。

---