我司某程序员近期倒闭，公司某项目即将验收，但该程序员（以下简称小张）编写的软件中出现了几个**逻辑问题，随后被甲方催促修复！这些问题**在技术上并不难，只需要一定的时间就可以敲掉，而且问题其实早就知道了，但是软件在研发前期就追着进度，所以这些问题是刻意放在第一位的，但是，我无法想象，这些遗留的问题会让小张筋疲力尽！
前面说过，这些逻辑问题做起来并不难，但是需要时间，当小张解决第一个问题的时候，原本留给小张的时间已经过去了一半，小张估计，按照这个进度，在工程验收之前很难修复，对此，小张向我抱怨道： “要不是甲方的项目经理盯着我写**，我想现在早就完成了吧！.””
这是从哪里开始的？
原来不知道甲方有没有KPI指标，甲方的项目经理催促小张在软件验收前解决问题。 Xiao Zhang 的第一个问题是，项目中有一个与设备通信的逻辑，与设备的通信需要读写 IO 卡，IO 卡的读写需要遵循一定的逻辑，虽然通信协议本身很简单，但 Xiao Zhang 被 IO 卡的读写逻辑所包围， 所以这块设备的通信一直很不正常。
如果小张一个人静静地躲在角落里，认真仔细地将IO卡的通信逻辑与**中的通信逻辑进行对比，那么用不了多久，小张就能理顺逻辑。
不过，甲方的项目经理总是催促小张，时不时会问小张有没有换技能。 小张虽然心里觉得不开心，但是他的**确实有问题，对甲方的项目经理说什么都不好。
因为甲方的项目经理一直催促，小张在改动后测试了一下**，觉得没有问题就把软件给了他们，谁知道呢，软件到了甲方还会有问题。
这样做几次后，不仅小张的心里空虚，甲方也着急，于是甲方的项目经理决定拉一个他们公司里懂得怎么做的人，通过一台远程的小张电脑陪小张，协助小张理顺小张的逻辑。
起初，小张并不觉得这有什么，觉得甲方还派了一个程序员站在他这边，说不定会帮他加快进度。
然而，让小张没想到的是，甲方的项目经理说，如果小张在远程，他也会盯着小张敲**，和小张实时沟通。
结果，出现了这样一幕，小张一上班，同事们就看到小张已经在那里和甲方这边的人交流了！
前面说了，小张就是因为这个而疲惫不堪，也正是因为这个原因。
第一点是甲方一直在通过远程会议指导小张敲**，但要知道，甲方的项目经理虽然懂一点编程，但**水平并不高，而且甲方派来协助小张的程序员只有两三年的工作经验， 而且他们没有小张那么有经验。
小张原本以为甲方的项目经理只是想远程看看小张的io卡逻辑是否正确，但随后他开始指出小张写的其他**逻辑。
小张说，甲方的项目经理会让小张扩展张晓写的沟通逻辑，当甲方的项目经理觉得有问题时，他会督促小张改变！
不过，小张虽然不熟悉IO卡的沟通逻辑，但他的能力并不弱，甚至很有信心，他知道甲方的项目经理认为有问题的地方绝对没有问题，所以他会争取。
但甲方的项目经理并不在意，抛出了一个张无法拒绝的理由：“反正你现在找不到原因，不如照我说的试一试！”。
无奈之下，小张只能按照甲方项目经理的要求，对**进行修改。 但是，正如小张所说，即使你改变了它，你也无法解决问题。
甚至有时候，甲方的项目经理会自以为是地认为小张**的写作有问题，但他所理解的，就算是刚来的程序员也不对劲。
好在甲方的项目经理没有糊涂，会咨询甲方的另一位程序员同事，甲方的程序员知道项目经理提出的问题很愚蠢，但要听从项目经理的话。
只是辗转反侧，小张基本没有时间独立思考，被甲方那边的项目经理牵着走了，一个不会编程的人教一个会编程的人敲**，这不是浪费时间吗？
第二点正是由第一点引起的，因为甲方项目经理的干扰，浪费了白天的时间，甲方的项目经理抓着小张不让小张下班，而那些日子里，小张基本上晚上10点以后就可以下班了， 而且下班也不好，有时候一回到家，就会被甲方问到。
小张觉得这种情况不会改变，他应该能够按时解决问题，但最终，他可能无法在项目被接受之前解决所有问题。 不过，甲方终究是甲方，就算小张觉得不开心，也说不出什么来。
对此，我只能建议小张将情况汇报给研发经理或老板，请他们帮忙，要么让公司内部逻辑清晰的人协助小张完成遗留问题的修复，要么直接帮张小解决甲方项目经理的远程指导请求， 至少要保证小张有时间独立思考。
不管小张怎么说，我觉得这件事有两个问题，第一个问题是程序员不喜欢被盯着写，因为作为程序员，有时候有些问题可能要查资料，被盯着写**会造成空虚。 第二个问题是，只要本身不是问题，就算不懂编程的人想看程序员写，如果你的编程能力还不如这个写的人，最好不要说话去影响别人的思维！