角色转变
自从7月份加入了当前的创业公司，承担起了iOS开发和技术管理任务。说是技术管理，其实就只带了五六个人，整个公司不到20人，谈不上什么专业管理，倒更像个“催活的”。不像大公司的leader ，我更偏向于细化任务，制定明确KPI，跟踪进度。
这个角色转变，让我看到了另外一个世界。
重新看待专业素养
以前，我把“专业素养”和“专业技能”混为一谈。认为一个有较多的工作经验和能实现复杂的功能的工程师视为“高手”。我也把专业技能的精益求精作为第一追求目标，想着老子只要技术过硬，到哪里都吃香。这个目标本没错，作为技术人员，对技术的追求本来就无可厚非。
而作为一名“工程师”，仅仅搬得一手好砖，那是远远不够的。
尽管几年前我就认识到，不仅专业技能重要，沟通能力、协作能力、规划能力、汇报能力、工程思维也同等重要，都是“专业素养”的一部分。然而经过最近几个月的经历，让我对这个问题认识更全面一些。
产品是以市场为导向的， 并不是以工程师为导向。这点你必须接受。很多工程师会对产品的“改动”以及“不合理的设计”有极大的抵触。这种抵触心理，很多时候是由工程师的认识局限性和固执的性格引起。这里面有很多矛盾能沟通能解决的：你觉得这个设计有问题，你可以说出你的认识，但你的认识只能作为产品经理的参考，最后还是产品经理拍板；你觉得一个并不太重要的小功能会导致工程结构的调整，那就在需求评审会上提出来，你的领导、架构师、产品经理认为你讲的有道理，那么这个需求是可以去掉的，最后还要反思一下是不是自己在架构设计上有缺陷。但最好不要附加太多的情绪，别那么小孩子脾气。
要有工程意识。做工程就会有工期计划问题、多部门配合问题、工程质量问题。就单说工期计划问题，有很多人不愿意去评估开发时间，不愿意做太多前期计划。功能需求来了，就迫不及待地开始编码，一顿操作猛如虎，两天之后去重构。工程中的环节都是承上启下的，对自己的工作做一个严谨的时间预估是对工程最起码的尊重。下一个环节的起始时间是根据你的截止时间作为参考的。否则整个工期就不可控了。程序员如何精确评估开发时间？
不要为所欲为。遇见过一个工程师，猎奇取向很重，对所有新兴技术都会去了解一下，这本来很好。但可恶的是，喜欢把公司的项目作为试验场。在不告知同事和领导的情况下，自己用一个新的框架重构一个小模块，结果出来一大堆新bug……，自称是“敢于追求新鲜事物”的人。另个哥们儿自称“崇尚自由”，可能所有的开发计划对他来说都是束缚吧，反正经常打乱计划顺序，经常延期。路子太野，会给同事领导和整个工程带来极大危害。
积极主动会提高自身价值。著名畅销书《高效能人士的七个习惯》中的第一条就是“积极主动”。积极主动的人一般都比较受欢迎，更受领导器重。这不仅是能力的体现，更是做人做事的优秀品质。
“最令人鼓舞的事实，莫过于人类确实能主动努力以提升生命价值”--亨利·戴维·梭罗
重新看待职场情商
这个标题其实是上面说的“积极主动”的延续。就简单列举一下笔者认为是“情商略低”的一些表现：
- 从来不加班，老子效率高，工作已经做完了呀；
- 情绪化严重，没耐心，易怒；
- 矫情，对于一些“不公平”无法忍受，四处泄愤；
- 犯错后第一反应是解释；
- 废话太多。
列举的这五条，大多数人或多或许会沾点边，包括我自己。而这些不好的习惯，都会限制自己的发展，或者短期利益，比如评优。
人生来就是一块棱角分明的石头，需要不断地雕刻自己。尤其刚毕业时间不长的新人，不主动快点收敛自己的任性，那么就会有人和事主动让你失去棱角。我也是从那个阶段过来了，慢慢地，就理解了之前的领导说的话和做的决定，理解了之前年长一些的同事的工作状态了。并对之前自己的一些任性的、自以为是行为感到懊悔。
工程师的潜力和规划
由于职责的原因，我要关注队员们的输出结果和平时表现。这个时候每个人的特质、态度、专业技能以及潜力很容易展现得清清楚楚。
一个人当前的特质和态度，会决定未来三五年的成长速度。有时候会很明显，很明显地能看出一个人三年后还是只能写UI和简单的逻辑；很明显地能看出如果公司裁员，第一批裁的是谁；很明显地看出三年后这个人能成长为leader；很明显地能看出这个人的发展方向是技术专家。
但人往往是会改变的，有的是自我蜕变，有的是有高人指导，有的是被重大事件瞬间改变的。自我蜕变往往很难，现在的特质是几十年养成的结果，哪有那么容易改变。
我认为有以下这么四点可以帮助自己：
- 选择一个优秀的环境(团队)；
- 制定目标，并付诸行动；
- 逼迫自己，勤奋起来；
- 多接触其他圈子和比你厉害的人。
说来容易，做来难。我也在努力成长的路上。
说说自己
这半年，经历了很多之前没有经历过的事情，学习到了很多，自认为成长了不少。上面写的这些东西，是我看到的一些现象，和自我反思后的总结，只为大家都能进步。
脾气变好了不少。以前只做纯开发，相对还是很纯粹的。现在不得不考虑更多的事情。项目虽然很简单，你也要多方面考虑架构设计、技术选型、项目进度、项目质量。要和队员们把关系搞好，保证大家团结起来把事情做好。面对个别不好好配合的同事，要花一些心思和时间去“对付”。很多棘手的事情，只能压制住自己的脾气，耐心处理。压着压着，脾气就变好了，可能胸怀也变大了。
沟通技巧有点改善。一直崇尚简单、高效、直接的沟通方式的我，对沟通方式重新认识了一番。刚开始有位同事不太配合工作，后来才知道其原因是觉得我有点“领导口气”，表示不服。以至于一度关系紧张。反思了一下，可能是因为刚开始我操之过急，急于求成，再加上太直接的表达方式才让仁兄感到不适。
后来老板给我支了一招：把“你今天把碗洗了！”改成“你今天给咱把碗洗了如何？”。还有，对于别人提出的错误观点，不应该去直接否定，最好是让他去试错，给出几个他没考虑到的点，让他去试试。这样会增加民主性，也顺带提升了自己“威信”。现在和这位仁兄关系处理的不错。
其实语言技巧只是交流中的一部分，更重要的是内容、语气、和相互理解。
底层leader的定位。我的原则是别以为自己“当官”了。本来就不是什么官，而是工作职责问题。在老板视角里，你是第一责任人，要帮老板落实开发任务。在同事眼里，首先你应该是帮他们扛雷的人，他们的利益保护者，其次是协调大家一起更高效工作的人，最后你是一些技术问题的决策者。所以呢，你既要落实公司的决定，实现公司的利益，也要和大家打成一片，让大家觉得“我们是一波的”。其实挺难的，基本都是同龄人，不像相差七八岁的leader能天然形成威信力。
总之，这个过程给我提供了磨练的机会，让我去思考了以前从没遇到过的问题。这是一个成长的过程，就够了。
