確かに若いキャリアの中で、風変わりなビジネス ルールとプロセスをサポートするコードを書いていることに気づきました。必然的に、これらの変更は常に非常に難しいコード ベースで行われ、多くの問題を引き起こしました。私の質問にはいくつかの部分があります：
ソフトウェアは企業の生活を楽にするためのツールですが、特定の問題を解決するための「魔法の弾丸」として、開発者としてどの時点でソフトウェアではなくビジネス プロセスの変更を提案するのでしょうか。
私たち開発者は、ソフトウェアに対するある程度の敬意と、単にビジネスの癖をサポートするためだけに変更を加える難しさをどのように伝えればよいでしょうか?
ビジネス プロセスのこれらの変化が私たちの業界を促進することは理解していますが、私の父が例えるなら、ハンマーを溶かしてネジを締めるためのドライバーを鍛造するか、単に釘を使用するか、どちらが簡単か.. .?
エンドカスタマー（つまり、雇用主または顧客の顧客）が聞くことができる最も苛立たしいことの1つは、「コンピューターは私にそれをさせない」ということです。たとえば、送料が計算された後に注文にアイテムを追加したり、消費税が計算される前に何かをキャンセルしたりします。ソフトウェアはビジネスに役立つはずです。確かに、それはソフトウェアを大幅に変更する必要があることを意味し、場合によっては、最初からやり直す必要がある場所から大幅に変更されることもあります。経験を積むにつれて、ビジネスプロセスの変更、法律の変更、税法の変更、顧客の変更などの調整不可能な現実を考えると、変更が容易なソフトウェアを作成することになります。いつの日かあなたはあなたのクライアントにとって信頼できるビジネスアドバイザーになるかもしれません。それはあなたのキャリアの早い段階では珍しいことです。私は今その段階にありますが、プログラムに報酬を支払ってから40年になります。私は、ビジネスがソフトウェアに対応することをめったに提案しません。それがいつ提案するのが正しいかを知るには、多くの判断が必要です。そして、あなたがあなたのソフトウェアに対して感じるかもしれないどんな畏敬の念も、それを支払う人々からそれを隠すために最善を尽くします。彼らはそれを彼らがいる実際のビジネスをサポートするためのツールとして見ています。
あなたが見ることができます
非常に効果的な人々の7つの習慣
、ビジネス プロセスを変更しようとするのに十分な大きさの影響範囲を開発する必要があるという感覚があるためです。
あなたの最善の策は、あなたが自分の仕事に非常に有能であることを示し、ビジネス側の人々との関係を築くことに取り組んで、問題のビジネスプロセスについて議論するために仕事の外に座って快適に感じることができるようにすることです.
これはゆっくりとしたプロセスですが、急ぎすぎると、ビジネスが押し返され、バグのように押しつぶされてしまいます。あなたが読んだら
異端者の時代
たとえば、変更を加えることに成功しすぎて、企業がそれらを破壊した企業の例が表示されます。
現時点で最善の策は、プロセスが変更された場合に新しいルールに簡単に適応できるように、ソフトウェアの適応性を高めるために、できる限り変更を加えることです。
何かをする前に、一歩下がってビジネスを理解しようとするべきです。プロセスを適応させることで変化に対応しているのであれば、それは良いことです。彼らが何年も同じことを続けていると、彼らが会社であり続けることを忘れることができます。ただし、対応している変更が上流または下流のビジネス プロセスに悪影響を及ぼさないようにする必要があります。ビジネス ユニットがそのチェックを行うことはあまりありません。しかし、すべてが地獄に落ちたとき、彼らが誰のせいにするか知っていますよね? そうすることで、それらの問題を回避し、「より良い方法」を伝道することができます。それをしないことは、永遠の欲求不満の処方箋です。
それを成文化することを考える前に、彼らのビジネスを学びましょう。
仕組みについては、私がいつもチームに書いてもらっていたのは「汎用ソフトウェア」でした。ビジネス ユニットによっては、フォームをキャプチャしてレポートを作成する方法が必要になる場合があります。わかりました、簡単ですよね？違う。リクエストは常に何か*200と考えてください。ほとんど同じことをしている 200 のそのようなアプリケーションをサポートしたいと思いますか? 私じゃない。怠惰すぎる。
私は自分のチームに、一般的なフォーム システムを作成し、オフザセルフまたは一般的なレポート メカニズムを使用するように指示しました。また、可能な限り XML/XSLT を使用することを強調しました (たとえば、新しいリリースごとに機能しなくなる Microsoft の easy-bake-oven テクノロジには依存しません)。その後、別のビジネス ユニットが「似ているが変更を加えたもの」を求めたとき、コアはすでにそこにありました。必要なのは、新しいフォルダー、変更された XML/XSLT だけでした。
それは常に - 常に - それらの将来の変更を扱いやすくしました. 「新しいフィールドが必要ですか? XML ファイルを変更します。レポートの作成方法を変更する必要がありますか? XSLT を変更します。プログラムの変更はありません。」それを得る？プログラムの変更はありません。できるだけロジックから外してください。ビジネス プロセスも XML/XSLT で表現できます。
実際には、あなたが遭遇するアプリケーションのほとんどは、永遠に行われてきた同じプログラミング ホイール (ちなみに、優れたアルゴリズムの本です) です。ビジネスを理解しておらず、彼らの技術をさらに理解していない人々によって、彼らはより貧弱に行われるでしょう.
初めて MS DOS を作成する場合を除き、彼らはあなたやあなたのソフトウェアを中心にビジネスを構築するつもりはありません。あなたがそれを提案した瞬間、あなたは去ってしまいます。そして...あなたはそうあるべきです。
それはCIOの役割/強さのようなものです。IT側がビジネス側に、コードよりもビジネスプロセスを変更する方が簡単/安価/費用効果が高いと納得させることができれば、ポイントがあります。そうでなければ、風変わりな商慣習はあなたが思っているよりも価値があるかもしれません。また、風変わりな問題に時間を費やすと、必要な機能が時間どおりに提供されないことを明確にしているのではないかと思います（幸運を祈ります）。
技術者が自分の道を進んでいれば、GUIとマウス/ポインターがラボから出ることはなかったでしょう。日常のユーザーにとって、彼らはここにとどまります。
残念ながら、これは完全に状況に依存します。
ビジネスとソフトウェアの豊富な経験があっても、それは依然として複雑な問題です。
あなたの特定の質問に関する限り：
あなたがそれらを見るとすぐに。重要なのは、あなたの提案を建設的な言葉で表現することです。ビジネスに関連する用語 (ROI、NPV など) も使用します。そして、補助的な利点を見つけます（）。したがって、ソフトウェアの変更によってビジネス上の問題が実際に軽減されず、コストが高く、ビジネス プロセスを修正することで付随的なコストが大幅に削減される場合、単に「コストがかかりすぎるのでできない」と言うのとはまったく異なるシナリオを提示します。 "。
ソフトウェアはビジネスによって所有されます。会社が所有する同様の価値のあるものよりも多かれ少なかれ敬意を払う必要はありません。
新しいソリューションを構築して既存のビジネス プロセスに適応させることと、ビジネス プロセスを既存のソリューションに適応させることの費用対効果を比較検討することには価値があると思います。しかし、実際には、この角度を考えているビジネスを見たことがありません。
それを念頭に置いて、次にできる最善のことは、ビジネスが将来要求する可能性のある特定の変更を予測し、それらの変更に簡単に適応できるようにソリューションを開発することだと思います.