私は、現時点でほとんどの人が忘れていることについて話そうとします。 彼らが何を開発するかは問題ではありません-画像を切り取るためのライブラリ、フレームワーク、CAD用の複雑なプラグイン、または別の居心地の良いERP-CRM。 停止すると思います。 もう一度グーグルでお願いします。 たぶん、あなたも始めてはいけません。
ほとんどのプログラマーになじみのある例：
数年前、私は小さな会社でプログラマーとして働くようになりました。 コンピューターとtechdirが呼び出されました。 彼は彼を紹介するために電話しました。 これは、PHP 3-4バージョンで書かれたフレームワークでした。 そこにはすべて問題ありませんでした-データベースへの実行可能コードの保存、テーブルからの自家製ブートストラップの管理パネル、および「__123123」という名前のデータベース。 ところで、YII 1はすでにその瞬間に勢いを増しており、ジャンゴは誓い始めました。 内部開発をOOP PHPに移植する計画については気にしませんでした。 まあいつか。 追加のリソースがある場合。 つまり、決して。 それまでの間、顧客は待っています。このフレームワークでさらに5つのプロジェクトを開始する必要があります。 すでにToRに署名しています。
私はすべてのプログラマーが彼のキャリアの間にこの現象に出くわしたと思います。 皮肉なことに、私たちは私たちの素朴さを思い出し、すべてを経験不足に帰します。 ただし、これには理由がまったくありません。 現在、まったく同じことを行っています。 常に。 私たちはマンモスを産みます。マンモスは明らかに、開発計画に基づいて死ななければなりません。 そして、彼らの骨は私たちのオフィスにあります。 通路のどこかで、人々はつまずきます。 しかし、これらは私たちの企業の骨です。 原則として、彼らをここに連れてきて、その瞬間に頭で考えました。
誕生
明るい従業員に戻りましょう。 彼は椅子のコンピューターから転がり出し、ソフトウェアを書くことにしました。 おそらく、これはテンプレートによってレポートを生成するための何らかのソフトウェアです。 かどうか。 これはおそらく、マウスを1回クリックするだけで、タスクトラッカーでTKを問題に引き裂くことができるものです。 当局は彼にリソースを提供します。 もちろん、作業は沸騰します。 また、ところで、リリースは非常に高速になります。 理由を知っていますか？ おそらく、最初の週末の後でも、受講者は既にクリックできるものを書いて、プログラムが24時間、10秒で通常どのように実行されるかを見るでしょう。 速いコード、目標は明確で、インターフェースは特に重要ではありません。後でテストします。 明るい未来。
激怒。 この瞬間、マンモスが生まれます。 彼は小さく、速く、みんなを楽しませ、会議室から会議室までかわいく乗ります。
通常、この段階では、プロジェクトの開発方法に関する前提が構築されます。
1）「Serge、ソフトウェアを切断する時間の50％」-「OK、ボス。」
2）「コードをロックしてください。 これは、当社独自の技術的利点です。 ニニのライバル”-” OK。
3）「私たちは機能的なものを飲みました。見た目は気にしません。純粋に仕事のためです」-「わかりました。」
社内の時間は年々非常に速くなっています。 2006は2015に置き換えられます。 2015年は2024年を置き換えます。 Seregaはずっと前に辞めました。 マンモスはすでに、レポートを準備することに加えて、天井と床の間を圧迫するのに苦労しています。
死と葬儀
その瞬間、インターンの1人がgithubで自己ホスト型のアナログを見つけました。これは、React + Rails with Flat Designで書かれています。 あるいは、誰か他の人が忍び込んでSaaSのディレクターにそれを売ったかもしれません。 または、会社の誰かが会議に行って、そこでプラグインgoogleドライブでこれらの問題がどのように解決されるかを聞いたかもしれません。言い換えれば、彼は、問題をより良く解決する素晴らしいテスト済みのアナログがあることを人々が見たときに亡くなりました。
ビジネスで慣習的であるように、「動作する-触らない」。 私はそれを翻訳します。これは、マンモスがさらに数年間使用され、新しい発見に徐々に移行することを意味します。 そして、はい、更新のために割り当てられるリソースはほとんどありません。 研修生は彼らを怖がらせ、競合他社の企業パーティーの元従業員は、ユーザーエクスペリエンスに関するストーリーで同僚を楽しませ、喜ばせます。
他にどう？ 私たちは運命です
はい、テクノロジーは互いに置き換えられます。 しかし、現在ではなく未来に目を向けて、社内で何かを開発する機会があります。 そして、非常に成功した例があります。
オープンソース すぐに。 初日から
正直に言って、社内開発の99％にはユニークな技術的優位性はありません。 ほとんどの場合、典型的なソリューションは、トリッキーで希少なビジネスプロセスを構築し、独自のものを削減し始めている企業には適していないため、ITがコンベアにさらに近くなります。 競合他社がシステムを盗むのではないかという恐ろしい恐怖。 可能ですが、このリスクを落ち着いて評価してください。 ほとんどの場合、他の都市や国、市場、ニッチの競合他社がソフトウェアの使用を開始します。 そして最も重要なこと-彼らはそれを改善し始めます。 オープンソースから実際の具体的なボーナスを得ることができます：
無料のテスター
高品質のコード
ファッショナブルなオープンソースプロジェクトの多くは、高度なプログラミング文化に準拠しています。 テスト、CI、コードレビューがあります。 このような正当化された品質競争とオープン性の条件で高品質の製品を開発することは、企業のリポジトリに閉じ込められた自分自身だけでいるよりも簡単です。
画像
basecamp.com/open-sourceは、Ruby On Railsが開発された小さな会社のページへのリンクです。 RoRプログラマーが、他のすべての条件が等しい場合、RoRプログラマーとそれ以外のものを選択した場合、その選択は明らかです。 これは単なる例です。 トピックははるかに広いです。
従業員のモチベーション
オープンソースを書くプログラマーは通常、自分の履歴書を同時に書いていることを理解しています。 これは、内部開発に取り組む従業員にとって無形の動機付けとなります。 彼らは別の職場でプロジェクトに取り組み続けることができ、すでに競合他社の機能を完成させています。 しかし、最も重要なことは、マンモスが不死鳥になり、はるかに長く生きることができることです。
リーンスタートアップ
あなたがそれを販売したいかのように、内部開発を開始します。 そして、はい、すぐに売ります。 これにより、高レベルの品質が設定され、ビジネスプロセスの穴を検出して競合他社を探索し、多くの価値ある批判を得ることができます。 同僚が「なんてかっこいいんだ！」と言うときはいつでも、「何枚販売しましたか？」 そして、「なぜそんなに少ないのか」という質問に対する答えは、「内部」ソフトウェアではなく、現在の製品の理解と構築における最も奇妙な間違いを明らかにするかもしれません。
エピローグ
企業が自分で何かを開発するとき、それは多くの場合、目のりんごのようなダンジョンに保管されます。 ソフトウェアは時代遅れになっています。 すぐに時代遅れになり、開発、リファクタリング、再設計、新しい統合のためにリソースを常に割り当てる必要があります。 3人のユーザーがいる場合、これを強制することは非常に困難です。 外の世界であなたの開発に直面してください。 これを早く行うほど、良い結果が得られます。 おそらく、あなたの優れたソフトウェアに関する最高のフィードバックは次のようになります。 github.com/project_author/project_name 。 " 誰かがすでにあなたの仕事をしているということです。 半年間何も費やしていないことに怒ってはいけませんが、それ以上費やしていないことを喜んでください。
骨でビジネスを圧倒するマンモスではなく、調和して生まれ変わり、妥協することなく年々恩恵を受けるフェニックスを設計します。 または関与しないでください。