開発プロセスの責任のコンポーネントとしての期日

製品開発では、効率の問題は常に非常に深刻です。 ビジネス、従業員の成長、変動性、透明性、その他の多くの要因の観点から最適となるようにプロセスを構築する方法は？ すべての問題を一度に解決し、頭痛からリーダーとしてあなたを救う「銀の弾丸」はどこにありますか？

流行の（そうではない ）開発方法論：スクラム、かんばん、XP、RAD、FDDなどがこの「銀の弾丸」のタイトルに定期的に適用されます。新しい方法とアプローチ、フレームワーク、ツールが定期的に表示されます。 ビジネスコンサルタントは企業に来て、彼らのノウハウを多額のお金で共有し、それがいかに正しいかを伝えます。 そして同時に、それは素晴らしくて安いでしょう？

そして、このプロセスまたはそのプロセスの助けを借りて、人々が満たしたいニーズを定式化できれば素晴らしいことです。 しかし、多くの場合、withoutせずにファッショナブルなアプローチが導入されるだけで、最終的に参加者の不満やビジネスの非効率性につながります-ペースが速く、スタートアップや競争が激しい現代の世界では、そのような無分別の結果は悲惨なものになります。

プロセスに必要なもの、解決する必要のある問題、およびこれに使用するアプローチについて考えてみましょう。 同時に、Badooでの取り組みについてお話しします。 これは、Habréのブログでの3回目の連続投稿です。 しかし、念のため、もう一度自己紹介をします。私はイリヤ・アジェエフで、BadooのQAを率いています。

プロセス参加者

プロセスについて話すと、彼らは主に参加者について話します。 条件、結果、リソース、目標などはまだあります。しかし、ほとんどの場合快適で効果的な方法での共同作業の組織は、機能の開発のプロセスを暗示しています 。

ユーザー向けの製品を製造している会社のすべての従業員は、さまざまな目標を持って毎日オフィスに来ています。 これらの目標のバランスを取り、良好なビジネスパフォーマンスを達成するための共同の努力ができればよいのです。 しかし、ビジネスと普通の従業員が異なる目標と価値を持っていることは明らかです。 誰かが住宅、新しい車、休暇のために貯金しています。 活発なコミュニケーションと自己啓発に興味がある人。 一方、ビジネスはお金を稼ぎ、従業員を目標を達成するためのリソースとして認識します。

従業員は（もしあれば）善良な人々であるため、従業員に給与を支払うだけの会社はほとんど存在しないことを認めなければなりません。 他の目標。ただし、従業員が常に共有するわけではありません。

そして、この複雑な共生において、会社の目標は個々の従業員の目標よりもさらに重要であるように思えます。 良い会社はそのリソースを高く評価し、愛していますが、ビジネスの観点からは、人々（他の多くのリソースと同様）は常に交換できます（時には非常に困難です）。 しかし、グローバルな目標を変えることは不可能です。 そして、これをビジネスに期待するのは奇妙だろう。 「今、パンを焼くのではなく、子供の朝に音楽演奏をしましょう！」何のために？ より大きな利益のために、そしてそれが簡単に実装できるなら、そうしましょう。 しかし、パン職人ヴォロディアが歌うことを愛し、望んでいるという理由だけで事業の方向性を変えたとしても（そうでなければ彼は辞めることができます）、当然のことながら、誰もそうしません。

したがって、生産プロセスの最初で最も重要な参加者はビジネスそのものです。 比Fig的に言えば、彼は音楽を支払って注文します。 ビジネスは何を望んでいますか？ 目標は大きく異なります。 慈善事業から始まり、親relativeの雇用で終わる（時々起こる）。 それでも、ほとんどの場合、主な目標は所有者の福祉を改善することです。 そして、できれば最低コストで 。 「可能な限り少なく支出し、可能な限り稼ぐこと」が市場のABCです。

機能を開発するための生産プロセスでは、ビジネス担当者は製品マネージャーです。 ビジネスの目標を理解、定式化、開発者に伝え、必要に応じて「噛む」、妥協を見つけ、すべてを正しく計画するように設計されています。 そして-プロセスを制御するために、結果を確認し、運用します。

彼の目標は何ですか？ これは明らかです。可能な限り短時間で、できるだけ多くの作業を取得します。 実験を行い、アイデアを実行可能性についてテストし、可能な欠陥を修正し、できるだけ早く製品でお金を稼ぎ始めるために（私は意図的に品質について話さないが、それは意味する：誰も低品質の商品を購入しない）。

