|
|
最近996的话题很火啊，网上似乎有两种声音，一方是老板及吃瓜群众党，一帮程序员党。老板们的意思无非是，你们这帮菜鸟、弱B、老油条，不想拼命干活就能赚钱？觉得不好可以滚啊！吃瓜群众们纷纷表示赞同，不想干可以自己屈膝抱头重心前倾获得动量。程序员们的意思，也无非是资本家压迫劳动人民啦！无产阶级要站起来啊！这一类的表达。
不过，似乎没有人对996的工作内容去仔细的分析一下，到底是什么造成了这么长的工作时间。在本人写了二十年代码的过程里，也不乏大量的加班时间，回头看来，加班所做的事情，无非是几类：
- 学习
- 修Bug
- 拼命堆功能赶工期
- 发版本
- 白天开会/打杂/各种沟通，晚上干活
我们可以自信来分析一下这5种情况。
首先是“学习”这种情况，因为项目需要用到一些还没掌握的技术，所以需要尽快学习掌握，这种情况对于毕业生或者经验较少的程序员来说，是最常见的。但是即便是有多年经验的程序员，要涉及一个不同的技术体系，也是需要时间去学习的，只不过老鸟们的学习速度往往会比新手更快。我们往往说，老程序员头脑僵化，学习能力下降，但实际情况是，老程序员们的掌握速度往往会比新程序员更快，只不过有时候新程序员有时候会比较莽撞的就开始动手写东西做产品，所以看起来好像速度很快。当然这也不排除老程序员不愿意走出舒适区，或者是评价者对老程序员的期望比新手要高的原因。对于这种情况的加班，我相信有上进心的程序员都是应该愿意付出的。对于需要提高技术水平的加班时间，我也认可这是一种奋斗必须的代价，不付出当然就没有回报。
第二种情况，修bug。这个问题应该细致点来分析，有一些bug，是由于自己学艺不精写下来的，对于这种情况，本质上和第一种是一样的，是一种学习。这也是进步必须要付出的代价。还有一些bug，其实是一种技术债务，由于早期的设计缺陷，或者追求短期利益导致的。对于这种情况，从本质上说也是技术人员自己所必须克服的。当然，有很多时候，程序员会说，进度压太紧啦，不可能不欠技术债务啦……这确实也是实话，但是无可否认的是，对于一个注重开发效率，软件工程知识熟练的程序员来说，是能把这类问题解决的更好的。我是常常会发现，身边很多程序员只在意算法，操作系统底层知识，运行性能这方面的知识，而极度忽视软件工程类知识的学习和实践，导致自己给自己挖了大量的坑而不自知。所以我认为修bug导致加班这件事背后，还是程序员自己的原因多一些，但解决方案却不是安排更多人力和加班时间，而是彻底的扭转自己的技术价值观。
第三种情况，赶工期。这个加班的锅，我觉得程序员和需求人员应该各背一半。软件开发的最大矛盾，就是不明确不稳定的需求，和落后的软件开发效率之间的矛盾。这个问题有两个方向的解决方案，一个方案是尽量提高开发效率。今年来流行的敏捷、持续集成、DevOps，还有各种新的语言、框架、模式，都是为了提高开发效率。我们的程序员有多少人是真心拥抱这些技术呢？还是仅仅沉浸在固步自封的熟练技术里重复解决问题？当然，另外一个方向，就是要有高质量的软件需求。我也常见，一些不负责任的需求方，因为自己受到巨大的市场压力，而放弃了自己思考的能力，妄图通过不停的抄袭竞争对手来增强自己的产品实力；又或者没有仔细的考虑开发成本，随意提出需求，然后再开发完成后又随意推翻，仅仅是因为自己缺乏足够的鉴别能力和想象力，让整个开发团队的工作量浪费在自己无尽的试错上。我就所见，大量的产品特性，在开发出来后，根本没有给用户试用过，就被产品人员以自己的喜好草率的推翻，这种情况，越是在大公司里面越常见，殊不知这才是对造成的老板最大损失。从这个角度说，造成996就是一种很不负责任，并且不人道的做法。如果这叫做奋斗，只不过是浪费老板的投资，浪费同事的生命。
第四种情况，发版本。专业术语叫做系统集成，由于互联网产品的版本周期快，所以这种集成频率会越来越高。针对这个问题，在“持续集成”这个热门的话题里，业界已经有普遍的讨论。但是我们还有很多团队并不能使用这些现成的经验，原因是“太忙了所以没空搞”。大家都知道磨刀不误砍柴工，但是在软件开发领域，偏偏就是很多人都不愿意磨刀。这里有我们的行业专业水平底的原因，也有因为我国对于劳动者权益缺乏保护的原因。由于可以无限制的要求加班，所以自然降低了提高工具，采用新技术的需求。长期来看这并不是好事。我最担心的就是，大量的公司管理者，都认为996是天经地义的，有事就加班，不去考虑提高开发效率，不去更新劳动工具。最常见的错误，就是给程序员配备落后缓慢的开发电脑，显示器都不舍得配个大的，这种做法真是愚蠢之至。所以发版本加班这个事，看起来是程序员的锅，但实际上是管理者的锅。发版本的加班，是因为平时缺乏项目管理体制，没有自动化测试，集成工具手工落后....等等一系列管理失败，最终造成了996。
第五种情况，白天打杂（摸鱼），晚上干活。曾几何时，我也觉得晚上安静，最合适写程序了。但是如果白天能有足够安静的环境，生物钟还是更适合在白天工作的。很多996的团队，基本上在太阳下山前，是没有多少真正产出的，原因有很多，归结起来一条，就是：上若好之，下必甚焉。除了一些老板喜欢用工作时长来判断员工的产出，还有一些原因是，老板本身就拿开会当成工作的主要工作形式——有一些管理者，自己缺乏主动学习的意愿，更希望让下属把情报和知识“嚼烂了喂给自己”，所以各种汇报会议就层出不穷。正常的讨论型会议，应该是会前就同步完信息，会上直接开始讨论预定的，需要选择决策的问题。但是太多的会议沉浸在轮流汇报，同步信息上，这就直接造成了白天的会议占用太多时间，要干活只好放到晚上了。
回过头来看996这个话题，我渐渐觉得并不是一个简单的问题。如果996是基于自我的选择，那这个并不值得关注，如果是被迫的996，可能并不能帮助项目的成功。我们要消灭不是996，而是消灭低效的开发过程和落后的价值观。
文/韩大
原文：https://mp.weixin.qq.com/s/SE--4Zg9oO8R11m9jD2X0Q
|
|
发表于 2019-4-24 10:38:38
