放弃了 7 年的 Java,投身互联网做 PHP,我是如何成为创业公司的 CTO?

${website.getHeaderOriginal(${article.taxonomyName})}


到了我们这个年龄阶段··|,都知道选择的重要性··|,如果选择的方向不对··|,就会越走越远··|--。在我个人职业发展上··|,经历了很多波折··|--。


在我去做 SP 增值业务的时候··|,这个行业正是衰败的时期··|,当时我面临了一次转型··|,放弃了 7 年的 Java 工作经验··|,投身互联网做起了 PHP··|--。


等到我发现传统的老牌互联网都做起来了··|,电商又比较火··|,可惜我又没有在对的时间进入主流大品牌的电商公司··|--。


让我欣慰的是··|,后来终于卡位对了一次··|,就是现在的移动互联网··|,而且卡准了当时很流行的 HTML5 技术··|--。


站在公司的角度··|,当我们的技术能力很强的时候··|,就会很容易产能过剩、过度开发··|,很多公司都出现过类似被技术绑架的问题··|--。


也就是说需要评估我们当前所在的量级段位··|,例如很多用户场景并没有达到我们设定的场景时··|,如果技术太强了··|,反而变成把太多的资源浪费在做未来的事情··|--。


这里··|,我要强调的就是在合适的时间点做正确的事··|--。说到如何正确地做事··|,是有一些思考:产品的概念够不够新··|,产品研发够不够快··|,产品运营够不够准;这些点无论对大公司还对小公司都一样适用··|--。


这里所谓的新··|,是一种模式··|,即这个产品模式是否适合当下的大环境··|--。


通过我的实践··|,真正能让产品研发快起来的经验有两条

  • 如果是技术型的团队··|,那你要发明出可以使我们产品研发快起来的武器··|--。

  • 我们如何去关注团队里的人··|,激发他们的创造力··|,这个是能让我们的研发快起来··|,并且超越所有的项目管理办法··|--。

如何在最短的时间实现我们想要的目标|-··?运营是否准确··|,直接影响团队士气··|--。


从技术的角度来看··|,我们的研发实力足够强··|,管理足够好··|,但是运营方向不准··|,容易出现研发人员很累··|,天天加班··|,做出来的东西一次一次的无用··|,一次一次被推翻的现象··|--。最终士气涣散··|,大家觉得自己所做的事情没有意义··|--。


所以··|,作为技术管理者一定要对业务有自己的理解和判断··|,并不是眼里只有技术··|,否则就只能停留在这个段位··|,或选择走技术专家路线··|--。

一个技术管理人员··|,如果只是把上级或其他部门交给你的事情分派下去··|,或者别人解决不了的问题··|,你可以带队解决··|--。


这些还不够··|,只能说明你还只是一个高级码农而已··|,如果这样的话··|,团队里的技术人员也挺悲哀··|,因为他也就只能成为一个执行的码农··|--。


作为一个 CTO··|,我认为至少要能够理解并指导团队如何管理需求··|,从而控制人员投入、控制开发周期··|,在时间、质量和成本三方面做出最优选择··|--。


同时··|,要管理好业务部门的预期··|--。用灵活的组织形式和透明的方法带领团队达成目标··|--。在任务艰巨之时··|,他能给团队足够的信心··|,激励团队克服困难完成任务··|--。


只有技术管理人员对需求把关准确··|,才能保障我们整个技术团队所做的事情是正确的、有价值的··|,而需求是以目标为导向的··|,以投资回报率(ROI)为标准要有成本概念··|--。


我们在做项目时··|,首先要清楚一个项目要实现的最终目标··|,通常产品经理会去整理一个业务部门或者是用户的一些需求和技术去讨论··|,这个产品要做成什么样子··|--。


这时候技术管理人员就要了解清楚··|,这个需求及其背后的终极目标是什么··|,然后再去考虑技术选型··|--。


如果说产品经理要求我们怎么做我们就做什么··|,我觉得这是管理人员的失职;其次··|,做技术管理··|,要有成本概念··|,记住投入产出比··|--。我们时刻记住这些··|,会提升团队人员的价值感··|--。


对技术人员来讲··|,质量是什么|-··?易用的产品、优雅的代码、漂亮的项目··|,这些大家都懂··|--。我更想说的是··|,作为技术管理人员··|,我们要达到怎样的质量··|,这个要有具体考量的标准··|--。