したがって、プロダクトマネージャーは、タイミングに関するデータ、現在の状況の概要を常に必要とし、プロセスの他の参加者に圧力をかけ、すべてを一度に望んでいるようです。 彼は、できるだけ効率的にそれを行う方法を理解したいだけで、理想的には、次回より多く、より速くする方法を理解したいだけです。 これは正常であり、ビジネスの観点からは良いことです。

したがって、製品マネージャーの目標の重要性をプロセスのすべての参加者に伝えて説明する必要があります。そうすれば、製品マネージャーは30分ごとに開発者を追いかける必要がなくなり、「まあ、いつ準備ができますか？！」タスクの仕事から。

Badooでは、タイミングは開発プロセスの非常に重要な部分です。 新機能の配信時間はできるだけ早く当社の場所に表示され、 期限と呼ばれます 。 これは、機能を実稼働する必要がある日付を表します。 期日は多くの要因に依存します-ほぼすべてが、必要な変更の説明の詳細レベルから始まり、コードをエンドユーザーに配信する方法で終わる、製品開発プロセス中に影響します。 タスクの分解、インターフェイス設計の複雑さ、テストとその自動化、外部とのやり取りの量、コードのアーキテクチャ-これらはすべて、期限に大きく影響する可能性があります。 そして、人々が生産のあらゆる段階で働くことを考えると、配達時間に対する人的要因の影響は莫大です。

チームのすべてのメンバーがプロセスの重要性を理解し、やる気と正確さがあり、常にすべてを時間通りに実行できれば理想的です。 これは可能ですか？ 常にではありません。 特に、共有された価値の説明と共有に関しては。 しかし、プロセスの後続の参加者自身がいくつかの単純な指標に焦点を当て、単純なルールに基づいて期限を守るよう努力することを確認すれば、常に妥協点を見つけることができると確信しています。

当社では、このインジケータは期日です。 開発者自身がビジネスの目標を達成するために努力することを保証するためにこれをどのように行っているかについて、さらに説明します。

このプロセスの次の参加者は誰ですか？ ベイカーボロディア。 私たちの場合、プログラマー。 業界の平均IQが高いと考えても、平均的な人はどのような目標を持つことができますか？ お金を稼ぎ、バリ島に行き、アパートを買い、老後を救い、ローンを支払い、ギブソンのギターを買い、早めに仕事を辞め、夕方に映画を見に行き、隣人と会う ITスペシャリストについて話しているので、さらに詳しく説明します：仕事のバックログを整理し、退屈なバグを再現し、上司の過ちを取り除き、Erlangを学び、新しいPythonフレームワークを「感じ」、英語を学び、Raspberry Piでドローンを構築し、その利点についてポッドキャストを聞きますコトリン。

もちろん、私たちは共通の目的で協力しているため、「プロジェクトをサポート」し、「ビジネスを理解する」優秀な人物がいます。 しかし、彼らに何度も給料を払わないようにしてください（私は気分を害するつもりはありません-ポイントが明確になるように特別に対照的にプレーします）。 結果はどうなりますか？ 彼らは、Yandex、Facebook、Google、および給与がかなり大きい他の会社に行き、夕食、食事、マッサージ、マニキュアを食べます。 そして、彼らはそれを正しく行います！ 仕事は、ビジネスがプログラマーの仕事（および頭脳）をお金で買う場所です。そのため、ここで商品とお金の関係が支配されます。 そして、ビジネスの目標が最小限のお金で可能な限り多くの仕事を得ることである場合、従業員の目標は反対です：できるだけ少なくして、それのためにできるだけ多くを得る。

もちろん、このプロセスには他の参加者もいます：デザイナー、コピーライター、翻訳者、アナリスト、テスター、リリースエンジニア、システム管理者。 しかし、第一に、彼らの目標は、パン職人のヴォロディアの目標とあまり変わらない。 そして、第二に、彼らはしばしば最前線の役割を果たさず、むしろ「攻撃を行っている」間、戦闘機開発者を隠します。 ところで、会社のそのような従業員はまったく存在しない場合があります。彼らの役割は、多くの場合、他の役割と組み合わされます。 製品開発では、そのような役割はすべて製品やプログラマーのリソースとして機能し、彼らがより良い仕事をするのを助け、ルーチンを排除します。

