8

私は現在合併中の大企業で働いています。私たちは、合併に関係するプロジェクトと、合併しないプロジェクトに取り組んでいます。私が気付いている問題の 1 つは、開発者のグループの多くが、それぞれのビジネス領域内で多くの異なるプロジェクトをサポートしているにもかかわらず、非常に細分化されていることです。そのため、多くのデータの正確性にあまり自信がありません。

このような変化する環境の管理に成功したモデルや標準はありますか? これらの変更をユーザーに伝えるには、どのような方法がよいでしょうか? 生産の一部で変更が提案された場合、パイプラインの上下に伝達されるように、冗長性を作成する方法はありますか?

編集: 主観性のため、このコミュニティ wiki を作成します

4

3 に答える 3

2

プロセスの監視、移行、および作成のための専用リソース。

私たちは合併と非合併を経て、他の会社を買収し、それらを私たちの「プロセス」に統合する過程にあります。ここでプロセスを引用します。私の意見では、まだ話すことは何もないからです。

私たちが最終的に成功するのは、会社全体で機能するプロセスを作成するための専用リソースがあることだと思います. スクラムはすべて優れていますが、企業の請求およびマーケティング サイクルに必ずしも適用されるわけではありません。では、それぞれが専門分野で効率的に作業するための最良のプロセスとプラクティスをどのように考え出すのですか?

ここでの私たちの魔法の弾丸は、まさにこのタスクに専念する人がいることです。彼は現在の状況を見て、何が必要かを見て、そこに到達するための計画を立てて実行します。彼は、部門、IT、およびそれを完了するために必要な人と協力します。何よりも重要なことは、彼はリーダーシップを発揮し、大きな頭からの支持を得て、大きな重い岩を転がすための適切な力を彼に与えることです(私はあなたがこれらを持っていると確信しています. Peters のしきい値を超えました)。プロセスが定義されると、プロセスを適切にツール化し、各チーム (会社) が定義に先立ってアドホックに採用したすべての異なるシステムからすべてのデータを移行するタスクが発生します。

他のタスクを実行しなければならないときにこれらすべてを実行することは不可能ですが、それを実行しようとして解雇されそうになったことは知っています (1 つまたは複数の岩を踏んだ) ため、この内部構造化に専用のリソースが必要です。あなたの会社にこれがまだない場合、私はこれを私の最初の戦場にします.

ここで例えると、プロセスが何であるかを知っていて、それをやり遂げるためのズボンを持っているシェフ ドルチェストルです。これは、忙しすぎてこれには対応できない CE* タイプの人物ではありませんが、どのプロジェクトのクリティカル パスにも属していない人物です。そうすれば、彼は客観性を保ち、一歩下がって全体像を見ることができ、常に動物園に夢中になることはありません。アジャイル プロセス パラダイムと正式なプロセス パラダイムの両方で経験を積んだ開発経験のある人が、この仕事に最も適していると思います。開発プロセスは、実際に成功するのが最も難しいプロセスである可能性が最も高く、彼がこれを行うことができれば、少なくとも紙の上では、残りは簡単になるはずです.

私たちがこれを手に入れて以来、変化は遅くなりましたが、今のところ、毎回神が送っています。変更が加えられるたびに、残りの部分がいかに非効率的であるかが明らかになり、それを成し遂げるためにより多くの弾薬が彼に与えられます。このようにして、誰かがそれに取り組んでいて、最終的には解決されることを知っていると、非効率性に対処しやすくなります。

幸運を祈っています。不可能ではありませんが、確実に実行可能です。

于 2009-07-17T01:42:46.083 に答える
1

あなたの大企業は他のすべての企業と同じように聞こえます。これらの特徴のうち、あなたに当てはまるものはいくつありますか?

  1. サーバー、オペレーティングシステム、システム、言語、データベースなどの多様なエコシステム
  2. システムの重複 (たとえば、合併する両社は、同じことをわずかに異なる方法で行うシステムを持っている)。
  3. 多くの冗長データベース。真実の唯一の情報源ではありません。
  4. 複数のアプリケーションで共有されるデータ。
  5. コードのテストを困難にする多くの複雑さと依存関係。
  6. 制限を回避するための「実際的な」努力によって引き起こされる多くの複雑さ。

常識やプロフェッショナリズム、または魔法が、プロダクションの上下に変化を伝えるとは思いません。

于 2009-07-17T00:26:23.687 に答える
0

考えられることの 1 つは、プロジェクトがビジネスと整合していることを確認するために、プロジェクトを監督する人々のグループを持つことです。物事が列車事故にならないようにするには、ある程度のリーダーシップが必要です。

スクラムには、スクラムオブスクラムの概念があることを知っています。基本的に、各チームの代表者が毎日 (場合によってはそれより少ない頻度で) 集まり、チームが何をしてきたか、今日取り組んでいることを伝え、障害 (他のチームの可能性もある) について話し合います。

また、一般的なアジャイル プラクティスは、変化を予測するという点で、問題に正確に対処します。

したがって、経営陣が物事を順調に進めていない場合、内部からの非常に優れたコミュニケーションとリーダーシップが必要になります。

于 2009-07-17T01:08:34.200 に答える