在將開發(fā)工作外包給遠程團隊之前，您可能已經(jīng)讀過有關雇用離岸開發(fā)人員的利弊的信息。我想您知道外包的優(yōu)勢是削減成本，員工靈活性，專注于核心活動和團隊的高效率。缺點：缺乏控制，語言障礙，知識產(chǎn)權問題以及您所在國家的失業(yè)。根據(jù)可用的文章，相同的內容可以使外包更具誘惑力。

作為在外包領域工作了三年的人，我想知道為什么沒有人告訴我有關資本流入，難以管理的工作分配以及雙方之間風險分擔的好處。也沒有人提到諸如擴大管理力度，客戶和供應商的利益競爭，與任何一方有關的不穩(wěn)定風險以及供應商的機會主義威脅等缺點。但是，作為一名營銷人員，我知道重寫文字的文案作家比首先研究然后創(chuàng)建原創(chuàng)文章的內容作家要多。

我的意思是說撰稿人告訴您的故事可能會誤導您，并不一定反映撰稿人的能力。有幾個原因。首先，很少有供應商雇用文案作家并撰寫內容，因為競爭對手也這樣做。其次，沒有廠商告訴您作弊的方式。

　　那么，他們將如何欺騙您？

讓我們回到開發(fā)人員的代碼質量變差的情況。我不排除黑暗時期的選擇，或者如果僅持續(xù)一周或更短時間，則不會排除排列錯誤的恒星。除非代碼質量好轉，否則我?guī)缀蹩梢钥隙ㄖ滥墓炭赡軙δ褂糜白幽Ｊ健?/p>

影子模式是某些IT服務供應商使用的機會主義做法。想法是該機構為您提供面試所需的專業(yè)人員，因此您可以毫不猶豫地雇用他們。一段時間后，代理商所有者在您不知情的情況下成立了經(jīng)驗不足的開發(fā)人員。結果是您為降低代碼質量付出了相同的代價。賣方還可以通過將其頂級雇員分配給其他項目來獲得收益。

　　在開發(fā)過程中，它看起來是這樣的：

　　由高級工程師編寫的代碼示例：

app.update(

'/api/v1/task',

[authMiddleware({ role: ROLES.user }), validateBodyMiddleware(taskUpdateSchema)],

async (req, res) => {

const { taskID, description } = req.body;

try {

res.json(await taskService.updateDescription(req.user.id, taskID, description));

} catch (e) {

res.status(500).json({ error: getErrorMessage(e.code, req.user.locale) });

}

}

);

低質量工程師在影子模式下編寫的同一代碼示例，他們對特定技術的設計模式，架構思想和最佳實踐一無所知：

app.post('/update-task', (req, res) => {

const session = req.cookies['session'];

const user = getUserBySession(session);

if (user.role < 2) return res.status(403).json({ error: 'You are not allowed here' });

if ('taskID' in req.body && 'description' in req.body) {

const db = getDbConnection();

db.query(

'UPDATE "Tasks" SET description = '' +

req.body.description +

'' WHERE "taskID" = ' +

req.body.taskID +

' AND "userID" = ' +

user.id

)

.then((res) => {

db.query('SELECT * FROM "Tasks" where taskID = ' + req.body.taskID)

.then((task) => {

res.json(task);

})

.catch((err) => {

res.status(500).json({ error: 'Something happened...' });

});

})

.catch((err) => {

res.status(500).json({ error: err.message });

});

} else {

res.status(400).json({ error: 'Bad query' });

}

});

　　對“影子模式”一無所知

每當我告訴同事有關陰影模式的信息時，他們都會問我它是什么。一旦我描述了陰影模式的狀態(tài)，我就看到了他們的“啊哈”時刻。幾乎每個人都知道這一點，但不知道這種做法的名稱。這表明，在觀察，聽到或可能已經(jīng)參與此過程的過程中，提供離岸IT服務的開發(fā)人員和管理人員。

實際上，對于項目所有者而言，關于此問題的信息非常有限。我只能想象，通過將頂級員工分配給其他項目，供應商可以獲得多少收益。

