怎么在互联网公司带团队

这篇文章 算是我在2015年的一个小结,2015年的经历,是我过去工作5年的一个缩影,但是给我自己接带来的思考缺远远大于过去5年。


在项目开发的过程中,

首先了解业务需求,在互联网公司,对业务需求的理解提出了更多的要求,不仅仅是要了解要做什么,更要关注为什么做这个,能够给客户带来什么?客户的真实的需求目的是什么?客户在使用功能的过程中,最关注什么?


在业务实现过程中,

关注代码质量,单元测试。在编码的过程中,加入codereview活动,提交代码时结对review。 这些活动,才是真正能够提升产品质量的措施。

在之前的开发经历中,个人比较偏重往前冲,完成更多的功能,让更多的功能上线。这样的思路,往往会导致问题多,并完全依赖开发的个人的素质,如果遇到一个开发能力不好的开发,往往提交的代码质量是不好的。

假定一个开发人员,具备编写完整的单元测试的能力,那么这样开发出来的产品,是质量可靠的,并可以不需要测试来验证功能。可以让产品来体验功能。

开发人员自身,在理解功能以后,编写对应的单元测试用例,不仅能够保证高质量的产品交付,同时也能够有单元测试的积累。

单元测试,更多的带来的是,长期的质量上的提升,同时也有益于代码的设计。

存在的疑问:在传统公司里,可以招聘一个开发,一个测试,花一个开发周期,一个测试周期来完成工作,但是,是不是可以招两个开发,在两个周期里,完成这一个功能呢?产出更有效的产品。国外的很多公司都是这种模式,而且一个开发本身应该为自己的产出的质量负责,并不是写完了,就交给测试。


在管理上,

技术管理,在大的项目上,我都会关注,发现其中的技术难点,询问开发的想法,并提出自己的设计想法。最终执行开发。通常,一般的小的设计,都不会有太多的技术难点,所以我也忽视了这个问题。而开发人员的开发能力也远未达到真正的工程师的开发水平。一味的在考虑赶进度,上了许多的功能,但是却招致了很多的埋怨和指责。

总体上我们也是采用的Scrum方式,日常的开发工作包括以下几种,

  • 业务功能的分解
    • 这里分解的粒度比较的重要,一个crud,基本可以作为一个功能点,一个技术难点,一个交互的接口。都需要拆分为单个的功能。
  • 工作任务的分配
    • 在敏捷开发里,这一点,是需要开发人员自己来选择的,如果执行下去,好处是很明显的。能够提升开发人员的积极性。但是,目前来看,我们这个方式并不能取得好的成果。
    • 通常,我都会根据每个人的特点来安排任务,后台的系统多,功能杂,我按照系统,划分了系统的owner,按照人员特点,结成了编码的pair,后期的项目质量提升明显。
  • 评估工作量并制定开发排期
    • 这里需要考虑开发的能力,功能的难度,在结合测试的时间,如果你是开发leader,并且期望开发能够交付高质量的产品,在这里你需要预留出足够的时间,让开发能够完成工作。
    • 如果你是项目经理,那么,你需要尽量争取多的时间来完成,当然,通常都不会给你太多时间,互联网时间比拼的就是时间。谁最早上线功能,谁就能够占到先机。那么在时间紧张的情况下,该怎么办?砍需求,这个就看你撕逼的本事了。这点上,我是做的比较弱,之前被灌输的一个观点是努力工作,觉得与人撕逼就是浪费时间,而事实上,甚至产品经理也会觉得需要开发多动脑筋来参与,而不仅仅只是编码实现。
    • 其次,在开发的工作量已经比较饱和的情况下,不要着急去增加工作,或者加班完成什么功能。往往有些需求,并不是很着急上的,只是产品YY了一下,觉得需求很急。在我们业务系统刚开始的时候,有一个业务功能,产品说很急,一定要上,但是由于开发没时间,这个功能过了8个月了,还是没上线,你觉得是一个重要的需求吗?
    • 总之,在这个阶段,你需要争取足够的时间。
  • 每天了解开发进度 站立会议
    • 在任务安排好以后,每天都需要更新进度,最好有一个由开发自己来更新,就可以避免开发人员不给力。
    • 早上的站会,是互相了解彼此的工作内容的过程。在开早会的过程中,很多人都只关心自己的事,说完了就无所事事。实际早会也是一个提升自己的机会,有的人会说自己遇到的问题,和解决办法。积极主动的人,就会提出自己的想法,提升自己在组内的影响力。
  • 讨论和跟进各种具体的技术问题
    • 在一般的业务需求层面,不太会有太多需要设计的内容,尤其是在项目搭建完成以后。大部分的开发都已经知道怎么去使用redis,sql,mongo等。一般的开发最擅长的就是定义service,dao,需要和其他模块交互的地方,发个MQ消息,或者是直接的RPC调用。在这个框架下面写代码,不在考验开发的设计能力,而只是业务的编码实现能力,需要真正参与设计的地方并不多。
    • 然而,在一个不成熟的团队里,却是不断的需要了解他们的实现方案,否则极有可能做出一个上线就OOM,或者不能处理大量请求的功能。 这也是普通开发人员和高级开发人员的差别。 互联网产品,遇到最多的是高并发的大量请求,一般的开发人员没有经验就容易犯错。
  • 协调一些产品需求变更
    • 我经常跟产品说,有需求变更不要紧,没有人会一次就考虑到所有的功能。但是,刚好是这样思维,让我自己没有去追求完美。我原来是一个追求完美的人,弄的别人会紧张,尤其是家里人。后来放弃自己追求完美的个性,这个思维放到了工作中,却让我自己吃亏。
    • 我之前一直觉得,好的开发,应该在开发的过程中设计一个可扩展的架构,以方便后续产品的变动。但是,换到产品的角度想,他们却希望,每个人都给他们提建议,这样,他们做出的产品才会好用。换成你,可能也一样。在需求一开始,就应该仔细的参与讨论,让产品需求能够尽可能打磨精细。让开发在后期的改动尽量少。
    • 但是变动总会有,我通常只会去协调他们找对应的开发。需求的变动,我并不总会去关心,有大的需求变化,开发自己也会跳出来说。
  • 跟进相关功能上线
    • 功能完成上线后,在线上环境可能会出现一些问题,
    • 一些未覆盖到的场景,由于提供的接口被多个模块调用,可能会出现一些问题。
    • 当这些线上问题出现后,开发人员需要迅速的定位。这个是比较考验开发人员的技术能力的。

作为一个互联网公司的技术团队,我们应该还有能力直接响应市场、运营、客服或其他部门同事的业务需求。

因为产品部门有时考虑的只是怎么来增加新功能,会忽视来自其他部门的真实的实时的需求。因为有些需求,在他们看来是不重要的。这个和组织结构相关,如果产品和技术是两个独立的部门,产品只关注产品部门自己的绩效,并不一定需要实时的来响应其他部门的需求。

而技术,则并不应该期望自己只成为一个执行部门,需要扩展技术的影响力,这种情况下,积极的去主动了解其他部门的需求,并主动的改进到工作中。不要成为一个Code Machine。



阅读更多

没有更多推荐了,返回首页