介绍
“我喜欢在限制条件下工作。”有没有人理解这种感觉？
- NES/SNES 时代的游戏创作者用各种创意娱乐孩子
- 实力低劣的运动队，用智慧和团队合作杀死巨人
- 旅游资源不知名的市镇振兴B级美食
等等，我可以列出无数在限制范围内设计的东西的例子，但我喜欢这些例子，不管类型如何。
或许这种偏好体现在我对工作的选择上，我亲身经历的制造环境也有各种限制，但毫无疑问，这些限制让制造变得有趣。我认为。
我目前在 LiB Co., Ltd. 从事的工作是“将难以招聘工程师的销售公司转变为 IT 公司”这是一个高度限制的游戏。你为什么决定做这么奇怪的事情？过去的文章在这篇文章中，我想谈谈“你如何对抗约束？”
本文中的“工程师”是指“软件工程师”和“IT工程师”。
本文摘要
本文的大纲如下。
[开始] 你不能聘请工程师，对吗？
首先，招聘人力资源的难度总体上在增加，但招聘工程师是最困难的
过去五年认可度迅速提升的产品经理（PdM）也很难
[批准]我公司（LiB Co., Ltd.）无法挑选
业务主题、技术套路、人事制度，连招聘起跑线都难上加难
另一方面，如果没有充分利用 IT 的系统，LiB 的使命是不可能的。
所以我无法逃避招聘工程师
[转1]我决定分配工程师的工作
暂时放弃聘请专职工程师，彻底拆解工程工作
逐渐聚集能够处理每个拆解元素的人，并构建一个让软件开发顺利运行的系统
【转2】我决定用PdM做分布式处理人员
单独的分布式处理最终会导致工程师短缺，因此我们决定利用 PdM 作为开发力量。
建立一个系统来培养PdM，PdM甚至会承担一般公司工程师负责的工作
【结论】有回复说你在努力
公司转型（硬事）期我一直在努力（=花时间）的萌芽已经出现
招聘希望充分利用这种环境并创建鼓励个人和公司行为改变的机制的工程师和 PdM
由于以上内容，我们假设读者将是那些有制造经验的人，以及可能涉及到负责制造的工程师/PdM/设计师等职业的人。
注意，基本上相当于“弱者的战略”的故事因此，它可能对陷入工程师短缺问题的公司有所帮助，但我不建议拥有大量工程师的公司使用它。
大软件时代的成熟理论
从20世纪末开始，“世界真正进入了伟大软件的时代！”
许多可以被称为“既定理论”的东西，被教导、尝试、成功和失败，已经成为本文所介绍的努力的哲学基础。下面，我将与这篇文章相关的东西罗列出来，这些东西对于同时代的航海者来说太明显了。
观众应该思考
- 最好想想看用户的人会创造什么
- 价值提供者和受益者的距离越近越好（D2C和无代码流）
- 从未见过的“伟人”的想法通常会失败
思想者应该使
- 最好不要玩消息游戏
- 经理→计划员→内部工程师→SIer联络人→SIer实施负责人→二次接收实施员等。在继电器环境下很难创造出好的产品（内部生产流程）
边做边想
- 最好有很多模拟/原型（1 个粗略的原型比 100 个漂亮的演讲）
- 与其进行思考，不如说是在被触摸的同时进行思考的捷径。
应该很快释放
- 应立即尝试想法
- 最初的假设大多不成立，因此最好尽早实现。
- 用户没有答案，但他们可以评价它的好坏
应该继续制作
- 对于一个产品，普通人是不可能给出正确答案的
- 健康的废料和构建，而不是“PDCA 仅嘴”
- 更好的利用尸体，用它们堆起来
软件变硬
与上述教条相反，它在现实世界中的实施存在许多障碍。一个著名的例子是流星坠落类型开发中“上帝”的存在，但我一个主要因素是由于缺乏工程师，软件变得越来越硬。我认为。
图：软件层次图（来源：维基百科、免费百科全书）
上图中，2、3层一般称为软件层，特点是越往上越容易变=软。
然而，“真正能把软件变软件的人”，一般公司有几个？
看似总裁无意下达变更令，CTO发怒的情况很多，但往往连产品组的成员和负责实施的工程师也不能随意变更。有。
如果您尝试处理资源和预算有限的软件，流程和规则的数量将不可避免地增加。遗憾的是，在任何人都可以通过一台PC为世界提供价值的时代，软件开发往往难以“软”做是。
基于我“软件应该是软件”的信念，我想创造一个环境，让尽可能多的人可以自由地实施“既定理论”。
不用说，这不是一个可以应用于世界上所有软件的想法。在许多行业和服务中，尽可能接近硬件是很重要的。
将销售公司转变为 IT 公司的战略方法
根据开头提到的限制，销售公司将转变为 IT 公司。届时，通过确保软件可以被正确地视为“软”，我们将创建一个可以在大型软件时代实施既定理论的组织。
为了实现这一艰巨的目标，LiB 采取了两种战略方法。
【策略一】工程工作分散化
【策略二】非工程师的分布式处理能力
我将详细解释每一个。
【策略一】工程工作分散化
LiB有五个工程工作的去中心化，所以我想一一介绍目标和效果。
这里使用的“去中心化”一词没有特殊含义，而是一个字典定义。
表示分散、不集中在一个地方或适度不均匀的意思。
出处：Weblio/日本实用语词典
这就是它的意思。
(1) 参与形式的去中心化——将触手可及的物品出租
自从我在“新冠疫情之前”期间于 2018 年 10 月加入 LiB 以来，员工被要求到办公室。另外，从业务主题、薪资水平、工作条件等方面来说，工程师的招聘难度极大，所以我立即放弃了聘请全职员工，因为时间太早了。
另一方面，除非你建立了一个坚实的工程团队，否则你永远不会摆脱这种情况。因此，首先，我们组建了一个拥有完整远程外包成员的团队。那时，
- 优先考虑技能而不是可用工作时间（例如，每周工作 3 次的老年人而不是每周工作 5 次的青年人）
- 即使与员工的工资有差距，也要尽可能支付与能力相匹配的薪酬（说服公司外包=可变成本）
- 建立一个便于他们展示自己能力的流程（例如，灵活的工作量调整、会议最小化、每月反馈周期等）
等等。 （如果我再写出来，这只是一件正常的事情......）
这样一来，我们就聚集了很多可以称为“专业人士”的外部合作者，并且能够稳步推进平台系统的发展。体系和团队的基础建立起来后，我们可以逐渐增加要培训的成员，所以我们逐渐增加了招聘的选择。
通过在早期创建一个完整的远程开发团队，即使在新冠危机期间也没有受到任何损害，并且在恢复招聘时，我们能够无视我们居住的地方进行招聘。所以它非常有效。
(2) 所需技能的去中心化——不要要求任何东西
创业对话：
官员：“我们需要尽快加强对工程师的招聘……”
HR：“我应该寻找什么条件？”
官员：“现在，做一名全栈工程师。”
HR：“你到底能做什么？”
高管：“必须能够开发iOS/Android应用，对服务器/基础设施有透彻的了解。我也想把团队管理委托给你。年龄到30岁出头，我们做不到排除我们的愿景和使命，年薪我给你最高800万！”这样一来，各种职业转换网站上都充斥着“全栈工程师招聘！”的职位空缺。这不再是这几乎就像是“获得像大谷翔平这样的棒球运动员”的指令。我喜欢，但有多少公司真正能够雇佣到他们想要的“全栈工程师”？
至少在 LiB 中，这种人力资源搜索成功的概率（即使参与形式是去中心化的）接近于零，所以明确你想要什么和不想要什么做过。除了缩小语言和框架之外，我们不要求麻烦的协调任务，让每个人都可以专注于自己擅长的领域的实施。同样重要的是
最近，我有了一些回旋余地，所以我正在努力让员工工程师有意识地负责没有经验的领域，并以成为更广泛领域的工程师为目标。我在这里。
（3）主数据去中心化——多次改也不会生气
请勿在系统中混合使用服务时可能需要调整的文本和设置数据。基本都是系统开发教科书上可以找到的，但是当我们真正想在运营服务的同时进行调整的时候，很多情况下每次都要求我们的工程师去修改发布，可能是这样。
LiB 系统独立于系统彻底管理主数据，并将其作为 JSON 文件（使用自动生成它们的工具）以适当的单元进行分发和管理。
这将PdM 可以在不留给工程师的情况下使改进过程变得艰难。相反，工程师说，“请更改◯◯的措辞”，“请增加◯◯的选项”，“请让保存◯◯的数据成为可能”。您可以从简单的更改工作中解脱出来。（我会省略细节，因为我开始写的时候会是一篇文章）
④ 下放新的开发工作——健全的废建
常说“扭转 PDCA 循环”，但如果在涉及软件开发的环境中尝试实现 PDCA 循环，往往会出现以下问题。
图：PDCA的现实（LiB招聘材料节选）为了在没有模型的情况下实现 UX，有必要重复一个健康的废品和构建。另一方面，无辜地重复报废和建造浪费了宝贵的工程师工时。为了面对这个困境，我认为有必要实现下图所示的情况。
图：PDCA理想（LiB招聘材料节选）为了实现这种状态，LiB基础系统配备了一种机制，可以实现各种屏幕和功能，即所谓的无代码。像 PdM 这样的非工程师正在重复报废，并随心所欲地建造。（这也是单篇文章，所以我将省略细节。）
此外，利用我们的内部基础架构 Google Workspace 环境，电子表格驱动的开发方法我们也在做这是，
即使有开发请求，我们也不会立即实现系统，而是仅将系统用于MVC架构的模型部分，用电子表格实现视图，用Google App Script（GAS）实现控制器。
使用基于电子表格 x GAS 的系统，我们将在每天摆弄它的同时修复规格。不会发生）
一旦成为可以持续使用的工具，规范稳定，系统实现需求（如性能）明确，系统将首次实现。
这样，几乎所有内部成员都是用户的系统都是用这种方法实现的。
⑤ 最终成果责任分散——从今天开始，你也是最后的堡垒
我们在上一节中谈到了无代码开发环境，但它们也促成了另一种形式的去中心化。那是，产品开发的最终交付物（用户直接接触的东西）的责任可以分散=共享是。
我所做的将成为最终产品，这是一件非常大的事情，
- 测试适当的质量发布
- 生产中出现问题的初步分析
- 减少错误（错误）发生的机智
ETC，每个人都可以体验到只有那些往往是唯一负责最终交付物的工程师才能体验到的东西将会
工程师们经常感叹，由于运营过程中的 bug 修复，他们无法专注于开发，但这种去中心化分散了运营过程中的负担，让他们可以专注于开发。
另外，当你开始自己分析和解决问题时，你将能够理解接受报告的人的感受，提高你向工程师报告事情时的沟通能力，减轻工程师的翻译工作负担。获得。
“工程工作分散化”总结
我介绍了以工程工作分散化为主题的五个想法。
（一）参与形式去中心化
(2) 所需技能的分散化
由由以下人员组成的团队
(3) 主数据去中心化
④ 下放新开发工作
⑤ 最终交付成果的责任下放
可以说是实现环境=可以实现的框架。③④⑤的配置简图如下。
图：简化架构图这是在开头引用的
上图中，也可以考虑对应操作系统的API和DB有3种，应用层对应的有3种。
正如开头所说，这种策略基本上是弱者的策略，所以自然而然地接受了各自的劣势。
（一）参与形式去中心化
→ 基本上你不能提出“现在改变这个！”之类的要求。
(2) 所需技能的分散化
→如果没有人能够做出整体最优的决策，每个人的视野都很狭隘，就会发生荒谬的事情。
(3) 主数据去中心化
→ 低质量数据混入其中，造成数据债务
④ 下放新开发工作
→ 邋遢的原型成为瓶颈（无法立即修复、停止工作等）
⑤ 最终交付成果的责任下放
→ 界面不切好，自己解决不了的事情会更多尽量减少这些缺点也是一个有趣的想法，但最困难的是**如何安排将负责与 3、4 和 5 中的工程师分开的工作的人员**。
这是我想在【策略2】中提到的“非工程师的分布式处理能力”中介绍的内容但是，由于写了我不习惯的长句子，我的 HP 用完了，所以让我继续第二部分。
非常感谢您阅读本文。如果有人在类似的环境中挣扎，让我们交换信息。另外，如果您对 LiB Co., Ltd. 感兴趣。招聘信息我也很想见到你！
转至第 2 部分“[从销售公司转型为 IT 公司 - 第 2 部分] 如果你不能得到它，那就成长它 PdM”
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308623146.html