我司某程式設計師近期倒閉，公司某專案即將驗收，但該程式設計師（以下簡稱小張）編寫的軟體中出現了幾個**邏輯問題，隨後被甲方催促修復！這些問題**在技術上並不難，只需要一定的時間就可以敲掉，而且問題其實早就知道了，但是軟體在研發前期就追著進度，所以這些問題是刻意放在第一位的，但是，我無法想象，這些遺留的問題會讓小張筋疲力盡！
前面說過，這些邏輯問題做起來並不難，但是需要時間，當小張解決第乙個問題的時候，原本留給小張的時間已經過去了一半，小張估計，按照這個進度，在工程驗收之前很難修復，對此，小張向我抱怨道： “要不是甲方的專案經理盯著我寫**，我想現在早就完成了吧！.””
這是從哪裡開始的？
原來不知道甲方有沒有KPI指標，甲方的專案經理催促小張在軟體驗收前解決問題。 Xiao Zhang 的第乙個問題是，專案中有乙個與裝置通訊的邏輯，與裝置的通訊需要讀寫 IO 卡，IO 卡的讀寫需要遵循一定的邏輯，雖然通訊協議本身很簡單，但 Xiao Zhang 被 IO 卡的讀寫邏輯所包圍， 所以這塊裝置的通訊一直很不正常。
如果小張乙個人靜靜地躲在角落裡，認真仔細地將IO卡的通訊邏輯與**中的通訊邏輯進行對比，那麼用不了多久，小張就能理順邏輯。
不過，甲方的專案經理總是催促小張，時不時會問小張有沒有換技能。 小張雖然心裡覺得不開心，但是他的**確實有問題，對甲方的專案經理說什麼都不好。
因為甲方的專案經理一直催促，小張在改動後測試了一下**，覺得沒有問題就把軟體給了他們，誰知道呢，軟體到了甲方還會有問題。
這樣做幾次後，不僅小張的心裡空虛，甲方也著急，於是甲方的專案經理決定拉乙個他們公司裡懂得怎麼做的人，通過一台遠端的小張電腦陪小張，協助小張理順小張的邏輯。
起初，小張並不覺得這有什麼，覺得甲方還派了乙個程式設計師站在他這邊，說不定會幫他加快進度。
然而，讓小張沒想到的是，甲方的專案經理說，如果小張在遠端，他也會盯著小張敲**，和小張實時溝通。
結果，出現了這樣一幕，小張一上班，同事們就看到小張已經在那裡和甲方這邊的人交流了！
前面說了，小張就是因為這個而疲憊不堪，也正是因為這個原因。
第一點是甲方一直在通過遠端會議指導小張敲**，但要知道，甲方的專案經理雖然懂一點程式設計，但**水平並不高，而且甲方派來協助小張的程式設計師只有兩三年的工作經驗， 而且他們沒有小張那麼有經驗。
小張原本以為甲方的專案經理只是想遠端看看小張的io卡邏輯是否正確，但隨後他開始指出小張寫的其他**邏輯。
小張說，甲方的專案經理會讓小張擴充套件張曉寫的溝通邏輯，當甲方的專案經理覺得有問題時，他會督促小張改變！
不過，小張雖然不熟悉IO卡的溝通邏輯，但他的能力並不弱，甚至很有信心，他知道甲方的專案經理認為有問題的地方絕對沒有問題，所以他會爭取。
但甲方的專案經理並不在意，丟擲了乙個張無法拒絕的理由：“反正你現在找不到原因，不如照我說的試一試！”。
無奈之下，小張只能按照甲方專案經理的要求，對**進行修改。 但是，正如小張所說，即使你改變了它，你也無法解決問題。
甚至有時候，甲方的專案經理會自以為是地認為小張**的寫作有問題，但他所理解的，就算是剛來的程式設計師也不對勁。
好在甲方的專案經理沒有糊塗，會諮詢甲方的另一位程式設計師同事，甲方的程式設計師知道專案經理提出的問題很愚蠢，但要聽從專案經理的話。
只是輾轉反側，小張基本沒有時間獨立思考，被甲方那邊的專案經理牽著走了，乙個不會程式設計的人教乙個會程式設計的人敲**，這不是浪費時間嗎？
第二點正是由第一點引起的，因為甲方專案經理的干擾，浪費了白天的時間，甲方的專案經理抓著小張不讓小張下班，而那些日子裡，小張基本上晚上10點以後就可以下班了， 而且下班也不好，有時候一回到家，就會被甲方問到。
小張覺得這種情況不會改變，他應該能夠按時解決問題，但最終，他可能無法在專案被接受之前解決所有問題。 不過，甲方終究是甲方，就算小張覺得不開心，也說不出什麼來。
對此，我只能建議小張將情況匯報給研發經理或老闆，請他們幫忙，要麼讓公司內部邏輯清晰的人協助小張完成遺留問題的修復，要麼直接幫張小解決甲方專案經理的遠端指導請求， 至少要保證小張有時間獨立思考。
不管小張怎麼說，我覺得這件事有兩個問題，第乙個問題是程式設計師不喜歡被盯著寫，因為作為程式設計師，有時候有些問題可能要查資料，被盯著寫**會造成空虛。 第二個問題是，只要本身不是問題，就算不懂程式設計的人想看程式設計師寫，如果你的程式設計能力還不如這個寫的人，最好不要說話去影響別人的思維！