sharepoint - カスタム開発への恐怖に対処する方法

Question

私は現在の雇用主との問題に取り組んでおり、他の場所での就職を真剣に考えさせられました。彼らは、カスタム開発を 100% 排除し、SharePoint などの COTS 製品に置き換える必要があるという印象を受けています。これが現実的な期待ではないことは承知していますが、これらの見解を共有する経営陣と私の主張を議論することは不可能であることがわかりました. 彼らの主張には、通常、機能 X をカバーする SharePoint に既に存在する機能に沿った何かが含まれているため、関連するリスクが少なくなり、それに対してテストを行う必要はありません。

その好例として、SharePoint リストが顧客の期待と要件を完全に満たすことができない状況があります。ただし、このデータを SQL データベースに保存すると、要件を簡単に満たすことができます。しかし、私たちの開発チームが SharePoint の境界の外に出ることを提案するたびに、コードのすべての行がプロジェクトの複雑さを増し、リスクを増大させる方法について経営陣は炎上します。これは状況によっては確かに当てはまりますが、常にそうであるとは限りません。しかし、彼らの主張は、SharePoint はデータを格納するためのメカニズムを提供するので、それを 100% の時間使用するべきだというものです。それが顧客の要件を満たすかどうかに関係なく。

私は自分が (100% の確信を持って) 正しくないとわかっていて、カスタム開発を行うことで正しくできることを常に強制されているため、仕事に来るのが嫌いになりました。しかし、それは私が働いているところでは不可能な議論のように思われるものです.

同様の状況を経験した人はいますか？もしそうなら、これらの課題を克服するために何をしましたか?

Answer 1

会社のビジョンを共有しておらず、彼らを啓蒙できない場合は、検討を始める良い機会です。

クライアントに役立たない、機能がない、または使用できない「解決策」を強制することにはリスクがあることを指摘しましたか?

おそらく、認識されたリスクに対処して軽減するための計画を考え出すでしょう。

Answer 2

懸念事項を文書化し、上司に知らせてから、彼らの求めに応じます。うまくいかない場合は、問題を提起したという文書があります。しかし、彼らの計画を台無しにしようとしているように見えないように、彼らのやり方でうまくいくように努めてください。彼らはより大きなリスクを冒しているため、より大きな責任を負っています。自分のやり方でうまくいくように最善を尽くし、心配するのはやめましょう。

Answer 3

これは悪く聞こえるかもしれませんし、あなたが望む答えではないかもしれません。私のオフィスには、「スカンクワークス」と呼ばれるあまり知られていない部門があります。人々は自分の意思で (通常は昼休みやコンパイル時に) 会社に役立つ小さなプログラムを作成することにします。これの面白いところは、その結果が会社に「コスト」をかけないことです。

会話は通常、次のようになります。

「このソフトウェアを購入する必要があります」 - ボス

「しかし、私たちは何ヶ月もそれを持っていました。ジョンは、その日までにそれを書きました」 - プログラマー

「？」-ボス

多くの場合、開発者は決定を悪いものと見なし、自動的に行われる並列プロセスを作成するだけです。次に、問題がファンにヒットし、顧客が不満を感じた場合、代替ソリューションはすでに用意されています.

自動リリース機の例があります。開発者はこれらのカスタム レポートを作成していました。顧客が増えるにつれて、開発者の作業負荷が増加しました。問題は、「顧客がカスタム レポートを入手するには、開発者が関与しなければならない」ことでした。そのため、会社がフルタイムでレポートを作成する人、または顧客にレポートを作成してもらう方法を見つける人を雇うことを検討している間、私はレポートの変更を探して顧客に直接リリースする自動リリース マシンを作成しました。また、開発者が持っているものよりも使いやすい、誰でもレポートを変更できるユーティリティも作成しました。上司が解決策を見つけようとしていると発表したとき、私は彼に、解決策は既に整っており、報告書に変更を加えてリリースすることもできると伝えました. これで、誰もがレポートを変更できます。通常、これらの変更を行うのは経営陣とカスタマー サポートです。楽しい面は、開発者が関与しなくなったことです。

早くやれよ。どうせ辞めるなら、やめたほうがいい。

Answer 4

管理者の誰かが SharePoint の在庫を所有していますか? そのシステムはCEOの弟が開発したのですか？

彼らが変化に対してそれほど回復力がある場合は、彼らと議論する前に本当の理由を見つける必要があります. 彼らは、複雑さが増す、テストが難しいなどと主張するかもしれませんが、すべての議論に対して、彼らの立場を示すもので、十分な敬意を払って、誤解されていると反論でき、それでも彼らが議論しない場合、あなたは議論している可能性があります.間違った点。

SharePoint はあらゆる技術的状況において究極であると読んだことがある人など、非技術的な理由でテクノロジーに縛られている場合 (もちろん、SharePoint 以外の記事が何について話しているのか見当もつきません = 良いことです)。そうすれば、わざわざ議論してエネルギーを節約しようとするべきではありません。就職活動に。

Answer 5

彼らにそれを証明してください。複数列の並べ替えで 100,000 個のアイテムを処理できるリストが必要な場合は、100,000 個のテスト アイテムを共有ポイント リストに追加するスクリプトを作成し、できれば「顧客」がリストを監視することを要求して、それを試してもらいます。:-)

Answer 6

私は通常、話だけでこれらの議論に「勝つ」方法はないことに気づきました。多くのマネージャーは、管理指向の記事を読んで製品やソリューションの意見を形成します。あなたがいくつかの反論を見つけることができるかどうか見てください。

