| konas's profile人在旅途PhotosBlogLists | Help |
|
人在旅途November 27 项目开发札记(10)今天终于把一个策划的简历送到人事去走录用流程了,千辛万苦啊.
我们的一位工程师对目前的一个方案提出了不同的看法,并引发了激烈的讨论.一时间,很多人都在对他的想法表示反对,包括我在内,并最后决定按照原有的方案进行实施.而他的执着和坚持让我暗暗吃惊,虽然表示服从,但看得出他并没有从心里接受这样的安排.是我的权威不够,还是真的是方案有问题?
下班后,我来到他的位置上,和他认真地讨论这个方案问题,并涉及了很多技术细节.在他看来,目前的方案因为历史遗留问题不光工作量巨大,而且难度不小.他提出的方案似乎有些道理,而且在进度上仿佛是一个捷径,确实比较诱人.
该如何选择?这个问题让我一时非常头痛.最后,我向他做了妥协.他是亲自操刀的人,他的意见我不能不尊重.让他按照他的方式进行尝试,但是他必须答应我两个条件:
1. 这个任务不会造成其他任务的延迟和冲突,并保证在时间节点之前能完成. 2. 每天需要单独完成这个任务的一个开发日志交给我和主程,并尽早看到原型.
我这么做,无非是因为这对我来说是一次冒险,他的方案要是失败那整个节点就会受影响.我需要把风险降到最低.
明天我可能需要和主程再确认一下这个决定,并找人来进一步评估这个新的方案. November 24 项目开发札记(9)每周绩效管理的结果出来了,基本上达到预期目的:能反应出每个人的点滴得失,并突出成绩优异者.
今天在周会上,有组长提出了,绩效考核首先在任务划分上需要区分难度,而在任务分配前需要知道每个人的职级,按照职级来分配不同难度的任务.职级高,薪水高的人就是要做有难度的任务,这才公平.而目前的组长是不知道下属的职级的,我立即从人事那里拿到了整个项目的人员职级表.但是人事提醒我,职级信息属于比较机密的信息,因为通过职级就能知道这个人的工资大概在哪个区间之内.我接触职级信息是没问题的,但是组长是不是需要知道下属的职级信息,这个我自己把握.
找来一部分组长,向其说明情况,并提醒他们一定保密,然后将他们小组的组员职级表给了他们.如果有麻烦,我来承担吧.
另外,我在小组管理上犯了严重的错误,虽然事先对服务器的主程进行了沟通,我希望将服务器方面的日常工作管理都归到客户端主程的工作范畴之中,他也表示了支持和认可.但是我没有向客户端主程进行说明,并公布这样的决定,导致程序小组的工作计划居然没有服务器的部分,而客户端主程也没得到这样的指示,没有介入服务器工作的管理.下午才仓促安排,也算是亡羊补牢吧.
所以,管理需要有明确的责权利的定义,否则容易出现管理空白或者重叠,造成矛盾或者遗漏.
晚上的时候,我向H总提出了一个请求,希望他能多找我们的组长谈话,听听他们对项目中的管理的意见和看法,或者对我有什么意见,平时可能他们都不太想说或者不好意思说.他欣然应允.
我不怕有人背后说我坏话,反而很想听到实事求是的坏话,知道自己的不足那是好事咧. 赞同和应和是香水,闻着很爽,闻多了容易中毒.
November 23 项目开发札记(8)早上一来就找了主程谈话,自己就昨天的问题向他委婉地道出了自己的不满.他也认同这个问题,但是他觉得自己的时间不够,特别是每天的会议太多.我承认最近的会议比较多,但是这在我进入项目的初期是无法避免的,我需要同大家做高强度的沟通和熟悉.我承诺他项目开始走上正轨之后,会议会很少.我自己也不喜欢开会.但是我同时提醒他要充分利用时间,不要做一些与工作无关的事情.大家很愉快的结束了谈话,看起来今天他的精神面貌不错.
整个项目看程序,整个程序就看他,key-man啊. 一天我都没有召集人来开会,而是尽量通过BQQ进行信息的传递.
我们的项目进度控制终于算是启动了.
对于游戏来说,工作计划可以分为两种: 依赖型和非依赖型的.倚赖型就是类似程序的工作计划有前后倚赖关系,并且各个任务单元是非独立的,他们都处于一个大的产品系统中无法剥离;非依赖型的工作则是比较独立的,跟工厂里的流水线计件付薪酬一样,任务彼此没有关系,可以单独剥离出来.
我叫项目助理将这两类任务分别做了Project,依赖型的project需要每天进行跟踪,对执行时间到期的任务进行过滤并核对到期任务的完成情况,已完成的任务需要注明落实情况,未完成的任务汇总会由我和小组长进行沟通,得出处理办法,并进一步修改project,核算对项目整体的影响.非倚赖型的project可以每隔几天进行跟踪,核对组长提供的成品数量计划.
这是一个非常枯燥的工作,但是需要坚持,这会有执行上的问题和抵触情绪,但是为了锻炼团队的整体作战能力,我别无他法.
另外,我曾要求组长将所有的bug分配到人并标明预计修复时间,今天主程就遇到了麻烦,有些bug是目前无法预测修复时间的,特别是一些本身属于远期任务范畴的bug.这些bug所反应的问题和模块修整目前还没有确切的开始时间和结束时间,因此无法进行预计.我对主程这样的态度很满意,这说明他没有放空枪或者说大话的习惯.然后我让QA改变了bug收集策略,将bug分为三种: 有责任人并有预计修复时间,有责任人无预期修复时间,无责任人.组长需要每个礼拜三下班之前,清理所有有责任人无预期修复时间的bug.
规则不怕修改,就怕轻视. November 22 项目开发札记(7)跟几位同事的谈话让我忧心忡忡. 我们的主程看起来正在犯技术能人的通病.
技术能人通常会比较自傲,并有典型的个人英雄主义倾向.他会认为自己能解决任何自己领域内的技术难题并乐此不疲.但是作为一个管理者,他却会常常无意识的忽略了下属的存在和他们所遇到的疾苦,让人感到孤独.
人最怕的事情是孤独.这是人类社会发展的副作用,一头猪或者一头牛是不怕孤独或者不知道孤独的,但是人的社会性决定了一个人会感到孤独.而孤独的潜台词就是被遗弃.消除一个人的孤独感并不是请他吃吃喝喝或者称兄道弟,而是在他最需要帮助的人出现在他的身边,为他解决或者试图解决他所无力面对的困扰.当然,如果别人没有困扰,你出现在别人身边并试图解决别人根本不存在的困扰,那很明显你太无聊了.
我必须承认,自己也常常犯这样的错误,结果往往是自己忙得要死,东西也没做好,更要命的是别人还帮不上忙.所以管理者不能成为孤胆英雄,他不应该要求自己做一个兰博或者终结者,因为非常有讽刺意味的是,电影里的终结者最后都是自己也被终结了.
管理者需要时刻保持帮助并培养下属的心态.如果抱着一个有所保留,害怕别人比你强的心态,那恭喜你,你完蛋了.只有你的下属的能力不断提高,能够胜任任何问题时,你才可以轻松.不然你的团队永远处于低级层次,而你永远无法从问题的泥潭中抽身.帮助下属不是去亲自解决他遇到的问题,而是按照自己的经验教给他方法和看问题的角度.授人以鱼,不如授人以渔,真是这个道理.当然,如果你既亲自解决了问题他又能从中学到方法则最好了.
一个人掌握的技术那叫知识,而所有人掌握的技术那叫生产力.知识凭什么能成为第一生产力?两个字:教育.
如果只是单纯的分配任务,然后守株待兔,等着任务完成.这样的管理者是没有技术含量的,而且常常等到的是噩耗.你可能觉得当甩手掌柜很潇洒并心向往之,但是你却没有注意到在当甩手掌柜之前别人所付出的艰辛.当甩手掌柜的两大前提条件是: 1. 组织的运作流畅,制度健全,特别是权力的相互制横 2. 直接下属的独当一面,并有独立的决策体系. 而要做到这些,该要如何的苦心经营,你自己琢磨琢磨吧. 我需要找主程再谈谈. November 21 项目开发札记(6)今天的计委会比我想象的要顺利.
基本上是一口气说完自己的ppt,老大们也没有怎么为难我.没有演示目前的产品,大家可能也知道原因,没有说什么.大概是我已经演示惯了,光讲ppt反而有种光说不练的感觉,有点意犹未尽.虽然邮件里看到有W总的名字,但是会上没有看到W总来,有点失望.W总一直对我很好,而我却无以为报,所以这也算是对我的一种动力吧.
大boss唯一微词比较厉害的地方是我的版本规划.规划中只有寥寥几句话,而没有具体的量化和验收标准.老实讲,我没有想这么糊弄大伙,隔壁的兄弟们还正在排这个月的时间表,实在没办法做到如此的精确.但是以后一定要注意,老大不需要这么模棱两可的规划,他需要知道你的确切目标是什么.
另外,当你下属的人数超过领导的预期时,你需要做两种选择.首先,你可能需要开始记录每个人每天的工作记录,当下次领导认真计较这个事情时,你可以用这样的记录来告诉领导,自己每个人的工作都是饱和的;或者你可以在必要的时候,将富余的人手借到其他部门或者项目工作一段时间.这都是保证你的团队完整性,不被瓦解的办法,呵呵,有点厚黑.
谢天谢地,程序的时间表终于出来了,主程虽然第一次用Project,但还是做得像那么回事,赞一个.在得到主策的确认之后,我准备再给他们半天的时间进行反悔和修改,到明天中午这份Project就是接下来一个月的考核标准.任何的提前都是贡献,任何的延迟都是失职.美术,音乐,QA,策划都将围绕这份Project制定各自的Project,并统一形成项目的Project.
而Project是否有用,就看平时每一天的跟踪,否则就是走过场.我已经经历了太多的Project,但都不幸被所有人抛弃而变得无人问津.而这一次,我不能容忍这样的事情继续发生.
为什么费尽心思作出来的项目计划会无疾而终呢?它又如何避免?这是个很有意思的问题,我想尝试回答一下.
首先,项目的不确定因素.不确定包括内在和外在,外在的不确定往往是不可抗的,将会直接打乱工作部署.所以,一个比较可行的办法是项目的计划不要做得太长,或者分阶段做.将任务细化的部分所占的时间尽量缩短,只占一个版本周期.而对后续的版本周期只作粗略的预估和分解.当遇到不可抗力时,将变更放在比较粗的周期里,而继续维持细分周期的稳步前进.而对于内在的不确定因素,这是考验主程或者架构师的地方,他需要做预估和风险控制.不过相比来说,外在不确定更加可怕,因为外在不确定会导致团队对项目计划本身的失去信任.而内在不确定在大多数人心里都可以接受. 说得直接一点,项目计划被外部破坏是项目经理的责任,而被内部破坏只是主程或者主美的责任.所以,一定要对外部的不确定因素保持警觉.
其次,对时间的科学对待.做计划不是先画好框,然后把东西硬塞进去,而应该是先把东西摆好,再来看框应该多大.前者可能开始看起来很漂亮,面面俱到,领导可能会心花怒放,但是最后大家都会明白,这是忽悠人的东西.而结局就是无人再来理会它.后者可能看起来非常让人失望,但是它确实反应真实情况的,而在项目开发这样的理性行为中,真实是权威的唯一标准. 再者,执行的效率可以挽救糟糕的计划.权威很难建立,却很容易丧失.当在计划的跟踪过程中,出现了不相符合的情况,需要第一时间采取行动,并防止类似情况继续发生.可以修改计划,可以放弃一些任务,但是不能让计划反应不出实际的状态.当与计划不吻合的事情一而再,再而三地发生时,你就会发现这个计划已经越来越没有价值了,而要挽救它将会非常吃力.人们常说计划赶不上变化,顾名思义,赶得上变化的当然是好计划.
最后,我的总结就是,计划可以切分为短期计划和长期计划,必须保证短期计划的稳定,而把各种不确定因素的影响放在长期计划中.项目计划和你的买房计划或者出国计划是一样的,它都需要反应出真实的预期,并且在过程中反应出真实的状况和影响.如果你做不到刚开始就做到完全真实的判断,那你就需要不断调整计划来反应真实情况.
计划就好像自己给自己做一面镜子,当你发现镜子中的人完全不是自己的时候,你肯定会到处去找榔头.
今天T总对我的点拨受益匪浅,很多平时听不到的做游戏的真谛.看来,我真的需要好好想想,怎么才能让这个游戏好玩了.. November 20 项目开发札记(5)需要戒急. 事情往往不会像你想要的那么顺利,那么迅速.任何事情都有一个过程,如果你不能在需要等待的时候保持耐心,那将会对你非常不利.同样每个人的处事方式和世界观也不尽相同,如果你不能采用合适的打交道方式,裂痕很快就会出现在你们之间. 今天我运行游戏时,发现在我的笔记本上总是会在一个地方让操作系统整个死掉.如此严重的问题让我非常恼火,我当时就询问了主程,而他却非常爽快地告诉我:”我不知道!”.这个答案当然无法让我满意,并在我的心里埋下了阴影.下午,微软的老外在对其XBOX的CPU架构大吹特吹的时候,我就不停地想起这件事.我开始怀疑他的能力和做事态度,并越来越有种冲动想冲上去找他来臭骂一顿.当我正准备上去的时候,我发现身边坐了另外一个游戏的主程,于是我低声询问了他,”主程是不是需要知道每一个细节?”.
他的答案让我继续坐在位置上. 1. 主程是一个产品的框架作者,但没必要也不可能熟悉每一个细节.除非你开发的是一个非常小的游戏. 2. 主程会非常清楚其他开发者所负责的部分,所以当你有这样的问题时,主程有可能会让其他开发者来回答. 3. 一个产品可能会有许多第三方的模块支持.当这些模块出现问题时,主程没有义务去解决.
我可能还没有给主程足够的时间,并且他还没来得及把开发队伍调动起来四面出兵.在这样的心境下我看到他做出的开发时间表,虽然比较简单,但是看得出他已经完全理解了我的意图并且考虑到了各个开发者的经验差异,具备一定可操作性.今天,最后一个开发人员终于到位了,而明天他们将有重要的任务分配会议,而我会拿到最宝贵的东西---开发进度规划.我决定继续信任他.
人经常分不清自己是果断还是武断,是执着还是固执.虽然自己非常想做正确的决断,但是却常常在事后对自己失望,很有意思.所谓当局者迷啊.所以,不要老是觉得别人脑子进了水,换成你也差不多是这个样子.
今天跟L总单独演示产品和PPT,她非常失望,虽然她说不是针对我,但是仍然感觉压力倍增.她在内部的转职和项目经理的交接上都对我的工作做了批评. 首先,项目内部的转职,例如助理要转成策划,或者策划转成美术,都须要项目经理做一个正式的内部面试以确认此人确实有能力胜任.而我没做,只是签了自己的名字. 其次,项目经理的交接需要有一项产品的验收,即原项目经理交过来的产品是保持原样的,没有经过任何篡改的.我没做,照单全收. 谈下来,我觉得L总的职业素质很高,看来公司请她过来不是没有原因的.当她问我这个项目还需要多少时间才能公测时,自己还是硬着头皮说出了自己心里的数字,她笑了笑,没有做评价.领导就是领导,这才叫城府.
明天,是我向老大们摊牌的时候.要对自己的想法有信心,面对强大的领导压力时需要坚持自己的立场,否则你的兄弟们就吃亏了. November 17 项目开发札记(4)我曾经非常熟悉的两位老朋友终于还是如期而至,准备演示和加班.
下周一,二,三都有游戏的演示.目前的游戏无论是在稳定性,友好度和可玩性都还非常薄弱,频繁crash,莫名的对话框,长时间的无响应,都在告诉我这是怎样艰巨的一个任务,而我又要带着一个早产的婴儿招摇过市(我为什么要说又?).这样的产品能取得什么样的演示效果我都不敢去想,没办法,硬着头皮演吧.
因为搭环境的原因,虽然我没有打招呼,几个主要负责人还是都一起加班到10点钟一直到跑得没什么大问题.他们走得时候还关心了我一把,自己非常感动.我感到集体的凝聚力正在形成,有这些人在,不愁事情作不好,而我只需要一样东西:时间.
我们的主程终于交出了他给我的第一份答卷,一份软件架构的评估方案.虽然还有些粗放,但是也说到了很多点子上的东西,不过他的解决方案却让我感到时间上的巨大冲突.公司不可能给那么充裕的时间让你重新架构,它更愿意看到产品外在比起以前来有不一样的地方,而对内在质量和架构优劣不太感冒.这个产品之所以会造成目前的困局,原因恰恰在此,希望高层能够学到一点教训.
但是可以肯定的是,下周将是我的公关周.人何时需要妥协,何时需要坚持,真是有意思的问题. 目前看来,这个主程还是让我基本满意,但还需要进一步的观察和考验.
今天参加了整个游戏中心的例会,感觉老大们都挖空了心思想怎么赚钱,只要什么能赚钱就搞什么,小钱也不放过.所以,有人说我们公司不缺钱,我更加深信不疑了.不过会上提到了激励机制,就没有下文了.
Outlook中的便签功能真有用,我开始爱上它了.屁大点事就往上写.好记性不如烂笔头啊,或者说我已经老了开始健忘了.
今天的策划宣讲取得了很好的效果,反响比前几次好得多,主策挺开心.我中途被拉去开会了,所以没看到他们激烈辩论的场面,可惜.不过我回头一想,是不是恰恰因为我不在了所以大家会激烈辩论?我有那么让人不想说话吗? 另外,我将对策划的有效建议也放到了日常的考核之中.希望能集思广益,让集体的智慧帮助我们的游戏更加好玩,更加优秀.
明天要对H总彩排下周计委会上的报告,希望他会接受我写的ppt. 11点多了,该回家了,脑子开始糊涂啦,收工! |
|
|||
|
|