如何處理對自定義開發的恐懼

Question

我正在處理與我現在的僱主有關的一個問題，這個問題嚴重地讓我考慮在別處尋找工作。他們認爲100％的定製開發應該被淘汰，並用SharePoint等COTS產品取而代之。雖然我意識到這不是一個現實的期望，但我發現無法向管理層中的人們提出分享這些觀點的觀點。他們的論點通常涉及到SharePoint中已經存在的功能，涵蓋了功能X，因此涉及的風險較低，無需對其進行測試。

例如，我們有一種情況，SharePoint列表完全是無法滿足客戶期望和要求的。然而，將這些數據保存在SQL數據庫中很容易滿足要求。但是，只要我們的開發團隊建議超出SharePoint的界限，管理層就會大肆渲染每一行代碼如何增加項目的複雜性並增加風險。雖然在某些情況下確實如此，但並非總是如此。然而，他們的論點是，由於SharePoint提供了一種存儲數據的機制，我們應該在100％的時間內使用它。不管它是否符合客戶的要求。

我已經到了憎恨來工作的地步，因爲我經常被迫做我認識的事情（100％肯定）是不正確的，可以通過定製開發來做出正確的決定。然而，這只是我工作時似乎不可能的論點。

有任何的你經歷過類似的情況嗎？如果是這樣，你通過這些挑戰做了什麼？

Answer 1

如果您不同意公司的願景，如果你不能開導他們，那麼肯定的是，這是一個好時機，開始尋找。

你有沒有指出，在強制客戶端上的「解決方案」，不幫他們或風險缺少功能或不可用？

也許拿出計劃來解決和減輕其感知風險。

Answer 2

我做在我目前的工作，同樣的事情，有對付這種情況沒有簡單的方法。我所能做的就是吞下我的論點，因爲他們沒有讓我去任何地方，並按照我的管理層的要求去做。這種偏離課程將違揹你的基本程序員的本質，即使用最好的解決方案來完成手頭的任務，也許在這個過程中建立一些很酷的東西，但是因爲他們是老闆，所以它纔是真正的唯一解決方案。您可以嘗試使用證據來證明現場案例，使用定製解決方案更有意義。但是，如果你的老闆和我的一樣，在尖叫比賽開始之前不會走得太遠。唯一的另一個解決方案是清除簡歷並找到新工作。

Answer 3

管理中的某人是否擁有SharePoint中的庫存？該系統是由CEO的弟弟開發的嗎？

如果他們是適應變化，你應該找出試圖與他們爭辯之前的真正原因。他們可能會聲稱增加了複雜性，難以測試等等，但是如果你能夠反駁每一個表明他們的立場，以及所有應有的尊重，被誤導，並且他們仍然不會討論的論點，那麼你可能會爭論錯誤的觀點。

如果他們由於非技術原因而被鎖定在技術上，例如某人曾經讀過SharePoint是任何技術情況下的最終結果（當然，並不知道該文章談論的是什麼SharePoint = good），那麼你不應該打算爭論和節約能源。尋找工作。

Answer 4

你記錄你的顧慮，讓那些你上面的人知道他們，然後你按照他們的要求去做。如果它不起作用，那麼你有文檔可以引起你的擔憂。但試着讓它按照他們的方式工作，所以它看起來並不像是在試圖破壞他們的計劃。他們承擔更大的風險，因此他們承擔更大的責任。盡你所能讓它按照自己的方式工作，並放棄擔心。

Answer 5

證明給他們。當需求要求一個能夠處理多列排序的100,000個項目的列表時 - 編寫一個腳本，該腳本將100,000個測試項目添加到SharePoint列表並讓他們嘗試，最好由「客戶」請求列表監視。 :-)

Answer 6

從第一天起我就面臨同樣的挑戰。管理層很自然地不願意爲解決方案添加自定義代碼。然而，在大多數情況下，解釋比客戶的正確解決方案包含一些自定義代碼還好。請記住，如果您認爲自定義代碼可以包含在公共代碼庫中，那麼老闆可能會批准該想法。

Answer 7

如果我是你的話，我一定會把我的簡歷發佈出去。不僅是你現在感到沮喪的經歷，它可能會長期影響你的職業發展。考慮一下。當你在目前的職位上與目前的僱主相處融洽時，其他開發人員正在採用新技術並擴展他們的經驗。

有這樣的事情，開發者之間的意識形態差異以及公司對開發者角色的想法是什麼。如果公開的討論和坦誠讓你無處可尋，那麼你不會因缺乏努力而犯錯。對一家公司的忠誠是一件好事，但這種關係必須是雙向的。

