开发者还是工程师 —— 你该怎么称呼自己？

21CTO社区导读：本文针对于软件开发者的称谓，透析了名字背后的素质与能力，能够指导你当下的角色与未来。针对于软件开发管理者与公司运营者，如何为自己的研发团队组建更正合理的模式，推荐给各位。

 开发者们，你该怎样称呼你自己？
 
这是一个似乎很简单的问题。很多年来，软件开发者的称谓也已进行了多次变迁，每一次改变都会对角色感知有着微妙的影响。
 
其实工作本质都是软件开发，当你回家过年被亲戚朋友问及干什么专业时，你会怎么解释现在从事的职业？
 
如果想让提问题的人很快就明白，你可以说是“程序员”这个他们可能熟悉的术语，或许能够联想到自己玩游戏或者电脑坏了很快能修好的人，这些角色其实都不符合你。
 
因此在大多数情况下，“程序员”有点带着点儿贬义。它回到了可编程计算机的最早日子，一个“程序员”可能只是一个技术人员，把规范翻译成打卡机识别的字符，隐含着是一个半熟练、非创造性的角色。
 
后来，“软件开发者”或者说“开发者”，渐渐取代了“程序员”这一称谓，这是软件编程者最常用的名称。“开发者”，“开发者”或者“技术人”暗示着这是一个有主见的人，能够聚合想法并使其成为现实的人，而“技术人”则更进一层，更像是一位匠人，成熟的技术牛人。
 
“开发者”这个标签强调的是创造力，暗示一旦担当就要有持续的责任，所以此标签也有一定的反意。因此有很多人更喜欢“软件工程师”这个称谓。
 
软件开发长期以来被用来描述需求和想法做为输入，并要求以“完成”软件作为输出的完整过程。
 
当软件项目变得复杂，涉及大量人员，需要有组织这些项目和人员的方法，而“工程”，特别是向土木工程借鉴了大量的名词和成熟的过程管理。
 
“工程”
 
“工程”这个对软件开发的称谓已经根深蒂固，计算机科学技术的学位也常由大学的工程类学院颁发的“工学”学位。
 
但是，如今的软件开发行业已从一个土木工程的线性过程模式转变为开发者占主导地位的迭代开发模式。
 
使用工程瀑布开发的模式越来越具有误导性，虽然“软件工程师”这一角色仍然受到管理人员和软件设计者的欢迎，但是原因已经发生了本质的变化。
 
对于管理者来说，把软件描述成“工程”的过程有一种控制和期待。
 
土木工程是一个结果驱动的过程，具有明确的权利与等级概念（“架构师”这一角色从土木工程全盘借鉴了过来）。一位“工程师”角色是一个固定期望，而严谨的思想却需要流动起来。
 
对于管理者的核心期待是开发者的创造力和解决问题的能力。对于开发者，称呼自己为“工程师”是自我价值的体现，他们心里在说，我们是专业人员，我们的教育、知识和经验需要得到尊重，这一点和土木工程师相同。
 
这两个定义之间存在一个创意概念为中心的差距，这一点是造成紧张关系的原因之一。
 
软件开发者认为自己是创造性和创新性的职业，坚持称为“工程师”，他们选择轻视土木工程师比较“土”的地方：不要浪费时间解决已经解决的问题。
 

 
“工程师”们的预期
 
把软件开发者视为工程师的项目负责人，正在发表一个强有力的声明：你们在这里是将需求转化为代码，以快捷的时间和最低成本解决所遇到的技术问题。
 
对于这类管理者，开发者就像土木工程师一样，有责任自我关注技术质量和解决方案，并尽可能将其应用。软件开发人员在加入公司之前要有意识管理者的期待，那么这个职位是与自己匹配的。事实上，有很多软件开发者也更喜欢这样的工作。
 
这种模式适合公司招聘的政策CTO或CEO不希望软件工程团队参与运营的实际情况。如果我们选择这个模式，那么必须招聘具有“超级生产力”的开发者，即能力强，效率高的人，这些人通常被称为Rockstar、10X程序员，管理者要给他们充分地自由与项目控制权。
 
如果有一天，团队出现不满甚至具有一定破坏力，管理者应该有这样的心理准备。这时开发都的预期需要提高，需要有一个“新需求”采用最新的技术，让软件工程师们燃起新的兴趣。
 
同时管理者还要明白，使用这种开发模式，项目将被锁定在受教育程度和薪酬最高的一群人的产品和技术理念中。使用令牌效将大家的思路集合，比如内部产品讨论，技术架构设计的探讨等通常不会让所有人满意。主要原因是我们给软件开发者提供设计与开发产品的机会非常有限。
 
“开发者”的预期
 
与“工程师”不同的是，“开发者”期待自己与产品经理之间的思想是双向流动的，工作是在一种流畅的过程中进行。在“开发者”模式下，产品团队与开发团队之间的关系是非常重要的，需要互相深度信任。
 
要消除产品与技术之间的冲突，产品与开发团队可以共享一个项目时间轴，或者完全合并。开发者更喜欢抽象的需求或者业务需求，而不是规范，更期望在实施需求及产品设计方面有相当大的自由度。
 
在“正确地工作”的情况下，有用此种开发模式公司的好处是：
 
1 在除了产品、市场、行政这些“泡沫 ”角色外，还有一群人批评（通常是直言不讳）公司的商业模式或产品观点；
2 技术团队有着强列的归属感，因为他们自己能对产品的方向与质量负责。
3 技术团队的创造力和创新力可被顺利落地。
 
这就是“开发者驱动”模式。当然，如果管理不当，这种管理模型也会出现失败。其导致的问题如下：
 
1 开发团队与产品团队之间关系紧张、不信任
2 惩罚性的工期“估计”与开发团队并不认可的平衡遭到破坏
3 浪费时间来开发或重新实施新技术或不成熟技术的解决方案
 
您需要什么？
 
您是否也想有一个满是“工程师”或是“开发者”的团队？答案与您你做的重大决策一样，取决于产品，公司文化（CEO的文化），以及时间和资金。这些因素也会随着时间而改变。
 
通过命令以及控制管理的“工程”模式，和开发者驱动的模式是有一些不合时宜的。对一些有正确价值观的小团队来说，这可能又是非常有效的。对于在竞争激烈的市场中有多个开发团队和成熟运营的产品的公司来说，我们需要的是“开发者模型”，能够在正常工作时提供全部的独立性和跨团队的创造能力。
 
我们的工作需要确保在正确的时间使用正确的工作模式。如果决心改变，需要我们确保团队的每个人明白为什么，每个人在“新的世界”里都占有一席之地。

作者：Ben Halstead。一名CTO顾问，撰稿人。
编译：21CTO社区 – 高明
来源：https://medium.com/cto-craft/d … a6890