SharePointで実行できないことの例を引用し、カスタム開発を通じてこれらの問題をコスト効率よく解決する方法の例を示すことができれば、順調に進んでいます。

間違いは、これをテクノロジーについて話し合うことです。効率、費用対効果、保守性についてではありません。これらは、技術者以外のマネージャーが代替案を検討するように促すマントラと指標です。

これらの問題のいくつかの概念実証を非常にうまくまとめることができれば、アイキャンディーは技術チームの外で販売するのに本当に役立ちます。

最後に、頑張ってください:)

Answer 7

私があなただったら、間違いなく履歴書を公開します。あなたが現在経験している経験はイライラするだけでなく、長期的にはあなたのキャリア開発を本当に傷つける可能性があります. 考えてみてください。あなたが現在の雇用主と現在の立場で苦しんでいる間、他の開発者は新しいテクノロジーを採用し、経験を広げています。

開発者間のイデオロギーの違いや、開発者の役割に関する会社の考えなどがあります。率直な議論と率直な議論がうまくいかなくても、努力が足りないからと言って責められることはありません。会社への忠誠心は良いことですが、関係は双方向である必要があります。

悲しいことに、彼らは最終的に彼らの仮定が間違っていることに気付くでしょう - しかし、あなたはその日が来るのを待つことはできません. 時々それは決して来ません。特に (誤解しないでほしいのですが、意図された目的で使用される SharePoint が大好きです)、SharePoint は次の Access になります。救世主。

Answer 8

私は、経営陣が彼らのアプローチにおいて建設的ではなく、あなたが説明するほど悪くはないが、十分に悪い場所で働いてきました。

いくつかのオプションがあります。1つは、先に進んで、クライアントのために必要なことを、可能な限り最高の「コストパフォーマンス」オプションで実行することです。この「市民的不服従」を機能させるには、おそらく開発者をチームとしてまとめる必要があります。

たわごとをファンに実際にヒットさせるより強力なアプローチは、クライアントに行き（外部クライアントである場合、または仕事を続けたい場合はこれを行わないでください）、これに何が起こるかをレイアウトすることですXとYの場合はプロジェクト。これは学校の外で物語を語っていて、悪いことになるでしょうが、面白いです。

もう少し良い方法は、チェーンを上って、あなたのためにたわごとを起こさせることができるスポンサーを取得することです。基本的に上司の後ろに戻ります。これはうまくいくかもしれませんが、経営陣との関係については予測可能な結果が得られます。

最後に、最も難しいのは、カスタムコードが悪いという見方をしている人を特定し、会話に参加させて、どこで信念を得たかを見つけ、例を挙げてそれに対抗することです。彼らの根底にある懸念（カスタムコード自体についてではない）に耳を傾けて理解し、その人が信頼できるようになった後でのみそれらに対処する必要があるため、会話に重点を置きます。

関係する個人に大きく依存するため、どちらのやり方が最も効果的かはわかりません。私が知っているのは、人を変えることはできないということだけです。私の経験では、これまでのところ、問題を解決する最善の方法は、そうでない人を離れて一緒に働くことでした...

Answer 9

私は現在の仕事で同じことをしていますが、この種の状況に対処する簡単な方法はありません. 私にできたのは、自分の主張を飲み込んで、自分の経営陣の要求に従って行動することだけです。これはもちろん、当面のタスクに最適なソリューションを使用し、その過程で何かクールなものを構築するという基本的なプログラマーの性質に反しますが、彼らはボスであるため、実際にはそれが唯一のソリューションです。カスタム ソリューションを使用する方が理にかなっている場合は、証拠を示してケースを探すことができます。しかし、あなたの上司が私のようなものであれば、悲鳴を上げる試合が始まるまでにそれほど時間はかかりません. 他の唯一の解決策は、その履歴書を払いのけて新しい仕事を見つけることです。

Answer 10

私は初日から同じ種類の課題に直面してきました。経営陣は、カスタム コードをソリューションに追加することを自然に嫌がります。ただし、ほとんどの場合、お客様にとって適切なソリューションにはカスタム コードが含まれていると説明することは可能です。

カスタム コードを共通コードベースに含めることができると主張する場合、上司はそのアイデアを承認する可能性があることを忘れないでください。

Answer 11

私は本当にあなたの痛みを感じます。

私だったら、空いた時間を使って自分の主張を裏付ける情報を収集し、わかりやすい方法で文書化します。

彼らがお金だけを理解しているなら、お金について話し、恐怖しか理解していないなら（「あれ」が怖いので「これ」をする）、恐怖を利用して、「彼ら」の解決策の中で怖いものを見つけてください。

すべての新しい実装、発生する時間、お金、および問題を文書化します。そして、代わりにあなたのソリューションが何であるかを文書化してください。

「あなたの」ソリューションに問題がないことに焦点を当てているため、おそらく彼らのソリューションに問題が見られません。

Answer 12

カスタム コードと呼ばないでください。代わりに、「予想される SharePoint ユーザー拡張機能」などと呼ぶと、特定の用語に関する誤解が和らぐ可能性があります。

また、すでに述べたように、経営陣がこの議題を推し進めている理由が他にも隠されている可能性があります。多くが有効であるため、これらをすぐに推測しないことがおそらく最善です。

最後に、開発が必要な場所がたくさんあります。より良い一致を探すのは悪くありません。

幸運を。