1C、痛みなし

私の人生では、1Cフランチャイジーとクリスマスツリーの売り手という2つのタイプのビジネスが他の誰よりも悪い状況で発展しているのを見てきました。 プログラマの数が増えているときの開発の幅に関するものではなく、内部開発に関するものです。 要するに、有効性についてです。

おそらく、クリスマスツリーの売り手はこのリストから除外することができますが、正真正銘のモミを売って新年の前に私を驚かせることができました。 以前は、モミと松の木だけがありました。 私はインターネットでモミと木を区別する方法を見ました-本当に、それはトウヒでした。

そのため、「最も発展途上の企業」のリストに残っているのは1Cフランチャイジーのみです。 多くの素晴らしい人々がそこで働いていますが、環境はこのようなものであるか、場所は気の毒です-彼らに何かが間違っています。

彼らは今日のことだけを考えています。 おそらく、フレームワークとアプリケーションの両方のソリューションを開発する1つのベンダーとの緊密な結びつきが原因であると考えられます。 21世紀には、正しい言語の誰もが、1つのプログラミング言語、1つの開発環境、1つの市場に結び付けられた長期ビジネスを構築することはありませんか？ しかし、熱いうちに鉄を鍛造してください-お願いします。 クールダウンしたら、何か深刻なことを考えることが可能になります。

しかし、何らかの理由で、すべてが失われているわけではないように思えます。 あなたはもっとうまくやることができます。

もちろん、効率を上げるさまざまな方法は興味深いものです。 しかし、特定のアクティビティに対するこれらのメソッドのはるかに興味深い組み合わせは、ケースです。 プロセス、動機付け、自動化、目標、管理システムが含まれます。 必ずしもすべてのコンポーネントが一度に必要なわけではなく、必要なものだけです。

私たちがよく知っているビジネスの特定の部分のケースを作成してみましょう-1C：フランチャイジー。 彼は他のフランチャイズで数年間働いた経験があるので、私たちに馴染みがあります。さらに、私たちは常にフォーマルでインフォーマルな環境でフランに出会います。

累積的な経験に基づいてケースを策定します-私たちが書いたほとんどすべてのものは、私たち自身でテストされています。 私たちは、純粋に学問的な関心を誰にも納得させません。 ただし、このケースをサービスに導入した大規模なフランがあり、彼ら自身がそこに何かを紹介しています。

1C：フランチャイジーが何であるかわからない場合は、ソフトウェアの開発、保守、改良のためのサービスを提供する特定の会社について話しているかのように読んでください。

このケースの目標は単純です-プログラマーの生産と、可能であれば収益を増やすことです。 または排気、彼はさまざまなオプションがあります。 行こう 私はあなたに警告します-Longrid。

初期状況

フランチャイズ全体ではなく、その一部を取り上げます。これを開発部門と呼びます。 これらは、オフィスに座ってシステムまたはコンサルタントからタスクを受け取り、結果をコンサルタントまたはクライアントにリモートで渡すかどうかを決定する1Cプログラマーです。

大規模なネットワークフランチャイズにはこのような部門がいくつかあり、それらの間には競争があり、十分なリソースがない場合は、専門家やタスクを積極的に交換します。 おそらく彼自身の自由意志ではないかもしれませんが、これはポイントではありません-私たちは、開発部門をビジネスユニットと見なし、「本物のプログラマ」の束とは見なしません。

開発部門が5人で構成されているとします。 合計月間平均出力は500時間です。 これらのうち、200は特定のチャンピオン（最も経験豊富で知的なコーダー）によって閉鎖されています。 2番目は100時間、80は3番目と4番目、40は初心者です。

クライアントの1時間の作業に2000ルーブルの費用がかかるとします。 プログラマーの内部レートは1時間あたり500ルーブルだとしましょう。 単純な見積もりでは、部門の収入は月100万ルーブルで、部門の給与は収入のわずか25％、この場合は25万ルーブルであると言われています。 合計で、同社は75万ルーブルを受け取り、そのうちプログラマは同じプログラマーに税金を支払います。 利益構造を考慮せず、単に非線形であることを理解するだけです。 オフィスのレンタルやCookieの購入などの固定費が含まれています。

たとえば、生産は比較的安定しており、あまりジャンプしません。 チャンピオンが休暇をとる場合、40パーセントの失敗がありますが、場合によっては700時間-良いプロジェクトが発生し、プログラマーが週末に働いている場合もあります。

事例目標

すぐに、ミステリーを作成しないようにケースを使用する目的を説明します。 私たちは、開発部門に毎月500時間ではなく、1000時間を配布したいと考えています。 二倍。 同じ時給、同じ固定費、同じ労働時間数の場合。 このプロジェクトには、たとえば30〜50兆ドルなど、わずかな時間の費用を許可できます。

ターゲットの状況で何をするかをすぐに決定することが重要です。 一方では、スペシャリストの時間、つまり問題の解決に費やす時間を販売しています。 一方、解決したタスクを販売し、数時間で評価します。 すべてがはっきりしているように見えますが、2つの評価システムの違いは非常に重要です。

1か月あたり500時間は、スペシャリストの500時間の実作業時間だとしましょう。 これらの500時間で、彼らは、例えば200時間の問題を解決し、平均価格は2.5時間です。 各タスクには平均5000ルーブルの費用がかかることがわかります。 クライアントはその種のお金を支払う準備ができており、市場を知っています。残りのフランチャイズも同じ価格です。

そして、私たちは2.5時間ではなく1.25時間で問題を解決することを学びました。 重要な質問は、どれだけクライアントに販売できるかということです。