　　屏幕跟蹤器或其他工具有幫助嗎？

恐怕供應商想欺騙您，他們會想出辦法。

屏幕跟蹤器可幫助您跟蹤開發(fā)人員工作多少小時，或他們花費多少時間瀏覽Stackoverflow，但這并不能保護您的項目免受諸如陰影模式之類的欺詐行為的侵害。例如，假設您開始在雇用的高級開發(fā)人員的筆記本電腦上使用屏幕跟蹤工具。代理商所有者可以將此筆記本電腦傳遞給影子開發(fā)人員，您將看到的都是相同的桌面，開發(fā)人員帳戶，IDE和工具。即使視頻通話也沒有用，因為兩個開發(fā)人員都可能在同一辦公室工作，因此在客戶給您打電話時切換席位并不是問題。因此，客戶會產(chǎn)生虛假的安全感，而不是針對欺詐的保護。

如何在沒有任何工具的情況下避免產(chǎn)品欺騙

為了避免給您模糊的建議，我將嘗試編寫一種算法，以幫助您了解在所有開發(fā)階段都需要尋找什么。

雇用工程師之前：

· 檢查供應商的可靠性。受信任的開發(fā)機構具有一些共性：法人實體，案例研究和流行目錄的評論。法人實體讓您感到受保護，知道如果出了問題，法律就在您身邊。最好的選擇是當供應商在您所在國家/地區(qū)擁有實體以簡化所有法律和付款流程時。案例研究表明該機構的工程師如何在與您相似的行業(yè)中開發(fā)產(chǎn)品。此外，如果您有空閑時間，可以在權威網(wǎng)站上查看評論。這些評論并不總是反映該機構的真實評估，但會為您提供一些信息。

· 充分檢查合同。請記住，合同同時保護了客戶和賣方的權利。最好通讀合同的一般條款，必要時添加其他條件，最后簽署協(xié)議。如果您有疑問或疑慮，請尋求法律專家的指導。

　　與工程師一起工作時：

· 在內部管理開發(fā)過程。這有助于您監(jiān)視進度并親自查看所有組織更改。如果您沒有時間自己管理團隊，則可以聘請CTO或PM。這確保了不為供應商工作的內部經(jīng)理不會為開發(fā)機構的利益服務。

· 直接與開發(fā)人員溝通。當您聊天，舉行日常站立會議或使用其他方式與開發(fā)團隊交談時，您將了解開發(fā)人員的行為方式。因此，您很可能會發(fā)現(xiàn)開發(fā)人員是否打算做其他事情。同樣，您可以將此責任委托給您的代理人。

· 跟蹤代碼模式。每個開發(fā)人員都有唯一的作者身份歸屬代碼。我工作的公司建立了一個工具，該工具可以通過20個不同的標準來跟蹤代碼的作者身份，其中包括：注釋中符號的平均數(shù)量，最常用的變量命名，代碼結構，代碼耦合等。可以手動跟蹤此類模式，但需要一些時間。

注意：最后的建議適用于那些擅長編程的人。如果您不是技術人員，那么評估代碼質量將是一個挑戰(zhàn)。

您還可以考慮使用Asana，Jira，Trello之類的PM工具，向以前的客戶征求反饋，并尋求IT顧問的幫助。

　　為什么這很重要？

產(chǎn)品的失敗不僅是由于缺乏動力或投資不足，而且還因為低技能的工人發(fā)揮了重要作用。入門級開發(fā)人員沒有完全意識到項目結構的范圍，因此，即使對代碼進行少量更改而沒有這種了解，也會使產(chǎn)品陷入不確定的狀態(tài)。這可能導致長時間的應用程序/頁面加載，安全漏洞，性能問題以及不正確的應用程序工作流程。這種不稱職會影響通用應用程序體系結構，因此所有進一步的應用程序開發(fā)和維護都將花費更多的精力和成本。

以上就是關于揭秘外包的陰暗面的全部內容介紹，想了解更多關于IT項目外包的信息，請繼續(xù)關注中培偉業(yè)。