Project management 为我们的开发过程添加更多结构？

我与一个小团队（4名开发人员）合作，为我们的定制硬件编写固件和软件。我正在寻找更好的方式来组织团队，更好地定义流程

我们当前的设置

• 开发人员通常一次处理2-3个项目

• 我们的项目是以迭代的方式工作的，开发人员定期与客户联系，慢慢地添加特性并修复bug

• 我们也有固定交付日期的项目，交付周期长，最终硬件可能在交付前几周出现。固定项目通常是对现有产品或实现的微小更改，并且工作以某种方式混合在一起

• 我们也在从咨询转向产品，所以我们偶尔会增加一些我们认为会增加价值的功能，这些功能都是我们自己承担的

问题

我们每周召开一次会议，在会上为每个项目分配一定比例的时间。“客户A希望下周测试功能X”，因此分配了所需的时间。“客户B与Y有问题，开发人员P可以开车下来看看吗？”，等等

当我们忙的时候，这些计划会被很松散地执行。问题出现了，低优先级的东西被推后。有时，开发人员不清楚优先级，所以当优先级发生变化时，会产生摩擦。下周，我们将意识到我们在Z项目上落后了，我们都度过了漫长的几天

有人告诉我，对于我们这个行业的小型初创企业来说，这是很常见的，但我只是想办法限制通宵“办公室里的比萨饼”的数量

有人告诉我，对于我们这个行业的小型初创企业来说，这是很常见的，但我只是想办法限制通宵“办公室里的比萨饼”的数量

我们不都是

“客户A希望下周测试功能X”，因此分配了所需的时间

谁分配的

你有自己的时间表吗？如果不是，管理层为您创建时间表的唯一反应就是通宵

现实的非通宵时间表将困扰管理层。除非你能证明你的客户想要一个通宵更少的更好的时间表，否则你就无能为力了

减少通宵达旦的唯一办法就是早点把事情做完。但是如果硬件不能更快到达，你就无能为力了，是吗

开发人员通常一次处理2-3个项目

一心多用效率低得令人难以置信。将大脑从一项任务切换到另一项任务需要时间来切换

当我们忙的时候，这些计划会被很松散地执行

那为什么要制定计划呢

是否可以只让一名开发人员负责一项任务/产品/客户？那么开发者P是唯一一个和客户B交谈的人？（当然，开发人员需要准确记录自己在做什么，以防被公交车撞到，但无论如何，他都应该记录问题和路线图。）

下周，我们将意识到我们在Z项目上落后了，我们都度过了漫长的几天

如果ProjectZ上只有一个开发者，他就不会被客户A的问题分散注意力

---

不要考虑开发人员为一个客户群服务，而是考虑一个开发人员为一个给定的客户服务。（这可能会使假期计划变得更加困难，但如果你总是通宵工作，那么你无论如何都没有花足够的时间离开办公室。）

我建议你遵循Scrum框架。使用企业产品创建Scrum环境。让产品团队为自己的单个产品开发功能，这是组合企业产品的一部分。如果您有足够的资源，请组建一个生产/问题支持和基础架构Scrum团队。如果问题来得太快，请让基础架构团队尝试遵循看板或Scrumban

---

如果采用得当，Scrum框架本身将解决大部分问题。

两个想法：提高质量和改进评估

我在一家生产产品的小软件店工作。我们和我在一家类似规模的商店工作过的最显著的区别是全职QA（现在不止一家）。这个人在第一天应该带来的价值在测试完成之前不是测试。我们使用。采用这种方法有几个原因：

重复测试以查找回归错误。你换了什么东西，它坏了什么

思考如何提前测试功能——这是开发人员和QA之间的一项紧密合作的活动，如果这没有什么坏处，那么您可能是做错了

让其他人测试和验证您的代码是一个好主意 在评估活动周围建立一些结构。重复使用一种格式，无论是Excel、MS Project还是其他格式（至少是数字格式）。这样做，您将开始看到围绕构建软件所做的工作重复的模式。一般来说，在您的评估中包括思考it（也称为设计）、构建、测试（QA）、修复和部署的时间。另外，读一下麦康奈尔的书，用你认为值得的任何东西，这是一本很棒的书

---

低质量意味着更长的开发周期。最有效的步骤是QA，而不是单元测试。如果它是一个web应用程序，我也会建议像Selenium这样的东西，但你要处理的是硬件，所以不确定能做什么。改进估计意味着能够尝试预测什么时候事情会变得糟糕，这听起来可能不算多，但提前知道可能是一种宣泄

对于基于固定工期的项目，我们通常会很好地参与进度计划。增量项目更加困难