开发者之间的差异：创造者 vs 修补者

提到开发者，你会想到什么？一个住在旧金山，每天工作23小时，致力于打造下一个Facebook的“编程兄弟”？如果是这样，你并不孤单。和许多行业一样，软件开发也充斥着各种刻板印象。其中一个特别普遍的观点是，所有开发者如果有机会，都会选择彻底重写应用程序。

诚然，许多软件开发人员喜欢从零开始，但也有一些人热衷于改进现有应用程序。他们不会从头开始构建一个只完成80%的解决方案，而是更适合在项目稳定后接手，并对其进行长期的维护和完善。这两种开发人员各有千秋，软件行业都需要他们。关键在于了解何时需要哪一种。

创客享受初期开发和最小可行产品 (MVP) 的乐趣

为了说明这些开发者的不同之处，我们来看看典型的产品生命周期。项目启动之初，需要经历一段快速开发期才能顺利起步。对于那些自诩为“创造者”的开发者来说，这正是理想状态。他们喜欢从零开始，就像一张白纸。正因如此，这类项目通常被称为“全新项目”。对于乐于验证想法可行性的开发者而言，参与这类项目简直如同置身天堂。一切皆有可能。天空湛蓝，点缀着朵朵白云，在他们眼中，未来总是充满无限可能。

一旦项目具备了所需的功能，就可以将其推向市场了。通常的做法是推出最小可行产品（MVP）。此时，应用的功能还比较少，用户模型也相对简单。接下来的发展将取决于市场。要么应用获得市场认可，用户群体不断增长；要么最终销声匿迹。

开发者更喜欢参与稳定且不断发展的应用程序的开发工作

此时，开发人员的任务发生了转变。他们不再需要思考宏大的架构并进行实现，而是需要专注于安全性、可扩展性、性能、漏洞修复和功能增强等细节。工作变得比项目初期更加细致，令许多产品负责人感到沮丧的是，开发人员的兴趣开始减弱。对于开发者而言，这个阶段所需的精细工作和精湛技艺不再那么有趣。

但有一群开发者，他们的才能和兴趣非常适合这类任务。他们之前一直没有一个专属名称，但我们喜欢称他们为“代码修补匠”。代码修补匠热爱重构，也就是修改代码以提高其清晰度。修复 bug 会让他们兴奋不已，而测试工作更是让他们乐此不疲。这些特质在项目初期可能并不那么重要，但随着应用的发展壮大和复杂性的增加，这些绝对是你团队中不可或缺的人才。

建造商：新建工程 :: 维修商：改建工程

另一种理解“建造”与“修缮”区别的方式，是想想新建和改建之间的区别。新建房屋通常从一块空地开始，就像创作者们钟爱的空白文本编辑器一样。而修缮则更像是电视节目《老房改造》。通常情况下，保留现有建筑结构有其充分的理由，但要对其进行翻新，则需要挖掘、拆除墙壁，有时还要处理一些意想不到的问题。

激励创客和修补匠的策略

就像任何性格组合一样，多样性通常是一件好事。你的团队很可能需要既有创造者也有改进者。关键在于如何激励他们，从而获得最佳绩效。创造者就像兔子——短时间内爆发力惊人。改进者则更像乌龟。在他们的世界里，稳扎稳打的改进才是制胜之道。

让创客们进行实验，并给他们设定截止日期。

没有什么比重复更让创客感到厌倦了。所以，要让你的创客们保持热情，就让他们去做实验。让他们自由地展望未来，运用设计思维。需要一个原型来验证某个概念？那就去找创客吧。他们会乐于快速搭建原型。创客们也往往能在黑客马拉松中如鱼得水，因为那种活动能在短时间内保持高能量。如果你时间紧迫，项目有截止日期，创客们会挺身而出迎接挑战，因为他们通常会受到时间压力的激励。克服重大的截止日期会给他们带来成就感，所以冲刺式开发对他们来说是一个很好的项目管理工具。只是别指望他们长时间专注于一个项目。创客们热爱探索新想法，如果项目过于枯燥乏味，他们很容易感到厌倦。

让修补匠们在一天中获得一系列小胜利

创造者那种天马行空的想象力和以截止日期为导向的项目管理方式，往往会给修复者带来压力。他们或许缺乏激情，但却以持之以恒而著称。修复者是处理技术债务、修复漏洞、优化功能、创建样式指南以及监控支持工单的理想人选。与创造者不同，修复者在工作稳定且相对可预测的情况下表现最佳。遇到尚未解决的问题？不妨交给修复者。他们会乐于深入挖掘，找出问题的根源。但切记不要过度管理修复者，否则会让他们非常恼火。相反，应该建立一个长长的待办事项清单，并赋予修复者自主决定工作内容和时间的权力。如果存在优先级或截止日期，请务必提前沟通，以便应对可能出现的未知情况。

那么你呢？你是开发者？修理工？还是介于两者之间？是什么激励你开发出最好的软件？