我们有一个小公司团队，甚至还有一个较小的开发团队。当前流程是每个销售代表（SR）是销售的每个Web应用程序的实际项目经理。开发人员直接从SR获得需求，功能和设计。让开发人员的实际负责人了解开发人员的实际工作量。虽然我们获得了更多的项目，因此可能会有更多的销售代表和开发人员，但这个过程不可扩展。
我们已经考虑让技术总监介于SR和开发人员之间。
SR1，SR2，SR（n）---＆gt; TPM - ＆gt; DEV1，DEV2
这似乎没问题，但我们当前的流程允许我们的销售代表/ QuasiPM实际上以非常直接的方式获得开发人员的时间。他们实际上是想逃避这一点。
我们对当前流程的问题是：
SR1，SR2 - ＆gt; Dev1，Dev2（Adhoc）
我会根据收到的评论添加更多信息。感谢您一如既往的时光。
EDIT2： 一般来说，有3个SR或产品所有者，3-4个开发人员，1个技术PM。
答案 0 :(得分：2)
不要将PM的放在销售代表和开发人员之间。这里有两个不相关的问题。
您提供哪些功能？ （只有SR知道这一点。）
你在进步吗？你准时完成了吗？ （这是PM的用途。）
你想要的是这个。
sales rep -> [ developers + PM ]
此外，您需要围绕交互的一些结构。
您不能允许SR将随机需求丢弃到开发团队。相反，您希望开发人员专注（“冲刺”）到目标并产生一些东西。一旦他们完成冲刺，他们就可以与PM和销售人员会面，以确定下一个sprint是什么。
这是Scrum方法，它可以很好地扩展。它控制交互，而不会让其他人受到交互的影响。
答案 1 :(得分：1)
我会专注于你当前的问题而不是选择一个全新的过程。如果您的主要问题涉及工作跟踪，请安装时间跟踪系统。它将显示开发人员花费时间的位置，反过来也可能显示每个项目的盈利/亏损。
一般来说，慢慢地，但不断地进化你的过程。监控你的问题和其中一些问题的实际成本，鼓励你自己只修复那些花钱或士气的问题，而不仅仅是那些让老板烦恼的问题。
提示：在企业中实施任何类型的指标可能很困难。确保它不会带有太大的问题并将其设置为不鼓励开发人员和销售代表以相同方向游戏数据。根据您的业务模式和每个交易，SR可能倾向于推高或缩减小时数。对于开发者来说，他们的偏见倾向于表明他们比他们更忙，直到有人指出他们看起来不像他们的同龄人那样熟练或高效。
添加提示：如果指标不会用于更改人员，请盲目收集（因此参与者不会知道）。您可能会获得最准确的信息。
答案 2 :(得分：0)
为了提高知名度，请考虑某种类型的董事会。我们最近开始使用Kanban（Lean的一部分），到目前为止它似乎是一种积极的力量。它试图平衡工作量（或流量）。
对于假期/计划，看板是一种选择。其他人包括XP和Scrum。恕我直言Scrum更像是一种管理哲学，而XP则是一种开发方法。 Planning Extreme Programming绝对值得一读。
客户（您的SR）将始终尝试绕过开发过程。 “难道你不能把这个故事放到迭代的中间吗？”无论您采用何种方法，您都需要获得管理层的支持和支持。对于SR而言，好处是：（1）他们可以优先处理故事（功能请求）;（2）他们可以更好地了解故事何时完成。
答案 3 :(得分：0)
陷入类似情况，我会告诉你我们的版本以及我们如何慢慢扩大规模。通常，在您的情况下，我们的PM会管理开发人员的时间。我们已经盲目地做了一段时间，但现在正在使用软件，它允许我们优先考虑开发人员的时间并将其公开显示给公司中的每个人。我们所有的PM都在同一栋楼里，所以他们能够交谈并决定开发人员需要集体工作的内容。
然而，这个过程仍然存在极大的缺陷。正如您所说，早上会议可以改变优先级，但通常只有在项目出现问题时才会改变。我个人觉得开发人员PM会解决很多问题，但这可能会对我们的远程办公有一定影响。以下是我对PM流程进行控制的建议：
我希望我有更多的信息可以提供关于下线，但正如我所说，我在同一地点 - 所以我给下一级别的提示。当然，在小企业之外，这种模式不太合理，但它正在帮助我们向前迈进。