Don't put PM's between sales reps and developers. There are two unrelated issues here.
What features are you delivering? (Only the SR knows this.)
Are you making progress; are you getting things done on time? (This is what a PM is for.)
What you want is this.
sales rep -> [ developers + PM ]
Further, you want some structure around the interaction.
You cannot allow SR to drop random requirements onto the development team. Instead you want the developers to focus ("sprint") to a goal and produce something. Once they finish a sprint, then they can meet with PM and sales folks to determine what the next sprint is.
This is the Scrum method, and it scales well. It controls interactions without putting additional people in the way of the interactions.
I would focus on your current problems versus picking a whole new process. If your primary issues involve working tracking, install a time tracking system. It will show where developers are spending time and in turn it may also show profit/loss per project.
In general, evolve your process slowly, but continuously. Monitor your problems and the actual costs of some of these problems to encourage yourself to only fix the problems that cost money or morale, not just the problems that are annoying to the bosses.
A tip: implementing any type of metrics in a business can be difficult. Make sure it doesn't come with too big of a stick and set it up in such a way that developers and sales reps are not encouraged to game the data in the same direction. Depending on your business model and each one of their deals, SRs may be prone to push up or push down the number of hours. For developers, their bias will tend to be to show they are busier than they are until somebody points out that they seem less skilled or efficient as their peers.
An added tip: If the metrics aren't going to be used to change people, collect them blindly (so the participants won't know). You will likely get the most accurate information.
对于假期/计划，看板是一种选择。其他包括 XP 和 Scrum。恕我直言，Scrum 更多的是一种管理哲学，而 XP 是一种开发方法论。 规划极限编程绝对值得一读。
客户（您的 SR）总是会尝试绕过开发过程。 “你不能把这个故事放到迭代的中间吗？”无论您选择什么方法，您都需要获得管理层的认可和支持。对于 SR 来说，好处是 (1) 他们可以优先考虑故事（功能请求），(2) 他们可以更好地了解故事何时完成。
For visibility, consider a board of some sort. We started using Kanban (one part of Lean) recently, and so far it appears to be a positive force. It attempts to even out the work load (or flow).
For vacations/planning, Kanban is one option. Others include XP and Scrum. IMHO Scrum is more a management philosophy while XP is a development methodology. Planning Extreme Programming is definitely worth reading.
Customers (your SRs) will always try to get around the development process. "Can't you just slip this story in to the middle of an iteration?" You need to get management buy-in and support on whatever methodology you pick. For the SRs, the benefits are (1) they get to prioritize the stories (feature requests) and (2) they'll have a better idea of when their stories will be done.
Being stuck in a similar situation, I'll let you know our version and how we're scaling up slowly. Generally, as in your case, our PM's manage the developers' time. We've been doing it blindly for a while, but are now using software that allows us to prioritize developer time and display it publicly to everyone in the company. All of our PM's are in the same building, so they are able to converse and decide what the developers need to work on collectively.
This process, however, is still extremely flawed. As you said, morning meetings can change the priority, but generally only if something has gone wrong in a project. I personally feel that a developer PM would solve many issues, but this would potentially help us far more since a few our our developers telecommute. Here is my advice for getting your PM processes under control:
Document everything! (Estimates, actual time spent, and what each individual is presently working on)
Use user/developer friendly software for easy collaboration between PM/Devs
Give the developers a priority queue (I prefer this to having to ask PM's what project needs done next instead of just pressing through the next task)
Continue analyzing your process and replace areas as necessary
I wish I had more info to give about down the line, but as I said I am about in the same spot - so I'm giving tips to the next level. Of course, outside of small business, this model isn't too plausible, but it is helping us move forward now.
发布评论
评论（4）
不要将 PM 放在销售代表和开发人员之间。这里有两个不相关的问题。
您要提供哪些功能？ （只有 SR 知道这一点。）
您是否取得进展？你按时完成工作吗？ （这就是 PM 的用途。）
你想要的就是这个。
此外，您需要一些围绕交互的结构。
您不能允许 SR 将随机需求抛给开发团队。相反，您希望开发人员专注（“冲刺”）一个目标并产生一些东西。一旦他们完成冲刺，他们就可以与产品经理和销售人员会面，以确定下一个冲刺是什么。
这就是 Scrum 方法，并且它具有良好的扩展性。它可以控制交互，而不需要额外的人来妨碍交互。
Don't put PM's between sales reps and developers. There are two unrelated issues here.
What features are you delivering? (Only the SR knows this.)
Are you making progress; are you getting things done on time? (This is what a PM is for.)
What you want is this.
Further, you want some structure around the interaction.
You cannot allow SR to drop random requirements onto the development team. Instead you want the developers to focus ("sprint") to a goal and produce something. Once they finish a sprint, then they can meet with PM and sales folks to determine what the next sprint is.
This is the Scrum method, and it scales well. It controls interactions without putting additional people in the way of the interactions.
我会专注于您当前的问题，而不是选择一个全新的流程。如果您的主要问题涉及工作跟踪，请安装时间跟踪系统。它将显示开发人员在哪里花费了时间，反过来它也可能显示每个项目的利润/损失。
一般来说，缓慢但持续地改进你的流程。监控你的问题以及其中一些问题的实际成本，以鼓励自己只解决那些耗费金钱或士气的问题，而不仅仅是那些让老板烦恼的问题。
提示：在企业中实施任何类型的指标都可能很困难。确保它没有太大的障碍，并以不鼓励开发人员和销售代表在同一方向上玩弄数据的方式进行设置。根据您的业务模式及其每一项交易，SR 可能会增加或减少小时数。对于开发人员来说，他们的偏见往往是表现出他们比实际情况更忙，直到有人指出他们似乎不如同龄人熟练或高效。
附加提示：如果指标不打算用于改变人员，请盲目收集它们（这样参与者就不会知道）。您可能会获得最准确的信息。
I would focus on your current problems versus picking a whole new process. If your primary issues involve working tracking, install a time tracking system. It will show where developers are spending time and in turn it may also show profit/loss per project.
In general, evolve your process slowly, but continuously. Monitor your problems and the actual costs of some of these problems to encourage yourself to only fix the problems that cost money or morale, not just the problems that are annoying to the bosses.
A tip: implementing any type of metrics in a business can be difficult. Make sure it doesn't come with too big of a stick and set it up in such a way that developers and sales reps are not encouraged to game the data in the same direction. Depending on your business model and each one of their deals, SRs may be prone to push up or push down the number of hours. For developers, their bias will tend to be to show they are busier than they are until somebody points out that they seem less skilled or efficient as their peers.
An added tip: If the metrics aren't going to be used to change people, collect them blindly (so the participants won't know). You will likely get the most accurate information.
为了可见性，请考虑某种董事会。我们开始使用看板（精益）最近，到目前为止，它似乎是一股积极的力量。它试图平衡工作负载（或流程）。
对于假期/计划，看板是一种选择。其他包括 XP 和 Scrum。恕我直言，Scrum 更多的是一种管理哲学，而 XP 是一种开发方法论。 规划极限编程绝对值得一读。
客户（您的 SR）总是会尝试绕过开发过程。 “你不能把这个故事放到迭代的中间吗？”无论您选择什么方法，您都需要获得管理层的认可和支持。对于 SR 来说，好处是 (1) 他们可以优先考虑故事（功能请求），(2) 他们可以更好地了解故事何时完成。
For visibility, consider a board of some sort. We started using Kanban (one part of Lean) recently, and so far it appears to be a positive force. It attempts to even out the work load (or flow).
For vacations/planning, Kanban is one option. Others include XP and Scrum. IMHO Scrum is more a management philosophy while XP is a development methodology. Planning Extreme Programming is definitely worth reading.
Customers (your SRs) will always try to get around the development process. "Can't you just slip this story in to the middle of an iteration?" You need to get management buy-in and support on whatever methodology you pick. For the SRs, the benefits are (1) they get to prioritize the stories (feature requests) and (2) they'll have a better idea of when their stories will be done.
由于陷入类似的情况，我会让您了解我们的版本以及我们如何缓慢扩展。一般来说，就像您的情况一样，我们的 PM 管理开发人员的时间。我们已经盲目这样做了一段时间，但现在使用的软件使我们能够优先考虑开发人员的时间并将其公开展示给公司中的每个人。我们所有的产品经理都在同一栋大楼里，因此他们能够进行交谈并决定开发人员需要共同完成哪些工作。
然而，这个过程仍然存在极大的缺陷。正如您所说，晨会可以改变优先级，但通常只有在项目出现问题时才可以。我个人认为开发人员 PM 可以解决很多问题，但这可能对我们有更多帮助，因为我们的一些开发人员远程办公。以下是我对控制 PM 流程的建议：
我希望我有更多信息可以提供，但正如我所说，我几乎处于同一位置 - 所以我 下一个级别。当然，在小企业之外，这种模式不太合理，但它现在正在帮助我们前进。
Being stuck in a similar situation, I'll let you know our version and how we're scaling up slowly. Generally, as in your case, our PM's manage the developers' time. We've been doing it blindly for a while, but are now using software that allows us to prioritize developer time and display it publicly to everyone in the company. All of our PM's are in the same building, so they are able to converse and decide what the developers need to work on collectively.
This process, however, is still extremely flawed. As you said, morning meetings can change the priority, but generally only if something has gone wrong in a project. I personally feel that a developer PM would solve many issues, but this would potentially help us far more since a few our our developers telecommute. Here is my advice for getting your PM processes under control:
I wish I had more info to give about down the line, but as I said I am about in the same spot - so I'm giving tips to the next level. Of course, outside of small business, this model isn't too plausible, but it is helping us move forward now.