在小型开发公司中,什么是可扩展的项目管理过程?

不要把PM的 之间 销售代表和开发人员。这里有两个不相关的问题。

• 您提供了哪些功能?(只有SR知道这一点。)

• 你正在进步;你能按时完成工作吗?(这就是PM的作用。)

sales rep -> [ developers + PM ]

此外,您还需要一些围绕交互的结构。

您不能允许SR将随机需求放到开发团队中。相反,您希望开发人员专注于一个目标并产生一些东西。一旦他们完成一个冲刺,然后他们可以与PM和销售人员会面,以确定下一个冲刺是什么。

Scrum 方法,并且它具有良好的伸缩性。它控制交互,而不会让其他人妨碍交互。

我会关注你当前的问题,而不是选择一个全新的流程。如果您的主要问题涉及工作跟踪,请安装时间跟踪系统。它将显示开发商在哪里花费时间,反过来也可能显示每个项目的利润/亏损。

一般来说,缓慢但持续地发展您的流程。监控你的问题和其中一些问题的实际成本,鼓励自己只解决那些耗费金钱或士气的问题,而不仅仅是那些令老板恼火的问题。

提示:在企业中实现任何类型的指标都可能很困难。确保它不会带有太大的棍子,并以这样一种方式设置它,即不鼓励开发人员和销售代表朝着同一方向玩数据游戏。根据您的业务模式和他们的每一笔交易,SRs可能会增加或减少小时数。对于开发人员来说,他们的偏见倾向于表明他们比现在更忙,直到有人指出他们似乎不如同龄人熟练或效率。

另外一个提示:如果这些指标不用于改变人们,那么盲目地收集它们(这样参与者就不会知道)。你可能会得到最准确的信息。

为了能见度,考虑某种类型的董事会。我们开始使用 Kanban Lean )最近,到目前为止,它似乎是一种积极的力量。它试图平衡工作量(或流量)。

对于假期/计划,看板是一种选择。其他包括 XP Scrum . IMHO Scrum更多的是一种管理理念,而XP是一种开发方法。 Planning Extreme Programming 绝对值得一读。

客户(您的SRs)总是试图绕过开发过程。“难道你不能把这个故事放到迭代的中间吗?”你需要得到管理层的认可和对你选择的任何方法的支持。对于SRs来说,好处是(1)他们可以对故事(功能请求)进行优先级排序,(2)他们可以更好地了解故事何时完成。

在类似的情况下,我会让您知道我们的版本以及我们是如何缓慢扩展的。一般来说,与您的情况一样,我们的项目经理负责管理开发人员的时间。我们盲目地做了一段时间,但现在使用的软件允许我们优先考虑开发人员的时间,并将其公开展示给公司的每个人。我们所有的项目经理都在同一幢大楼里,因此他们能够进行对话,并决定开发人员需要共同完成的工作。

然而,这一过程仍然存在极大的缺陷。正如您所说,晨会可以改变优先级,但通常只有在项目出现问题的情况下。我个人认为开发人员PM可以解决很多问题,但这可能会对我们的帮助更大,因为我们的一些开发人员可以远程办公。以下是我对控制PM流程的建议:

• 使用用户/开发人员友好的软件,便于PM/DEV之间的协作
• 继续分析您的流程,必要时更换区域