時間を売るなら、1.25時間売ることは理にかなっています。 クライアントは非常に満足しています-安くて速く。 しかし、私たちにとって、ビジネスとしては、そのようなスキームの恩恵はほとんどありません。満足しているクライアントと、何かを必要とするスペシャリストの自由時間だけです。 より多くの顧客を見つけ、1.25時間タスクを販売したとします。 その結果、1か月以内に何が得られますか？ 2000ルーブルと同じ500時間。 意味がありません。

1つのオプションは、時給を上げることです。 しかし、競合他社よりも早く問題を解決できますか？ 小さな仕事では、誰も特にこれに気づきませんが、40時間のタスクでは、違いはすでに顕著です。

しかし、1時間の価格は、私たちからの新しい顧客を思いとどまらせることができる外の世界にとって顕著な変化です。 彼らは私たちが2倍の速度で何をしているのか知らないのですか？ サイトに書かれたスローガンは特に説得力がありません。

タスクを2.5時間販売し続ける方がより正しいようです。 クライアントは何も気づかず、通常の目標結果を取得します。2倍のタスクを実行すると、2倍のお金が​​得られます。

妥協オプションを選択できます-たとえば、2時間で販売します。 次に、クライアントは目に見える節約を（特に大量に）見、結果をより速く得、私たちは真っ黒です。 さらに、プログラマーの内部レートが保存されていても。

簡単にするために、2.5時間の販売を続ける場合はオプションを検討します。 少し複雑なアルゴリズムを使用して着信タスクを評価します。リアルタイムを推定し、それに2を掛ける必要があります。これについては後で詳しく説明します。

はい、社内開発の強化など、解放された時間を使用するためのエキゾチックなオプションがまだあります。 これは最後になります。

それですべてです。目標は明確です。必要な変更の分析に移りましょう。

重要な問題

彼らは、レバーを挿入して最大の効果を得る必要がある力の適用ポイントが常にあると言います。 私はこれに同意しません-そのような点が常にそこにあるという意味で。 しかし、この場合、それは-モチベーションのシステムです。

私たちの動機付けシステムは、実行された作業の個別の時間給です。

プログラマーには多くの利点があり、ビジネスにはほとんどありませんが、マイナス面はたくさんあります。

専門家には知識と経験を共有する理由はまったくありません。 行う価値がある唯一のことは、あなたのプロフィールを上げることです。 すべてが重要である場合、経験を共有することは禁忌であり、問​​題解決に役立つことはさらにありません。 あなたが愚か者を教えるならば、彼はあなたの競争相手になります、そして、彼はあなたに感謝さえしません。

たとえば、給料（これはそのようなプログラムです）をよく知っていれば、他の人はそれを知りませんが、常にパンとバターを食べます。 2番目の給料が表示されるとすぐに、仕事のほとんどを取得する努力をする必要があります。

これはビジネスにとって何ですか？ 専門家が能力を共有しない場合、トレーニングの世話は会社の肩にかかっています。 コースを編成するか、サードパーティの組織（1Cなど）に支払う必要があります。 2つ目は、主要な専門家という形のボトルネックです。 5人のうち1人だけがERPを知っている場合（これもそのようなプログラムです）、この従業員が消化できる以上のERPジョブを物理的に取得することはできません。 たとえチャンピオンであっても、月に200時間を超えることはありません。 まあ、どちらかリスクを取る-途中でそれを理解するために仕事を取る。

コンピテンシーを共有することは不可能です。 可視性を行うことができます。 しかし、誰がプログラマーであったかは、あなたがそれについて連絡されないように支援を提供する方法があることを彼は知っています。 チャンピオンにセミナーやトレーニングを実施させることもできます。 彼は、インターネット上で非常にアクセスしやすい資料を正直に報告します。 彼は本当の、実用的な知識を自分に任せます。

個々の時間料金は、ビジネス内のビジネスのようなものであり、この「内部ビジネス」は、LLCではなく、常にIPです。

そして、特に定期的に起こる変化の時代では、能力が重要です。 もちろん、数年で小康状態があります-たとえば、ERPのリリース前に、誰もが既にソフトスターターを理解している場合（これはプログラムでもありますが、元気があります）。 しかし、たとえば2004〜2010年には、SCPに関する知識を持っている「プロジェクトエンジニア」が何よりも優れていました。 おそらく、おそらく、ERPの専門家は他の誰よりも優れた生活を送っています。

個々のピースワークは、作業ソリューションとベストプラクティスを共有する能力を失います。これもまた意味がないからです。 まあ、あなたはその人にあなたの処理またはサブシステムを与え、彼は1日でクライアントと合意して40時間閉じ、20 trを上げました。 どうしたの？ もちろん、同意して部門内に闇市場を作ることはできますが、それは意味がありません。 「タスクをください、解決します」と言う方が簡単です。 もちろん、絶望的な状況では、彼は与えますが、原則として、彼はそれを自分自身に任せます。

コンピテンシーを異なる方法で見ることができます：所有者は誰ですか？ あなたのチャンピオンが2010年から会社にいたとしましょう。 彼はERPで多くの作業を行い、能力を獲得しました。 彼らは誰のものですか？

会社は言う-彼らは私たちのものです。 お客様、プロジェクト、タスク。 コンピテンシーを与えます。 それらをピックアップするには？ ダニを引っ張らないでください？ これは有形の資産ではありません。 彼はびっくりし、能力が叫んだ。

そして、コンピテンシーとは何ですか？ 製品。 かどうか、製品の販売からの収入。 ERPによって200時間出荷され、2つの利益を受け取りました-400 tr と能力。 お金-もちろん、ここでは、現在の口座にあります。 譲渡、支出、投資することができます。 そして、コンピテンシーはどこにありますか？ あのaldげ頭で。 それらで何ができますか？ 実際、何もありません。

