浅谈技术管理

最新推荐文章于 2024-08-28 21:00:40 发布

weixin_34072857

最新推荐文章于 2024-08-28 21:00:40 发布

阅读量114

点赞数

文章标签：数据结构与算法面试 python

原文链接：https://my.oschina.net/leejun2005/blog/161296

版权

2019独角兽企业重金招聘Python工程师标准>>>

针对这些年旁观和经历过的技术产品场景，做一些个人的总结和判定，尽量不涉及争议性话题，比如对一个互联网公司而言，技术重要还是产品重要之类的，这种话题一扯开，各有道理，谁也别指望说服谁。

此外，加一个前缀，主要针对非技术领导者所面临的技术管理困境，在很多从传统企业转型或个人站转型的互联网企业里，这个问题较为突出。

以下一些产品经理 or Boss 面临的场景，不知道读者是否熟悉。

这么简单的需求？为什么开发告诉我要做那么久？
同行 or 竞争对手都做出来了，为什么我的开发说这个无法实现？
我明明说清楚了，开发也确认了，给我的产品怎么是这么奇怪的一坨？和我想要的完全不是一回事。
线下测试都ok，一上线就各种崩溃，诡异现象，弄得我们什么运营活动都搞不了.
请了个大公司出来的，工资巨高的，结果也没看出比便宜程序员好在哪里？
天哪，又给我说要重构！又是好几个月啥需求都做不了！

看上去，有没有同感？且慢，程序员也有话说。

你需求三天一改，两天一变，你以为我代码会72变，我多少工作打水漂了你知道不？
你说这个简单，你前面系统数据结构各种不支持，我不大改我根本支撑不了这需求，我跟你说数据结构你听么你？
你告诉我做A,B,C,D,E，我都按你说的做了，做完了你说不是你要的，鬼知道你要什么。
你就给我这点开发时间，我已经加班给你把事干了，我反正实现了，测试也通过了，线上出问题，你业务场景各种诡异，我哪里知道，又没早跟我说。
天天有事没事就拉我开会，你知道我思路多难集中么？完全没效率，你尊重过我的时间么？你以为写代码随时抽五分钟就能写一坨么？
这代码补丁打得，找一个小问题要一个下午，不重构你后续功能没一个可以顺利快速搞起来的，我替你考虑，你还埋怨我？
哎哎哎，上面的那位童鞋不要乱讲，我设计架构的时候，也没想到现在业务这么变态啊，当时我可是按照标准的流行业务模式设计的。你没理解我架构精髓，就知道重构，你有问题哦你。

好了，打住打住，架构这话题太大，程序员自己都会pk起来，不和谐。

下面说一下我的理解和相应的对策。

问题1：信息不对称

产品人员往往认为，描述了功能需求，甚至简单的给一个竞争对手的范例，工程师就能完美的实现所有业务需求；但是，工程师对业务的理解往往是欠缺的，因此在产品的塑造上，很可能因为个人理解偏差，带来极大的随意性；即便是产品经理具有超强的控制力和投入，保证技术在功能实现上与使用场景吻合，但往往因忽略了业务的性能诉求，导致线下ok的东西，线上各种问题。

个人认为，让技术充分了解业务诉求，并参与业务讨论，是有必要的，只有这样，才能深刻理解产品的设计目标和设计要点，这样才能减少产品跑偏，与需求不符的现象。

问题2：尊重技术人员的时间观

工程师什么时候开发效率最高？我相信不止我一个人会有这样的感觉，凌晨1点-2点这段是时间，夜深人静，无人打扰，开发效率最高。应尽可能营造无打扰，无中断的开发环境；从设计代码到编程到测试，开发需要整段的时间来思考和实现，比如下午4点有个会，哪怕只有10分钟，等于一个下午没有效率。至少以我个人而言，是做不到可以随时中断，随时继续的开发水准。我几年前比较多的编程都是在半夜完成的。

所以，产品人员应当与技术人员勤沟通不错，但是请尽量将完整时间给工程师，比如早上上班后开沟通会，保证后续的完整性，下午午饭后立即开沟通会，或者用午餐会的形式，留给完整的下午时间给工程师，都是值得建议的方案。

问题3：理想主义情绪