そのため、ビジネスを代表するプロダクトマネージャーの後のプロセスの主な参加者はプログラマーです。 パン屋のヴォロディアは興味があればたくさんできます。 彼は夜寝ることができず、食事も外出もできません。 しかし、ビジネスのタスクは異なり、それらの多くは面白くなく日常的です。 したがって、Volodyaが10の興味深いタスクを自分用に完了したが、ビジネスには関係がなく、1つが面白くないがビジネスには非常に重要な場合、これは彼が1つのタスクのみを完了したという事実と同等です。 製造された商品が流動的で競争力があり、どの技術が使用されているか、Volodyaがどのようにベーカリーのアルゴリズムとパターンをうまく適用したかは、ビジネスにとって重要です。

もちろん、Volodyaは締め切りについて知りたくない、プロダクトマネージャー、デザイナー、会計士とやり取りしたくない-彼は座って彼の興味深い仕事に没頭したい（そして誰も気にしない） そして、これらの条件、期限、計画、顧客、競合他社では、これはVolodyaが我慢することを余儀なくされる厳しい現実ですが、製品マネージャーの場合のように彼の戦略目標の一部ではありません。

責任

パン職人ヴォロディアの目標とは程遠い会社の目標が、開発プロセスでまだ考慮されていることを確認する方法は？ そのため、多くの落とし穴、問題、驚きを伴うすべての段階で、主に会社にとって有益な決定が行われますか？ ヴォロディアは期限を遵守し、理想的にはアーキテクチャの計画、 オーバーエンジニアリングなど、ビジネスニーズから遠ざける可能性のある問題を回避する必要がありましたか？

Badooでは、このプロセスを「開発者の責任」と呼び、あらゆる面でこの責任を奨励しています。 すでに述べたように、私たちのプロセスでは、開発者は自分が取り組んでいるプロジェクトのマイクロプロジェクトマネージャーとして機能します。 これはどういう意味ですか、どのように刺激するのですか？ 非常に簡単：開発者は期限（期日自体）を満たす責任があります。

これは、開発者が期限を設定する必要があることを意味します。 もちろん、彼はタスクを注意深く研究し、計画する際にできるだけ多くの要因を考慮に入れてこれを行わなければなりません。 そしてもちろん、彼はこの期間を遵守するよう努力する必要があります。 しかし、開発者が期限を破ることができるという事実に備える必要があります。 一番下の行は、私たちがどのように進むかです：私たちは締め切りに間に合わないようにするすべてのニュアンスを考慮し、それに答えを準備します（次回そのような問題が再発しないことを確認する方法）。

開発者は誰よりもプロジェクトをよく知っているため、開発者からの回答が必要です。 彼はこの用語を今回命名しましたが、今後も命名します。 おそらく彼は再び間違っているだろう-これは怖くない。 このアプローチがエンジニアリング文化を改善し、開発者と会社全体の成長を刺激することが重要です。 そして、そのような問題を将来どのように回避するかについての決定が信頼できるものであることは明らかです。 「次回は試さない」ではなく、これが二度と起こらないようにして、人的要因を最大限に排除します。

実装の期限（期限）を受け取ってそれを確認したテクニカルマネージャーが、期限までにプロジェクトに注意を払うのをやめなかったらいいと思います-これは危険であり、多くの問題の解決を最終段階に遅らせます（簡単に、速く、安く解決できる問題） ） ここでは、特定の所定の周期で（これにより開発者が作業から気を散らさないように）、各タスクに戻って状況を明確にし、タイミングを調整する必要があります。 期限に間に合うように妥協の決断を下す必要があるかもしれませんが、将来のために「研磨」と機能改善を残します。

期限までにn日を投げるだけでは最善の解決策ではないことは言うまでもありません。 それを制御する方法は？ 非常に簡単：スケジュールよりも早く完了したタスクも、不適切に計画されていると見なされるべきです。 同時に、「不適切な計画」は、すべてが悪いことを意味するわけではなく、開発者を罰する必要があります-これは、マネージャーのこの側面に注意を払い、用語に影響する問題を議論する必要があることを意味します（たとえば、「創造的なエクスタシー」や開発プロセス）。

もちろん、 パーキンソンの法則を忘れないでください。これは、割り当てられた作業には常に時間がかかると述べています。 しかし最初に、これに対抗する最も効果的な方法は、期限までに何か便利なことを行うことでタスクを完了するのにかかる時間を短縮することです。これは複数のプロジェクトを並行して行うため、機能開発にうまく適合します。 第二に、期限からの逸脱を遡及する機会とみなし、将来のより正確な予測を行う方法に関する信頼できる決定の開発を促進します。 そして第三に、期限に間に合ったとしても、次の質問をする必要があります。