その男は私たちの費用で学んだことがわかりました。 彼のトレーニングにお金を投資したわけではありません。 しかし、私たちはこの利益をただ1つの方法で得ることができます-これらの能力を活用し続けること、すなわち すべてのERP作業を単独で実行します。 さて、またはチャンスを取り、別の回復不能なリソースを取得するために初心者を置きます。

このような状況の理由はつまらない-間違った動機システムです。 それは奨励しないということではありません-それは人が能力を共有することを直接禁止します。

動機付けシステム-それは何のためですか？ そのため、自分自身の自由意志で、すべての熱意をもって、会社にとって有益なことを行います。 モチベーションシステムは、毎日何かを指摘し、歩き、蹴り、指摘しようとするリーダーに取って代わります。

自分の自由意志の人が会社にとって何が有益であるかを確認する方法は？ まず、もちろん、会社にとって何が有益かを理解することです。 第二に、会社の利益がその人にとって有益であることを保証すること。 ミッションやスローガンの形ではなく、実際に。

ケース

このケースでは、目標を達成するのに最適な方法を選択しました（出力を2倍にする）。 一般に、もっと多くの方法がありますが、ここでは執筆に従事するのではなく、行為に従事します。 また、出力を2倍にするために、すべてのメソッドを実装する必要はありません。多くの場合、1つで十分です。

特定の会社の初期条件の違い。私は何も知りません。 おそらく、従業員あたりの生産量が最も低い世界で最もモロミックなフランチャイズがあります。 あなたはこのフランチャイズからではないので、あなたのメトリックは高くなります。 しかし、どれだけ高い-私にはわからない。 しかし、出力を2倍にできるという事実は事実です。

それで、あなたがする必要があること：

• 初期バランスを選択し、自動化し、評価システムに追加します。
• コンピテンシーシステムに初期バランスを自動化して追加します。
• 動機付けシステムに関する決定を行い、自動化します。
• コンピテンシー戦略のパラメーターを選択します。
• 職務官を任命する。
• プログラマーに相談してください。

行うには：

• 着信タスクの一般的な議論。
• 戦略に従ったコンピテンシーによるエグゼキューターの選択。
• 相互支援の管理と会計。
• タスクのステータスを管理します。

次に、各項目の概要を簡単に説明します。 しかし、最初に、自動化の説明。

自動化

ケースのほとんどすべてのバリエーションに存在するポイントは自動化です。 プロセス、管理、およびモチベーションに加えるすべての変更は、迅速に自動化する必要があります。

「高速自動化」は非常に高速です。 日中（データベース構成を更新する機会を待つことを含む）。 ここからすぐに、同じチームの力でこの自動化を実行する必要性が浮かび上がり、その開発が増えています。 あなたが大金持ちで、内部の自動化の対象ではない別の部門がある場合、幸運ではありませんが、解決策があります-秘密の自動化。

ケースにあるすべてのものについては、膝の上に自己記述された構成で十分です。 その後、いつか、あなたはそれを改善し、あなたの企業システムに組み込み、人間工学に基づいたインターフェースを作ります。 今、私たちは可愛さと便利さなしで、ほとんど裸のデータが必要です。 したがって、共通システムを完成させるアクセス権がない場合は、独自のシステムを作成してチーム内で共有してください。

タスク管理システムが1Cでない場合、残念ながら、あなたは幸運ではありません-おそらくそれを捨てなければなりません。 または、1Snoyのプロキシとして使用します。クライアントがスタックしている場合は、そこでタスクを実行させますが、現時点では、1Cで自分でシステムを作成し、データをアップロードします。 そうでなければ、何も動作しません-bitrix24、JIRA、Github、および他のシステムの開発者は、申し訳ありませんが、彼らはあなたのニーズをくそったかったのです。 追加する場合。 ここでもタスクにプロパティを追加できますが、表形式の部分はほとんどありません。さらにレポートもそうです。

隣同士に座っている社内チームの作業を自動化するために、悲しいかな、最高のプラットフォームは1Cです。

グレーディングシステム

新しいグレーディングシステムが必要です。現在、2.5時間で行うタスク、1.25時間で行う必要がある、2.5時間で販売する必要があります。 ターゲット状態のタスクには、2.5時間と1.25時間の2つの評価があります。 1つは時間の真の投資であり、もう1つはクライアントに対する特定の評価です。 現在、現在の状態では、これらの推定値は（平均して）等しいと考えています。

個人的には、1つのユニット（時間）で2つの評価を維持するのは好きではありません。 誰も彼女を好きになるかもしれないと思うのを止めることはできません。 実際には、さらに多くの見積もりがあります。クライアントのクロック、計画中にプログラマーによって呼び出されるクロック、クロックは実際のものです。 それをすべてまとめて、どういうわけか分析する方法-悪魔は彼を知っています。

スクラム-ポーカープランニングのシステムをお勧めします。 各タスクは、フィボナッチシリーズから取得したポイントで評価されます-1、2、3、5、8、13、21、34など。 評価は、このタスクの包括的なビジョン、実行の複雑さ、人件費、不確実性、および仕事の引き渡しにおけるクライアントの問題のある性質を反映しています。

「アンカー」から始める最も簡単な方法は、1ポイントのタスクがあることを確認することです。 これは、解決する最も単純でアトミックなタスクです。 したがって、2ポイントのタスクは2倍困難です。

