怎么在互联网公司带团队

最新推荐文章于 2024-07-17 17:57:24 发布

阅读量2.6k

点赞数 1

分类专栏：工作之外的领悟文章标签：互联网产品质量团队管理敏捷开发

本文链接：https://blog.csdn.net/shmiluwei/article/details/50903815

版权

工作之外的领悟专栏收录该内容

4 篇文章 0 订阅

订阅专栏

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

在项目开发的过程中，

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

在业务实现过程中，

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

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

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

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

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

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

在管理上，

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

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

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