将自己与软件分开

Question

我的工作包括技术分析。我喜欢软件开发，但这不是我的工作。但是，我开发了一个可执行程序，库，数据库和模块的实质系统。说这些产品让每个人的工作变得更轻松并不是不切实际的。我为每种产品都制作了相当数量的文档。

在我的工作中，作为一个相当称职的软件开发人员实际上可能会受到伤害（如果您的原始工作不是软件开发），这意味着您可以迅速降级到软件维护，更糟糕的是，您可能与项目联系在一起因为“只有你知道软件”。如果你认为NASA的一个项目可以持续15到20年（旅行者已经持续了32年），那不一定是件好事。即使你和其他人一样好，其他人也会进入令人敬畏的旗舰项目或核心工程（我的热情）。

为了防止这种情况，我制定了以下规则：

  

如果你问一个问题，我会回答   你记录了答案   官方手册;如果您要求提供功能，我将与您一起在实际代码中实现它。

我认为会发生的是用户在提问之前会更加努力（否则他们必须自己记录答案），并且随着新功能的增加，更多人将学习软件的内部工作原理。

足够的背景。

具体而言，我想知道您的软件开发生命周期中遵循的官方流程，以确保知识在整个组织内传输。

我坚信这不是一个主观问题，但会让社区维基避免对抗。

谢谢。

Answer 1

确保文档涵盖出现的任何问题是一个好主意。出现这些问题是因为：

• 该功能尚未记录
• 文档是写的，但不够清楚，或者假定读者尚未获得某些知识（需要交叉引用或只是对该主题的更多解释）
• 该人没有阅读文件（他们没有找到或甚至没有找到它）

如果用户没有找到它，可能是你太有帮助了，所以他们在咨询文档之前就会问你。你必须推迟。否则，需要修复文档“错误”。

然而，告诉用户他们必须记录事物的方法不太可行。您将通过这种方法看到的问题是：

• 大多数用户根本不会这样做，除非你有足够的影响力强迫他们
• 大部分人都会做得很差 - 最低限度满足要求
• 即使他们付出了一些努力去做“好”的工作，文档仍然可能缺乏一致性 - 从提供的信息量，使用的语言，文档的目标水平来看以及关于读者已经知道的假设。

最终，您可能需要担任编辑，或自己编写文档。

你的规则的另一部分更好。不仅仅是为人们做事，而是回过头来给他们足够的信息以便他们自助。正如您所说，这有助于传播知识，并使其他人能够帮助您扩展您的系统。这个硬币的负面影响可能是其他人也可能会破解内容，你会发现你的整洁/有组织/稳定的结构随着时间的推移开始变得更加混乱和松懈。

最终，可能更好地为您服务的方法是：

• 与您的经理交谈并要求您有机会继续参与更激动人心的项目，可能会将您一周的一部分时间分配给维护/保管人员。一位欣赏自己技能的优秀经理将尽力帮助您获得工作满意度和职业发展。
• 接受一个替补学习 - 一个初级程序员，在他有足够的知识接管维护者的角色之前，他会帮助你维护系统。同样，这是与您的经理一起接受的一种方式，可以让您自己接受新的挑战。提醒您的经理，您的技能对新项目的公司更有用。
• 如果您的经理无法帮助您前进，我发现真正摆脱遗留软件纠缠的唯一方法是等待软件停止使用（可能需要很长时间） ，或转移到一家新公司（它具有即时效果，但可能会让您从头开始为新公司重建类似的系统）。