本文探讨了如何在IT项目中避免过度加班，关键点包括明确项目范围、控制需求变更、制定合理方案和数据规则，以及确保上线策略的清晰。通过严格管理，有可能实现不加班的项目目标。同时，作者反思了社会对加班文化的过度推崇，表达了对健康工作生活的向往。
所有文章在公众号“MZ信息化咨询杂谈”同步更新，习惯公众号阅读的朋友可直接关注公众号哦。
相信很多从事IT行业，尤其是从事信息化行业的朋友都有类似的感受，最近几年来，项目越来越来越难做，其中之一的表现就是项目上工作时间越来越长，也就是加班越来越严重。
从表面上看，造成加班越来越多的主要原因是在正常的工作时间内无法完成项目既定的任务和目标。
笔者曾经在《SAP那些事-职业篇-21-为什么项目越来越难做了？》中分析了几条项目越来越难做的原因，其中一条就是需要在有限的资源（包括时间，时间本身也是资源）内需要完成的项目任务越来越多。
在这篇文字中，我想聊一聊我们能不能实现一个不加班的项目的梦想。
从我个人经验来看，如果我们在项目中做好如下的几点，我们是可能做一个不加班的项目的，我们一起来看一下。
-
清晰的项目范围以及严格控制
项目初期对项目范围的清晰界定以及项目执行过程中项目范围的严格控制。
这一点是实现不加班项目的最重要的一点，我们现在的项目往往容易出现两个问题，一个是在项目初期对项目的主要范围没有界定清楚，一个是在项目执行过程中不断的突破项目范围。
前期的确对项目范围难以界定的非常明晰，但是这个项目的目标、项目范围涉及到哪些系统、每个系统要做哪些功能、每个系统谁来负责做、项目的核心需求是哪些，这些还是要清晰界定的，这写也是未来细化业务需求以及确定业务蓝图的基础。
一旦项目开始，那么在蓝图阶段就更要确定具体的需求以及方案、实现方式，同时基于方案对项目任务进行明细分解，对明细的任务指定时间和资源安排，这个时候通常来说就能知道我们这个项目后期是不是要加班了。
在确定蓝图和需求后，只要在项目接下来的执行严格控制项目范围的需求蔓延，我想加班的概率至少降低一半了。
说明：我们要严格控制需求，并非需求一点都不增加，而是要让用户知道，需求实现都是讨论确定的，后期增加我们是要评估的，甚至大的需求是要引起项目变更的，这对用户和乙方来说都是有利的。
2.实现方案的变更以及确定
从笔者经验来看，核心业务的方案前期方案验证阶段需要充分的讨论、分析设置测试，以便确定主题方案的可行性，这个可行性的有两层含义，一层是技术上的可行性，一层是业务执行的可行性。
笔者个人经验是，太复杂的方案，技术上有时候觉得挺“牛逼”，挺“高大上”，不过这种方案一般都会带来业务执行上的困难，所以主体方案一定是在技术方案和业务方案融合、妥协的结果。
一旦主体方案确定，后期不可轻易动摇和更改，很简单，因为更改的成本很高，更改很可能导致加班和更多资源的投入。
3. 数据规则以及数据变更。
笔者以前也在文章中表达过，在一个信息化项目中，再怎么强调数据的重要性都不为过的观点。
如果前期数据规则（或者说规范）制定不合理（比如典型的BOM层次设计），或者说有遗漏，后期再更改数据的规则也会导致大量的返工工作，这也是加班。
4. 上线策略以及上线数据准确性。
要说整个项目加班最严重的恐怕是上线阶段了，这个阶段如果上线策略不清晰，宣贯不到位，再加上线数据不准确，一到二个通宵甚至一到两周到深夜恐怕是避免不了的。
说起来容易，做起来难。
不过我仍然希望在我主导的项目中，能够尽量减少加班。
不知道从几时起，我们中国人被“拼搏”、“奋斗”、“成功”这些词所包围，好像你不加班，就不是在“拼搏”，不是在“奋斗”，离“成功”就不沾边了。
甚至工作中如果不加班，领导也认为你是没尽力，你不够负责。
我就奇怪了，难道我们就没有一个不加班也能做好事的办法，不能“站着就把钱赚了”？
我有个梦想，做一个不加班的项目。
我有个梦想，在远离城市喧嚣的角落搭建一个院落，养一条狗。
胸有千言，下笔有限，大家共勉。
一句话，希望大家都保重身体。
备注：此篇最初写于2018年10月。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
