给技术人员一些技术以外的建议

　　做 IT 也有好些年了，中间踩过很多坑，踩完坑之后也有不少收获。有些东西只有自己经历过才会印象深刻，不废话，先记录以下这些吧，后续想到再更新。

　　1 需要及时反馈

　　举个例子，如果你手头有一个事情需要别人去完成。当你告诉别人这个需求的时候，很多情况下是希望那个人能够给你完成时间点的，而不是简单的告诉你会去做。更好的情况是，当你给出需求的时候，那个实现者能够提供出更好的方案，或者能够和你一起分析实现过程中可能遇到的问题，解决的大致计划，最后给到你一个完成的时间点，顺带说明下可能存在的风险。这样的回复，你会觉得这个人做事是靠谱的，是真正理解了你的需求去做的，而不是拿到需求后放在那里应付一下或者排计划(排计划最好也给出一个能够制定计划的时间点)，需要不断地 push 才能做。

　　工程师或者技术人员作为实现方，承接很多来自产品、运营、甚至市场的需求。这些需求当中，有些可以明确的确定相应的技术方案，有些需要调研，有些可能现阶段技术上还不够成熟。无论是以上哪种情况，在接受需求的那一刻，你需要及时的反馈一些信息给需求方。比如预计完成的时间，可能会遇到的困难。让需求方能够经常性的知道事情的进展情况。这个就好比我们网上买完东西后，会经常性的去查询当前货物的物流情况，大概什么时候能到。所以换位思考，当提了一个需求给你的时候，你也需要经常性的将这个信息反馈给需求方，让他实时了解进展。

　　2 注重团队合作

　　现在的软件开发，是一个分工合作，协同作战的过程。像张小龙一个人写出 foxmail 的年代已经一去不复返了。在开发的时候你需要将自己作为团队的一份子，互相合作。当自己遇到问题的时候，及时的抛出来给团队，而不是一个人在那边死磕。记住，你的背后是一个团队，你和他们在一起战斗。

　　在这个大规模协作的时代，一个人想要做出类似前辈们那种靠着单打独斗就做出类拔萃的成果已经变得极其困难了。这样的人，更多的时候是以领导者或者组织者的身份出现，但是真正的成绩都是靠背后的团队创造的。现在的产品想要成功，除了产品本身要可用、易用之外，很大程度上还依赖产品背后的运营、市场、投放、推广、数据挖掘、黑客增长等等方面。酒香不怕巷子深在现在这个快节奏的时代已经成为了历史。一个优秀的团队，是一个产品成功的必要条件。让自己融入优秀的团队，成为团队的一份子，荣辱与共，共同解决困难，一起分享喜悦。

　　3 专业人做专业事

　　现在的社会分工很细，自己不懂的领域，找专业的人来解决。技术人有个特点是很多的事情喜欢刨根问底，追求知道所有的技术细节，甚至恨不得所有的东西都自己从头搞一遍。在现代软件规模下，自己搞完全是不现实的做法。术业有专攻，一个不专业的人去做一件事情，无论从时间成本还是经济成本肯定是不如专业人士，而且除此之外，往往还有看不见的成本，比如人的能力。即使时间充裕，资金充足，最终出来的产品也未必能够超越专业的。所以除了核心部分，其他的就交给专业人士去做吧。

　　4 做事要讲究效率

　　在外界看来，互联网有个特点就是加班多。996，997 也经常被周围的人提起。从效率上来说，程序员有效的工作时间也就那么几个小时。程序员是一种创造性的活动，需要的是灵感，而不是靠时间堆积的。所以更多的时候是需要找到自己效率最高的哪几个小时。在哪几个小时里去提高自己的生产力，而不是磨洋工。

　　还有一点，随着产品开发的节奏越来越快，手头的事情也会越来越多。永远不要想着把所有的事情全部处理完，总是有一些重要的，紧急的事情需要去处理。那些不重要和不紧急的事情，就随它去吧。大部分时间专注于那些重要不紧急的事情，才能避免经常处理重要紧急的事情。

　　5 做好自己，再说别人

　　家里小朋友现在做一些事情，比如看电视，或者玩手机，我们都会有限制，而小朋友张口的理由就是爸爸妈妈也看电视和玩手机。比起看电视或者玩手机，被批评的时候总是先从别人身上找缺点这一点反而问题更严重。这就好比我们经常听到或者自己感受到的，一些电动车闯红灯，被交警抓到的时候可能首先会说你看前面谁骑电动车也闯红灯了，为什么没事，觉得自己心里不平衡。甚至说你看行人也闯红灯，为什么不用罚。

　　这里面其实我们往往忽视了一个重要的点：就是我们做这件事情的时候本身就是不对的，既然不对为什么不从自身先找找原因。我们总是乐于积极搜索别人的短处和自己的长处。而自动忽视自己不好的地方。做好自己，绝不是一件容易的事情。自己没做好，其实是没理由说别人的。但是反过来，别人没做好，没理由说自己，这就强词夺理了。

　　6 凡事可以做的更好

　　这一条也算是对以上几条的补充。

　　大家都知道以前的汽车装配都是需要大量的工人来做的，很多装配工人成为熟练工之后就觉得装配是个体力活了。但是事实上，我们今天已经很少看到工厂里有大量的装配工人了。觉得体力活完全是认知问题，不代表做汽车装配这个没有提升的空间了，否则的话目前你去工厂可能还会看到大量的装配工人，而不会有现在流水线的装配作业了。有没有提升空间关键在于你是不是那个不安于现有的体力活，想把它做成流水线的那个装配工人。

　　有时候工程师业务做久了，业务层做的工作类似于装配工人做的事情，会觉得没有提升的空间或者提升的空间不大。其实大部分只是因为你用已有的认知思维用你熟悉的习惯方式做业务而已。拿到业务后，你会下意识的决定使用很多熟悉的技术方案，这些方案形成了你自己的舒适圈，你喜欢呆在这样的舒适圈中，没有想过去突破。渐渐的你就会觉得业务对你来说没有了挑战，觉得做着没意思。

　　其实写业务代码一样可以很牛逼，业务做多了之后，你需要思考的就是如何将业务封装和抽象出来，使业务代码可以更加方便的维护。或者从 SDK 的角度出发，如何让新人能够通过简单的文档就能实现业务。这些事情，同样都是业务层面的事情，但是在技术维度上却已经是两个完全不同的层次了。有句广告词：没有最好，只有更好。同样的一件事情，做完和做好，结果上不一样，收获也不一样。

　　以上几点是平时工作中的一些感悟，自己有些也做的不好，拿出来分享给大家。也算是给自己一个警示，和大家一起共勉。