最近又背了黑锅

鼹鼠和蝉

haoyumichael 发表于 2015-2-6 08:40
被不懂技术的project manager坑也不是一次两次。但一直被污告 introduce bug,至少要你们dev team lead出面r ...

version control有，貌似有点用，前几天同事merge了代码以后，ticket再reopen居然静悄悄，没有队友跳出来点我的名了。

鼹鼠和蝉

andorians 发表于 2015-2-6 09:49
你这边办事方法也有点问题吧，一个ticket被重新打开第二次，你就要去跟踪了，打电话也好写邮件也好，总要盯 ...

我们是L3，你们经常接触的是L2。L3没办法直接接触客户。

鼹鼠和蝉

whocares2014 发表于 2015-2-6 10:12
有可能是你做support捅出一堆漏子，于是只能把你转去做开发了。

系统支持需要比较好的沟通能力，和扯皮功 ...

然后做dev又捅出一堆漏子...

gifox

第一个需求哪里，没有process sheet 你就开始写了？
功能不清楚要求BA提供Solution，过后根据expected output 提供UT 文件。都留纪录，开会要闹就来啊，把证件拉出来
而且如果是新问题，坚决拒绝reopen.要求新ticket

小生

这是外行管内行的结果吧。

gifox

还有，楼主的公司不用Itil的么？流程描述起来看着不像

大飞熊

鼹鼠和蝉 发表于 2015-2-6 10:19
为啥不能说。有comment，没人看。客户开的ticket名曰"某系统有问题"，完全相关。 ...

你应该告诉你的manager说，客户raise的ticket太笼统了，当同步到内部的时候需要分开，这样可以easily trace in the future。
作为同步的人应该不是作简单的copy cat，要分类明确change request还是bug这样更加方便account manager的工作。

鼹鼠和蝉

gifox 发表于 2015-2-6 10:40
第一个需求哪里，没有process sheet 你就开始写了？
功能不清楚要求BA提供Solution，过后根据expected outp ...

是L3那种轻量级的dev。要是L4每人负责个模块，哪有这种大锅饭这么多是非。

鼹鼠和蝉

大飞熊 发表于 2015-2-6 10:54
你应该告诉你的manager说，客户raise的ticket太笼统了，当同步到内部的时候需要分开，这样可以easily tra ...

我得向我的组长汇报，组长再汇给lead，lead再跟sync lead交流，sync lead再跟其组员下达命令，或许能劝动客户也或许不了了知。对于除了我以外的其他人来讲，这是无所谓的事情，只要改了就行了呗。我也觉得改好了就行了呗。长此以往不知不觉成了鱼肉。

大飞熊

鼹鼠和蝉 发表于 2015-2-6 11:09
我得向我的组长汇报，组长再汇给lead，lead再跟sync lead交流，sync lead再跟其组员下达命令，或许能劝动 ...

everything by email. then you can complain in the meeting, said "I raised this issue in email couple month ago, blahblah."

kakei14

坚决argue，坚决fight，但是稍微注意下态度，楼主必胜。

鼹鼠和蝉

小生 发表于 2015-2-6 10:48
这是外行管内行的结果吧。

是啊，这也叫上梁不正下梁歪。澳洲dev这块真是远比不了国内，没有开发产品的乐趣和成就感，反而一堆堆的是非。

hustwater

没看到楼主介绍QA啊，应该有QA负责测试，还是楼主兼职了QA？

鼹鼠和蝉

hustwater 发表于 2015-2-6 11:34
没看到楼主介绍QA啊，应该有QA负责测试，还是楼主兼职了QA？

呵呵，看得很仔细啊，没错，没有QA。

wucxzx

LZ，你和客户的交流很不足。当ticket被reopen的时候你就要去follow up了。而且一定要在客户确认的情况下才能close Ticket。平时处理细节时多留点心，不是那么容易背黑锅的。

guyue

我们公司的IT全部外包，我们有个self service的界面来raise ticket，问题得到解决后，总有人跟我们confirm ticket is closed.

zjchina

这在澳洲太正常了。不据理力争，别人只会强调你语言不通

gzrain

你可以在开会把问题说清楚，不同问题/bug即使是在同一类别也要分开不同ticket，否则commit message就跟ticket out of sync.

如果manage再叽歪责任问题，那好，每次fix bug把git blame截屏作为attachment放在ticket里面，估计马上那些人就闭嘴了

fifapig

工作流程有问题啊。 一个ticket任务完成后状态应该是resolved. 然后你的leader或者是 product owner 审核，若没通过，应该reopen接着干。若是通过后应该sign off, 然后这个ticket就closed了。那么这个时候，这个ticket就不能再打开了。若是又来新的需求应该创建一个新的ticket, 如果需要可以联接这2个ticket. 这样才能权责分明，若果客户老要改动，但是你的头每次都已经sign off了，那只能证明你的领导是脑残，无法理解客户的要求，这样跟你就没有直接关系了。

bigtailcat

关键的点上比如说有没有邮件确认是客户要求的，还是BUG？你做决定的时候有没有跟你的投邮件确认，如果都留证据了，黑锅也背不到你头上

gavy

感觉楼主不懂保护自己啊   凡事对自己有潜在利益威胁的都要in writing    这样出事了才能据理力争  

tony_wang99

公司内部不是挖角过去的，而是因为其他原因变组的，一般都是混得有问题的。很多时候不是技术问题引起的。

sea_snail002

鼹鼠和蝉 发表于 2015-2-6 11:09
我得向我的组长汇报，组长再汇给lead，lead再跟sync lead交流，sync lead再跟其组员下达命令，或许能劝动 ...

”改好就行“这种思想要不得，而且还会害到自己，除非他们要的只是结果，不在乎是谁的责任。所以还是按照流程来的好。至少认真追查起来的时候有理有据。就像这边的医生看病，明明很简单的病，也要把该走的流程走一遍，按流程走医生就没责任了呗。

还有就是你们ticket 没有log 的吗？不发Email可以在log里详细记录更改流程和原因，以备以后刨根问底的时候有个参照。

cais

LZ查到bug在哪里之后 git blame 或者 git log -p看是哪个人干的，再查一下当年是哪个ticket/issue，然后连到现在这个bug 的ticket里面去，摆事实，讲道理。

fuleinist

LZ跳槽吧。。。

tom22

鼹鼠和蝉 发表于 2015-2-6 07:04
败就败在叫得最快的大多是一个同胞。要是印度人，我早就灭了他。

同胞? 敌人. 灭了他.

turrella

刚有鞋穿的人 发表于 2015-2-5 20:03
就是楼主做个东西，有小毛病，修复，又有，又修复，反反复复

别，你这么解释给别人听，楼主更得背黑锅了。。。