ある会社と他の会社はどう違うのですか？ 顧客が1つの会社から注文しても満足しているのに、別の会社に気付かないのはなぜですか？ ある会社が1年半ソフトウェアを開発し、別の会社がわずか6か月で管理されるのはなぜですか？ 多くの理由がありますが、それらはすべて1つの機能を共有しています。成功する企業は効果的です。 この記事では、個々のコンポーネントに基づいて企業の効果を高める方法について説明します。
インフラストラクチャとツール
一般的なインフラストラクチャの問題：
-アプリケーションをテストするためのサーバーとモバイルデバイスはありません。
-データベースまたはソフトウェアの必要なバージョンがないか、構成されていません。
-アカウントはなく、サービスはプロジェクト、タスク、会計、顧客会計、注文の管理に使用されません。
このような問題は非常に簡単に解決できます（解決する必要があります）：WebプロジェクトとAPIを展開するには、Microsoft AzureまたはAmazonのアカウントが必要です。すべての一般的な（理想的にはあまり一般的ではない）オペレーティングシステムにテストデバイスが必要です。 ソフトウェアは、サブスクリプション、リース、または（信じられないでしょう！）購入によって入手できます。
プロセス全体の主な目標：可能な限り迅速に、潜在的なクライアントに彼の要求に最初の答えを与えること。 展開と評価に費やす時間が少ないほど良い。
どういうわけか私はサーバーが必要でした。 まあ、私が個人的にそれを必要としていたのではなく、むしろ、私が実施したプロジェクトのために、私たちはそれが必要だったと言うことができます。 私は真のアーリア人のように振る舞い、上司に必要なものとその理由について手紙を書きました。 短い休止（2週間）後、私は同じことを書くように頼まれましたが、それはただちに行われました。 サーバーの必要性を説得力をもって実証しなかったという手紙を受け取ったとき、もう少し時間がかかりました（約1か月）。 それから私は、原則として、私はサーバーをそれほど必要とせず、ラップトップは一般に過剰であり、私の愚かな要求の重要な活動から注意をそらしたいと書きました。 3か月後、彼らはサーバー（部門の従業員がポルノを保管していた古いコンピューターを使用）を見つけました。もちろん、このアプローチを使用したプロジェクトはしばらくしてから安全に折り曲げられました。
下位レベルでは、時間とひいてはお金を大幅に節約できる、実績のあるツール、ライブラリ、開発環境を使用することが重要です。
部門での作業は本格的です。期限までにほとんど残っていないため、テストサーバーに製品を展開することはできません。 2人のアーキテクト、技術専門家、上級開発者という最高の頭脳がこの問題に困惑しています。 全体の障害はメモリ内にあります-テストサーバーに展開する場合、それだけでは不十分であり、ローカルサーバーでデバッグされるスクリプトにはエラーメッセージがいっぱいです。 これは数日続いており、当局は少しユーモアを失いました。それは、モジュールの1つが正しく構成されていないために、使用可能なすべてのメモリを「詰まらせる」多くのデバッグ情報が生成されることでした。 手動デバッグは、正しいモジュールの識別に役立ちませんでした。 これは、ローカルマシンにインストールされ、5分後にどのモジュールが正常に動作しないかを示す1つのベンダーのデバッガーという特別なプログラムによって行われました。 当局は、問題の解決に対する私のささやかな貢献に感謝し、数日後にすべての開発者向けにこの製品のライセンスを購入しました。
自動テスト、継続的統合、リモートデバッグ用のツール、環境とイメージを展開するためのスクリプトは最初は困難ですが、後で非常に効果的な実践を行うことで、作業の一部を自動化し、ルーチンを取り除き、迅速に初期段階で問題を見つけることができます。 多くの企業はすでに自動化の重要性を認識しており、関連する欠員をオープンし、自動化のために従業員を準備しています。
私たちは、十分に大きい顧客向けに新しいプロジェクトを作成し始めました。 CI用にサーバーを構成し、バージョン管理システムをテストして展開する必要がありました。 すべて問題ありませんが、サーバーはありませんでした。 サーバー（または少なくとも通常のコンピューター）を提供するよう要求する書簡が当局に書かれました。 2週間後、別の手紙、1か月後-別の。 返品は「なぜサーバーが必要なのか」というスタイルで行われました。 2か月後、通信がIT企業でのハードウェアとソフトウェアの必要性の理論的議論に変わったとき、古いハーフワーキングコンピューターが見つかり、それがそのサーバーになりました。 ただし、ご想像のとおり、「下から」の取り組みでさえ、このプロジェクトを失敗から救うことはできませんでした。
そして、はい、ツールはあなたの会社のレベルと一致しなければなりません。 Google Doxを使用して100人と20のプロジェクトを管理することは可能ですが、困難です。 一方、5人で作業する場合は、Sharepointをインストールすることもできません。 あなたは常にあなたの頭と現実と友達になる必要があります。
専門知識
現在、独自の専門知識は、まれな専門技術または新しい技術（Tizen、Xamarin、Unity、AutoCAD）、ドメイン領域（銀行向けモバイルアプリケーションの開発）、または専門分野（Wordpressの高速化、UIテストの自動化）です。 特定の主流の言語、技術、またはCMSの知識は、競争上の優位に立つことはできません。
見込み顧客は、他のすべての条件が同じであれば誰に、ウェブサイトに示されている25のプログラミング言語とテクノロジーを持っている会社に行くのでしょうか？ 答えは明らかだと思います。 公平に言えば、多くの顧客が、エスキモーに雪を売ることができる広範なポートフォリオ（そのタスクに関係しない）、有名人、および専門的な販売を購入することに注意する必要があります。 しかし、今はそのような顧客について話さないでください...専門化は、追加の努力とマーケティングなしで会社を配置する効果的な方法です。
Remout
世界は変化していますが、すべての企業が急速に変化しているわけではありません。 仮想世界の州境は長い間消去されており、人々は自宅からでも、セーシェルのバンガローからでも働くことができますが、それを使用しないのは愚かなことです。
どのくらいの頻度で従業員を探す必要がありましたか？ まあ、あなたがマイクロソフトやグーグルのような国際企業であるか、キエフ、サンフランシスコ、ロンドンといった大都市にいるなら。 そして、あなたが小さな町に住んでいて、狭い専門分野を持っているなら？ この場合、唯一の正しい決定は、遠隔地の人々と協力することです。 「リモート従業員」と「フリーランサー」は異なる人なので、私は「フリーランサー」とは特に話しません。
従業員がfi罪することを心配していますか？ 時間の追加が心配ですか？ 悪い知らせがあります。仕事と労働の量を適切に評価する方法がわかりません。 真実は、何もしないという目標を設定した従業員が、たとえあなたの側に平等にいても、少なくともリモートでフィロインするということです。
そして、遠隔地の従業員に慣れていて信頼していないという理由だけで別の都市や国への移転を主張する企業は、私に心からの誤解を引き起こしています。
一般的に、Remoutの本を購入し、読み、心配をやめて生活を始めます。
コミュニケーション
おそらく最も簡単で最も難しいアイテムです。
一方では、コミュニケーションの欠如は悪いことであり、他方では、多くのコミュニケーションも助けにはなりません。 終わりのない集会、25人への対応、その他の「コミュニケーション」の喜びについては、すでに沈黙しています。
彼らが言うように、あなたは何をすべきかわからない、集会を行う。
私たちの時代の集会の有効性は、特に抗議者の数が3人以上の場合、大きく上回っています。 8時間の勤務時間外に、6時間が集会で占められていた日がありました。 この2つはそれほど重大ではない問題を解決しますが、何人かはそれをすべて聞くことを余儀なくされます。
しかし、これはおなじみですか？ 時間追跡システムに時間を入力し、プロジェクト管理システムのタスクに費やした時間を入力し、ドキュメントとガントチャートを更新し、夕方には日報が届きます。10：00に、あなた、私の友人、昨日、私がやったこと、そしてあなたが今日レポートとラリーを記入することの間であなたがすること。
サムライコーデックス
顧客との関係がどのように見えるべきか、また会社自体の中でいくつかのルールと推奨事項があります。
1.普通の従業員はそれぞれ上司を2人以下にする必要があり、タスクと実装の時間は互いに矛盾してはなりません。 そうしないと、従業員はタスクの優先順位を独立して決定することを余儀なくされ、必要な情報と知識がすべて不足しているために、高い確率で間違ってタスクを実行します。
2.プロジェクトでは、各チームメンバーは自分の役割（または役割のリスト）と、顧客側の各人の役割を知っている必要があります。 言い換えれば、チームの各メンバーは、誰が最終決定を下す権利を持っているか、誰がプロジェクトを引き受けるか、誰が推奨事項であり、誰が拘束力があるかを知る必要があります。
3.プロジェクトの種類ごとに、TKを最初から高いレベルで概説するために、準備された質問のリストが必要です。 モバイルアプリケーションの場合、このリストは次のようになります：1）どのプラットフォームとその最小バージョンをサポートする必要があるか2）既製のAPIがあり、そうでない場合はいつ準備するか3）実装会社はアプリケーションの公開/サポートに参加し、など
4.作業指示書の明確さと詳細は、顧客の明確さと妥当性に依存する必要があります。 顧客が必要なものを明確に知っている場合、技術仕様は最小限である可能性があります。 顧客が泳ぎ、しばしば気が変わった場合-TKは可能な限り詳細にすべきです。 新規顧客に対する態度は、現在の顧客よりも重要である必要があり、意思決定の妥当性と速度をテストする最善の方法は、前払いを取得することです。 作業プロセス全体をテストするのはこの段階ですが、ミニチュアです。 そして、この段階で困難がある場合、それは将来困難を避けないことを意味します。
5.マーフィーの法則、誰もが知っていることを願っています:-)覚えておくと良いことはさらに2つあります。 1）パーキンソンの法則1：仕事はそれに割り当てられた時間を満たす。 したがって、パーキンソンによると、チームが1年間プロジェクトを作成できる場合、その年を作成します。 2）パレート法（またはパレートの原則）：努力の20％が結果の80％をもたらし、残りの80％の努力は結果の20％しか与えません。 3）予算とプロジェクトの条件の再評価の場合、エラーの価格は直線的に増加し、過小評価の場合は指数関数的に増加します。 4）9人の女性が1か月以内に赤ちゃんを産むことができず、最大圧迫限界は25％以下です。 さらに-残業と全体的な効率の低下のみ。
まとめ
結果はあなたを驚かせるでしょう：プロセスの効率に応じて、同じ人の生産性は2-5倍変化します。 そのため、中小企業は企業や大規模なボディショップよりも常に効果的です。 プロジェクトを競合他社の2〜3倍高速化するのはプロセスの効率です。 そのため、「効果的な」従業員の1時間のコストはボディショップのコストよりも高くなりますが、最終的なプロジェクトの価格は常に低くなります。