|
看到一个讨论帖，原文如下： 平时的工作如何体现一个人的技术深度？平时工作中很多时候需求细而碎的，如何在工作中积累技术深度？又如何体现一个人的技术深度？ 思考：做需求与做需求的差异再回答问题之前，我想先抛开「技术深度」这次词，讲讲做需求这件事，说说我对做需求的理解。 每一个程序员都是从刚毕业做需求开始，为什么有的人逐渐成为大牛，主导大型技术项目或走向团队管理岗位，而有的人一直还在做需求。 我觉得这里面的差异在于：每一个对做需求这件事的理解有所不同。 这里面的差异在于，你是抱着一种什么样的心态去完成这个需求，是把这个需求做到极致，还是只是当做任务完成这个需求，达到产品想要的功能就行。 这两个表面上看似差不多其实相差极大，差异在于，你有没有站在更高的角度，希望这件事做到完美。 从需求角度有没有思考产品设计当中的缺陷，能不能反向为产品设计提供建议，从技术角度能不能做到高质量高兼容性无bug，以及下次再有类似的需求能不能快速高效率的迭代。 用一句话来描述就是，能不能跳出自己是一个程序员是一个被动执行人的角色，而是将自己当做产品当做技术负责人的心态去做这件事。 业务需求该怎么做知易行难。如果一开始做不到，那就先着眼小事：关注细节，从需求开始的需求评审、编写技术方案文档、设计文档、到开发的代码注释、结构设计，保证高质量，完善无漏洞的代码逻辑，再到异常埋点、指标监控、线上可用性运维等等，认真对待一个需求的每一个环节。 当你自认为已经做好整个流程的每一件小事之后，接下来可以通过深入细节，思考整个流程是否存在问题。 做需求过程中沟通协作的有没有问题，流程规范的有没有问题，机制环节哪方面问题，代码公共基础能力的是否有缺失，开发过程中你所遇到的问题是不是一个通用问题，能不能抽象出一个公共库解决大家的问题，能不能制定一个SOP的解决方案流程，亦或是提炼出一个最佳实践在组内外分享经验。 通过这些一件件小事来锻炼自己解决问题的能力，以及更深层级的发现问题的能力。再通过不断的发现问题，思考问题出现的原因，拿出解决方案，最终落地解决了自己或组内或协作方的问题，锻炼自己的综合能力逐步慢慢成长。 再说「技术深度」说了这么多，你可能会说，这跟我问的技术深度有什么关系？我想说：抛开业务需求谈技术深度都是耍流氓。 举一个例子，数据可视化方面3D three.js，视频直播方面的编解码压缩，客户端安全方面的攻防渗透，每一个都是有技术深度的事情，但问题是即使你掌握了这些领域拥有了非常高的技术深度之后呢，不能应用于业务需求，不能解决产品急迫要解决的问题，不能完成你老板的OKR，达成部门的战略目标，还是英雄无用武之地（当然你也可以选择一个可以用得上的团队，那是就是另外一回事了）。 由于这些单点的有技术深度的事情，不能为你带来直观和显而易见的 「回报」（也就是颜如玉、黄金屋与金榜题名），也就间接的打击了积极性（当然自己对某门技术感兴趣而钻研的不再本次讨论之列）。 所以提升自己的技术深度，最好的方式还是在公司业务中，发现有深度的事，然后去在攻克这个问题的过程中，提升了自己的技术深度，即跟随公司业务的发展的同时自身也获得了成长，你用技术能力为公司解决了业务发展过程中的问题，自然也就从公司获得了该有的回报。这是一个ROI投入产出比最高的获得技术深度的方式。 获取做有深度事情的授权当想明白获取技术深度的路径之后，接下来要解决的就是：如何让领导给你安排有技术深度的事情？ 业务发展中有很多有技术深度有技术难度的事情，为什么领导要安排你来做这件事呢？你凭什么让领导觉得你 「有能力」 也 「有意愿」 来完成这件事？能力与意愿是作为领导在分配工作当中的最重要的两个决策项。 既然你能提问如何积累技术深度，我相信你一定是有强烈意愿的，那么剩下的就是如何让领导认为你有完成这个有技术深度的事情的能力？ 最简单来讲就是，你能不能在开发需求中做到深度思考、追求极致、精益求精、有责任心、有主人翁意识与主R意识，在每件小事中能做到 「自闭环」，之后才会逐步让你承担更大范围更高挑战更大深度的事情，形成正向循环。 这也是我前面为什么要先重点强调做好每一件小事的重要性。 | 
楼主
标题置顶
标题高亮
