技术人员的管理

shuddkk

技术人员很单纯，但有些人觉得很好管，有些人觉得特别难管，这里需要管理者完成心理建设和掌握一定的管理技巧。更重要的问题在于你怎么看待你管理的这些技术兄弟，是压榨他们的价值，还是在认可文化的前提下通过提升他们的能力，双方共同成长。

我不是一个管理型人才，应该说我不懂管理，也不会有人天生懂管理，大家在不同场景遇到的问题都不尽相同。管理对于一个技术出身的人而言天然痛苦，工程师们天生的社交恐惧心理，与人打交道痛不欲生，与机器打交道其乐无穷。但是，逼不得已，一个创业公司或者一个研发团队，不可能让一个销售型人才来带，双方就更痛苦了。所以很多场合，一些技术人员逼不得已赶鸭子上架，负责了对技术部门的管理，一开始都是鸡飞狗跳。

我觉得管理技能是可以锻炼的，是能够解决的，一种最直接的方式是把坑一个一个的踩过来，成本高周期长；还有一种就是听取前人的经验教训，能迈过多少就迈过多少。我写这些也是把曾经犯过的错误进行了总结，提炼了我认为最基本的三个要素供大家参考：

一）首先要真诚对待，我们的目标是通过筛选和培养出人才，推进公司的发展，所以是相互尊重相互成就的过程，一定不是农场主与奴役的关系。这里我故意放大描述，因为很多管理者心态就不对，认为自己是管理者就应该高高在上，通过不经意的言谈举止体现出来，颐指气使，最终相由心生，展现出来的就是傲慢，指责，压抑。

二）其次要提前沟通好目标和质量标准。技术人员的管理其实是特别好量化的，大家都是理科男，对于0和1的理解很到位。沟通好目标方向，以及什么叫黑什么叫白，大家就单线程的执行去了，特别单纯可爱。所以计划的制定尤为重要，一定有任务描述，有完成时间点，以及衡量好坏的指标，如果可以的话尽量让技术人员理解做这件事情满足公司的哪个重要战略方向，为什么很重要。

同时任务划分因人而异，切忌每个人来了就丢一个任务大包，大家的理解能力不一样，技术等级不一样，所以除非你明确已知某位同事是能够接任务大包自行分解的人才，其他的你都应当帮他分解成足够小的单线程任务（这里说个心得，你最好先假设每个人员都不是人才，这样你心情会好很多。你的预期调整为每个人都不行，你后续看到的就是他这个可以那个也好，培养一下提升很快，筛选的就是人才了；反过来说，如果预期每个都是人才，交付过程看到的就全部是问题，你不爽他也不爽，是人才也被干掉了。而预期来的是人才的想法是绝大多数人的初始值）。这里每个人的目标制定与成长计划应当是量身定制的，如果你满足第一点真诚对待的要求，你就知道如果连帮兄弟们梳理目标和成长计划都“没有时间”的管理者，大家会认为不被重视，放任自流。

三）既要管，还要理。这里就提到初级技术管理人员一定会面临的问题：很多人做到了制定目标，但是忽略了过程的跟踪。过程的跟踪就包括了确保思路的正确性，以及标准动作的规范性（代码规范，单元测试覆盖度要求，版本发布流程动作等），还有就是基础能力的学习储备。只按照到时间点对结果的验收，中间会有很多信息丢失和理解不一致的地方，一段时间过后再看结果一定出问题，那时候只剩下骂。浪费时间不说，相互之间不认可，管理者认为员工能力很差没有交付，技术人员却还会觉得自己很牛，领导啥也不帮忙，只会扣帽子推卸责任。

跟上面一样，目标的梳理要因人而异，沟通的方式也就因人而异，主动型人才和配合默契的人才，交代一件事过一个季度再去确认都行，而刚入职的一定要每天跟踪，甚至每次代码提交都跟踪，确保关键动作没有问题。及时反馈，让大家尽快切入到共同的知识体系，保证后续的配合。

还有一个问题大家经常遇到，就是说太忙没有时间沟通，说有这个时间代码都写了很多份了。这也是认知的问题，管理就是要做好后备力量的储备，做好人才筛选的准备，必须给予培养的时间和精力，想在这方面省时间的，一定不会是一个合格的管理者。一定要留时间沟通，做到的要表扬，没做到要帮助兄弟们梳理为什么没做到，如何解决。所以，一个管理者至少每周花上一天时间跟兄弟们做面对面的交流。

最后，研发不只是代码，有质量管理，有架构选型，有效率提升的工具选型，还有学习方法，时间管理，代码哲学以及人生观的问题。大家会选择优秀的平台和领导，领导一定要以身作则，用卓越的能力和战略思维带着大家前行，先成就员工，再成就公司。

小白的白

研发不只是代码，有质量管理，有架构选型，有效率提升的工具选型，还有学习方法，时间管理，代码哲学以及人生观的问题