让开发人员执行项目管理的软件经理

我是一家嵌入式系统公司的软件开发人员。我们有一个项目经理，他负责整个项目进度表（包括电气，质量，软件和制造），因此他的软件进度表非常简短。

我们还有一个软件经理，我的老板。他让我编写和维护软件进度表，设计文档（高低级设计），SRS，变更管理，验证计划和报告，发布管理，审阅，当然还有软件。

我们整个软件团队只有一名测试工程师（十名成员），并且在任何给定时间，都有几个项目正在进行。

我花了80％的时间制作这些文档。我的老板来自流程方面，并且认为我们需要更好的文档来改进软件：

1. 他认为设计是最重要的，编码是“只是将设计写下来”，时间不要太长，并且“所有代码都应在硬件准备好之前编写”。
2. 即使我们告诉他与分布式模型的协作更轻松，也不了解中央版本控制和分布式版本控制之间的区别。
3. 不懂代码，想了解每个错误及其建议的解决方案。
4. 认为验证应由开发人员完成，测试人员应进行验证。事实是，我们的验证仅检查实现是否正确（我们不编写单元测试，在计划中从未考虑过），而验证是黑盒测试，因此缺少单元测试。

我真的很困惑

1. 我负责维护所有这些文件吗？本质上，这让我感到自己正在执行软件项目管理。我可以接受技术文档，但我相信开发人员不应该进行计划/计划。
2. 我不太喜欢创建文档，我想解决问题并编写代码。以我的经验，创建设计文档只会在一定程度上有所帮助，而对于更好或更快速的代码来说却无济于事。
3. 我觉得老板并不真的在乎制造更好的产品，而只是在管理层眼中成为一名好经理。

我能做什么？整整一年，我已经完成了3个月的实际编码，其余时间仅用于制作文档和等待来自客户的错误报告。

您听起来像软件工程师。

项目经理更加关注整个项目的状态，并以有效的方式分配资源，以确保在适当的时机实现里程碑。他们还消除了障碍，并帮助项目资源专注于其特定的工作职能。

编写和维护设计与技术文档是成为软件工程师的重要组成部分，适合您的角色。太多的好事可能是坏的（请参阅Analysis Paraylsis）。

他认为设计至关重要，编码是“只是将设计写下来”

如果项目经理认为设计文件至关重要，那么他希望这些文件在过程中可以交付。如果他觉得他们足够重要，可以将您80％的时间分配给您，那不是浪费时间。

它应该不会花太长时间，并且“所有代码都应在硬件准备就绪之前编写”。

这是一厢情愿的想法，并且是关于软件开发工作原理的过时的瀑布式视图。无论您投入多少设计和准备工作，它总是永远不会那么干净。但是，在此注意事项上，您应该具有清晰的硬件规格和正确的测试环境，以及与代码进行交互的模拟硬件仿真，但现实世界还是很混乱的。

在理想的世界中，项目管理非常容易。这个世界并不完美，但是无论您多么希望它如此，这都会使真正的项目管理变得异常困难。这就是为什么向他们支付巨额费用的原因。

（2）不了解中央版本控制和分布式版本控制之间的区别。

他为什么要在乎？它如何影响里程碑？没有。

3）不了解代码，想了解每个错误及其建议的解决方案

他的目标是开发软件，而您的目标也应该是。他不需要理解代码，但是他确实需要了解阻碍软件正常运行的问题。一旦你们两个在这个基本水平上达成共识，那么您的共同目标将帮助您更有效地合作。

（4）认为验证应由开发人员完成，并由测试人员进行验证。

这种情绪有什么问题？担任质量保证角色的测试人员应关注验证功能和要求。在进行测试之前，开发人员应尽一切努力来验证和测试他们的工作。

我不太喜欢创建文档，我想解决问题并编写代码。

如果您想成为一名简单的程序员，那么也许您应该与老板讨论一下，看看您在项目中是否有更好的角色。有人需要编写和维护技术文档，因此也许其他开发人员之一可以帮助您完成其中一些任务，因此您不必花费80％的时间编写文档。

