进度落后不是开发者的错,工作流程可能才是凶手

「为什么赶不出来?」

专案错过死线的时候,管理者总觉得就是开发团队的错。不过真的是开发者动作太慢吗?

专案管理服务Sprintly 的产品行销经理, Justin Jackson 在部落格内说,他们利用Sprintly ,追踪开发人员执行各项工作的时间,并依种类和大小细分,得到了以下结论。

有什么共通点?

第一点就是,开发人员表现非常平均。根据软体搜集的资料,75% 的开发周期都在175 小时左右。

第二,在ticket 开始前变数最大,这就是厂商开出规格和安排工作的时间,也就是当ticket 从出现到安排作业所需的时间。这个阶段浪费了很多时间。

第三,从「完成」转换到「测试完并准备好分配」对团队而言也很困难。

进度落后的原因?

如果不是你的开发人员特别慢,那为什么开发会逾期?答案可能是:你的流程有问题。

需求不明

确定技术规格很重要。如果开发者不懂一项功能的目的,那他要怎么开发这功能?

“绝大多数的技术规格开出来时,没经过审慎思考,通常等到我们开始设计或开发,就会碰到一堆麻烦,因为很多规格都有漏洞。”
— eagerMoose on Stack Exchange

厂商太常开出自己没仔细想过的功能,所以开发者一定要去了解,为什么使用者需要这个功能、这个功能是做什么的、要怎么用。你可以用固定的格式来描述使用者情境。

“使用Sprintly 时,你得用这个格式来写:我是一个___,我想要___,所以___。 (要把事情做对)一定得这样。”
— Darren Rogan, the Hack and Heckle podc​​ast

这个形式为特定功能设定了方向,也维持小规模的情境设定,不会过度展开。

不断变更需求

开发者第二大抱怨主因就是,专案开始后,不停变动的技术规格。 Hacker News 的一位使用者形容得很贴切:

开发者:「我们把屋顶和墙都装好了!」

厂商:「我们现在想要把所有的墙都移​​开。」

这大部分是安排工作前没有好好规划功能,所产生的症状。

避免在流程中途变更需求的方法之一,就是在真正开始开发前,先做互动模拟。我们用灵活的方式工作,不代表我们可以随时变更规模。最理想的情形是,你在过程中得到的点子,都该立刻纪录下来,并考虑日后放进更新。

另一个防止变更需求及规模的方法就是尽可能预测进度。 Sprintly 内有项功能,就是根据进度,预测完成一项功能还须多少天。

切换工作

Justin Jackson 提到,流程中最后一块绊脚石,大概就是工作的切换,而这可能有以下几种常见形式:

  1. 开发者已经完成A 工作的一半,此时你走到他的办公桌旁,要求他切换到B 工作。
  2. 开发者已经完成A 工作的一半,此时你走到他的办公桌旁,要求他同时处理B 工作。

举例来说,Sprintly 的开发主任时常需要检查程式码、帮员工分组、开会、紧急状况出来救火。

开发主任不断分心做其他事,导致他完成一项工作的时间要比其他人来得长。

当管理者让开发人员中途切换到新工作,就会产生问题,而如果工作时程一直在变,将让团队付出重大代价。

Stack Overflow 的CEO,Trello 共同创办人Joel Spolsky ,​​也在部落格中提到切换工作的伤害:

“从这些事件中你会学到,别让人同时处理两件工作,并确定他们清楚工作内容。优秀的管理者会承担责任,替人移除障碍,让他们专心于一件工作并完成它。若有紧急事态,在打扰全心沉浸于专案的工程师前,先看看你能不能自己处理。”

担起责任

管理者的工作就是提供一个环境,让开发者能成功完成专案。在指责开发人员,要他们为延迟行程负责前,应该先检验你自己。

这里提供一些简单的步骤,可以检查看看你有没有拖累团队:

  1. 让你的团队了解目标:和你的团队一起定义,如何让使用者的生活更好,搞清楚使用者需要的结果。让开发者接受与否很重要,对功能的热情程度,会大大影响开发速度。
  2. 设计使用者情境要有明确规范。每项工作都使用同一个模板创造,除非充分叙述工作细节,否则开发者都有不接这项工作的权利。
  3. 减少切换工作成本,不要打扰你的开发者!寄email 或提出任何要求前,先衡量一下对生产力造成的影响。

重点是,怪罪开发人员「太慢」前请三思,很有可能是你的工作流程拖累了他们。

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部