目前的产品团队主要是跑 Scrum 的方式,截至目前为止已经接近 100 次的 Sprint 了,从最一开始只有两个工程师,後来平均一年增加一位工程师,到目前也有了四位工程师,Trello 也被我们操到非常的当,总共完成了上千张卡片,也有着十分稳定的产出。
然而,为什麽这样的团队会需要调整呢?主要因为目前产能虽然稳定,但需求方的部分却不够稳定,比喻来说,好像是一个人开车,有时候暴冲,有时候急煞,即使引擎是稳定的输出,对於整体的状况长期来看是极度不好的,因此需要做些调整。
以开车作为例子,只要我们不急煞或是暴冲应该就可以解决问题了吧?然而现实状况并不会这麽容易,即使我们有 PM 作为中间的缓冲,客户或是 Bug 仍是会突然出现打坏节奏,因此,我们需要有机动部队,也就是球来就打,或是能够校正球路、预判球路的角色。
通常我建议是由 Tech lead 负责,因为平时需要做 Code review 以及对於整体状况最为了解,在预判球路或是球来就打时能够发挥比较大的效益,不巧的是,我正好是技术负责人,如今较不适合接下这个位置,於是必须从产品团队里面进行挑选。
由於团队中每个人各自有强项,我主要会以下列面向来考虑
从团队成员挑选到机动组的好处显然是能够更快速地整合客户的需求,甚至是让客户关系更加提升,而坏处除了降低产品开发的产能外,还有工程师个人的心情会受到影响。因为是机动组,工作节奏或是方式会明显地与其他成员不相同,像是可能会在晚上处理紧急需求,早上自主放假等等,所以上班时间也是相较弹性自主,这部分是需要工程师自身适应的。
<<: 自动化 End-End 测试 Nightwatch.js 之踩雷笔记:Regex
>>: Day20 - 在 XState 与 Side Effect 互动吧~ action API
话说~ 从疫情到现在,已经不知道多久没出去玩了~ 好想出去玩玩喔~ 从开赛到现在已经默默地来到第二...
本来预计都写在 Day22 的,但是加上本篇内容後会让一天的篇幅太长,且考虑到有些夥伴可能没有建立资...
太鼓达人 教学原文参考:太鼓达人 这篇文章会大量使用「阵列」的操作,搭配「变数」、「逻辑判断」、「点...
Amazon Elastic MapReduce(EMR)是可以在EC2 instance 或 Am...
上一篇介绍了Back to High School Physics,是一个简单的距离公式,主要是英文...