目標の1つは、写真にあるものを取り除くことでした。
私たちの物語は他の皆と同じように始まりました。
まず、従業員への口頭での指示：これを行う、それを行う、なぜあなたは忘れたのですか？ もちろん、それではできません。
タスクマネージャー
次に、タスクマネージャーがやってきました。 まず、BugZilla、次にMantis、次にJIRAへの切り替えを試み、次にRedmine（告白する価値があります 。6年間立ち往生しています ）、次にOneBoxに切り替えました。 しかし、これらは単なるタスクマネージャーであり、タスクの選択とパフォーマンスインジケーターのシーケンスの戦略を設定するものではありません。
タスクマネージャーがいるとどうなりますか？ マネージャー（たとえば、プロジェクトマネージャー）は、タスクを割り当て、開発者にタスクを配布します。 ただし、次の2つがあります。
- 開発者が今やるべきタスクを決定します。 そして、原則として、彼は「最も興味深い」を選択します。
- マネージャーは、それについて明示的に尋ねるまで、何が行われているかを知りません。
- マネージャと開発者は、いつ完了するかわかりません。
疑問が生じます：プロセスを制御する人さえいますか？
時間給
これに加えて、開発者に費やした時間ごとの時間給をすべて追加すると、本当に地獄に落ちます：
- 開発者が時間を伸ばすのを妨げるものは何ですか？ 本当に30分間のタスクで、彼は60分間それをしますか？
- 加速を妨げるものは何ですか？
- マネージャーは「高価」だから売れません
- 一般に、このスキームは開発者に長時間をかけるように明示的または明示的に動機付けせず、ただ時間をかけるだけであり、結果は重要ではありません。
- そして、「突然」行う必要のあるタスクの束が常にあります。
2番目の質問が発生します：誰が誰を制御しますか？ プログラマーマネージャーですか、それともプログラマーですか？
松葉杖の推定
5年間このような計画がありました。 そして、このスキームの曲率を認識する代わりに、「開発者に時間を見積もってもらいましょう」という松葉杖を最初に思いつきました。 このクールなアイデアは、次のことにつながりました。
マネージャーはタスクを与え、評価を求めます。
開発者は見積もり、ほとんどの場合、開発者は「ヒット」と言います。 彼が推定値を推測した場合（これは私たちが知っているように決して起こらない）、彼はよくやった。 時間がなかった場合、開発者は怒って、できるだけ早く（定性的にではなく）実行しようとします。これは、見積もりを10時間呼び出して、12時間目にタスクを実行し、10を支払うからです。
したがって、開発者は、見積もりを数回過大評価し、できるだけ早くそれを実行する必要があることをすぐに理解します（品質が低下します）：私は20と名前を付けました。
最初の生産管理
全体として、事態がこれ以上進行しないことを認めるのに6年以上かかりました。 開発者（および本質的に製造業）が、会社の製造ではなく会社を管理していることを認識するため。
何時間も払って、開発者のタスクを選択する自由はすべて制御不可能なプロセスであり、それらを制御する試みはすべて松葉杖で松葉杖を発明することに帰着します。
そして、スキームを根本的に変更しました：
- 開発者は実行するタスクを選択しません。 タスクの順序は、CRMシステムを通じて部門の長によって割り当てられます。
- すべてのタスクは、2時間を超えないように設定されます。 つまり、すべてが第1レベルの最小タスクに分割され、「何をする必要があるか」という1つの簡単な質問に答えます。
- KPI開発者-1か月にできるだけ多くのタスクを実行します。 完了したタスクの給与が請求されます。
ずっと良くなった。 「開発者Xは今何をしているのか」とは問いませんでした。なぜなら、彼は優先順位1の計画で彼のタスクが何であるかを知っていたからです。 開発者は期限に悩まされませんでした。
後で、平均的な開発者が毎日どのくらいの作業をするかを予測する方法を学びました。そのため、どのタスクが完了するのかをおよそ把握することができました。 カレンダー上でその日の計画を立てる方法を学びました。 シンプルなメカニズム。 後に、「プロジェクトA、プロジェクトB、もう一度A」にジャンプする必要がないように、同様のタスクを自動的に分散およびグループ化するCRMシステムを製品に教えました。
これは、開発者のカレンダーが1週間どのように見えるかです。 開発者は計画に従うだけです。
最初は、開発者に何らかの計画を実行するよう要求するのは奇妙に思えます。
しかし一方で、R＆Dタスクに取り組んでいない場合、開発者は製造しています。 工場も生産です。 工場の管理者が機械の主人のところに行って、「今日は何個のブランクを作りますか」と言ったのを見ましたか。 生産には計画があり、1日多くをしなければなりません。
開発者も、適切な指標を見つけ、適切で実際の計画を設定するだけです。
それでも、通常はタスクの優先順位を削除しました。 すべてのタスクには1つの優先順位があります。 優先度がタスクの順序になりました。
そして以前（Redmine）は次のようなものでした：
給与区分
しかし、6か月後でも、このスキームの側面は上昇しました。
例：プロジェクトは、実行する必要がある120のタスクで構成されています。 120のタスクすべてがいつ準備できるかを予測することを学びました。 マネージャーには期限があります。 しかし、開発者は突然118のタスクを実行し、時間内に2つのタスクだけを圧迫することはありません。「キック」せずに彼にそれをさせることはできません。 また、「キック」は私たち自身のルールに違反しているため、開発者は期限を考慮しません。
現実には、開発者はこれら2つのタスクを圧迫しません。なぜなら、彼はすでに多くのことを行っていることを理解しており、「RFPでさらに2つのタスクはあまり効果がない」と考えているためです。
スキームは次のように修正されました：彼らは賃金のセグメンテーションを行い、線形ではありません。
N完了したタスクの場合-X USD。
1.5Nタスクの場合-2X USD
2Nタスクの場合-3X USD
などなど。
このスキームは、より多くのことをやる気になります。
品質
そして、彼女の側は登りました：開発者はできるだけ多くの仕事をして、品質を忘れました。 バグもタスクであるため、バグを作成し、彼らがそれを見つけて修正したら、+ 1タスクがあります。
すぐに「バグにお金を払わず、バグを数えない」という考えがありましたが、これは間違った方法です。
- バグの修正が重要だと言うとき、潜在意識は「バグは良い」と信じています。
- バグを修正することは重要ではないと言うとき、潜在意識は「バグは標準である」と信じています。
- そのため、「バグは悪いので、それを行うことはできません」と言わなければなりませんでした。
そして、2番目のKPI品質を導入しました。
品質とは、その月に見つかったバグの数に対する、1か月に完了したタスクの数の比率です。
たとえば、開発者は100のタスクを実行し、テスターは15のバグを発見しました。つまり、開発者のバグの割合= 15％です。
開発者向けのKPIインジケーター-バグの割合は15％未満でなければなりません。そうでなければ、最初のZPバーを超えることはできません。 言い換えれば、常にジュニアです。
そして、その時点で、最初は（3人の開発者が辞めたために）悪くなり、その後はバグが現れなくなったので問題ありませんでした。 何らかの指標をたどり始めるだけでよく、すぐに変更と調整を開始します。
2か月後、すべての開発者のバグの割合が10％未満だったため、品質のカウントを停止しました。 すべて調整済み。
これらの実装後に何を得ましたか？
- 開発者を蹴るのをやめました
- 誰もそのような優先順位を変更することはできません。チームリーダーのみが従業員のカレンダーにアクセスできます
- 「どれくらいやりますか」と尋ねることなく、タスクを完了する時間を予測する方法を学びました
- 本当にタスクの順序を変える-私たちは生産を管理します
- ほとんどのタスクマネージャーのように、優先順位はまったくありません。
- まあ、開発者がタスクが同じ製品にある製品を作ると、それは吹き飛ばされます:)
次は？
これは制限ではなく、何かが故障し、しばらくしてから次のスキームを再度実行する必要があると思われます。
必ず情報を共有してください。
当社は2006年以来存在しており、私たちは通常のウェブスタジオのように他の皆と同じようにスタートしました。 すべてが始まったとき、人事管理については何も知りませんでした。職務と責任の雇用と委任については何も知りませんでした。 現在、従業員の効率とすべてのプロセスの自動化に取り付かれています。 40人の従業員がいます。4週間で+20人の開発者をトレーニングできますが、さらに詳しくは次の記事で説明します。