ソフトウェア業界で流行している最悪の偽りの経済(それは最終的に貯蓄以上の費用がかかるお金を節約する方法)とは何ですか?
ソフトウェア業界で流行している最悪の偽りの経済(それは最終的に貯蓄以上の費用がかかるお金を節約する方法)とは何ですか?
回答:
すなわち、「すぐにそれを行うだけで、後でリファクタリングします」。第一に、この動作に関与している誰かが実際に後でリファクタリングするのをまだ見ていないからです。第二に、良い方法の代わりに迅速に物事を行うと、将来の機能を追加したり、将来のバグを解決することが難しくなり、最終的には時間を無駄にすることになります。
悲しいことに、多くの人は、開発者のサイクルを節約して、何かを高速に実行できると考えています。可能だと思いますが、実際にはまだ見ていません。
本当に素晴らしい1人ではなく2人の安い開発者を雇う。(同じ価格で)
私の例は、NimChimpskyの例の完全な反対、つまり:
市販品を社内で開発しようとしています。
通常、これは実際に市場をチェックして問題を解決するものが既に存在するかどうかを確認できないために生じます。これは、研究を行う前にコーディングに「飛び込む」ことを好む開発者や、その時間=お金を考慮に入れないプロジェクトマネージャーによってさらに悪化する可能性があります。
私の分野で見た最も一般的な例の1つであるWeb開発は、CMSシステムを開発しようとしている企業です。これらは常に小さなものから始まりますが、機能がボルトで固定されるとすぐに肥大化して制御不能になります。その一方で、より適切な無料の製品とフレームワークが常にたくさんあります。
プロジェクト管理専用のリソースはありません
数人のプログラマーが契約したときに何度か経験しましたが、すでに日課が厳しい人はプロジェクトを管理すべきでしたが、実際には他のタスクで忙しすぎたため、プロジェクトは勢いを増しませんでした。プログラマーは「プロトタイプ」などを作成しましたが、リードがなければ、その多くは忙しく見えるように輪になって実行されていました。
新しいプログラマーのための悪い装備
私はかつて、「新しいプログラマーは、ふさわしいと証明されるまで、小さな画面の本当に古いPCで作業しなければならない」という方針を経験したことがあります。そのような政策がネガティブな選択を引き起こし、常により健全な環境で働く選択を常にしている善良な人々を追い払ったことは驚きではありません。
プログラマーをテスター/テクニカルライターとして兼任させることで費用を節約できます
テスター/テクニカルライターの仕事にプログラマーの給与を支払っている場合、お金を無駄にし、その仕事に自分のキャリアを捧げている人よりも質の低い仕事を得ている可能性があります。また、プログラマーが厳しい締め切りテストに直面している場合、ドキュメントはそれを満たすために途中でやめられたり、やめられたりする可能性が非常に高いです。
ところで:開発者は常に厳しい締め切りに直面しています。
製品開発に関係しないコードの調査/読み取り/作成はリソースの無駄です。
一部のプログラマーやマネージャーでさえ、それを信じています。通常、彼らは頭の中の知識に基づいてプログラミングを行い、問題に直面したときに調査を行い、答えを探します。積極的に知識を継続的に改善することはありません。私の意見では、常に最新の状態に保つ必要があり、収集した知識は既存および将来の問題を解決するのに役立ちます。もちろん、そうするために時間を賢く割り当てる必要があります。
これもダンの答えに似ています。一部のマネージャーは、開発者が市場にある既存の製品を調査せずに、要件に応じて製品にすばやく飛び込み、開発することを望んでいます。
多くの場合、オフショアリングにはさらに費用がかかります。私の会社では、新しい従業員のスロットを取得するのは非常に困難です。また、現場の請負業者を獲得するのも難しい。オフショアとオンショアの3:1の比率が維持されるはずです。その結果、多くのチームがオフショアを数十社雇って、ほとんど使用せず、4人のオンサイト請負業者を獲得できるようにしています。
長いフィードバックループ!
それはすべての人に起こります:あなたは素晴らしいと思う何かを構築し、あなたは間違っていたことがわかります。それは問題ではありません。問題は、停止する必要があると判断する前に構築に費やす時間です。
高レベルでは、この問題は長いリリースサイクルで見られます。フィードバックなしで1年間ビルドすると、1年全体でギャンブルをしていることになります。頻繁にリリースすればするほど、ギャンブルは小さくなり、ギャンブルが上手になります。
しかし、それは最低レベルでも起こります。開発者として、コードレビュー(またはペアプログラミング)が頻繁に好きです。誰かが「ちょっと、もっと簡単な方法があります!」同じ理由で、ユニットテストを迅速かつ頻繁に実行するのが好きなので、バグが成長する前にキャッチして殺すことができます。
短いフィードバックループの重要性に気づき始めると、どこにでもそれが表示されます。たとえば、OODAループの軍事概念。
私自身の逸話ではありませんが、無料のコーヒーを開発者に提供しなくなったお店を聞いたことがあります。それぞれの方法で旅行します)、いくつか購入します。
ほぼ偽経済の定義。
2台目のモニターは高価すぎるため、単一画面のワークステーションを提供します。毎年1時間の作業しか節約できないとしても、2番目の画面は依然として良い投資です。私のおかげで、多くの時間を節約できたことは確かです。
マルチモニターのセットアップは、開発タスクだけでなく、ほとんどすべてのタスクをより効率的にすることができます。2台よりも3台のモニターの方が優れていますが、余分な画面があるたびに効果が顕著になりません。
マルチモニターのセットアップ:
格安のハードウェアに与えられたコンサルタントコンサルタントを超える費用150 $ /時間を。
より優れたハードウェアを視野に入れると、少なくとも1日あたりのジョブの効率が30分向上する可能性があります。これにより、30分* 20日間/月= 600分/月= 10時間/月> 1日以上の仕事= 10時間* 150ドル/時間= 1500ドルになります
コンサルタントが1500ドルのコンピューターを持っているとしたら、コンサルタントはより効率的に仕事をしませんか?コンサルタントのイライラを軽減しますか?
問題は、コンサルタント用とPCハードウェア用の2つの予算があることです。
私が疑う最も一般的なのは、マネージャーが単に開発者に仕事を効率的に行うために必要なツールを提供していないことです。
基本的に、ジョエルテストのポイント9 。
「問題に(十分な)遺体を投げる」は、残念ながら一部の場所でまだ使用されています。 ブルックの法則は、この教訓を学ぶために経験を必要とするものもありますが、神話の男月からこれに反論します。一般的に、これは、経営陣が人を追加し、それに代価を払わなくてはならないという誤った声明を信じる可能性があるため、やめる力ではありません。
毎日の会議:
(meeting duration in hours) x (Y team members) x (average salary per hour) = ...
社内で開発するのではなく、既製のソフトウェアを購入する。
私は、人事と生物学研究所の両方に焦点を当てた企業規模管理システムの経験があります。
既製のソリューションの費用は£50〜100,000で、ビジネス要件を満たすためにさらなる開発とカスタマイズが必要でした。
社内で開発されたソリューションは、開発に(6か月未満)かかり、他のプロジェクトも並行して作業され、既に採用されている開発者を利用していました。
私は、社内で開発されたLIMS(ラボ情報管理システム)が稼働している公的部門から、既成のソリューションの実装が1年以上かかり、どこでも完了しなかった大規模な国際的な医薬品に行きました。
(既に雇用されている開発者が他のプロジェクトに並行して取り組んでいるので6か月です。約10kです。これには、既製のソリューションに関連するサポートコストは含まれていません)。主なポイントは、社内で開発されたシステムが実際に使用されていたことです!したがって、それに関連する追加の費用便益がありますが、これは計算できません。
私は基本的なウェブサイトなどに同意しますが、なぜ自分で開発するのが面倒です。ただし、大規模で複雑なシステムの場合、および社内スキルを既に持っている場合は、自分で構築します。
オープンソースの選択肢がより優れており、無料の場合、高価な既製の製品を購入します。
いくつの会社がgitを使用していますか?いくつもの企業が、くだらない企業のバージョン管理を使用していますか?
ええ、それはコードを維持するプログラマーを見つけやすくしますが、採用される最新の流行語を学ぶだけではない優秀なプログラマーを見つけるのを難しくします。ええ、それは個々のビットコードを理解しやすくしますが、2x4とほぼ同じくらい硬直させ、理解する必要があるコードの量を増やします。ええ、それは巨大企業に支えられていますが、巨大企業はゆっくりと官僚的に革新すると言いました。
悪いプロジェクトマネージャー/チームリード。
一人の無能な人には、人々のグループの仕事を台無しにする力があるからです。最終的に、プロジェクトは上位管理者(プロジェクト/チームリード)の決定がなくてもはるかに良くなります。
「すぐにそれを行うだけで、後でリファクタリングします」が決定します。
生産性は創造性よりも価値があります
一般的に、創造性は測定するのが難しく、ソフトウェア開発に関しては、測定することを気にせず、観察することすらほとんど不可能です。一方、生産性は測定することができ(しばしば不十分)、観察することができます。
結果として、(より多くのコード行を書く|質問に応じてテクノバブルをより速く書く|より生産的に見える)開発者は、同じ問題を解決するためにコードの行数を減らす|よりも高く評価される傾向があります。コードを書くのに時間がかかりますが、より信頼性の高い製品を作成する|主題をわかりやすく、わかりやすく、英語で|創造的に解決するのに十分なほど十分に理解してください。
以下のすべては、使用時に不適切であるか、不適切に使用されていないことがあります
外部ソフトウェアと社内ソフトウェア
ISO 9001準拠(エコノミー-製品の品質が低下した場合のMSS損失リスクの軽減)
開発/ QAアウトソーシング
開発/ビルド/リリース/サポート手順
請求できない配送マネージャーが多すぎます。
数年前、私たちの会社ではいくつかの大きな予算プロジェクトが進行中で、採用はピークに達していました。当時、私たちの会社はあまりにも多くのデリバリマネージャーを雇いました(その多くはIT担当者ではありませんでした!)。マネージャーとプログラマーの比率は文字通り1:2でした。その後、これらのプロジェクトの完了後、私たちはこれらのマネージャーの多く(何人かは本物の怠け者)がベンチに座って何もしていなかった状況にありました。会社が誰も解雇する必要がないように、誰も昇給をほとんど/まったく行わない評価サイクルがありました(私たちの勤勉なプログラマでさえ、ため息です)!幸いなことに、同社はこの状況を認識し、今年の第1四半期に適切な評価を行いました。
階層的に組織化された経営管理学士(など)が多すぎて、現代の経営について考えていることを適用しようとしています。「KPI」、「SLA」、およびそうでない人を悩ませ、「レポート」(もちろん、それらを生成するためのインフラストラクチャを気にかけます)、プログラマーが豪華なEXCELシート、Q4レポート、その他のものを埋めて、1つの素晴らしい新しい管理ツールからコピーして別の管理ツールに貼り付ける(それがルールであるようです)これらのツールは互いに統合されたり統合されたりすることはありません)、レポートや数値が提示される会議に出席します(そして、誰もがこのKPIを満たせなかったことに罪悪感を覚えます)。