※ 引述《NDark (溺於黑暗)》之铭言： : ※ 引述《JJ1118 (JJ)》之铭言： : : 主管不懂你的工作内容，相同的RD也不懂主管真的的工作。 : : 主管永远认为你应该要懂他的想法或需求，若你不懂要问。 : 这里我跟你看法不同. : 一个好的主管一定要知道属下在干麻. : 可以不知道每分细节的事,但至少要知道大概五成.最好要包含写了哪些函式或模组. : 主管(这里可代换为不同公司的PM,就是管"事情"的那个人)要负责追踪与掌控产出. : 如果主管(或PM)没办法"掌控"确切的进度.那就是差劲的管理. : 如果产出与规格不同(察觉并追踪这件事绝对是视野高的人来作, : 可以委托QA人员,但是结果回来要十分清楚), : 绝对是主管要把执行者固定在原地直到问题解决为止. : 否则不可以再继续进行其他的地方.因为炸弹会越埋越多.其他人会一起被波及. : 由下询问上的执行是绝对会出问题的. : 因为权力不对等. : 主管一个眼神,都会让原本(技术)正确的事情变成(政治)不正确的事情. 部分同意，大部分不同意，甚至觉得观念有误。 不过对於主管的定义要分一下。 你第二句的好主管是（高一阶的主管），最後依据主管眼神是高好几阶的主管。 因为高一阶主管要了解下属的工作内容（尤其是中阶主管对Working level的员工）， 但是通常出来骂人、变更需求、提出需求.....都不是高一阶主管。可能是其他单位， 甚至更高层的主管，因此他们不了解你的那些细节是完全合理的。 因此在接收开发需求时若不完整，没有向提需求的单位或是主管反应， 我不认为那些主管要负太多责，因为他又不是工程师，他怎麽知道要写到多细， 表达到什麽程度你们才懂，你们也没说不懂。 另外关於专案经理、负责人要确实掌握进度。 没错，专案经理的工作就是掌握进度、管理进度、甚至要协助管理风险。 但是他们不写code，进度到什麽程度是谁回报的？ 难道今天我的验收方式是，你把这个功能叫出来让我确认过，真的可以run， 我才同意这个功能叫写完了.... 当然是依据工程师的回报，工程师怎麽回报？ 依据估计要写800行，现在大概写了8成...还是依据要写8天，现在写6天？ 还是......太多种方式了。再加上写出来的code要不要验证？有没有问题？ 要花多少时间确保正确？这问题连开发的工程师自己都答不出来， PM要如何写进度呈报主管，更别说掌握准确的进度。 不要把问题都丢出来给其他单位，就因为程式开发的不可测，因此管理需要很有弹性。 但是就因为需要弹性，才会造成工程师永远都抱怨管理人员不了解软体开发。 问题是，连工程师自己都无法管理好自己的开发状况，如何让别人管理。 另外补充：权力不对等.....这种思维就是问题。 大家都是领出钱者的薪水，就算是总经理他也是领薪水的，只是大家做的事不同罢了。 双方的终极目的都是把事情做好，如果需要去找他们询问就该询问， 揣摩上意就是问题。 如果一个单位只有由上而下的指挥模式，除非上意非常清楚，不然绝对会出事。 为何国外都不会称呼职称，直接叫名字，就是因为大家同样是授薪阶级， 你是总经理也不表示你就一定对。需要总经理给资料时，你就是要找他拿资料。 尤其软体开发业通常不会很大，更少有主管摆主管架子。 通常都是工程师摆架子，主管在旁边倒茶递水，就怕这些工程师心情不好不爽写。 我前一阵子逼我们一位工程师离开。他离开时一直说，公司都不管工程师的想法， 时程压太短.... 别人家一个相同类型游戏作2个月，他老兄开发6个月还一直有bug，很多功能没做完。 然後跟我呛「时程都是你们定的，哪有一个软体开发不delay？」 每次问进度都是「我不知道，我也不能保证....」 「你也知道软体开发突然有什麽无法解的bug也很难说」 每个案子请他先依据需求分析出需要制作的模组或功能， 他很努力的写出来.....然後请他估时间（当然估不出来） 我想请问，如果你是PM，他无法估时程给你，当然只有你估时程给他， 难道你能跟老板说，「这个案子就看那个工程师什麽时候写完罗！」 我认同工程师有很多难解的问题，也背负很多压力。 但是其他单位的角色一样有压力，一样每天都在看别人脸色。 完成案子是大家的目标，如期如值如预算是专案管理的基本精神， 顺畅的沟通更是完成案子不可或缺的。 请工程师主动跟其他人沟通，而不是被动等着接受上面的指令， 然後就认为指令都是你们下，我听命行事，做不好也是因为你们指令下错。 就是这种心态，我是完全不能接受的。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.128.227.51