着信ストリームの処理時に推定が行われます。 新しいタスクが表示されたとき。 チームの各メンバーが自分のマークを付けます。その結果、5つのマーク（私たちが説明した例の場合）があります。 系列の複数の要素によって発散する推定がある場合、そのような大きな違いがある理由について話し合い、理解する必要があり、それを排除するために、一方が過大評価されているか、他方が過小評価されています。 すべての不一致が解決されると、平均が評価されます（評価の合計を評価の数で割った値）-問題の評価になります。

「上から」システムを実装する場合、投票を手配するのではなく、自分で評価を行うことはかなり可能です。 スクラムはありません。自分でルールを作成します。

問題を解決する過程で、推定値が過小評価または過大評価されていることが明らかになった場合は、安全に変更できます。 もちろん、タスクが終了するまでに、最終的な成績を知る必要があります。

評価はシステムに入力し、小道具タスクの形式で保存する必要があります。

ポイントが気に入らない場合は、何らかの標準時間を使用できます。 このオプションはお勧めしませんが、私の意見は無視できます。 例えば、練習の夜明けに、私は「最高の」などの評価を思いつきました-最高のプログラマーが問題、コンテキスト、クライアント、機能などを知るのに何時間を費やすでしょうか。 -コードを書きます。

ここで、初期バランスを入力することが非常に重要です。すでに解決した1〜2か月のタスクを評価し、システムで見積もりを行うことが重要です。 まず、独自のグレーディングシステムを実践して開発します。 第二に、そして最も重要なこと-現在の速度と「ポイント価格」を取得します。

たとえば、2000ルーブルで月に500時間売ると、これは500ポイントになります。 その後、現時点でのスコアは2000ルーブルです。 変更の導入後、1000ポイントを生成し、2000ルーブルで販売し、2倍の収入（会社と従業員の両方）を受け取る必要があります。

最初の残り物は非常に重要です。なぜなら、それらなしでは基本的な質問に答えられないからです-それはうまくいったのでしょうか？ 怠けないでください。

古いタスクを評価するのではなく、新しいタスクから始めるのは魅力的です。 残念ながら、変更のダイナミクスにより、1か月で生産が2倍になり、1か月で見積もりを処理する方法を学ぶことができます。 この場合、同じ量のダブル出力を販売します-自分を欺く。

「上から」システムを実装する場合、理想的なオプションはプログラマーから初期バランスの入力を密かに行うことです。

コンピテンシーシステム

コンピテンシー会計システムは、一般的でないのと同じくらい重要です。 もちろん、証明書の数の記録はコンピテンシー会計システムではありません（証明書もコンピテンシーではありません）。

コンピテンシーは階層的なガイドです。 その構造と詳細は、ニーズとハードワークに完全に依存します。 データを入力することで苦しむので、挽く必要はありません。 コンピテンシーであなたにとって何が重要か、本当に知っておくべきことを決めてください。

コンピテンシーの会計には、タスクと個人という2人のアナリストしかいません。 ディレクトリに記入する際にガイドされます-システムが発行する「タスクに必要なコンピテンシー」とシステムが発行する「コンピテンシー」の質問への回答はあなたに合っているはずです。

技術と方法論という2つの主要な部分にコンピテンシーを分けました。 テクニックはプログラミングとプラットフォームに関するものです。 たとえば、外部データソースの操作、bitrix、または複雑なデータ構成スキームとの交換。 方法論-これらは特定のサブシステム、ドキュメント、および会計のセクションです。 たとえば、SCPの1か月の締め切り、予算編成、注文管理、生産スケジューリングなど。 あなたは私の経験を使用することができます、あなた自身を作成することができます。

情報システムでは、タスクオブジェクトに表形式の部分（コンピテンシー）が表示されます。 ディレクトリの要素をリストし、評価を付けます。 どのような評価-私は知りません、それはあなた次第です。 私自身がユニットを配置し、10ユニットのセットの後、能力に自信があると考えました。 興味を設定し、100％が得られればコンピテンシーを確認することができます。

その後、すべてが明確です。 古い解決済みの問題の残高を入力できます。 すべての新しいタスクでは、このtab.chastを埋める必要があります。 まあ、少し後で、プログラマーが花びらの図とコンピテンシーに関する一連のレポートを描くようにする必要があります。

特定の「コンピテンシープラン」をシステムに追加できます。このプランでは、開発の優先順位と各従業員の適切な能力レベルをリストします。 さて、計画の事実が行うレポートに加えて。 コンピテンシーの成長のばらつきを見るのは特に興味深いです。あなたのチャンピオンは、現在、クライアントの間で人気のある主要な、または唯一の調査地域でのみ働く可能性があります。

そのようなシステムは、問題を解決することで確認された真の能力のみを測定します。 インタビューでの証明書、コース、おとぎ話-これは私たちに関するものではありません。

モチベーションシステム

このアイテムは上司専用です。 原則として、プログラマーが実際に仕事の割合を受け取ったときの作品の動機付けシステムは、（他の職業の動機付けシステムと比較して）まったく受け入れられます。 しかし、本書の冒頭で述べた欠点があります-それは個人主義を助長します。

いくつかの解決策があるかもしれません;私は最も簡単なものを提案します-KTU。 タスクに必要な「請負業者」があり、それに表形式のセクション「請負業者」を追加する必要があります。そうすると、すべてが適切に配置されます。

詳細tab.party-従業員と割合。 したがって、タスクの料金は1人ではなく、数人（通常は2人以下）になります。 金額は同じで、パーセンテージで割っただけです。 会社は過剰に何も支払いません。

このようなシステムは、売り手の間でよく見られます。たとえば、一方が顧客を引きずり、もう一方が取引に伴った場合です。