以我的经验，创建设计文档只会在一定程度上有所帮助，而对于更好或更快速的代码来说却无济于事。

这基本上是正确的……但前提是所有十名开发人员都花80％的时间来编写技术文档，而这些文档是没人会读过的。这是我以前住过的一个巨大的管理反模式。如果您发现自己正在为团队做大部分文档，那么您被剥夺执行更多编码工作的权利似乎并不公平。

事实是，最好的技术文档是代码本身。

我觉得老板并不真的在乎制造更好的产品，而只是在管理层眼中成为一名好经理

我觉得他确实很在意，因为产品是他的病房，如果项目和功能没有完成并且客户不满意，那么高层管理人员就不会非常在乎他。问题在于您对必要的质量改进的看法与他和他的高层管理人员以及客户对他们认为重要的看法不符。

尝试了解对产品真正重要的是什么，因为虽然您可以将流程的效率提高三倍，但是如果您花整整一个星期的时间来做，那么这是以客户要求的另一个重要功能为代价的。

我们所有人都希望在上级领导的眼中看起来很好。这样做没有错，自我服务是人类的天性。这是事实。

在某种程度上，我同意您的项目经理。软件开发远远超出了编码功能。:-)

考虑到您的情况，我将向他解释说，他的请求占用了您80％的时间，并试图理解为什么花时间来维护文档而不是进行开发（这超出了编码）对他来说很重要。

仅供参考，Atlassion是一家软件公司，每个QA人员拥有13名开发人员，并且大多数测试（计划和执行）由开发人员完成。我在敏捷2012和他们的团队中的一个演示中了解到了这一点，我目前正在尝试模仿这种做法。

但是，我还将与您的项目经理讨论他是否愿意尝试Scrum作为一种方法来帮助推动整个团队前进。根据您的描述，我认为您没有使用Scrum。

像您一样，我对不断变化的计划感到非常沮丧，而Scrum轻量级方法帮助我克服了这种挫败感。

根据我的经验，绩效最高的团队是完成工作所需的流程最少的团队。在某个时候，附加的过程开始使产品失去质量。如果质量检查人员开始因为遗漏错误而错过了错误，因为他们更关心将文书工作排除在外，而DEV则因为编写文档而没有编写功能或修复错误，那么您就遇到了问题。但是，弄清您公司中的实际情况是一个高度本地化的问题，只有您团队中的人才能回答（不是我们）。

您老板的一件事很不对劲，那就是您的QA很少而且没有单元测试。根据定义，开发人员创建的错误是对他们的疏忽。期望开发人员始终测试自己的功能，除此之外几乎没有测试是一个过程问题。可以根据您所在的域在一定程度上用自动测试来代替QA，但是如果您没有，则可能会让漏洞漏掉（通常导致费用比尽早发现它们要高）。

同样，从严格的业务角度来看，雇用质量保证人员比雇用开发人员便宜。如果团队具有良好的QA / DEV比率，您将能够为所花的资金提供更多的支持。

我已经看到或直接听到的CMMI实施过程都非常繁琐，而且文档繁重。您的老板认为文档应该足够详细，以使实现变得微不足道，这强烈暗示着他的期望是相似的。

如果您在文档编写/维护中收到的份额不成比例，则要求将其更均匀地分发是合理的。如果其他开发人员的文档与编码比例相似，并且您想花费大部分时间编写代码，现在可能是时候考虑寻找新雇主了。

您在谈论医疗系统...因此安全至上-因此文档（特别是可追溯性）至关重要。

一位测试人员看起来有些轻松，但是除此之外，是的-您有责任确保文档就位。

我在医学界的经验是有限的，但是在航空航天/国防界，我们有Do-178B（现为C），它规定了生命周期模型，用于指定必要的文档和测试级别（取决于安全性[更具体地，软件的设计保证级别），并且在汽车领域，我们也有ISO26262。

如果没有适当的文档，则该产品不会获得认证。

但是重要的是要使用必需的文档来使您的产品更好。...不要以事后的方式对文档进行反向工程，因为那样做就没有现实意义。