文章如果要换个题目，可以叫<第一次IDP约谈有感>。本文主要记录了一下IDP面谈的过程和我的一些反思。如果你只想了解啥是IDP，请阅读第一节即可。如果还想了解IDP的基本套路，请顺带看第二节。如果你是好奇宝宝或者在蹲厕，请继续看第三节，记录了我的一些反思。

关于IDP

IDP，即Individual Development Plan，个人发展计划。

我是上班了大半年才知道这个术语，百度百科里的”IDP”词条都没有这种解释。（然后我去添加了这个词条的义项）。

IDP的宗旨是每个人为了自己的发展负责。本人在IDP的推动中起关键作用，这个过程是非强制的，但是它对个人的发展有帮助。

IDP有两部分：

• 待发展项结果。可以自己反思总结，或者和mentor或者LEADER沟通，发现自己不足的点。
• 发展计划。针对自己不足的点，制定具体、可度量的、系统的计划。

IDP是一种计划，制定IDP只是一个开始，在之后的工作中严格按照IDP执行才有意义。

我认为IDP不是一定工作了才需要做，学生阶段、家里蹲阶段、创业阶段等等都可以，它督促你反省与思考，提供具体可度量的目标，不容易迷失在前进的道路中。

第一次IDP面谈

这周五(2017-04-14)我进行了人生的第一次IDP面谈。

早在两个星期前LEADER就提醒每个人，要认真准备IDP，但是我在去厦门浪了几天之后，彻底忘记了这件事情。直接后果是，当LEADER找我面谈的时候，我的第一反应是懵逼，当时的我除了知道IDP是”个人发展计划”的意思外，啥都不懂。

现在想来，面谈的过程中，我逻辑不清晰，重点不突出，有些话没想清楚就说了，导致前后有些矛盾，同时交谈的过程中，我有些紧张，思维不活跃，表达不够具体。这次面谈给自己打4分，远远不及格。反观LEADER，很老司机，交谈的过程中思路清晰，话题被我带偏的时候能立马回到正确的方向，对我抛出的问题能很快指出问题的根源，给出改进的意见。

交谈的内容当然不可能一一记下，总之就是我的沟通表达能力被吊打。根据我现在还记得的面谈过程，总结下来，这次IDP面谈的关键提问有如下：

1. 你半年之后的目标是什么？ 你三到五年的目标是什么？
2. 你觉得现在的你离实现目标还有哪些点需要得到提高？
3. 你是否有提高自己这个能力的计划？
4. 你有哪些工作中很想得到提高的能力？
5. 现在在工作上有什么问题依旧是未解决的？
6. 过去半年工作你有什么收获？

可见，提问的目标大致有两部分：一，个人能力的发展。二，工作表现的提高。这个可以理解，公司关注员工的个人能力提高，提高了的个人能力也可以反馈到工作效率，提高公司效益，这是一个互惠互利的过程。对于一个普通员工来说，如何平衡个人能力发展和工作产出需要花时间认真思考。

反思

讲讲面谈的过程中，我的一些收获把。我觉得我的反思可能对部分同学有一些借鉴意义。

定期总结和反思的必要

我于2016年7月份入职，半年的实习期结束后，写周报就不再是一项强制的要求。虽然我偶尔也会自己记录一下一周做的事情，但是效果非常差。我会觉得在我不被要求写周报的一长段时间里，工作的收获非常少，印象也不深。逐渐逐渐，我觉得有点麻木，没有入职开始时的好奇心，没有深挖一件事情的自驱力，思考的问题的方式逐渐趋向表面(此处省略各种缺点)。麻木和习惯是强大的敌人，如果不是这次IDP面谈给我敲响警钟，我可能会继续麻木下去(这句话是真心，不是跪舔)。

从IDP的效果上看，我看到了定期总结反思的必要性。如果没有定期的总结和反思，就会把一个月过成同一天，人就会慢慢麻木，慢慢咸鱼。思考才能让时间变得深刻。

什么都别说了，我以后每周都要求自己写周报。

时间管理？解决问题的根源。

LEADER问我，你有什么地方是需要提高的。我首先回答的是，我需要提高自己对时间的管理能力。

这确实是一个我的一个痛点，”如何提高自己的工作效率”这个问题我思考过很久。其原因是，工作中，临时出现的，琐碎的事情实在是太多了：回答客服的问题；处理项目范围内的CASE；回答其他业务技术的问题；帮产品或者其他技术拉取相关数据；排查线上故障或者BUG等等，事情总是接踵而至，不仅仅能够专心coding的时间变少，在coding的过程中我还总是被打断。

于是我认为：我需要一个更科学的，更合理的时间管理方式，才能提高自己的工作效率。

LEADER却说：我认为这不是时间管理的问题，而是你没有从根本上解决出现的问题。

像是打开了新世界的大门，我从这个视角出发，再来看待之前的问题，似乎有了更好的解决方案。修复常见的CASE，降低case量；将常见问题文档化，可以降低沟通时间……先从根本上解决问题，然后再根据优先度处理事情。第二象限（重要不紧急）的事情高优先度，低优先度的事情延后解决。这比”找一个更好的时间管理方法”更有可行性。

你说你工作效率低，事情总是做不完。可能不是你工作效率低，而是你事情本来就多，但是多出来的那一部分是可以优化的、从根本上杜绝的事情。

制定计划需要可度量的指标

