市场应对能力缓慢
许多企业都有激励制度的问题。 下面，我们说一下典型的KPI从技术领域开始。 1.以工作量为考核目标。 据说一家公司以代码行数作为评估目标。 这种策略实际上是为了激励大量的垃圾代码。优秀的代码简单而优雅，高重用性和低耦合性是追求的目标。如果评估员工的代码行数，新手程序员绝对高兴，你不需要考虑架构，不需要考虑重用，大量的复制粘贴很容易堆积大量的代码。当我第一次编程时，我也有直接粘贴以前的代码来重写的习惯，这实际上是一个糟糕的重用性。 2.以解决问题为考核目标，如处理实际问题数量、修复等BUG数。 这听起来很合理，但我以前举过这样一个例子，两个项目组，第一个领导水平很高，项目代码非常稳定可靠，在线后没有问题，项目团队变得无所事事。第二组长，稍差，写项目代码在线，经常出现一些奇怪的问题，结果疲惫，各种加班，各种火灾，第一组团队都被调到支持第二组，第二组组长因为优秀的工作热情，大量的问题处理性能和持续的加班工作和领导欣赏，晋升，第一组长只能成为下属。 很多企业都会犯这样的错误，这样的案例其实很多。 3.以专家组的考核为准。 技术，让技术专家评估，一些大公司有非常优秀的技术专家，组成评委会，技术工程师需要申请升级，报告他们的工作表现，使用技术，完成工作量，目标，技术专家根据其表现决定是否晋升和加薪。听起来很合理，对吧？ 然而，事实并非如此。十年前，我遇到了这样的问题。我需要处理一个在线问题。这个解决方案并不复杂。我可以根据我的计划很快完成。与我相匹配的工程师很好，水平也很高，但他们向我抱怨：对不起，我上次没有通过高级工程师的评估，说我的工作技术价值太低，我的工作评估不能提高这个计划。我有什么算法？你能看到吗？他们都是农民工。你为别人感到尴尬吗？他们必须在一两天内完成一两周的工作。说实话，这仍然是一个非常关心产品需求和易于沟通的程序员。如果有一种以自我为中心的技术计划，他们需要制定一两个月。 今天我说一些人可能不相信，许多大公司，有很多技术过剩，因为这个技术评估体系，大惊小怪，不必要的技术解决方案，不必要的过度结构，许多是为了满足技术评级和晋升的需要，所有这些，除了浪费人力和资源，也导致产品迭代缓慢，市场响应缓慢。 事实上，我们看到许多小型创业公司，甚至个人，可以在短时间内发布有趣的产品，包括一些Hackathon(编程马拉松)活动，36～48小时生产的产品也很相似，但大公司经常生产数百人的类似产品，超过半年。有些人会说，你不明白，大公司的性能要求很高，很复杂。我真的对此略知一二。 更可怕的是，为了升职，一些管理职能的人不需要很多人的职位，不得不创造一堆工作任务，招募一群人来满足一些根本没有实际意义的事情。如果他们有更多的人，他们的自然职位就会上升。 4.基于错误率评估。 这个想法是评估你工作中的问题数量，BUG数量相关故障数。 嗯，大家都知道它的作用，多做多错，少做少错，不做好。 程序员已经习惯了背锅侠。 5.基于团队目标。 单独的技术真的很难评估，所以你必须根据团队目标与你的项目团队进退。虽然存在不公平，例如，如果优秀的技术与不可靠的产品经理相匹配，它可能会被拖累，但至少这也是一个缺点较少的解决方案。 然而，我们知道大公司最害怕什么，部门障碍，一些热情的技术牛，愿意与更多的人分享，愿意帮助别人分析问题，解决问题，愿意帮助更多的年轻人，然而，这一切，都没有激励。许多大公司都在那里KPI在指导下，部门利益高于公司利益，甚至不同部门争夺项目、资源和话语权。 如果一个员工专注于公司的利益，甚至愿意为公司的利益牺牲团队的利益（在某些情况下，例如，公司有一个特别重要的项目，远远大于当前的项目价值，一个优秀的技术，在与部门经理沟通确认后，紧急支持项目，比按时完成部门项目更有价值，我个人非常鼓励这种行为），在这个评估目标下，是典型的被淘汰。 可怕不可怕？ 技术岗位不容易评估，所以其他岗位，设计师岗位类似于技术岗位，做得更好，好的设计，比1000平庸的设计好，但好的评估，如何定量？ 在产品和设计领域，KPI问题是，互联网行业只能评估已知的东西，如何评估未知的东西，IT在行业中，我们应该经常面对未知的场景，提出新的观点、新的想法和新的产品特点。然后，在这些事情提出之前，我们的KPI原则是