我们做任何项目的时候··|,其实都在做权衡··|,做时间、成本和质量的选择和取舍··|--。这里特别强调的是质量··|,技术管理者在确定质量标准的时候··|,实际在考虑什么··|,我们又该如何与别的部门领导或上级领导沟通··|--。

团队的组织架构设定应该以保证灵活高效为准则··|,例如为了保持高效··|,我把测试团队和项目管理团队合并成一个团队··|,统称质量保障部··|,下设测试团队··|,技术客服··|,项目管理··|,安全等团队··|--。


目的就是为了在团队初期充分发挥项目的作用··|,把控整体的研发节奏和时间控制··|--。


就像产品团队究竟是应该放在技术体系还是业务体系这个问题··|,都有成功的案例··|,都有可取之处··|--。所以在不同的阶段··|,根据关注点不同··|,应该保持团队的灵活组合方式··|--。


另外··|,根据公司的业务模型来选择组织架构··|,做到快速的响应变化··|--。创业初期的时候··|,快最重要··|,部门不应特别多··|,人员配备上也以全栈工程师为主··|--。不同阶段··|,我们的组织架构也要相应调整··|,要善于尝试··|--。


部门人员之间··|,前端后端的划分··|,研发和测试的划分等都要做到透明有依据··|--。


我们用项目经理举例来讲··|,小团队时··|,完全没必要设项目经理··|,研发领导就可以充当项目经理··|,这样他的执行力会更高一些··|--。


而当你的部门超过五个的时候··|,面临跨部门协作··|,这时可能需要一个项目助理··|,不需要太资深、懂 SMART(目标管理)原则··|,知道一件事情什么时间、什么节点··|,需要有什么结果即可··|--。


当公司业务运行模式稳定··|,慢慢从野蛮生长过度到精细化时··|,项目经理就越来越重要了··|--。


传统生产企业的精益管理也普遍应用在 IT 互联网企业··|,例如要实现 Just In Time(消除浪费)··|,做到标准化生产··|,我们就要做好任务分解··|,实现流水线式工作方式··|--。


我认为流水线这种方式适合用在稳定且变化不大的项目上··|,而不太适合互联网企业初创时期··|,因为一个小团队··|,创业方向不明确··|,需求会来回变··|,流水线式的作业方式不灵活··|,不利于快速响应··|,也浪费时间··|--。


  • 两周迭代、快速交付:创业初期要讲快··|,两周迭代是一个比较好的节奏··|--。

  • 每日立会:要实现三周迭代··|,每日例会不要超过五分钟··|,形式可以多种多样··|,只要抓住例会目的就行··|,形式不限··|--。

    一般我们例会最重要的是··|,对前面工作完成情况有没有风险进行一个评估··|,并评估后面的进度··|,如果发生风险的时候··|,要把这个问题怎么解决讨论清楚··|--。

  • 持续集成:也就是在研发过程中的迭代··|--。

  • 单元测试:三周迭代的情况下··|,单元测试很难做到··|,如果必须要做就很可能浪费很多时间··|--。

  • 结对编程:组织结对编程··|,通常可以采用 3 种方式··|--。

    第一种是由牛人编··|,层次低的人看··|,或者由层次低的人编程··|,由层次高的人看··|,这样利于层次低的技术人员知道··|,牛人大概是个什么样子··|,自己要朝哪个方向努力··|,这样也会让新人有归属感··|,这就是结对编程的目的··|--。

    第二是一个非常好的模式··|,就是由一个有经验的人··|,让他快速找到一个模板··|,告诉大家这个功能怎么去做··|,应该注意什么··|--。

    第三种方式就是做代码审查··|,好处就是能让你的团队编码风格和方法论尽量统一··|,同时··|,代码审查能让我们在做一些人事调动时不会太被动··|--。

  • 快速交付··|,缩小反馈环:有必要强调的是··|,我们一定要建立第一责任人制度··|,通过第一责任人去收集反馈、沟通协作··|,提高效率··|,教育团队逐步让团队成员懂得责任··|--。


首先想说的是··|,不得不承认··|,异地管理难度非常大··|--。所以也建议大家如果有可能··|,尽量不要把团队建在异地··|--。但如果有异地团队了··|,怎么办|-··?

  • 我们前面提到的第一责任人制度··|,用来解决异地沟通管理不畅通的问题··|--。

  • 想尽办法实现异地通过视频会议来沟通··|--。

  • 切记不要用邮件来沟通具体问题··|,邮件适合做确认用··|,而不适合具体问题讨论··|,否则效率太低了··|--。