开发人员往往有理想主义情节，希望所设计的架构可以支撑更广泛更持续的应用诉求；有时候产品人员也会有这样的想法，过于追求远大的宏伟目标；理想主义往往导致投入太多的无用功到无谓的兼容性设计上，而实际上，随着业务的发展和市场的变换，往往大部分提前准备的或者按照高端目标准备的设计，都是浪费的；其实，最重要的是把握当下的市场，互联网产品淘汰更新频率太快，未来是怎样，很多不确定的因素。

一个典型的架构悖论是，为了支撑更多更复杂的业务诉求，而设计了一个非常宏伟庞大的架构，但是新的诉求出现的时候，很抱歉，互联网发展太快，新的诉求超出了最初的预期，然后，因为架构太复杂太庞大，所以无法实现。

这事在著名的互联网上市公司是经常出现的。

轻架构，着重当下，代码做好低耦合就可以了，不用把架构弄得太复杂，而且，个人认为，最好的设计是，让后续的程序员（中等水平），不读文档，只看代码就能接手。

问题4：80%的无用功

这事可以说是问题3的升级版；也可以说是问题1的升级版；程序员往往因为对业务诉求不清晰；或者为了追求完美，将80%的精力投入到并不存在的业务诉求上，这我也遇到过，而且，当事人，无论是产品负责人，还是技术人员，在我点明之前，都茫然不知，以为只是技术不够成熟才导致周期过长。

举个简单例子，在统计系统，查看来访的refer统计，如果一个网站有几万个refer来路，请问哪个站长会去看超过1000名以后的来路？这个业务诉求是不存在的，但是工程师却努力的为此纠结，‘我的存储压力太大了啊，每天要存储多少这类信息啊。’ 你需要存这么多么？

类似的很多数据统计和分析系统里，汇总数据是不能丢的，这是必须的，但是各种排行数据，总有一些长尾是业务上永远不会去看的，这些数据占据了80%甚至90%的存储资源，带来各种负载和查询压力，而实际上，却不存在这样的业务诉求。

简单说，很多业务系统，都存在这样的现象，有超过90%的数据为了满足不到1%的需求，怎么处理？

小公司，建议直接砍掉；大公司，留在另册保存，单独查询接口，不占用主体业务资源。

这样下去，技术压力就会减轻很多，考虑的复杂度就会降低很多。

问题5：考核机制

抱歉又要说这个经典案例了，明明可以很简单完成的事情，工程师会说”我要评高级工程师，我需要有技术价值体现啊，我不能这么简单的做啊！“ 这事在大公司常见，所以简单问题复杂化，管理考核体制首当其冲。

顺便说一句，大公司创新乏力，很大程度是被这个原则拖累的，程序员想的不是把产品做多牛，是自己技术炫出来先，好上一个层级；产品人员只好苦捱技术炫技的过程，错失市场良机。

问题6：没有足够的思考和设计时间，以及学习研究的时间

好吧，前面说了，不要追求完美，不要设计复杂的架构，但是即便是轻架构，即便是简单的代码，也需要足够设计和思考的时间；

小公司、非技术管理者，往往简单的认为，实现开发就是编码、编码、编码。

其实，设计到位，编码就会如拉稀一般一泻千里；设计不到位，就如便秘一般，寸行难行。

按个人的经验，自己以前设计统计系统的时候，会想几周，做一些简单代码，测试一些想法和原型；等一切思路上的疑惑解决后，编程就是很简单很容易的事情了。

看程序员的工作效果，请给予更宽松的时间和绩效考量，不要看一个程序员发呆，或者听音乐，就下结论说他不干活；别真把程序员当码农。

当然，必须指出，好的程序员，在思考清楚后，实现效率是快的惊人的，也请部分开发工程师别为自己的偷懒和无作为推脱。

简单的评判标准是，如果给一个优秀的程序员足够的思考和空闲时间，应该有一个代码爆发期；他的成果应该能够在短时间内得到集中的体现。如果是思考一段时间后写代码依然便秘的，那么，这个人的水平大概也就清楚了。

问题7：资深与多面

大公司的技术人员，如果不是特别顶级的，往往能力局限在某个领域，当然深度足够，但是广度基本都很欠缺；特别是一毕业就进入大公司的，最悲惨的是在某个特定架构下写程序的，写了五年后出来一看，尼玛原来自己只会写一种架构下的代码。（当然，必须指出，在大公司还是早期小公司的时候进入的技术人员，往往更全面一些。）而小公司往往需要多面手，最好服务端也会，客户端也会，样式表也会，反正老板是分不出写程序和写程序还是有区别的。但是深度要求，恐怕就没大公司那么深了。