私たちの場合、KTUを使用する主な動機は、チャンピオン、そして実際にはすべての人を協力して「促進」することです。 人に仕事があり、技術、技術、またはすべてを一度に熟知していないとします。 しかし、彼は他の男が同様の問題を解決していることを知っています（または彼は知りませんが、コンピテンシーに関するレポートを見たなら確信しています）。

その2つ目は助けになると思われるが、「兄弟愛で助ける」ことを除いて、彼には理由はない。 請負業者は、最終的に2時間で解決できますが、タスクに10時間を費やすことができます。

今では違います。 請負業者は「知る」ことに近づき、協力を提供します。 「知っている」と言う-数時間のビジネスがあります、私は例を持っています、私は少し終える必要があり、それはそれです。 いくらですか？ -パフォーマーが尋ねます。 さて、40％で-「知る」と言います。 請負業者は同意し、15分でチップと教育プログラムを取得し、同時にコード例を取得し、2時間で問題を解決し、500ルーブルを取得します。 x 2時間x 60％= 600ルーブル、つまり このセグメントでは、彼自身のために、彼は1時間あたり266ルーブル（2.25時間で600ルーブル）で働きました。 私がそれを自分でやった場合、それは1時間あたり100ルーブルで動作します（私は10時間を費やし、1000ルーブルを取得します）。

「Knowing」は1時間あたり1600ルーブルで動作しました（15分を費やし、400ルーブルを受け取りました）。 それが彼が知識がある理由です。 通常の仕事、すなわち 彼は彼の労働と時間を1時間あたり500ルーブルで、彼の本当の知識を1時間あたり1600ルーブルで売っています。 誰も赤ではなく、ほとんどは黒です。 クライアントは、お金を失うことなく、すぐに決定を受け取りました。 会社は金銭的な損失はなく、2人の満足した従業員と1人の満足した顧客を受け取りました。 パフォーマーは耳に満足しており、知識豊富な、最終的に、自己教育への投資から配当を受け取るようになりました。

すべての割合が異なることは明らかです。 時には知識のある人が説明するのに1時間、時には1分かかることがあります。 請負業者も、2時間以内にそれを行い、5時間後にはそれを行います。 しかし、それにもかかわらず、平均排気量はプラスであり、非常に重要です。

私の意見では、主なことは、プログラマーに興味のある分布を完全に与えることであり、それに干渉することではありません。 彼らに同意させてください、彼らは大人です。

2番目に重要なことは、あなたがボスである場合、チャンピオンからこれらの「無料」の時計を受け取ろうとしないことです。 結局のところ、請負業者にのみ支払うような誘惑があり、愚かさの係数が減少していてもです。 刊行の初めに、給与の割合は変わらず、プラスでもマイナスでもないことに同意しました。 関心を維持し、生産を倍増させながら、同社は独自の道を歩むことになります。

コンピテンシー戦略

真の能力会計システムを作成したら、その使用方法を決定する必要があります。 基本的に、2つのベクトルがあります。タスクを実行する方法を知っている人と、方法を知らない人にタスクを配布します。

最初のベクトルは、最大のソリューション速度を提供しますが、能力の開発は提供しません。 2番目のベクトルは、最小の決定速度を提供しますが、能力の最大の成長を提供します。

最良の方法はベクトル間のどこかにあることは明らかです。 一方では、私たちには大学ではなくビジネスがあり、能力だけに対処することはできません。 , , , .

, . : . – , , , , .

: 70 % – , 30 % – . , . , . , , .

, – , , , ? 悲しいかな。 -, . -, . , , . « » – « — ».

, , – , , . , – . . -, , . , , .

– , , . , – , .

«», , , . – , , , . – , , - . .

– , . , – – .

, , . , - «, , , . , . , , . , . „ “? ? , , , , 9-00 . , . – , ».

– , ( ). .

. , . , , , , . , , , . , , , , , .

- , . 5 15 . , – .

– , , . - , . . , . , , « ».

, , . 1 – , . , , . , , – , , , – - «», , . 1 , - .

, , - , , . : .

– . , , . , – , , . .

, – , . , , . , « », - .

, , , - . , , , , .

. , , – , – . , , .

– , ? 何のため？ , ? ? - ? , , , . , - , ?

, , – . , , . , .

, -, 1? . , , .

1. , , , ( – , , ..)? 100 %? 50 %? 20 %?

, 3 %. , – . – , , . .

– , ? , . , , , , .

, . , , . 50 , . , , . 8 .

: ? , 5, ? , , , .. , ? ? , , . 16 .

, , . 別の例。 , , , 10-20 – : , . 次に何が起こりますか？

. ( ), - – . – , .

: , , – , . , – , , , , . , . 15 . 10-20, ? 5 ?

, , . , , , – , , . .

, . – 50%, .. - , .

, , . , , – , . , , , – . , ! – .

, , . , . ? – , . – . . , , « ». , .

, , , . , – . «» , «».

: , . , ( EDT), .. , – . , .

, , , . .

– , , . – – , . – .

– 1? – . , , 5 . ? : . , , – , . – , 5 , . , . ? , , ? – 13 , , .

, – ( , ) - . , .

. , – , , , . , . – .

, . , , – , .

. , , , .

, – - . , , – , . , , .

, – , , , . , – , , . .

, , – , . : . . , , , – , .

. , , , .

, – .

. – . .

, , 30 % . , – , . , , .

, . , , . , : , , .

, . – , , «, , ». , , . , , .

« » , . : . , , . , , 1 , .

– , . , . – « », , , – . , – , ( , ).

, , , , . , .

, – . .

, , , , . , – , .

. , , – .

, .

