作者NDark (溺於黑暗)
看板GameDesign
标题[心得] 游戏软体管理经验谈(5)-执行人力
时间Fri Oct 28 21:31:20 2011
游戏软体管理经验谈
发布区域:PTT GameDesign版(telnet://ptt.cc),部落阁Black Straits Historical
(
http://ndark.wordpress.com/)
版权所有,禁止转录
作者:NDark,目前任游戏公司软体工程师(专案主程式)
时间:2011 秋
执行期的人力安排
同样的人力安排为何又要再讲一次?
原因是当专案开始进行之後,事情的发展可能不如预期顺利。
有工作会延迟完成,有人力会闲置。
当有人力离开团队或是当工作延迟,下一个工作又应该要开始时该怎麽办?
这就是先分派人力的一个盲点。
先分派人力的好处是可以估出比较完整的时程。但是缺点就是,工作不可能估的非常准确
。若执行的人员早已知道下一个工作什麽时候该开始,就会急着完成前一个工作来达到表
面上的 "on schedule",甚至会草率完工(常听到的藉口就是做完了但是还没测)。如果
没有验证清楚就放过关,未来一定会付出代价回来修。反过来如果验证非常清楚,就是不
让他过关。下一个工作当然就铁定延迟开始。难道要拿鞭子鞭笞工程师加班吗?若真的非
常重要的工作项目,则必然其他人会来帮忙擦屁股。这样耽误到其他人的工作来完成这项
工作算是谁的credit?
我们一开始就讲了工作时程规划是规划未来,而未来就是说不准的。在专案的进行中都会
有莫名奇妙的工作冒出来。简简单单把电源供应器装上开发机主机板,就是会有人把板子
烧掉,然後只好等新的料件来,工作就(莫名奇妙)迟了一天。
先分派人力还有另一个游戏业常见的风险,游戏业的规格变化的比其他产业频繁得多
([注]好吧,看来知名手机厂hTC已经追上游戏产业了)。
除非很有定见的制作人或企划,多半开发到一半,规格早就不知道飘到哪里去。
当规格变化太快,先前的规划就完全的失准,这时若拿着先前规划的时程来要求开发团队
准时完工,那就是明朝的剑斩清朝的官。
因此规格改变时,分析与规划当然要适度的再执行,这时却也造成时间的浪费(又规划了
好几次),也造成团队内的不信任感(感觉需求不停在变,没有做完的一天等等)。
[注] "高工时工程师(HTC工程师)"
http://www.mobile01.com/topicdetail.php?f=566&t=2370096&last=30927800
相对於先分派(告知团队,所有工作的执行人是谁),我尝试的是另一种动态分配,规划
期作出来的工作项目与人力分派只是为了估计时程,真正执行期谁来执行并不十分明确,
等到前一项(依存的)工作项目即将完成,下一项即将开始时,才真正指派人力。这种做
法看似很不科学,对於整体时程很不精确。但是就我的经验,工作人员在没有下一个工作
追赶的情形下,才会真正的把自己该做的工作做好,管理人员也才能够狠下心来打枪那些
半成品,也就是勇敢的把不成熟的工程师与程式码留在原地;
反过来讲,工作项目都能 "及时"的被 "空闲"人力展开。
这个管理方式的一个明显的缺点就是而那些工作能力强的软体人员,
就会接比较多工作(但绝不是用超时工作),也当然显而易见的那些做比较多工作项目的
人员是比较有产出的人员。
这样动态的管理方式是需要团队的技术力尽量接近,可以临时调配互相支援;
强迫开发人员写注解,强迫开发人员互相沟通,减少搭配合作上的困难;
以及开发中不会有太过份难以理解的程式码,技术力不可过分集中,
避免支援人员完全无法接手的情形发生。
--
"May the Balance be with U"(愿平衡与你同在)
视窗介面游戏设计教学,讨论,分享。欢迎来信。
视窗程式设计(Windows CLR Form)游戏架构设计(Game Application Framework)
游戏工具设计(Game App. Tool Design )
电脑图学架构及研究(Computer Graphics)
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 118.160.139.160
※ 编辑: NDark 来自: 118.160.139.160 (10/28 21:31)
※ 编辑: NDark 来自: 118.160.139.160 (10/28 21:33)
※ 编辑: NDark 来自: 118.160.139.160 (10/28 21:36)
1F:推 jimmibear:很感谢这连串分享 看到这里很有感触 尤其是关於Agile 10/29 04:01
2F:→ jimmibear:现在正在为下个案子开始前作准备 但是前一个案子中 10/29 04:02
3F:→ jimmibear:Agile执行的不是很理想,所以我最近都在想要怎麽改进. 10/29 04:03
4F:→ jimmibear:尤其是团队较大(flashx3 phpx3 artxN designer在美国) 10/29 04:04
5F:→ jimmibear:所造成的沟通困难的问题. 书上是说最好分成6人的scrum 10/29 04:05
6F:→ jimmibear:team, 但是实现起来好像不是那个单纯的一件事情... 10/29 04:06