前言
这个系列的来历是，前段时间一个队友建议我把自己做事情的思路总结出来给队友们参考，我也一直在思考用什么样的方式来总结这些经验合适。这阵子暂时离开了工作岗位几天之后，也在和朋友们约饭交流的过程中总结了些心得和经验，所以打算以实习日记的形式写下来与大家分享，来谈谈我的岗位、我的项目经验、我的公司等等和实习有关的东西，讨论技术、产品、市场、团队等我所能观察到和意识到的每一个方面。
这篇文章主要以实习工作遇到的项目为例，介绍我在某个项目的过程中的经历和经验，希望可以给大家带来一些启发。
一个典型的项目流程
我的实习项目的一个典型的流程是这样的：我们的各个业务部门，比如宅急送事业部等，经常遇到数据分析的问题需要解决，他们会和我们部门沟通对接、开会讨论确定需求。然后我们部门的Senior会把部分任务分解并分配给我们实习生，和实习生详细的讲解需求是什么、要做成什么样子、大概要什么时候做完、时间赶不赶、要用什么数据库的什么数据、技术上大概需要怎么处理等等。我们接到项目之后就开始做，做完以后和Senior讨论沟通，Senior再和对应部门对接讨论，再反馈结果给我们，我们再继续根据业务部门的具体需求继续修改，直到做完为止。
在这个过程当中，我会怎么做呢？在讨论、执行、填坑、汇报、修改整个流程里面，我都会把握一个原则：反复沟通、快速迭代、及时反馈，以保证尽可能少走弯路。
在讨论环节，Senior讲完了整个背景以后，通常情况下我是懵逼的，这个时候如果我完全没有总结下来我要做什么、怎么做，我会问我的Senior我应该做什么，Senior会再给我概述一遍。我理解大概以后，会重复一遍，“是不是这样，XXBBXX……”，Senior如果觉得哪里理解的不对，会再和我讲，直到我理解清楚目的为止。比如，Senior给我的最新项目是一个对我们近期发的优惠券的效果的分析，由于各种原因，业务部门和他都不清楚优惠券数据是个什么样子，因此让我从不同的维度分类探索。一开始我很懵逼，因为之前都是一些比较固定的事情，这次突然要我自己探索，我就没有理解清楚。Senior非常耐心地再次提点了我，直到我明白为止。这个时候我的新问题又来了，那么我的探索应该指向什么方向呢？Senior又告诉我，业务部门希望可以看每组活动的效果，我立刻就明白了我需要探索的目标。我又产生了新的困惑，如果活动太多怎么办？Senior又给我解释了这个技术细节，虽然可能活动非常多，但是最大的肯定只有几个，我在后期把剩下的标记为“其他”就可以了。然后我就明白了我要做的事情是从不同的分组看看最近做的活动效果怎么样，看看从什么角度分类最适合讲故事，把看起来最“make sense”的找出来。于是我就回去开工了。
在搞清楚我要做什么之后，我会开始思考我要从哪几个方面入手，开始写README或者TODO文档，规划一下每一步做什么、要用什么数据库的什么数据的什么变量、要用什么函数。通常这部分如果遇到问题，我会在前面的讨论环节提出来，或者再次跑去和Senior讨论确认。如果Senior知道，他会直接和我说；如果他不知道，他会告诉我谁知道，或者让我自己去探索。如果遇到必须要我自己研究的部分，我会把这个步骤也写在TODO文档里面并做标记。比如，我把看优惠券这件事情分为了三部分，第一部分是用SQL把交易数据和使用券的数据合并，第二部分是导出来CSV然后用Pandas看看有券有哪些维度可以分类加总，第三部分是用Tableau把加总数据可视化。我分析了一下步骤，第一步和第二步可以一起做，第三步要根据前两步的结果汇总；因为我们的数据量很大，第一步占用的时间最久，通常在服务器正常的情况下一轮要跑半个小时左右，如果抽风就……很绝望了，所以我先导出了第二部分需要的数据放进了Pandas玩，一边挂着Hive让它慢慢查。第二部分结果出来以后，我发现果然如我想的一样一片混乱，就跑去和Senior沟通。Senior再次提醒我让我画出来饼图先看看比例，于是我就先放着了这个问题，把第三步做出来。果然画出来饼图之后，我发现大部分维度都是一团糟，只有业务部门最需要的按活动组分组加总的结果最“make sense”，而且果然每个饼图里面比较大的就几个。
在这个过程中，如果我遇到一些我清楚比较耗时间的坑，或者我没有解决方案需要探索，我会请示Senior要不要把坑填上。虽然对于我来说，这些点是我真正需要学的地方，然而我是在工作，我首先会考虑我能不能按时完工。比如说，在画完上面说的饼图以后，我发现了新的问题，就是同一个活动的命名和标记非常混乱，于是我把这个问题汇报给了我的Senior，然后请示他要不要我自己动手清洗。如果在我之前的项目里面遇到这种问题呢，我会自己动手处理文本数据，手动或者半自动清洗，但是这样做比较耗时间，也不敢保证正确性，于是我和我的Senior请示我要不要继续做，Senior告诉我说让我继续往下画图，于是我就把我挑出来的十几个变量都画了一遍饼图。
初步结果做出来之后，我通常会立刻捧着电脑去和Senior讨论有没有发现方向上的偏差，如果有缺少的部分或者做错的部分，我会立刻拿回去继续修改。如果没有主干问题，这个时候Senior会和我讨论怎么完善细节、如何让图表结果更好看。如果我不太确定要怎么实现，我会和Senior沟通我的思路，如果Senior不在意，我会按自己的思路尝试；如果Senior有更好的思路，通常会告诉我怎么怎么改进。如果我觉得哪里我可能会遇到坑，我会告诉我的Senior这里我不熟悉，需要研究一下，可能会耽误时间。因为我们的工作进度通常不太紧张，所以Senior一般都会给我很多时间让我慢慢改，这个时候我就可以非常愉快地给自己挖坑填坑了。比如说，今天看了一下午的Tableau的文档，研究怎么把饼图画的更好看。
后面的过程通常就比较磨人，就是一步一步地根据Senior的要求、Boss的要求、业务部门的要求一个一个细节的改，几个版本几个版本地更新结果，几十次几十次的改一个项目。但是通常提高对问题的敏感度的地方也在这里。比如说，之前的一些项目Senior会要求我加一个维度，我发现自己的代码逻辑需要重新组织一下才能实现。再下一次的时候，我会在Senior让我做某个项目的某段之前，提前问下一段的逻辑，以方便选择更合适的逻辑。然后就是一些对工具的困惑，这些困惑有些可以解决，有些没法解决，解决掉一部分是一部分，也可以很有进步。
完工以后的项目我会检查和整理文档和注释，包括完善README，完善主要代码的行间和行外注释，修改文件命名增强可读性，主要文件分文件夹存放，临时文件、中间文件另外存放等。之后这个项目就会变成我的一个轮子，以后抄自己代码就方便了许多，也方便给别人分享这个项目的流程，很快速地就可以变成一个Presentation。如果有一些可能比较普适性的在数据库方面或者工具方面的心得，我会放在一个单独的文件夹里面存放总结出来的经验，形成指导和说明文档，方便自己和别人查看。通常我也会发现一些新问题，就会和我的团队吐槽这些问题，有一些我会知道原因，有一些大家都不知道，我对问题的敏感就是这么一点一点积累出来的。
我为什么要这样做？
在这样的项目习惯的背后，思路其实非常简单清晰：以优化整个团队的效率为目标组织每个项目。在项目之前和项目过程中，我会花大量的时间和精力，非常主动地和团队沟通，提出问题和讨论方案，搞清楚Senior和我的预期是不是一致，然后修改掉该修改的部分，以防止走弯路浪费时间，甚至影响后面项目的进度。在整个项目过程中，我会计划好每一步要做的事情再动手，防止自乱阵脚浪费时间。在每一步，只要做出来一点结果，就立刻和Senior讨论，看有没有偏差、要往哪个方向改进。梳理和总结项目资料是为了帮助自己和别人更好地把做完的项目作为一个模板持续使用，以在后面的项目里面提高效率。
我在管理自己的团队的时候，经常会发现，作为一个Senior，最大的麻烦就是信息不对称。一方面，由于“知识诅咒”现象的存在，人容易认为自己已经学会的东西别人理所当然地应该会，特别是某个领域了解越深越容易出现偏差，经常不知道我的队友不知道什么，也就不好针对性地讲解；另一方面，我经常看不到我的队友的计划、进度、困难、结果、总结，对我的队友的情况一无所知，或者需要不停地催才会行动，能自律地给自己定DDL、和我反复沟通需求的队友非常少，这就让我的整体计划的修改非常棘手。所以我会很主动地多抛出问题、多抛出结果，让我的Senior知道我在非常合作地跟着他的脚步走。在业务方面，因为我很明白，我刚入职，很多情况还不太熟悉，即使有一些感觉有点违反我的经验的问题，我也会先压着把项目做完，而通常我做完以后就发现了原因。这个过程中我也不断发现，我的Senior们在指导我的技术和业务逻辑方面非常有帮助，因此也更加信任我的团队。
合作不仅是一种态度，也是一种能力。面对可能多变的业务需求，保持充足的沟通非常重要。那么怎么定义什么是需要沟通的，什么是不需要的呢？思路很简单，会直接或者间接影响到Senior的所有信息都需要沟通。比如，技术实现的细节要不要沟通呢？如果这个技术细节非常耽误时间，可能会拖累项目进度，导致Senior的安排可能会出现混乱，那么这里的实现方案就需要沟通。如果进度不理想，解决一个问题超出了我的预期时间，比如改一个SQL语句超过了一个小时找不到bug，这个时候就需要让Senior知道问题出来哪里，是系统性问题还是我自己的能力盲区的问题，也需要沟通技术细节，这个时候我甚至会拿着SQL代码去找Senior们反复讨论反复修改，因此我入职之前虽然对SQL、Hadoop、Hive一无所知，但是一周以后我很快就熟悉了SQL；一个月以后的现在，我已经写不下去很多Pandas操作转投SQL了。我自己作为Senior带团队的过程中，我非常喜欢我的队友向我提问和展示结果，我可以知道他们困惑的问题在哪里并针对性地解决，可以看到他们已经做的东西，确认他们有没有在做事情、做的事情有没有偏，然而……现实都是骨感的，这样的机会相比于我分出去的任务通常是少到让我绝望。而越是复杂的任务，少了这种不断的沟通，越是容易崩溃。我的团队有一些项目，做了一个学期没有看到第一版结果，虽然有各种各样的原因，但也是让我很无奈。总之，做项目成员不容易，做项目Senior更不容易。
总结
平稳的执行力、良好的沟通反馈，是流畅地完成一个项目的关键。习惯的养成并不难，而意识的养成却不容易。我也是在经过十几个组织，经历过成员、组长、合伙人（核心负责团队之一）、执行负责人（上头有个boss）、总负责人（自己是实际上的boss）、创始人（自己创建的项目）等一个组织可以存在的所有角色之后，才开始慢慢明白这些。希望可以对你有一些小小的启发和帮助。