不幸的是，最終可能會意識到他們的假設是錯誤的 - 但是你不能等待那一天的到來。有時它永遠不會到來。尤其是（並且不要誤解我的意思，我喜歡SharePoint的用途，因爲SharePoint的目的是爲了它的用途），SharePoint正在成爲下一個Access，因爲閱讀管理雜誌的人看到了足夠多的內容，稱之爲彌賽亞。

Answer 8

我真的感到你的痛苦。

如果是我，我會利用業餘時間收集證明我的觀點並以易懂的方式記錄下來的信息。

如果他們只懂金錢，那就說說錢吧，如果他們只懂恐懼（因爲害怕「那個」，所以「做這個」），用恐懼，在他們的「解決方案」中爲他們找到可怕的東西。

記錄每個新的實現，時間，金錢和出現的問題。並記錄你的解決方案將取而代之。

他們可能不會在他們的解決方案中看到問題，因爲他們專注於在「您的」解決方案中沒有問題。

Answer 9

這聽起來很糟糕，可能不是您想要的答案。我的辦公室裏有一個叫做「臭鼬工廠」的鮮爲人知的分部。人們自己決定（通常在午餐時間或編譯時間）決定編寫幫助公司的小程序。關於這件事的有趣之處在於結果並沒有使公司「花費」任何東西。

的對話通常是這樣的：

「我們需要購買此軟件」 -Boss

「但是，我們有那個東西了幾個月約翰寫道，早在天。」 - 程序員

「？」 -Boss

很多時候，開發人員認爲這是一個糟糕的決定，只是創建一個自動發生的並行進程。然後，當東西擊中粉絲並且顧客感到沮喪時，備用解決方案已經到位。

我有一個自動釋放機器的例子。開發人員用於創建這些自定義報告。隨着我們的客戶增加，開發者的工作量增加。問題在於「爲了讓客戶得到定製報告開發者必須參與的事情。」因此，在公司希望聘請某人全職報告或想方設法讓客戶完成報告時，我編寫了一個自動發佈機器，用於查找報告變更並將其直接發佈給客戶。我還編寫了一個實用程序，允許任何人對比開發人員更易於使用的報告進行更改。當老闆宣佈試圖尋找解決方案時，我告訴他這已經到位，甚至他可以對報告進行更改並讓他們發佈。現在，每個人都可以更改報告，通常是進行這些更改的管理層和客戶支持人員。有趣的一面是開發者不再參與其中。

只要做到這一點。如果你要退出，不妨試試。

Answer 10

我曾經在一個管理層沒有建設性的地方工作，並不像你描述的那麼糟糕，但是夠糟糕。

有幾個選項。一種是繼續前進，爲客戶做最需要的「物有所值」選擇。您可能必須讓開發者團隊合作，才能使這種「公民不服從」行爲起作用。

更有力的方法，將真正使狗屎命中風扇是去給客戶（不這樣做，如果它是一個外部客戶端，或者如果你想保持你的工作），並奠定了是怎麼回事發生在這個項目上，如果X和Y.這是非常講故事的故事，將是壞的，但有趣。

一個稍微好一點的方法是上鍊，找一個能夠讓你的狗屎發生的贊助商。基本上是回到老闆的後面。這可能會奏效，但它會爲您與管理層的關係帶來可預測的結果。

最後也是最難的是找出認爲任何自定義代碼不好的觀點的人，並讓他們參與對話以找出他們在哪裏得到了信仰並用示例反駁。強調談話，因爲您必須傾聽並理解他們的潛在顧慮（不會涉及自定義代碼本身），只有在您獲得該人員信任後才能解決這些問題。

我不能告訴你哪種做事方式最好，因爲它很大程度上取決於所涉及的個人。我所知道的是，你不能改變人，以我的經驗，解決問題的最好辦法是離開並與不是那樣的人一起工作......

Answer 11

我發現通常沒有辦法通過談話贏得這些辯論。許多管理者通過閱讀管理導向的文章形成產品或解決方案的意見。看看你能否找到一些反制品。

如果你能舉出的東西的SharePoint是不能這樣做的例子，顯示瞭如何可以成本有效解決通過定製開發這些問題的例子，那麼你對你的方式。

錯誤在於試圖讓這個關於技術的談話不是關於效率，成本效益和可維護性 - 這些都是影響非技術管理者考慮替代方案的咒語和衡量標準。

如果您能爲這些問題的概念證明做得更好，eye candy確實有助於在技術團隊之外進行銷售。

最後，祝你好運:)

Answer 12

如何不把它稱爲自定義代碼。相反，如果您將其稱爲「預期的SharePoint用戶擴展」，或者它可能會減輕圍繞特定術語的誤解。

另外，如前所述，可能還有其他隱藏的理由，管理層正在推動這一議程。最好不要再次猜測它們，因爲很多情況都是有效的。

最後，還有很多需要開發的地方。它不會傷害尋找更好的匹配。

好運。