韓国のソフトウェア開発の課題
-
- いいね！76
いいえ。そのプロジェクトを成功させた経験者を選択するのが最も優れています。高収入のスカウトでも連れて行きます。
ringoapp
@ringoapp
@happy__engineer @booiljoung @agebreak 자사 제품 개발이라면 그 방법도 있겠지만 외주/수탁개발의 경우엔, 그건 계약에 위배됩니다. 선택지가 안되죠. (자사제품이라도, 상사 및 고객과의 약속이 있지만…)
2014-07-01 21:16:55自社製品の開発であれば、その方法もあるが、外注/受託開発の場合には、それは契約に違反します。選択肢がだめ。 （自社製品でも、上司や顧客との約束がありますが...）
행복한 엔지니어
@happy__engineer
@ringoapp 늦어진 프로젝트일정을 일정에 맞춘다는 말이 이미 저의 생각에는 무언가 하나를 포기할수 밖에 없는 상황이 아닌가 싶어요. 물론 이때 결정은 쉽지 않을것 같고요. @booiljoung @agebreak
2014-07-01 21:17:03遅くなったプロジェクトのスケジュールをスケジュールに合わせるという言葉が既に私の考えでは、何か一つを放棄するしかない状況ではないかと思います。もちろん、この時の決定は容易ではないようで。
Ted
@booiljoung
@happy__engineer 처음부터 유사 성공 플젝 경험자들로 채우기도 하구요. 회사 운명이 달린 플젝이라면 특히 그렇게 합니다. @ringoapp @agebreak
2014-07-01 21:17:46最初から同様の成功プロジェクト経験者で埋めるしね。会社の運命がついたプロジェクトなら、特にそうです。
ringoapp
@ringoapp
@happy__engineer @booiljoung @agebreak 계약된 플젝이라면 포기할 수 없어요. 위약금을 물어야 할 상황이죠.
2014-07-01 21:17:47契約されたプロジェクトならあきらめることはできません。違約金を支払わなければならない状況だ。
행복한 엔지니어
@happy__engineer
@ringoapp 외주 계약일 경우 거의 불가능한게 사실입니다. 하지만, 오히려 이런경우 마지막까지 사실을 숨기기 보다는 오히려 적극적으로 이야기 하는것이 좋지 않을까 싶습니다. @booiljoung @agebreak
2014-07-01 21:21:58外注契約で、ほぼ不可能なのが事実です。しかし、むしろこのような場合は、最後まで事実を隠すよりもむしろ積極的に話をするのが良いかと思います。
Ted
@booiljoung
@ringoapp 요구사항만 보고 일정 추정하기란 점치기에 가깝죠. 많은 플젝이 이렇게 추진되고 망합니다. 기능 위주로 끝내기는 해주죠. @happy__engineer @agebreak
2014-07-01 21:22:21要求事項だけ見て日程推定することは占うのに近いです。 多くのプロジェクトがこのように推進されて滅びます。 機能中心で終えることはあります。
행복한 엔지니어
@happy__engineer
@booiljoung 동의 합니다. 사실 요구사항만 보고 일정을 추론하는건 정말 쉽지 않을일인것 같습니다. @ringoapp @agebreak
2014-07-01 21:23:37同意します。実際の要件だけを見て、スケジュールを推論するのは本当に容易ではないことであるようです。
ringoapp
@ringoapp
@happy__engineer @booiljoung @agebreak 아, 처음엔 숨기면서 인원충원 하기도 하면서 버티다, 나중엔 결국 죄송하다고 꾸벅거리며 대책이라고 내놓는게 또 인원충원인 게 대부분이죠. 그렇게 일정은 늦어지고, 인원은 늘어나고..
2014-07-01 21:24:14ああ、最初は隠しながら人員補充したりして堪えて、後には最終的には申し訳ないとこっくりながら対策として打ち出すのがまた人員補充であることがほとんどでしょう。その日程は遅くなって、人員は増え..
Ted
@booiljoung
@happy__engineer 정부나 회사 홈페이지 사용성이 엉망인건 그런 이유 입니다. 기능 우선으로 사용성이아 푀적화는 미룹니다. @ringoapp @agebreak
2014-07-01 21:24:52政府や企業ホームページのユーザビリティが台無しはそんな理由です。機能優先的に使い勝手の向上は遅延します。
Ted
@booiljoung
@happy__engineer 분석 디자인 계약과 개발 계약을 따로 해야하는데 요구사항만 보고 계약하고 망하는걸 보면 신기하고 답답 합니다. @ringoapp @agebreak
2014-07-01 21:28:27分析設計契約と開発契約を別々にするべきなのに要件だけを見て契約して滅びるのを見ると不思議で息苦しいです。
ringoapp
@ringoapp
@booiljoung @happy__engineer @agebreak 어쩜 지금껏 남의 다리만 긁어왔는지도. 정작 바꿔야 할 건 프로세스가 아니라 계약형태인지도 모르겠네요.
2014-07-01 21:29:59どうして今まで他人の足だけ掻いてきたかも。いざ変更する必要がガンのプロセスではなく、契約形態なのかもしれませんね。
행복한 엔지니어
@happy__engineer
@ringoapp 프로젝트를 하는데 있어서 일정은 계약의 형태부터 프로세스, 업무 진행까지 어쩌면 전반적인 부분에서 부터 영향을 받는 아이템임에는 분명한것 같습니다. @booiljoung @agebreak
2014-07-01 21:32:17プロジェクトをする上でのスケジュールは、契約の形態から、プロセス、業務進行まで多分全体的な部分でから影響を受けるアイテムであることは明らかなようです。