在被问到专业技能提高的计划时，我说我有过计划:把我之前买过的几本技术书都读完。

LEADER指出，这种计划是不确切的。

我说，我的计划是两个月读完一本书。

LEADER说，这也是不确切的,非常概括，也非常不明确。两个月读完一本书，进度应该如何分配？ 另外，什么叫读完？

结论：计划的制定需要将一个大目标分解成若干个小目标，再给每个小目标制定具体的时间要求和产出，同时产出需要有一个能具象化到数值的可度量的指标来衡量结果。

分享与演讲能力

话接上一点，我提到我计划在读书的过程中，随手做批注，同时读完书之后，会写读书笔记或者一些总结的文字。

LEADER说，不考虑做分享么？

我不记得我怎么回答的了，大体上我的反应是：我拒绝。

废话，技术分享是一个比看高数还要痛苦的过程。技术分享和看技术书籍是无甚关联的事情。一般的技术书籍，会介绍某个技术的各个方面，大部分书籍都是着重讲使用方法，部分穿插着整体架构或者设计理念，很少会涉及到底层实现。而一个优秀的技术分享，是需要一定的深度的，不能仅仅停留在使用方法上，所以书本上的知识是完全不够的，我得花费比看书更多的时间去糊脸上上查看文档或者看代码，这无疑是一个痛苦的过程。

LEADER则表示，技术分享的过程中，真正收获最大的，其实是分享者。

LEADER又问我，你觉得自己的表达或者演讲能力如何？

我说，我已经放弃演讲这个技能了。

作为一个英语视听说课上演讲紧张到忘词的人，演讲能力是我的痛，痛到我直接准备放弃。

LEADER说，这不行啊，你再过几个阶段，晋升是需要演讲的，你的工作，你的成功，都是需要演讲来让面试官了解的。

我默然。

写到这里我突然想到了上次参加黑客马拉松的经历。我和我队友Robbie同学都是码农，在最后的作品答辩的过程中，我演讲的效果也是挺差的，最后打了一圈酱油回家洗洗睡。(说得像演讲的好就能得奖一样)

演讲能力在职场上，在生活中，都是一个非常重要的能力。无论主动还是被动，都是需要锻炼一下的。

谨慎批评

在谈到我对当前参与项目的评价时，我坦言，不对，我吐槽道，我觉得这个项目历史因素太多，写的有点烂。

“那是不好在什么地方呢？”

我顿了几秒钟，回答道，历史逻辑多，代码太乱，可维护性差。

“所以都只是代码上的问题么？”

我又顿了顿，因为我觉得项目不管是代码上还是在线上的表现都让我觉得项目的质量差，但是要我给出一个具体的东西证明一下，我又不能立即想出来。我回答说，业务逻辑里会有bug，而且存在数据一致性问题，关键操作没有幂等。

“一致性确实是有问题的，所以你有解决或者计划解决这个问题么？”

我实话实说，没有，因为现在项目没有到优化一致性或者可用性的阶段，还是在解决业务需求。

LEADER继续围绕项目质量发问，我则略心虚的一一回答。谈话的画风就是：我认为我做的项目质量很差，但是我没有整理出哪些地方有问题，也没有针对有问题的地方制定相应的修复方案，甚至没有一个很明确的东西证明这个系统确实很烂。

这段谈话也是我对自己很不满意的地方，全程花式懵逼，回答没有技术含量，同时自己确实也是有问题，只能硬着头皮接受意见。

教训是：

1. 谨慎批评。你批评一个事物的前提，是你有理有据让人信服，否则你一定会被打脸打的啪啪响。
2. 主观感受要不得，评价一个事物的好坏，需要有客观的证据，最好是实打实的数据。

当然，一个优秀的工程师会认真分析项目的不足之处，然后针对各个不足，制定相应的计划，并付诸实践。我离优秀还差好一段距离。

大局观

大局观很重要，不仅仅体现在游戏上。

比如在这次面谈中，我始终都是被动跟着LEADER的节奏走的，每当谈话的方向有点走偏的时候，总能扯回来。回想到之前还在找实习或者找工作的时候，听到有同学吐槽他的面试官，面试的交谈过程没有一个明确的方向，谈到什么就是什么，扯了一大堆有的没的，也让同学觉得这家公司不靠谱。

其实我也扯不清白大局观具体是什么。我认为它更多的是，在专注思考某个具体的问题的同时，能够站在顶层或者更广义的层面进行再思考。上帝视角懂么？差不多那个东西。

主动

“主动”是LEADER最后说到的一个关键词。

主动发现问题，主动挖掘问题的根本原因，主动解决问题。

我理解”主动”是一个对抗”懒惰”，对抗”麻木”的一个过程。自动去锻炼身体，坚持每天看书背单词，是生理上的对抗懒惰。主动在遇到问题时，思考问题的根源，是精神上的对抗懒惰。

人人都知道主动是什么意思。但是只有优秀的人才能真正做到。

计划

叨逼了这么多，要制定一下之后的计划，不然就是自己打自己脸。

1. 定时写周报。一周一次。
2. 记录自己工作中遇到的一些问题或者痛点，然后强迫自己定时(每周五下午or周日晚上)去Review，看如何从根源上解决。
3. 看完一本书，准备一次技术分享。每周的有效阅读量保证在80页以上(再也不给自己定太高的目标了)。
4. 不抱怨项目坑，整理项目有问题的地方，制定初步修复的计划。这个没有具体指标，说说就好。