最重要的一条是从根本上解决异地问题··|,就是尽量业务本地化··|,至少实现本地备份··|--。

我觉得现在很难找到一个理论··|,能适用于我们整体的发展··|--。因为现在··|,各个公司都发展的很快··|,一年、两年··|,发展的体量、规模都不太一样··|--。


拿组织架构来讲··|,我觉得如果是快速发展期··|,半年到一年可以调整一次··|,实现良性发展··|--。良性发展是什么呢|-··?各自有各自领域的强大··|,然后互相能够灵活组合··|,这是我们所追求的··|--。

很多时候··|,我们带领团队··|,可能有很多麻烦··|,主要是人的原因··|--。


所以对于一个 CTO··|,要当个好领导··|,要做的是带领团队中的成员··|,把公司要兑现员工的那些承诺变成现实··|--。


这就要求一个 CTO 不只是要有管家的意识··|,还需要在信任、倾听、预见、医治和接纳上做到位··|--。


  • 信任和倾听:真心实意地和团队成员沟通··|,倾听他们的真实想法··|,了解每个人的特长··|,根据每个人的特点给予适合的位置和充分的信任··|,了解每个人的真实需求··|,给予激励和引导··|--。

    只有这样··|,你才不只是一个领导··|,而是团队精神层面的领袖··|--。大家也会用同样的信任和真诚回报你··|--。这样的团队··|,凝聚力是一流的··|,这也是我们带团队的一个非常重要的努力方向··|--。

  • 预见未知:作为一个领导··|,无论是模式、人员、还是其他方面要有能力去预见风险··|,然后带领团队规避风险··|,而不是带领团队横冲直撞··|--。

  • 医治:作为领导要注意团队人员应该逐级提升··|,而不是跨级提升··|--。要针对不同性格的人分配力所能及的事··|,要有意识去看每个人的性格特征有哪些优点··|,能否被我所用或放大··|--。给每个队员找到合适的位置··|,让他们有荣誉和归属感··|--。

  • 接纳:为了让团队多样化··|,领导要学会接纳··|,可以有意识地让团队人员的性格出现一些偏差··|,尊重每一个个体··|,这样的团队会更安全、更有生机和活力··|--。

    包容和接纳是很重要的··|,领导要注意的是不要带领团队走向一个极端··|--。领导做决策时不要小众利益化··|,要站在整体的角度去看待、去分析··|--。


我们要想让团队稳定而有凝聚力··|,最重要的是要了解成员的需要并表达我的需要··|,即双向的需要··|--。


我需要员工知道我想要什么··|,我的目标是什么··|,这个是必须要传递给成员的;你也要很清楚地知道··|,员工要的是什么··|,你才好把不同的人放在不同的位置··|,根据不同人采取不同的激励或者引导方式··|--。


要做到双向需求沟通··|,管理者可以从观察、感受、需要、请求几个点抓起来··|--。


  • 观察:如果你带大团队··|,观察就是情报工作··|--。你要有洞察力··|,不是观察他们有没有骂你、有没有懈怠或者怎么样··|,而是观察和感受他们现在的工作状态··|--。

  • 感受:重视员工对一件事情的感受··|,这是做个好领导最能体现的用心之处了··|--。有些事情··|,我们如果做的很人性化··|,给员工的感受会很不一样··|--。

  • 需要:真正的理解员工的需要··|,按需提供一些帮助、建议和指导··|--。

  • 请求:尽量理解员工的请求··|,并给出合理的答复··|--。在技术上面要能够指导团队··|,在情感上面要多照顾团队··|--。


有句古话“己欲立而立人··|,己欲达而达人”··|,所以··|,作为 CTO··|,如果想在管理的路上立得住且走得远··|,你手下必须要有强将··|,而且强将得是你培养出来的··|--。


这样你就会拥有一个团结、协作、强大的团队··|,也能把事情放心交给别人去做··|,你才有精力去做对公司和团队更重要的事··|--。


作者:曲毅

编辑:张雪芳、陶家龙、孙淑娟

本文选自《CTO说》




${website.getFooterOriginal(${article.taxonomyName})}

发布者 :沙龙365_沙龙365_沙龙365官方网站 - 分类 沙龙365娱乐