Do IT 方法

什么是 Do IT

Do IT 方法针对的问题是，如何为一个人做一个东西。Do IT 是三个单词的缩写。

• Design 设计出完美(O用圆来指代完美)解决方案
• Implement 根据设计去实施解决方案
• Test 按照设计去测试所实施的解决方案

为什么要 Do IT

我的经历告诉我，很多东西没有做好，就是这三个重要的环节中的某一个出了问题。而且几乎可以肯定的是，一个东西没有做好，就是在 Do 上没有做好。很多时候，做东西的人将大量精力放在 I 或者 T 上，不知道一旦 Do 错，那就都错了。

本篇虽然讲的是 Do IT。其实讲的是最关键的 Do。只是，在做完一件事情的时候，不仅仅只需要 Do 就可以了，还需要去 I 去 T。从而组成完整的 Do IT。

Do

Do 占了四个字母的两个（一半），指示其在整个制作环节中的重要性。在整个制作环节中，Do 所需要花费的时间也有一半时间。

字母 D 从上到下的实体是由小到大，再由大变小的过程，指示 Do 的主要表现形式为：从一个简单的想法（问题），通过发散思维（如头脑风暴）引申出多种想法（关联问题），然后得到多种设计（解决方案），最终经过优选得到一种最佳的设计（解决方案）。

字母 o 是一个完整的圆。这表明了设计所要达到的程度（什么样的设计才算是完成的设计）。由这个圆，可以联想到如：自圆其说、八面圆通、破镜重圆、功行圆满等词。这基本上概括了一个完美的设计所要达到的要求。换句抽象的话来讲，就是：概念的完整性。

什么是概念的完整性，一个具体概念的完整性的系统，其内部不会自相矛盾，概念内部可以相互支持，相互依赖。从而构成和谐的统一。

I

I 是四个字母中占用空间最小的一个字母，指示其在整个制作环节中居于最次要的地位。在整个制作环节中，I 所需要花费的时间也是最少的。

字母 I 从上到下很直接了当，基本上没有什么障碍，所以可以是最快做完的。之所以是可以最快做完，因为在 Do 中已经把所有的问题已经解决了。如，在 I 中可能遇到的问题，如果遇到了，怎么处理等。如果 Do 不解决这样的问题，势必让 I 的过程变得异常困难，从而反过来说明 Do 没有完美地考虑 I 是不是可以真的把东西给 I 出来（即 Do 没有达到其完成的标准）。

这里就解决了很多直观的感觉，很多直观的感觉认为，做事才是最难最耗费时间的，殊不知，那真是因为在直接做事之前，没有一个好的解决方案，只好在做事的时候临时去支离破碎地考虑解决方案，那当然会导致做事(I)的时间变长。

T

T 比 I 所占用的空间要大一些，指示其在整个制作环节中的地位高于 I。在整个制作环节中，T 所需要花费的时间要高于 I。

T 是一根横线加一个 I，表明

1. T 包含了 I。即测试包含了实现。T（测试）出 I（实现）有问题，需要再去 I（实现）。
2. T 也是 I。即测试也是实现。测试与实现都是在完成 Do 出来的完美设计。这个设计的完成需要 IT（由设计变为实际的功用，统称实现）。

Do IT 方法示例

家里停电了

在家里呆着，突然停电了。

停电这样的事件引发了问题，为了更多的了解问题，考虑可能的原因：

• 接入口保险丝启动保险
• 家里可能短路
• 别人家里短路造成一个区域都停电
• 供电局计划内停电

然后对可能的原因组织：

1. 家里的问题
2. 家里保险丝启动保险
   1. 短路
   2. 电器负载过高
3. 区域的问题
4. 别人家引起一个区域内停电
5. 供电局计划内停电

然后形成一个解决方案：

1. 出门看看是不是整个区域都停电了
   1. 如果是，就等待
2. 如果不是，先看看保险丝是不是已经启动保险（有几个地方的保险丝）
3. 打开保险，如果立刻就停电了，那就短路，要修理了
4. 打开保险，如果没有立刻停电，可能是电器开得太多，那就开少一点

接下来就是实施，在实施的时候要一步步地看自己的判断是不是正确。

当然，在实际生活中，这样的过程是很快的，几乎想都不用想，以上是为了举例而选择生活中的一件事情。

做一个软件项目

本人的行业是 IT 行业，做项目是不可少的。如果来一个项目要做，大概是这样的：

1. 了解用户问题，用户期望通过这个项目得到哪些便利。为了深入了解用户目前的业务习惯，需要多方面去交流。
2. 整理用户的问题，可以分成几块，确定不同问题的优先级
3. 根据整理，给出一个设计，在设计的时候，不仅要考虑要让用户问题得到完美解决，还要考虑在实施的时候，会有哪些技术难点，并将技术难点都在这个阶段进行验证和解决
4. 做一个示例让用户去体验一下
5. 根据所有的设计，整理出一个文档（用户使用规范）。在这个文档里面，明确地定义出一个用户与软件的交互接口，用户可以知道怎么去使用这个接口，开发人员也知道如何去实现这个接口。
6. 开发人员去实现，同时测试跟上。((在这个过程中，用户可能对一些问题需要重新考虑，此时需要相应地更新《用户使用规范》，由于之前用户已经对示例进行过体验，所以产生巨大改变的可能性比较小))
7. 交付项目，后期维护项目