针对这些年旁观和经历过的技术产品场景,做一些个人的总结和判定,尽量不涉及争议性话题,比如对一个互联网公司而言,技术重要还是产品重要之类的,这种话题一扯开,各有道理,谁也别指望说服谁。
此外,加一个前缀,主要针对非技术领导者所面临的技术管理困境,在很多从传统企业转型或个人站转型的互联网企业里,这个问题较为突出。
以下一些产品经理 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:《管理的最低要求》
目标清晰,职责明确,赏罚分明,超越伯乐:目标清晰有两层含义,一是团队的目标要非常清晰;二是给员工设定的绩效目标要非常清晰。什么叫清晰?能量化才叫清晰。所有的工作一定有最关键的地方,一定是可以量化的。如果量化不了,要么说明不够关键,没抓住要害,要么说明没想清楚。同样的,我相信大多数员工的绩效目标设定的都是不够清晰的,很多人的目标都是定性而非定量。比如目标是「做了什么事情」,没有一个定量的考核标准,这种都存在问题,要么有很大水分想蒙混过关,要么就是忙错方向到最后不解决问题。对员工伤害最大的是,到最后都没法证明他的业绩做的比别人好。其实一个简单的问题就能判断出员工的绩效目标设定是否清晰:员工是否知道当他做了什么之后,「一定」能够得到「超出期望」的评价或晋升?如果回答不出来,就说明员工的绩效目标设定的不够清晰。目标都没设定清晰,团队有力量都不一定使对了方向,所以我认为这是管理者在带团队时需要做的第一件事情。
——————————————————————————————————————
@ 郑昀 老兵笔记:昨天面试的时候我告诉候选人,一个公司如果让一帮人只做业务另一帮人只做架构(其实也只是技术选型而已),这样是不对的。
第一,每个工程师都有更高更快更强的愿望,我们讲究的是平凡人(可以)做非凡事。
第二,只做技术选型远远不够。技术管理分为三个层次:研发能力,研发效率,研发活力。“研发能力的提升”是研发部门的生理需求,“生产效率的提升”是公司的安全需求,“研发活力的提升”是研发人员的社交需求和尊重需求。三者循环往复,互相促进,缺一不可。
Refer:
[1] 从Code Review 谈如何做技术
http://coolshell.cn/articles/11432.html
[2] 管理的最低要求(1)
[3] 管理的最低要求(2)
[4] 豆瓣的研发管理
[5] 我心目中的理想团队
[6] 产品小团队
http://www.jianshu.com/p/9bf5fe5012ed
[7] 涅槃重生:我的技术转管理之路
[8] 从技术转管理的困惑
[9] 如何管理技术团队?我的 6 个建议