ポイントをキャッチすることは非常に重要です-私たちはすべての人に期限を順守させるように単純にしようとしているのではありません。 （ベーキングとは対照的に）機能開発には多くの不確実性があります。 似ているタスクはほとんどありません。これらは「普遍的な」パンではありません。 パン屋の「何かがおかしくなった」場合、それは不可抗力が起こった（電気を切った、小麦粉を間に合わなかった、など）か、ただ怠け者だったことを意味します。 反対に、開発では、たとえ一生懸命努力しても、期限に間に合うことはめったにありません。 そして、開発者が期限に間に合わなかった場合、これは彼がどこかを手探りしているという意味ではありません。 結論は異なります-締め切りに間に合わない理由を調べ、理由を評価します（締め切りに影響したのは、状況、リソース、実行者の怠、またはビジネス目標の誤解です）。 開発者は非常に効率的ですが、結果に焦点を当てることなく、彼にとって重要と思われる些細な些細なことに常に気を散らされます（あるいは、ローダーVasyaが友好的な関係を持っているため、それを支援します）。 その結果、開発者は多くの理由を心から重要と考えていますが、結果はありません。 ここでは、マネージャーの継続的なサポートと調整が必要です。

要約すると。

1. 開発者は、タスクの期限を期限の形式で設定します。 これは、タスクが実稼働する時間です。
2. 技術管理者は期日を確認する必要があります。 以前に自分でプロジェクトを研究し、将来に影響を与える可能性のある要因をすぐに指摘していたので、彼がこれを行うといいでしょう。 コーチングはこの段階で開始する必要があります。
3. 事前に決められた一定の周期で、管理者は開発者と状況を確認する必要があります。すでに発生している可能性のある問題と、すでに加速できるプロセスを検討してください。 例：「3行のコードのレビューに3日かかったのはなぜですか？」
4. プロジェクトが完了したら、いずれにせよ、振り返りを行い、質問をする必要があります。

期日は楽観的な予測です。 当社はこれをすべて理解しており、開発者がプロ​​ジェクトのすべての段階でマネージャーのサポートを必要としていることを知っています。 また、開発者には少しの時間的余裕があると仮定しても、落ち着いて自信を感じるのに役立ちますが、それは悪いことではありません。 私たちの目標は、「馬を死に追いやる」ことではなく、効果的かつ実用的にそれを行うことです。私たちはまだ協力して多くのクールなプロジェクトをしなければならないからです。

例

以下の状況は、良い解決策とそれほど良くない解決策を説明する例と考えることができます。 明らかに、解決策は唯一の真の解決策ではありませんが、本質をつかむことができます（願っています）。

1. テスターが多くのバグを見つけたため、タスクの再発見が多すぎたため、コンテキストの切り替え、キュー内のタスクの待機など、隣接するすべての段階で不必要な時間コストが発生しました。悪い決定：テスターに​​叫んで、テスターを発動し、新しいものを雇います。 良い解決策：コードを単体テストでカバーし、次回コードの品質に関するフィードバックをより迅速に取得できるようにすること。 製品の品質を改善するための方法論と実践に取り組みます。
2. デザイナーは新機能の設計を複雑にしすぎたため、ボタンを文字通り一から描く必要があり、時間がかかりました。 悪い判断：設計者にこれを行わないよう依頼してください。 適切なソリューション：アプリケーションのガイドラインを作成し、標準コンポーネントを作成し、設計者に提供して、ガイドラインに従って作業します。
3. 開発者は、新しいファッショナブルなフレームワークで新しい機能を作成することを決定し、他の場所で変更を行ったため、ほとんどすべてを書き直す必要がありました。 悪い判断：フレームワークが悪いことを全員に伝え、二度と使用しないでください。 良い解決策：コードの問題は最小限に抑える必要があります-この特定の問題を解決するためだけです。 新しいアプローチ、フレームワークなどは、調査、 円滑な展開などを伴う技術的負債のフレームワーク内で個別のタスクとして実行する必要があります。
4. バグを修正する過程で、開発者は別の古いバグを見つけ、それを修正し始め、古いコードに埋もれ、プロジェクトの半分をリファクタリングしました。 悪い決断：バグの修正とリファクタリングを禁止します。 良い解決策：コードのタスクには最小限のものがあります-バグの修正に関してはそれだけです。 XPにはリファクタリングによる開発が含まれるという事実にもかかわらず、あらゆるものの変更に着手する前に、状況について数回考える必要があります。 多くの場合、この段階でのリファクタリングは延期するほうがよい場合があります。 プラグマティズムは、コードの美しさやアーキテクチャの正確さではなく、前景にあるべきです。 あなたはリファクタリングが必要だと思います-これをマネージャーと話し合ってから、コードを「シャベル」し始めてください。
5. すべてを時間通りに行いましたが、レイアウトの2日後に、システムの非常に重要なコンポーネントが新しいコードによって破損し、ユーザーが製品を使用できなくなり、機能をロールバックして修正する必要があることがわかりました。 悪い解決策：優れた開発者とテスター。 優れたソリューション：システムのこのコンポーネントやその他の重要なコンポーネントの監視を開始し、それらをセルフテストでカバーし、パフォーマンスと基本的なビジネスインジケータに関する少なくとも最小限の統計情報を備えた新機能を提供します。

