私は、技術標準に大きく依存している組織で働いています。これまでのところ、これは素晴らしいことであり、開発者に指示を与えるのに役立ち、チーム間を非常に簡単に移動するのに役立ちます。
しかし、昨年、私は新しいテクノロジーを使用して物事を行うためのより効果的な方法を発見し、これらの戦略をテクノロジーのロードマップに追加するのに苦労しています.
誰かがこのような経験をしたことがありますか?もしそうなら、彼らは組織に変化をもたらすために何をしましたか?
5 に答える
8
許可を得て、新しいテクノロジーを使用した小さなプロジェクトを行うことを申し出てください。その価値と機能を実証します。
于 2008-11-21T21:29:55.270 に答える
2
私はかなり後進的で古風な店だと思います。私たちはまだ CVS (!) を使用しています。Perl は今週 5.6 から 5.8 にアップグレードされたばかりで、PHP 4 から 5 に移行したのは今年だけです。成功した場合はお知らせください:) しかし、経験に基づいて言えば、新しいテクノロジーの採用を妨げる大きな要因は、テクノロジーの利点や優位性が知られていない、または認められていないということではありませんが、むしろ、経営陣が到達したいと考えているより差し迫った優先事項があるわけではありません。
チーム、部門、または会社が現在使用されているテクノロジーでうまくいっている場合、またはそれらを比較的うまく使用している場合でも、新しいものに変更したり、新しいものをテストしたりすることはまだ十分な正当性がない可能性があります.
私が行っていることは、あなたが劣っていると考えるテクノロジーで遭遇した実際の具体的な問題のログをとることです。たとえば、私の場合、CVS がチームのメンバーに問題やフラストレーションを与えたときのログを取っています。特に、私の好みのソリューション (git) でチームの時間を節約できた場合や、CVS が迅速な解決策を提供できた場合はなおさらです。許可しません。ある時点で、蓄積された証拠は、新しいテクノロジーに変更するという決定をサポートするのに十分な重さになる可能性があります.
于 2008-11-22T04:05:43.100 に答える
1
私は小さな代理店で働いていますが、上司と直接連絡を取ることができて幸運です。仕事をするためのより良い方法を見つけたときは、仕事のサイクルの早い段階で選択肢があることを彼に知らせるようにしています. 時間が経つにつれて、私たちは一定レベルの信頼を築いてきました.新しいアプローチを提案するたびに、抵抗は少なくなります.
また、新しいテクノロジーを使用してどれだけの時間とお金が節約されたかを正確に文書化するようにしています. これは、会社のプロセスを進化させるための最も説得力のある方法です。Bean カウンターはメトリクスが大好きです。
于 2008-11-21T22:35:04.750 に答える
0
あなたが作ったものがあなた以外のグループによって支持されることになった場合、あなたは基準に従って生きる必要があります. 標準なしで開発されたオープンソースを想像できますか?
于 2008-11-22T01:25:59.040 に答える
0
適切な意思決定者に対して明確かつ合理的に主張すれば、提案が受け入れられる可能性が高くなります。
いくつかのヒント：
- 基準の変更の価値を明確にします。個人的な好みや利便性だけでなく、ビジネス価値の観点からこれを表現してください。
- メリットに比べて、変更のコストとリスクが小さいことを証明できることを確認してください。これらを定量化できると、非常に役立ちます。
例:
- 最新バージョンの Java で標準化するということは、年間 YYm のコストで XX の古いコード ブランチを維持し続ける必要がないことを意味します。
- YY がクラウド インフラストラクチャ テクノロジを採用することで、新しいサーバーのプロビジョニングにかかる時間が 7 日から 1 日に短縮され、6 日分の余分な収益を顧客に請求できるようになります。この技術はすでにチーム A で成功裏に試行されているため、リスクは低いです。
于 2012-01-06T02:19:12.867 に答える