Leapfrogのテクノロジーとツール

間違ったツールが原因の認知的不協和音

むかしむかし、今日のプログラマー、アナリスト、そしておそらく大学で勉強したマネージャーでさえ、賢明な原則について知らされました-最初にタスクが決定され、次に製品の要件が書かれ、それからテクノロジーが選択されます。 なぜ、真面目な企業が開発した膨大な数の大規模なプロジェクトに、それを控えめに言っても技術やツールが存在しないのはなぜですか? 優秀で給料の高い専門家の群れは、開発の基本原則の1つを忘れていますか?

いいえ、全員がこれを覚えて理解していますが、トレーニング中に誰も話さないニュアンスが役割を果たし始めます。



仕入先



深刻な組織が深刻な問題の解決策を模索する場合、通常はIBMやMicrosoftのような巨人になります。 または、高い確率でITフィールドのモンスターが再び勝つ入札を手配します。 そして、これらの企業は長い間、顧客の問題を解決する人々のグループではなくなりました。 今、これらは「偉大なベンダー」です。 場合によってのみ、彼ら自身が何かを開発または実装します。 通常、彼らは「箱入り」ソリューションの1つを販売し、注文を小規模なパートナーに転送します。 そして、パートナーはすでに特定の顧客向けのソリューションを完成させて実装しています。 つまり ベンダーの目標は、顧客の問題を解決することではなく、製品を販売することです。



さらに、パートナーはベンダーの製品をできるだけ多く販売しようとしています。 第一に、彼らはこれからパーセンテージを持ち、第二に、成功した販売は評価を上げ、ベンダーから注文を受け取る可能性を高めます。 つまり 「私たちはあなたに、あなたは私たちに、そしてその間に顧客の問題を解決します。」



たとえば、Microsoftのコンサルタント(「マーケティング担当者」と読みます)は、BizTalkとMS CRMが必要だと顧客に確信させました。 その後、注文はパートナーの1つ(ある会社「A」など)に転送されます。 会社「A」のスペシャリストは、割り当てられたタスクを研究し、システムの要件を策定し、販売された製品が最良のソリューションとはほど遠いことを理解します。 単純にいくつかのWebサービスを開発し、既存のカスタマーポータルをわずかに完成させる方がはるかに良いと仮定します。



しかし、販売された製品を拒否することはできません! したがって、不適切なタスクを解決するには、それらを使用して「仕上げる」必要があります。 同時に、作業のコストと期間が増加し、最終製品の品質が低下し、鋳鉄製で動きの遅いシステムが得られます。



しかし、問題の本質は、製品と技術が専門家ではなく売り手によって選択されたことです。 その目的は、問題を最適に解決することではなく、最も高価なソリューションを販売することです。



スキル



世界のすべてを知り、できるようにすることは不可能です。 これは特に、製品とテクノロジーのリストが無限になりがちなIT分野に当てはまります。 したがって、ベンダー、パートナー、「独立した」アウトソーシング会社、学生のVasily Pupkinなど、誰が助けを求めても、誰もが知識とスキルの枠組みの中で問題を解決します。 そして、男はまったく異なる知識を持って来て頭を振ります。 さて、なぜここにあるのですか? もっと簡単だったかもしれません!」



さらに悪いオプションは、ツールが正しく選択された場合ですが、経験と学習時間の不足のために、ツールが誤って使用されました。 私自身の経験から言えば、場違いの開発者が自分の所有物をうまく使うと、結果はずっと良くなると言えます。 彼らが人生で初めて見るものを紹介しようとしている状況では、何も良いことは期待できません。



「そして、すでに...」



エラーが開発者のせいではなく、顧客のせいである場合、これはまれなケースです。 つまり タスクは最初にフレームワークで設定されました:「既存のソリューションを改良して...



既存の製品が元々この問題を解決するために開発されていない場合、必要な改善がアーキテクチャと矛盾する場合、またはこの場合により適したツールがある場合、検討する価値があります-価値がありますか? おそらく、既存のソリューションを開発する代わりに、それを置き換える時が来たのでしょうか? または、「責任範囲」を分割します-新しいタスクに新しいソリューションを適用し、古いソリューションをそれが存在する形式のままにします。 常に選択肢があります。時々、古い馬を「ポンピング」するのではなく、新しい車を買う時が来ました!



それで判明した



アウトソーシング業者やコンサルタントに目を向けると、いくつかの問題について考える必要があります。

  1. 彼らは請負業者を不必要な技術的枠組みに押し込んでいますか? 追加の制限は困難です。これは時間と無駄なお金です。
  2. テクノロジーは適合するために提供されますか、それともあなたが本当にそれを売る必要があるというだけですか?
  3. 開発会社の開発者は代替手段を提供していますか? 彼らはそれらを検討する準備ができていますか?
  4. 彼らは選択された技術の経験を持っていますか?


そして、結局のところ、経験は同様の問題を正確に解決する必要があります! 企業ポータルが必要で、フラッシュを提供することを提案している場合、フラッシュゲームの開発における同社の豊富な経験はそれほど有用ではないでしょう。



主なことは、問題には解決策が必要であり、解決策にはテクノロジーが必要であることを理解することです。 そして、これらの優先順位を変更しようとすることは常に高価です! これをよく忘れてしまうのは残念です。



PS

これはすべて、問題に対する私のビジョンです。 私は別の視点を読んでとてもうれしいです。



All Articles