非常に多くの状況が存在する可能性があります-すべてを予測することは不可能です。 しかし、問題に対処するときは、将来、同様の問題の多くをすぐに解決しようとします。 このアプローチは、プロジェクト全体を改善するだけでなく、開発者のレベルを大幅に向上させます-それは、彼が問題をより広く見ることを奨励するからです。 この場合の開発者は、アーキテクチャ、管理の専門知識を受け取り、 自分自身が開発チームであり常に改善しているエンジニアリングチームの重要な一部であると感じています。

そして、責任者が一人いるべきだということを覚えておくといいでしょう。 複数の開発者がプロ​​ジェクトに取り組んでいる場合でも、そのうちの1人が調整と期限を担当する必要があります。多くの場合、これは最も経験豊富な専門家です。 だから私たちは集団的責任の状況を避けようとします：結局のところ、誰もが何かに責任があるなら、事実上誰も責任を負いません。

Badooの私たちは、最も経験豊富な人ではなく、若くて「ホットな」人に割り当てられ、その成長を刺激するアプローチも実践しています。 同時に、経験豊富な開発者がプロ​​ジェクトのすべての段階を監視し、あらゆる方法で彼を助け、エラーを指摘し、指摘します。 そして、同時に機能が少し遅くなり（これはまったく必要ではありませんが）、より多くのリスクがある場合でも、このアプローチはチームの人々の成長を保証するため、戦略的に正しいです。

おわりに

プロセスを作成する際に、システムを最適化するようにします。 独創的な問題を解決する理論には 、「理想的な最終結果」（ RBI ）と呼ばれるアプローチがあります。 彼は、問題を解決するとき、理想的な解決策を想像すること、費用、合併症、および望ましくない効果なしで望ましいアクションが実行されることを提案します。

機能開発では、すべてが計画どおりに進んでいるという自信を得るために、開発者に何かを要求し、それを制御しようとし、ますます多くのインジケータで自分自身を取り囲んでいることがよくあります。 しかし、より多くの人、より多くのタスク、より多くの指標、管理することがますます難しくなります。 その結果、インディケーターと会話のあるテーブル以外には時間がない状況に陥ることがありますが、物事はまだうまくいきません。

さらに、開発者のモチベーション、ビジネス目標の理解と採用の刺激に影響する多くの要因があります。ビジネスの見通し、会社にとってのプロジェクトの重要性の理解、シームレスな実装と運用の欲求、主観的な顧客満足など。形式化して測定します。 さらに、特定のアーティストに価値を伝えることが難しい場合があります。 多くの場合、非常に優れた開発者であっても、「食の風」の方向の変化に気付かないため、正しい方向を示す、何らかの種類のわかりやすくシンプルなメカニズムが必要です。

したがって、すべての段階で開発者のRBIを刺激する主要なツールの1つとして期限を検討します。 プロセス全体を経て、将来の多くの問題を回避するためのソリューションを考案します。 これにより、多数のKPIに頼ることなく責任を委任できます。 ほとんどすべての人が理解でき、アクセスできます。 そして、それは私たち全員をビジネスの主な目標に導きます：可能な限り迅速にできることです。 そして、それも安くなるかどうかは、私たちが使用する決定、したがって、私たち全員に依存します。

そして、あなたはあなたの会社でどのようにしていますか？