アカウント名:
パスワード:
>そーゆー質問は顧客の業務担当者にすべきもの。派遣の開発者には答える権限がないのです。
それって、エスカレーションパスの設計ミスだろ?運用設計からやり直し/見直しした方がよいシステムだと思う。
>顧客側の夜間バッチの当番には連絡がついた事がないので開発会社に電話する慣習が根付いているらしい……
それが問題なんだとわかっているなら、対応しちゃいけないとわかっていることを対応しちゃうわけだろ?設計/製造上の問題を明確化していない、つまり、可視化が出来ていないビジネスモラルの低い環境だと思う。
>「知らんがな」だしな
そういう事を聞かれた時点で、PMとかに「エスカレーションパスの不備だ」と指摘していると、すこしは良くなるみたい。言わないで、黙って発言したり操作するってのは、ある種の業務妨害になりかねない。
>止めて大丈夫な仕組みが作られてるかどうかならともかく
そこらへんは、運用設計と維持/保守担当の管轄だからね。ジョブとかアプリ作った人間に聞くことではないよな。しかし、運用側は「そんなことは引き継いでいない」とか言う。どこでその情報が消えたのか?そもそもその情報が伝わるパスはあるのか?といったことから設計しなおさないと、同じ事が繰り返される。
知っていたとしても、無権限での代行を許すというのも、無茶。無権限でやって、上手く行ったところでほめられもしないし、失敗したらそれこそ大きな問題になっちゃうからね。
連絡先の制限も最近ではセキュリティとか影響でちょっとだけよくなってますね...
代りに別の問題がいろいろでてますが
# 長期的にはそもそも仕事がなくなるんじゃないかという不安が...いや明日かもしれませんが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
夜間バッチのオペレータからの電話 (スコア:5, 興味深い)
曰く、「バッチが予定時間を過ぎても終了しない。強制中断してよいか?」
そーゆー質問は顧客の業務担当者にすべきもの。派遣の開発者には答える権限がないのです。
(そもそもオペレータが私の自宅電話番号を知っている時点で終わってるけど)
# 顧客側の夜間バッチの当番には連絡がついた事がないので開発会社に電話する慣習が根付いているらしい……
notice : I ignore an anonymous contribution.
Re:夜間バッチのオペレータからの電話 (スコア:3, すばらしい洞察)
>そーゆー質問は顧客の業務担当者にすべきもの。派遣の開発者には答える権限がないのです。
それって、エスカレーションパスの設計ミスだろ?
運用設計からやり直し/見直しした方がよいシステムだと思う。
>顧客側の夜間バッチの当番には連絡がついた事がないので開発会社に電話する慣習が根付いているらしい……
それが問題なんだとわかっているなら、対応しちゃいけないとわかっていることを対応しちゃうわけだろ?
設計/製造上の問題を明確化していない、つまり、可視化が出来ていないビジネスモラルの低い環境だと思う。
Re: (スコア:0)
「知らんがな」だしな
#
止めて大丈夫な仕組みが作られてるかどうかならともかく
Re:夜間バッチのオペレータからの電話 (スコア:1)
>「知らんがな」だしな
そういう事を聞かれた時点で、PMとかに「エスカレーションパスの不備だ」と指摘していると、すこしは良くなるみたい。
言わないで、黙って発言したり操作するってのは、ある種の業務妨害になりかねない。
>止めて大丈夫な仕組みが作られてるかどうかならともかく
そこらへんは、運用設計と維持/保守担当の管轄だからね。
ジョブとかアプリ作った人間に聞くことではないよな。
しかし、運用側は「そんなことは引き継いでいない」とか言う。
どこでその情報が消えたのか?そもそもその情報が伝わるパスはあるのか?
といったことから設計しなおさないと、同じ事が繰り返される。
知っていたとしても、無権限での代行を許すというのも、無茶。
無権限でやって、上手く行ったところでほめられもしないし、
失敗したらそれこそ大きな問題になっちゃうからね。
Re:夜間バッチのオペレータからの電話 (スコア:1)
連絡先の制限も最近ではセキュリティとか影響でちょっとだけよくなってますね...
代りに別の問題がいろいろでてますが
# 長期的にはそもそも仕事がなくなるんじゃないかという不安が...いや明日かもしれませんが
M-FalconSky (暑いか寒い)