这不是IT，这很IE
现在我的工作是思考如何能激发员工的自主工作意愿；如何能缩短软件开发的周期；如何能使软件更加可靠；如何降低软件开发成本。别人说，你这个工作不是IE，算是IT了。我说，这不是IT，这很IE。
---六号
CASE 1
我：“这个功能需求为什么加上去？没有用户反馈这样的需求。”
IT：“看上去更加专业吧。”
我：“花了多久时间？”
IT：“两个晚上。”
我：“这个功能很棒，但是没有客户需求，你做这样的需求就是等于浪费。假若这两个晚上能把时间花在学习新的内容上，效果会更好。”
IT：“好的！”
所有的价值源头是用户，凭空而出的需求都是没有价值的。这点和IT无关，这点很IE。
CASE 2
周一晨会：
我：“A需求比较重要，先做A需求，再做B需求，下周一前需要两者都进行交付。”
IT：“好。”
周三晨会：
IT：“我把B需求做好了。”
我：“A需求还没有做好，为什么先做B需求呢？”
IT：“B需求比较酷，不过A需求我下周一之前也能做好！”
我：“如果完成A的中途出现异常呢？如果A需求所需时间超出你的预期呢？假若我们先做A需求，即使它超出预期时间，我们还可以舍弃B需求的修改，去完成A需求。但是你这样做，A需求完成周期一旦超预期，客户就会抱怨，销售人员就要和客户赔不是，我们也就会损失信誉。所以请下次一定要按照我的优先级做！”
这样在一个有限的资源中调度安排，最大可能的去满足客户的需求。我觉得很IE，和懂不懂IT没有关系。
CASE 3
IT：“我把代码复制过去，然后改一些参数名称，新的项目里就可以使用了。”
我：“不错，这样复用了之前的代码，能提高效率。不过是不是可以写成通用的函数，进行模块化，这样以后连参数名称都不用改，直接调用函数就可以了？”
IT：“对，这样是更快一些，不过第一次写模块函数可能需要更多时间。”
我：“没有问题，但要保证模块的通用性。”
这样一个通过函数模块化来提高编程效率的案例，和我们使用标准工时资料的情况、我们采用Group Technology去设计组装工艺的情况都十分相像。这样提升编程效率的方式，我觉得很IE，和懂不懂IT没有关系。
我结识了一些在IT行业从业的IE从业者，他们大多数从事项目管理工作。他们也和我分享了一些心得：
比如如何估算代码量？这个和时间研究十分相似。
比如如何找出迭代循环中的瓶颈？这个和线平衡分析十分相似。
再比如开发流程的分析，其实和流程分析一致，就是减少暂存，减少移动等非增值项目。
还有等等等等，这些都和IT的知识没有关系，都很IE。但不过在IT行业工作的IE，必须得懂IT；就像在工厂工作的IE，就必须得懂那个工厂的工艺。仅此而已。
IE们，加油！去把IE更多的应用领域！