转型技术 Leader 不能错过的几点建议

在我十多年的工作经验中，遇到不少老板，其实是对他们的技术 leader 很不满意的。有时候迫于自己不懂技术，项目又在一直进行，暂时都在忍着。但背地里却也都在物色新的人选，要不我也不会遇到这些人。其实，那些 Leader 的技术实力听起来都并不弱，可为何还会出现这种局面呢？这里主要还是意识和观念出了问题。下面我们简单聊一聊。当然，这些对想转型为技术 Leader 的人也相当受用。

| Leader 的基本价值

技术 Leader 存在的最基本价值，就是要保证项目能按时交付。现实中，甚至有一些 Leader，都脱离了具体的编程工作了，也还是混得风生水起。这大多是因为，他们能让老板相信，只要他在，团队就能按部就班地完成需求。这份信任其实很难。当然，一般情况下，Leader 总是团队里技术能力数一数二的。要不也很难应对各种意外情况和为整个团队擦屁股，更难以服众。但技术实力相当的人其实也不少，为啥并不是人人都是一个合格的 Leader 呢？就比如一开始谈到的那些技术 Leader，他们总是稀里糊涂的让项目一次次的延期，还怼天、怼地、怼老板。这种压根没把项目进度当回事的人，能让别人放心把项目交给他吗？

| 项目管理的学问

当然，保证项目按时交付，也是个很大的学问。当今互联网行业，在项目管理方面，无论是瀑布流，还是敏捷开发，重点都是要考虑以下两方面：如何制定合理的计划和怎么进行有效的进度监督。当然，每种方法论都有自己一系列的相关细则，但本质上的东西，很多也是相通的。

| 制定合理的计划

制定合理的计划，关键还是要看你能不能做好需求量化的工作。无论是编写用户故事，还是拆解任务计划，都需要我们做得足够的细致。这样才能让我们估算出来的工时，和实际开发时间大致相符。你当然可以无脑的申请“足够的时间”，但没有明确的细则，也很难真正说服别人。最后只能成了“你专门多报，别人每次砍点”的恶性循环了。这种情况，怎么相互建立信任？当然，具体的量化和时间估算的方法，可以参考不同方法论的玩法，也需要你积累足够的经验。

| 有效的进度监督

有效的进度监督，首先是你得勤快。互联网行业而言，每日的进度沟通是必要的。当然，你得有办法去核实，团队成员说的进度更新，是否真的有效。自己顺一遍代码，或者通过测试反馈都可行。而进度出现了问题，也需要及时调整任务的安排。当然，更重要的是，在必要的时候，及时和需求方沟通。拖着不说没什么好处，等别人发现了问题再找你，你就很被动了。而别人大概率也会认为，你并不靠谱。

| 博弈技巧

无论制定计划，还是进度出了问题，都需要和需求方重新探讨时间表。怎么和需求方博弈，其实也是个很有技术含量的事情。首先，博弈的目标，无非是项目延期或是砍掉一些需求，尽量别加班。而博弈的关键，还是在于你是否有足够细致的量化任务表。有这个，你才能比较有理有据的谈延期或砍需求。当然，现实中也有很多寸步不让的情况。此时，你就可以给他讲厨子的故事了。炒菜是需要时间的，催得着急，当然可以说马上好了，但最终菜做出来的时间，并没有什么实质改变。（该比喻源自《人月神话》）

| 技术升级和团队建设

Leader 日常工作的一个很重要的事情，就是处理一些高技术问题。比如各种技术债，和整个团队的技术升级。当然， 最好是带着整个团队一块做，提升整体实力是一方面，让大家工作不那么无聊也很重要。当然，很多团队也在做其他的一些团队建设。比如一块吃个饭，增进下感情，确实也能让工作更加顺利。不过，在中国的现实层面，这些并不是所有公司，都十分看重的。

| 意识与态度

上班，从来都只是一场交易。作为一个基层员工，没意识到这个问题，影响并不大。但到了 Leader 层面了，如果还没意识到这个事实，那定位上肯定会出比较大的问题。我们是来给公司提供优质的编程技术服务的。老板没责任为你考虑。类比来说，你点奶茶的时候，会花很多时间，考虑服务员的感受吗？你只在乎他快不快，弄的东西好不好。人家服务员可能不小心夹了手，或者让顾客催的心情也很烦躁。所以，你凭什么总希望老板能考虑你的感受？做个有想法的人，多站在老板角度想问题，很多事情都会变得顺利一些，自己的价值也更大一些。当然，也是有不少穷凶极恶的老板的，但这不影响我们提供优质服务。实在接受不了，大可以换一家。

| 转型的机会

随着互联网风口的消散，现在转型的机会肯定是大不如前了。没那么多新项目组需要新的 Leader，也没有雨后春笋般的新公司。但在一个单位一直呆着，只要一直努力，意识和思维上能调整过来，还是有些机会的。当然，也可以考虑考虑一些小公司，最起码可以混到些实际 Leader 经验。