所以问题来了，从大公司挖一个专家来，结果发现这个不会，那个也不会，还不如自己3000块钱招的野路子程序员；这就是需求不匹配，目标不清楚；如果小公司遇到了非常严重的技术瓶颈，一旦突破业务会爆发性增长；而恰好某个大公司有这个领域的技术专家，那么这种定向的动作是会有很好的效果；但是如果只是觉得技术差点事，或者只是对技术不满意，希望通过来一个大公司的解决问题，这事能如愿的不多；

当然，还是那句话，从小公司开始就进入大公司的元老核心技术，见证一个公司从小到大历程的，经历过公司几次技术升级的，是非常难得的极品人才，问题是，这样的人，市场上是很难遇到的。而且，就算遇到了，往往也不是小公司请的起的。

PS：最后说一句：

技术总是在短期内被高估，但在长期被低估。

——————————————————————————————————————

题外话1：《管理那些事儿》

http://www.jianshu.com/p/a452db17ff89

跟同事讲管理。我说，管理分5件大事。

第一是定方向。大到选择业务线，小到“怎样完成本季度的KPI”，都是定方向。下属常常吐槽主管的方向，其实，定方向是最难的事情，站着说话不腰疼。可靠的方向还包括一整个大框架设计（业务框架或人事框架），不仅仅是红旗一挥这么简单。

第二是找方案。在选好的方向上，制定有可行性的操作方案。这个方案可以不那么细，但得让人有信心，你的方向和框架是有可行性的，不是放卫星，不是大跃进。

第三是项目规划，把方案拆分到阶段，拆分到目标，拆分到人，总之是拆分出一个可监督，可验证的执行计划来，把握好节奏感。

第四是执行管理，在实际操作中，分解和审查每一个环节，保证时间可靠，质量可靠。奖罚制度通常也应用于执行管理层面。

第五是招聘，假定人手不够，还得招到合适的人。

从高层的角度上来说，定方向和招聘是头等大事。中层呢，找方案和项目规划是头等大事。一线主管就得做好执行管理了。

我说，管理这活儿啊，和性格有很大关系。比如说，因为个性孤僻、个人主义和完美主义，我自己其实不适合也不喜欢做管理，但做了十多年管理，手熟，仅此而已。以前在国内走专家线是很难的，地位和待遇的天花板都不高（近两年倒是有很大改善），想再上一层楼，就得走管理线了。摊手。

——————————————————————————————————————

题外话2：《管理的最低要求》

目标清晰，职责明确，赏罚分明，超越伯乐：目标清晰有两层含义，一是团队的目标要非常清晰；二是给员工设定的绩效目标要非常清晰。什么叫清晰？能量化才叫清晰。所有的工作一定有最关键的地方，一定是可以量化的。如果量化不了，要么说明不够关键，没抓住要害，要么说明没想清楚。同样的，我相信大多数员工的绩效目标设定的都是不够清晰的，很多人的目标都是定性而非定量。比如目标是「做了什么事情」，没有一个定量的考核标准，这种都存在问题，要么有很大水分想蒙混过关，要么就是忙错方向到最后不解决问题。对员工伤害最大的是，到最后都没法证明他的业绩做的比别人好。其实一个简单的问题就能判断出员工的绩效目标设定是否清晰：员工是否知道当他做了什么之后，「一定」能够得到「超出期望」的评价或晋升？如果回答不出来，就说明员工的绩效目标设定的不够清晰。目标都没设定清晰，团队有力量都不一定使对了方向，所以我认为这是管理者在带团队时需要做的第一件事情。

——————————————————————————————————————

@ 郑昀老兵笔记：昨天面试的时候我告诉候选人，一个公司如果让一帮人只做业务另一帮人只做架构（其实也只是技术选型而已），这样是不对的。
第一，每个工程师都有更高更快更强的愿望，我们讲究的是平凡人（可以）做非凡事。
第二，只做技术选型远远不够。技术管理分为三个层次：研发能力，研发效率，研发活力。“研发能力的提升”是研发部门的生理需求，“生产效率的提升”是公司的安全需求，“研发活力的提升”是研发人员的社交需求和尊重需求。三者循环往复，互相促进，缺一不可。