重建技术时不应该做什么

从天真的评论开始,很快就会变成每次技术会议上出现的事情。积压工作充满了错误,而较少的工作重点是为客户创造价值。迭代周期需要永远,新的想法很快就会被甩掉,因为无法实现。 相对较低的回报需要付出巨大努力,随着进度的减慢,竞争对手开始冲过你。这对技术和非技术团队来说都是令人沮丧的。最终,这对每个人来说都是纯粹的挫败感。

我们是怎么来到这里的?

如果重建是每个人名单上的主题,那么在确定如何进行之前,有必要弄清楚你是如何到达这里的。我已经多次见过 – 并且一直在这种情况下,所以我可能会冒一些猜测。

1)你采取了这么多的技术捷径。

当时,它具有商业意义:您需要完成交易,实施功能并关闭合作伙伴关系。但是,快捷方式可能有一种令人讨厌的习惯,就是回过头来咬你。如果你没有花足够的时间重构代码,你的技术债务利息就会受到影响。 未能投资重构可能是缺乏经验的技术领导力的一种表现,但这通常归功于缺乏授权的技术领导者。 。 。或者甚至可能完全被忽略。

2)您没有让开发人员参与您的设计过程。

设计过程需要将客户需求与技术可行性结合起来。如果您在设计完成后只涉及程序员,那么您不太可能充分利用现有技术。 这使您可以创建定制解决方案,而不是利用现有的库,约定或现成的解决方案。很容易低估维护自定义代码的成本。

3)您采用了瀑布式开发流程。

瀑布开发的特点是长的迭代周期,其中范围是固定的。这对于具有高度技术和商业确定性的项目非常有用,但初创公司的情况几乎不确定。因此,瀑布式方法通常会导致过度构建和功能膨胀。 这与敏捷方法形成鲜明对比,敏捷方法强调迭代的重要性,并建立反馈循环,使您能够满足客户不断变化的需求。

你祈祷的答案

由于各种原因,“大爆炸重建”具有吸引力。它代表了一个空白的画布,您可以在其上投射您的希望和梦想,最重要的是,不再需要处理由其他人编写的复杂代码。 然而,通过追求大爆炸重建,你可能会把你带到这里的大部分错误永久化。锁定范围并期望在六到十二个月内不会发生任何变化,这不可避免地会失败。这是适应不断变化的客户需求的对立面。 更重要的是,大范围注定被低估了。复杂性随着范围呈指数级增长,因此处理大四倍的大型项目的确定性要低十六倍。无论您最保守的发布日期是什么,请添加6到12个月(至少)。 任何新项目的最初兴奋很快就会消失,几周后,技术团队将开始变得失去动力。他们会低估许多可能出现的复杂挑战。由于他们不会定期向客户发货,他们的大部分工作将完全隐形 – 不仅对客户而且对整个团队而言。 如果产品在很长一段时间内没有改善,那么市场营销和销售方面的非技术人员就会感到困惑,而且它们的速度会比泰坦尼克号上的啮齿动物快。一旦错过最后期限,整个公司的士气将从悬崖上掉下来。

切馅饼

大爆炸重建的替代方案远不那么吸引人:想想缓慢的迁移,而不是大爆炸。而不是一次解决所有不同的问题,而是逐个解决这些问题。 以下是一些帮助您进行缓慢迁移过程的提示。

1)揭开情感现实。

如果’重建’不断出现,那就是你的团队感到沮丧的信号。与您的团队一起尝试这个练习:让他们想象重建已经完成并且技术完美无缺。然后,提出以下问题: 你的生活将如何与众不同? 是什么让你最放心? 最令你兴奋的是什么? 通过询问这些情绪化的问题,尝试了解对您的团队有何影响的具体细节。这将有助于您将精力集中在实际问题上。

2)了解敏捷概念。

重建通常是投资整个团队敏捷培训的好时机。根据我的经验,敏捷培训可以带来巨大的投资回报,为团队成员提供一个共同的框架来解决这样的问题。

3)简化你获得的每一个机会。

当您达到重建的需要时,您可能已经积累了很少客户实际使用的功能。没有规则说你必须更换每一个功能。相反,寻找杀死功能和简化产品的机会。

4)关注客户价值。

一旦您将技术分解为可管理的块,就可以逐个优先重建,重点关注能够增加最大客户价值的最小块。

5)重构的内置时间。

采取渐进式方法并继续研究下一件事是很诱人的。相反,请确保您花时间改进现有代码。例如,您可以将25%的sprint资源完全分配给主动重构。

领导力的考验

技术危机是对每位创始人的领导力的真正考验。迁移永远不会是最受欢迎的选择,也不是最令人兴奋的选择。但它可能会让你获得比重建更好的结果。

正如每次领导力挑战一样,这需要很多同理心 – 并且需要大量的团队倾听。沟通是关键,保持团队一致需要纪律。最后,你需要耐心 – 如果你处于这种状况,就没有快速解决方案。事情需要的时间比你想要的要长。 。 。这就是为什么现在是时候变得更敏捷了。

Leave a Reply

Your email address will not be published.