使“敏捷”产品经理相信计划的价值

Question

几个月前成为一家初创公司的技术主管。软件开发在组织结构图中的Product下面。

即使以启动标准衡量，我继承的代码库也很差。开发团队花了三周时间更新站点页脚中的静态文本，即使在80%的页面之后，他们也放弃了。更新页脚的‘可重用组件’会破坏一些模板，尽管他们已经使用代码好几个月了，但他们还是说不出原因。当然，原来的承包商早已不在，没有留下任何文件。

我买了东西清理，写下来，减少技术债务，但当然，首先，我们需要建立一个新的中等规模的功能，将涉及整个堆栈。我们知道这是朝着其他更大的特征迈出的一步。代码库似乎充满了废弃的、半成品的特性，所以我接受了其中一个开发人员花五天时间研究代码和想出不同的方法，而不是在某个人的头脑中接受第一个想法。

在第三天的第五天，产品经理向开发人员询问进度--简短的回答，以下是一些我们可以做的想法，但还不清楚哪些是好的，因为代码很乱，第二天有一个站点停机，他需要更多的时间。那天晚上，经理扔掉了尖峰，并根据其中一个想法用一个“原型”代替了它。在这样做的过程中，他们，产品经理，当场做出了几项技术决定，对技术领先的我起了很大的作用。从这次和其他事件中，我很确定“原型”很快就会上线，在“这看起来还行吗？”在开发公司的Macbook上进行测试。

我知道所有的“敏捷创业”的事情。上周，我对风险的态度放松了，需要把一些东西，任何东西都拿到用户手中。我不介意让军衔拉我。

但是..。我被明确地告知“我们是一家初创公司，我们不参与这项调查*”--“研究”被说成是一个肮脏的词。我也更欣赏为什么代码基是它的方式。

老手会注意到这一点--这看上去像是产品很差的情况，因为流程很差；可能是来自组织文化的穷人。站在战壕里，这似乎是最糟糕的情况“敏捷意味着弥补它，从我们的错误中吸取教训是给失败者的！”我见过的。

我怎样才能让经理相信一些计划和预先考虑的价值呢？或者，也许，我应该说服自己，这就是这个敏捷创业“应该”的样子吗？

Answer 1

有几个关键点可以避免：

• 敏捷!=惰性开发
• 钉和原型是不可互换的想法。
• 您上面描述的任何东西都不是敏捷或scrum规定的。

对于你关于如何证明自己的观点的问题，这取决于他们的真正动机。如果他们不理解他们正在做的事情的影响，你可以围绕技术债务对快速交付新特性的能力的影响提出一个理由。另一方面，如果他们只是使用“我们是敏捷的”来掩盖糟糕的开发和业务实践，你就没有理由说这会改变事情，因为他们已经知道了，他们也不在乎。现在，我已经看到了很多这两种情况，所以我鼓励你不要假设，或者，如果你必须的话，选择乐观的选项开始。

技术债务

在技术债务方面，我所看到的最成功的例子是：

在冲刺中你有X倍的时间。对于高水平的技术债务，假设40%的时间用于管理技术债务，60%用于新特性。如果我们发展得很好，也许那堆东西会稍微长一些。让我们选择一个数字，并称之为可能是1-2%的每冲刺。然而，在一家初创公司，我们必须快速转向，很多时候我们会意外地招致大量的技术债务，所以即使是一个好的创业团队也可能会在冲刺中再承受5-10%的风险。当然，如果你不努力工作，它可以建设得更快。如果你不清理那些技术债务，它就会建立起来。很快，一个应该需要一两天的改变就需要3个星期(听起来很熟悉)？

在这一点上，你可以作为一个帮助或卑鄙的人，这真的取决于你是否同情他们。如果您能够停止并修复旧的问题，这将是很好的，但是组织可能不会，所以让我们找到一个新的解决方案。首先，你需要停止这么快地承担技术债务。有效的质量措施(包括单元测试、代码标准和代码评审)是至关重要的。然后，你需要开始偿还你已经发生的债务。也许每周五用冰激凌清理代码是公司可以吸收的东西。此外，针对最新的特性开发需要完成的领域，将有助于展示一个更干净的代码基础如何通过更快的特性交付来为自己付费。

Planning/Analysis

在你的问题中，你似乎把技术债务和分析混为一谈。因此，如果它是有用的，你也可能需要出售他们在这个。要做到这一点，重要的是要理解存在着复杂和复杂的问题。对于一个复杂的问题，专家可以在短时间内分析这个问题并找出一个好的解决方案。存储来自已知表单的条目的最佳数据结构就是一个很好的例子。在复杂问题中，存在许多未知因素，或者不同因素相互影响的方式难以预测。这需要实验和观察结果。再多的分析也不会让你找到答案，你必须进去尝试一些东西。了解你正在解决的问题类型是至关重要的。

这与迭代开发也有明显的不同，迭代开发更多的是解决问题的各个部分，而不是一次性解决整个大问题。

希望这能有所帮助。祝你好运，我希望和你一起工作的人不知道他们行为的影响。

Answer 2

你不能，因为他们在计划中没有价值。

项目管理系统将因按时和预算完成项目而获得荣誉，而不是因为产品的工作效果如何。

你能做的就是在工作开始之前欺骗他们加入更多的需求。例如“在电脑上工作”。

驱动良好编程实践的是更加细微的需求。不是“质量”或“做得对”

听起来，您需要“与模板系统一起工作”和“零停机时间部署”这样的需求来驱动您想要进行的一些重构。

如果您能够获得正确的需求，那么修复代码就会成为项目，并且PM会为您工作，而不是针对您。

Answer 3

“我怎么才能说服.”问题假设你是对的，而产品经理是错的。从你问题的框架来看，你似乎没有花大力气去理解产品经理的推理。但考虑到产品经理可能有更大的前景。作为开发人员和技术人员的领导，您有责任了解您正在操作的业务限制。

正如您解释的那样，产品经理快速做出决定，节省了两天的研究时间。你还表示，你明白“上周需要把一些东西、任何东西交到用户手中。”考虑到这些前提，产品经理似乎做出了正确的决定。

考虑到你已经购买了一些资源用于清理，管理层似乎确实明白，这种快速和肮脏的解决方案涉及到权衡。你想说服他们什么？你应该花三天的时间进行研究，而不管修复程序的关键程度，还是需要开发的特性？

上市时间对于创业来说可能是至关重要的。假设一家科技初创公司正处于关键时刻--如果你继续一个月的用户增长，你就会得到大量的新投资。如果增长停滞，企业就必须关门。在这种情况下，一家初创企业将自愿接受技术债务--以长期可维护性为代价，优化功能的快速交付。如果企业倒闭，长期可维护性的问题是没有意义的。如果它成功了，你可以雇佣更多的开发人员来清理混乱。

我认为你应该做的第一件事是与产品经理交谈，以更好地理解你正在工作的制约因素和优先事项。