將自己與軟件分開

Question

我的工作由技術分析組成。我喜歡軟件開發，但那不是我的工作。但是，我開發了一個可執行程序，庫，數據庫和模塊的實質系統。說這些產品讓每個人的工作變得輕鬆並不是不現實的。我爲每個產品製作了大量的文檔。

在我的工作中，作爲一個合理的軟件開發人員實際上可能會受到傷害（如果您的原始工作不是軟件開發），這意味着您可以很快降級到軟件維護，更糟糕的是，您可能被綁定到項目，因爲「只有你知道這個軟件」。如果你認爲在美國宇航局一個項目可以持續15 - 20年（航海家已經持續32年），這並不一定是好事。即使你和任何人一樣好，其他人也會轉向真棒旗艦項目或核心工程（我的激情）。

爲了防止這一點，我已經制定了以下規則：

如果你問一個問題，我作出迴應，但 您記錄在 官方手冊的答案;如果你要求一個功能，我會和你一起在實際的代碼中實現它。

我認爲會出現的情況是，用戶會試着問問題之前，很難（否則會記錄答案本身），和更多的人會了解軟件的內部工作作爲新的功能被添加。

足夠的上下文。

具體而言，我想知道您的軟件開發生命週期中遵循的官方流程，以確保知識在整個組織內傳輸。

我堅信這不是一個主觀問題，但會讓它成爲社區wiki來避免對抗。

謝謝。

Answer 1

確保文檔涵蓋出現的任何問題是一個好主意。這些問題上來，因爲：

• 的功能尚未記載
• 的文檔寫的，但不夠清晰，或假定一些知識，讀者還沒有獲得性（需要交叉引用，或只是一個圍繞主題位說明）
• 的人沒有閱讀文檔（他們沒有發現它，甚至都懶得尋找它）

如果用戶沒有找到它，機會你是否太有幫助，所以他們在諮詢之前詢問你文檔。你必須推回去。否則，有文件「bug」需要修復。

但是，告訴用戶必須記錄事物的方法不太可行。你會用這種方法看到的問題是：

• 大多數用戶根本不會做，除非你有足夠的影響力，迫使他們
• 最會做的不好 - 最低限度，以滿足要求
• 即使他們在做一件「好」工作時付出了一些努力，文檔仍然會因缺乏一致性而受到影響 - 就提供的信息量，所使用的語言，文檔所針對的級別而言，以及關於讀者已經知道的假設。

最終，您可能必須扮演編輯的角色，或者自己寫文檔。

你的規則的其他部分更好。不要只爲人們做事，而應該推回給他們足夠的信息，以便他們能夠幫助自己。正如您所說，這有助於傳播知識，並且還可以幫助其他人幫助您擴展系統。這個硬幣的消極方面可能是其他人也可能侵入其中，隨着時間的推移，你會發現你的整潔/有組織/穩定的結構會變得更加混亂和脆弱。

最終，可以更好地爲您服務的方法是：

• 跟你的經理，並要求你能移動到更精彩的項目，也許是用於維護的這一週的部分機會/託管職責。一位瞭解自己技能的優秀經理將盡力幫助您獲得工作滿意度和職業發展。
• 接下來的研究 - 一個初級程序員，他被帶進來幫助你維護系統，直到他有足夠的知識來接管維護者的角色。再次，這是你的經理應該採取的措施，作爲解放自己以迎接新挑戰的一種方式。提醒你的經理，你的技能對公司來說更適合新項目。
• 如果您的經理無法幫助您向前邁進，那麼我發現真正擺脫傳統軟件糾纏的唯一途徑就是等待軟件停止使用（可能會很長時間） ，或轉移到一家新公司（即時生效，但可能會讓您爲新公司重建一個類似的系統）。