このトピックについては別の記事がありました。すべてを繰り返すわけではありません。 ちなみに、この記事は1Snikovにはあまり興味がありませんでしたが、開発者の他の種族の代表者はそれを気に入っていました。 これは、1Cプログラミングの世界では、これまでのところ、すべての方法が効率を上げる方法に適しているとは限りません。

職務責任者を選択したら、上記の記事へのリンクを伝えます。 彼が理解し、受け入れ、満たす必要がある主なことは、彼がタスクのステータスを監視する必要があるということです。

毎朝は、儀式から始めるべきです-タスクのステータス管理。 非常にシンプルで自動化が簡単です。 最初のウィンドウ-まだ機能するようになっていない新しいタスク。 これは、上記で検討したチームとのディスカッションリストです。 ディスカッションの結果は、このウィンドウを空にすることです。

2番目のウィンドウでは、タスクは作業に受け入れられましたが、エグゼキューターはありません。 一般的な議論の後、同じ方法で空になりました。 議論の後、両方のリストが空になるはずです。 タスクのステータスが「仕事に受け入れられない」および「エグゼキュータが割り当てられていない」状態になるまでの許容時間-1営業日以内。

タスクが明確ではなく、顧客の明確化が必要な場合-タスクは、質問のリストとともに、ウィンドウ/ステータス「Clarification required」または「Send for revision」に移動します-何を指定してもかまいません。 決定論は重要です。

ディスカッションの後（またはその前）、アテンダントは、ステータスの遅延がないように、改訂のために送信されたリストをチェックします。 たとえば、声明を明確にするために3日間が割り当てられます。 3日が経過しました-速度が低下しないように、お客様に連絡する必要があります。 おそらく、彼は単に答えるのを忘れていました。

プログラマーとの議論の中で、「作業中」ウィンドウを見ます。 ランク付けされています。誰が誰がどのタスクに従事しているかを理解しています。 したがって、タスクが請負業者に関連付けられた「作業中」ステータスになる時間があるため、この時間を監視する必要があります。

トライト-初心者のための知識の時間の境界を見逃さないために。 彼らが彼に独立した決定を下す日を与え、その日が過ぎた場合、彼は高い確率で手を挙げず、彼が対処できないとは言わないでしょう。 最後までバカになります。 これは必要ありません。そのため、ステータスの有効期間を平凡に制御することで、不必要な損失や愚かさに対する罪悪感から私たちを救うことができます。

最後のウィンドウ-顧客からの承認を必要とする完了したタスク。 ここでの原則は、修正のために送られたものと同じです。たとえば、3日間の期限を設定し、その後、自分自身に思い出させ始めます。 落ち着いて、自信はあるが、しつこい。 繰り返しますが、顧客は単に自分のビジネスを十分に持っていることを忘れてしまいます。

ファイナル

それで終わりです。 議論された主な数字は、作業単位の本質的な価値、すなわち ポイント。 私は、このコストを半分に削減できると主張しました-半分の時間で同じ量の作業を生成します。

クライアントの1つ（現時点で重要なもの）のスケジュールは次のとおりです。



ご覧のとおり、ケースを適用する前（4月まで）、ポイントの値はほぼ同じレベルでぶら下がりました。 これは、同じ時間を費やして、同じ量の結果を生成したことを意味します-0.9時間で平均1ポイント。

ケースを使用した最初の1か月で、ポイントの値は急激に低下し、0.22時間で、約4倍になりました。 もちろん、最初の1か月は考慮に入れる必要がありますが、仕事の提供に急激なジャンプがあったため、完全に信頼することはできません。

2か月目はより示唆的で正確です。 まず、終了する古いタスクはもうありませんでした-5月に終了したすべてのタスクは、過去2か月で生まれました。 ケースの使用中。 次に、ケースの使用が落ち着き、習慣になりました。 結果-1ポイントで0.33時間で、ケースの3倍です。

さて、その後、図は約束された平均の半分にぶらつき始めました。

もちろん、このクライアントだけでなく、一般的なすべての作業についても肯定的な結果が得られました。 を含む-私たちは多くを持っている内部で-外部の顧客よりも。

たとえば、これは獲得したポイントの合計数のグラフです。



ご覧のように、このケースの前に、1か月あたり平均400〜500ポイントを配ったところ、この数値は1400に増加しました。これは3倍の増加です。

両方のスケジュールは、残念ながら10月に中断されます。以前はgithubでタスクを実行してから、Flowconに移動しました。 2つのソースからの一般的なスケジュールは、怠lazを描きます。

数値の依存関係を理解することは興味深いです。 Oknosoftは、カスタマーサービスに対してほとんど何もしません。開発が優先されます。 ケースを使用する前に、問題が発生しました。顧客にとっては時間がかかりすぎ、開発のためにはほとんど残っていませんでした。

ケースを使用することで、このtrapから抜け出すことができました-まだ十分ではありませんでしたが、開発のためのより多くの時間がありました。 結果はすぐに現れました。私たちにとって非常に重要ないくつかの製品を実装しました。

1つ目は、ビジネスプログラミングプロジェクトのサイトです（リンクは提供しません。さもなければ、「nmivan、始めましょう...」という件名のメールを受け取ります）。 キーワードはサイトです。これは、以前はインターネット経由でのみ動作するビジネスアプリケーションを作成したためです。 このサイトは、metadata.jsプラットフォーム上に構築されていますが、重要な成功は、サイト自体やコンテンツではなく、プラットフォームとそのコンポーネントの改良です。 また、metadata.jsでサイトを作成することもできます。 さらに、このサイトにはCMS機能とマイクロサービスが含まれています。

長い間手に届かなかった2番目のプロジェクトはペーパーレスでした。 ショップディスパッチの機能、ブラウザを介したクールな視覚化機能（ウィンドウ制作などで重要）。 ブラウザを介したペーパーレス化の作業（たとえば、テレビに接続されたバーコードスキャナーの使用）は、本番環境でmetadata.jsのソリューションを使用する可能性を大幅に拡大および簡素化します。 特に、metadata.jsコードで外部イベントを操作する単純さを考慮すると、1Cのようにアクティブなフォームだけでなく、どこでもキャッチできます。

3番目のプロジェクトFlowcon.Lifeについて話しました 。 私たちにとって、それは非常に重要です。 プラットフォームの開発に役立つ一連のタスクを提供しました。 これはビジネス向けではなく、人々向けの最初のプロジェクトです。

4つ目はほとんど興味がありません-これはFlowcon、1C +タスク/チーム/ビジネス管理サービスの構成です。

まあ、もう少し-小さくて退屈な、または大きくて秘密です。 合計、たとえば、6個。

それはたくさんですか、それとも少しですか？ 2人で明確にします。 彼らはまた、実装プロジェクトでクライアントと協力し、記事を書き、多くの場合、お互いに、そして全世界と呪い、さらには地獄への怠け者です。

すべては相対的です。 9か月で6つのプロジェクト-たくさんですか、それとも少しですか？ 過去6か月で1つのプロジェクト（パラメトリック注文サービス）しかなかったことを思い出すと、その増加は非常に大きく、1か月あたり0.15プロジェクトから1か月あたり0.66プロジェクトに増加しています。

私たちにとって、これらのプロジェクトは出荷された時計よりも価値があります。なぜなら私たちを開発するからです-私たちはすべてWindowsの概念に入れました。 プラットフォーム、製品ライン、販売チャネル、流通ソリューションの機能。 出荷されている時計とは異なり、唯一の消耗品はお金です。

もちろん、プロジェクトの複雑さと人件費はすべて異なり、その数だけで判断することは困難です。 したがって、可能な限り適切に自分の状態とダイナミクスを理解するために、引用したいくつかの数字を使用します。

包括的な評価を見れば、このケースが機能し、ビジネスに真の利益をもたらすことを非常に迅速に理解しています。 私たちのケースでは、このケースでは十分ではありません。なぜなら、ご理解のとおり、開発が優先事項だからです。

ところで、これは加速を使用するための非常にエキゾチックなシナリオです。 お客様にサービスを販売することはもうありませんでしたが、時間をかけて新製品を購入しました。 私たちが正しいかどうかはわかりません、時間はわかります-真実は今日だけを考えるべきでしょうか？ ほとんどのフランチャイズがそうであるように。

さて、彼らは私たちについて話しました、今あなたについて。 記事を読んでいる間に質問があると確信しています。 加速のトピックは私にとって新しいものではないので、私はあなたが尋ねたい質問の多くを聞いたことがあり、すぐにそれらに答えます。 質問をグループ化します。

「信じない」

信仰は必要ありません。 信仰が必要だと思うなら、何かが間違っています。

コンサルティング、本、セミナー、クラブの会員など、私があなたに何かを売ろうとするなら、信仰が必要でしょう。 そうすれば、あなたの信仰を培う動機があるでしょう。 しかし、私はあなたに何も売っていないので、信仰の問題は純粋にあなたの個人的なものであり、主観的であり、私とは何の関係もありません。

まあ、一般的に、ここでは、宗派ではなく、事例があります。 私たちにはビジネスがあり、あなたもそうです。 私たちのビジネスはあなたに何も借りていません、あなたのものが私たちのものを借りていないのと同じように。 さらに、彼は信じるべきでもありません。

1人の1Cプログラマがドキュメント処理を半分に高速化する方法を考え出し、この方法を概説したとき、2人目の1Cプログラマは同じ方法を適用しようとする信仰を必要としますか？ もちろん、誰かが必要とすることを除外するわけではありませんが、ほとんどは不要です。

データベースのコピーを置き、提案された変更を行い、結果を確認します。 それは2回判明-クール。 それは1.5倍になりました-クール。 変更されていないか、悪化している-あなたは著者に手紙を書きます。 彼は手伝おうとして、彼の方法をより抽象的にするか、「pf、私に何か、私は成功した」と言うでしょう。

2番目の1Cプログラマーには何が悪いでしょうか？ なし。 結果がなかったとしても、彼は単に少し時間を費やします-そして、有効に使用します。

状況はケースとまったく同じです。 最初の記事で述べたように、その実装のコストはごくわずかです。 通常、ほとんどのメソッドは無料で実装されます。 当社からのものを含め、何も購入する必要はありません。

なぜ信仰？

「そしてあなたは見せて、証明する」

私ができること-示した。 「証明」について-上記を参照してください、信仰については、意味は同じです。

証明は非常に時間がかかるプロセスであり、その目的は実際に証明です。 私にはそのような目標はありませんが、論文を擁護するわけではありません。 試してみれば自分で証明できます。 あなたに何も証明できません

私たちのケースが機能したことを証明することさえできません。 小学校-ブルドーザーからグラフィックを描いたと言うでしょう。 そして、どんな数字、報告書、口座や税からの声明であっても、私は言うことができます-「pf、そしてどこで事件はどこにありますか？」

分かりますか？ 証明、信仰など -これはあなたの個人的な、内部的なもので、私とは何の関係もありません。 これはこれに対するステレオタイプであり、内部の信念、知覚の特異性、そしておそらく自己防衛の方法です。私は何も変えず、彼らが私に信仰を与えてそれを証明するまでそれをします。 それは明確で正しいように聞こえますが、1つの単純な理由により、変更の可能性を完全に遮断します-誰もあなたに何も証明しません。

「意味がありません、何もうまくいきません」

あなたがしようとしない場合-はい、それは動作しません。 また、自己防衛の方法。 誰からのものかは明確ではありません。

「これはナンセンスで、ある種の幼稚園で、うまくいきません」

私の意見ではこれが一番おかしい。 これが機能しないことを誰に納得させようとしていますか？ 私？ だからそれは私のために働く。

「それがどのように機能するか」というケースを書いた場合、そのような声明のポイントは、私がナンセンスをしていることを警告することです。

他の読者を説得しようとしている場合、あなたの目標は私には明らかではありません。 私は彼らの重要性と価値に異議を唱えるつもりはありません、私は理解していません。 残りは気にしますか？

自分を説得しようとしているなら、あなたは素晴らしいことをしている。

「私たちには完全に異なる問題があります-これとこれ」
非常に役立つコメント。 私は間違いなくそれらを私の仕事で考慮に入れます-あなたにとって何が問題で、何が問題なのかを知ることは重要です。

「著者は映画を見たり、本を読んだり、寝たり、黙ったり、プログラムをする必要がある」

著者が行う必要があることは無関係です。 リンクとヒントについては、もちろんありがとう。

「完全に異なる問題を解決する必要があるが、特定された問題を解決する必要はない」

コントラストを削除すると、素晴らしいコメントになります。 何らかの方法ですべての問題を解決する必要があります。 問題は優先事項であり、それらは各ビジネスおよび個人にとって主観的です。

このケースは、特定の条件で特定の問題を解決することを目的としています。 違いを考慮に入れるためのバリエーションとオプションが推奨されています。 比較的一般的な推奨事項を具体的なものに変えることは、実装者としてのあなたの仕事です。

さて、私が説明することは、あなたが1Cプログラマーなら、典型的な、一般的な、そして普遍的なものを特定の現実に適応させることによってそれを行うだけです。 ここでも同じです。

「複数のソリューションを販売するだけですか？」 それがポイントですか？」

いいえ、そうではありません。 複数販売は、それがいかに効果的であるかの一例ですが、この場合ではありません。 これを別のプラクティスの例と考えてください。

理解することが重要です-1Cの効率を改善するための多くのオプションがあります：フランチャイジービジネス、そしてそれらは途方もない結果を与えることができます-数十または数百回。 このケースはオプションの1つにすぎず、非常に控えめな結果-2倍になります。

「一般的に、そのように働く必要はありませんが、そのように...」

別の記事としてのみ良いです。 この場合のように、実験が時間の観点から理解でき、安価である場合は、慎重に研究し、適用しようとします。

「プロジェクトについてですか、それとも1回限りの作業ですか。」

基本的な違いはありません。 プロジェクトには、相互に関連するタスクが存在する相互接続されたステージの存在という仕様があります。 しかし、原子の本質は同じままです-タスク。

プロジェクトタスクはいつでもストリームに変換できます。 ある意味では、それらは一度限りのものよりもさらに単純です。 コンテキストと関係はそのままです。したがって、より印象的な加速結果を得ることができます。 プログラマー間で経験が交換されるだけでなく、関連する問題を解決することで経験が蓄積されます。

ちなみに、設計作業で2か月間チェックしました。 特定のマイルストーンで区切られたタスクのリストの形式で、プロジェクトのみが「フラット」にされました。

「1人または複数のプログラマーを開発することですか？」

ケースをチームに適用すると、最大の効果が得られます。 体系的思考について基本的な用語で説明します。

そして、1人のプログラマ、5人、100人-これがシステムです。 システムには要素と接続があります。 私たちの場合、プログラマは要素です。 相互作用、自動化、動機付け、目標、管理はコミュニケーションです。

システムの全体的なパフォーマンスを向上させるために、要素と通信の両方に作用することができます。 理解することは非常に重要です、これが鍵です。 誰もが要素に基づいて行動しようとしているからです-つまり プログラマー。 プログラマーがそれを改善するために行うこと。 これは便利ですが、あまり有望ではありません。

要素と関係の両方にわずかなパフォーマンスがあるためです。 特定のプログラマーのみ、モチベーションシステムのみ、または管理のみを無限に改善することは不可能です。 いずれにせよ、生産性が一時的に上昇した後、停滞が見られます。

大ざっぱに言えば、レバレッジはほとんどありません。 プログラマが1人だけの場合、システムの制限は要素の制限に等しくなります。 深く掘り下げると、プログラマをシステムとして想像し、その中に接続を見つけることができますが、原則はそのままです。

システムをセットとして見ると、つまり 原子的な要素-プログラマー-の場合、生産性を高める機会はほとんどありません。 つながりを見つけて行動し始めると、新しい機会に満ちた未知の世界全体を発見するでしょう。

「なんで？」

あなたが事業主であれば、その答えは明らかなようです。 成長を望むなら、何かを変える必要があります。

ビジネス1C：フランチャイジーでは、しかし、何も変えることはできません。なぜなら、あなたのために何かをする「母」がいるからです。 新製品、市場、サービス。 その後、何も変更せずに成長できます-市場の成長直後、市場でのシェアを維持します。

市場の成長率が十分であれば、すべてが順調です。 私たちには十分ではありません。これらのレートを追い越したいのです。 そして、新しい市場を作り、古い市場でのシェアを増やし、市場の構造を変えます。

覚えている場合（何らかの理由で記憶している）、1Cにはこのポジションがありました。価格ではなく品質で競います。 さらに、品質は、特にビジネスの内部特性です。 あなたの仕事の質は「母」や競合他社に依存しません。

全体のケースはパフォーマンスに関するものです。 パフォーマンスは、システム品質の指標の1つです。 「母」が注文したように、すべて。