「どうするか」をどのように決定しますか？

この記事では、「1C：Enterprise」プラットフォームに何をいつ実装するかをどのように決定するかという質問に答えます。



この言葉遣いで私たちはめったに尋ねられませんが、多くの場合、非常に頻繁に特定の質問が発生します。それ？」、「いつやっとやるの?? !!!」、...



いつ何をするかをどのように決定するかを説明しましょう。

要件または希望？

一般に、非常に一般的に受け入れられている要件管理プロセスがあります。

残念ながら、基本的に、それらはカスタム開発に関連しており、私たちは流通しています。 さらに、非常に、非常に循環しています。

残念ながら、それらは主に適用されるタスクに関連しています。 そして、技術的なプラットフォーム（フレームワーク）があります。



2番目の状況は、私たちの状況の特徴において小さな役割を果たしているようです。

私たちの場合、「需要」の概念そのものが（特にロシア語の読みにおいて）完全に正しいとは思えません。 何かを「必要とする」顧客は一人もいないので、私たちにできること（「機能」の可能性）は非常に異なる用語（「願い」、「申し出」、「必要」、「アイデア」）で説明できます。 "、....）。



この件名には単一の名前を付けていません。

ほとんどの場合、「ウィッシュ」という用語を使用します。 ただし、これは特定のケースを常に正確に反映するとは限りません。



私たちは数千（数千）の願​​いを記録しました。 もちろん、私たちがそれらすべてを実現することを想像することさえ不可能です。 さらに、時間と複雑さを考慮しなくても、それらすべて（すべて一緒に）は単に必要ありません！ そして、したがって、問題は常に発生します-今何をする必要がありますか？！ もちろん、「今」とは、非常に異なる時間範囲を意味します。



主な情報源をリストするのは簡単です-願いはどこから来るのですか？

• 適用されたソリューションの開発者の願いとアイデア
• パートナーの願いとアイデア
• ユーザーの希望とアイデア
• 会社経営の願いとアイデア
• 他のユニットの願いとアイデア
• 市場の一部の製品に実装されているもの（競合するものと競合しないものの両方）
• 世界のITおよびビジネスの開発動向から得られるもの
• 私たち自身のアイデア

このリスト内のアイテムの順序は、優先順位を反映していません。 これは単なるリストです。 優先度はより複雑な方法で定義されます。 さらにそれについて。



実現可能な願いを選択する個々のアナリストはいません。

開発チームは、実装するタスクと開発方向の選択を担当します。

優先順位付け

優先順位の選択（「機能」の計画）は現在、チームによって実行されています（以前は中央で行われていました）。



つまり、選択は一般リストからではなく、チームリストから行われます。



チームリーダーのティムは、チームメンバーと協議して、潜在的なタスクに優先順位を付け、計画を立てます。 もちろん、ここでは計画の頻度が役割を果たします（計画は複数の期間にわたって行われます）が、これは別の問題です。



生成された計画は、必要に応じて他のチームと話し合い、プロジェクト管理と話し合います。 もちろん、この議論では、決定が変わる可能性があります。



私たちは、チームが永続的な「バックログ」を持っていることを保証しようとします-将来の計画の2-3段階のために、優先度によってランク付けされた潜在的なタスクのリスト



チームで希望を選択するための方法論はわずかに異なる場合があります。 これは、チームが担当する機能の範囲の機能、およびチームのチームリーダーの好みによって影響を受ける可能性があります。



もちろん、このアプローチでは、チームのチームリーダー、アーキテクト、およびチーム開発者の要件が増加します。 プラットフォームの使用方法を理解し、ユーザーとアプリケーション開発者の要望を分析し、ITトレンドを監視し、競合するテクノロジーの開発の方向性を理解する必要があります。 ここで、競合する技術は、ビジネスの競合他社としてだけでなく（多くの場合それほどではない）、特定の分野の既存および新興の技術として理解されています。 たとえば、プラットフォームのUIメカニズムの場合、これらは最新のUIフレームワークです。データを操作するメカニズムの場合、これらはデータを操作するための普遍的なメカニズムです（ORMなど）。



したがって、他のすべての品質に加えて、チームリーダーであるプラットフォームメカニズムの責任者もアナリストの役割を果たしていることがわかります。 この用語は使用されていませんが、作業のこの部分は非常に重要です。

実装の対象と方法

開発の一般的な方向と最も重要なタスクは、会社のディレクターと合意されています。 ディレクターは推奨事項を提示し、決定に直接影響を与えることができます。 もちろん、最終決定の選択（チームレベル、プロジェクト管理、会社のディレクター）は、管理上の従属の対象となります。 しかし実際には、これは問題を引き起こしません。なぜなら、ほとんどの場合、すべてのレベルで相互理解（コンセンサス）を達成できるからです。 また、意見が異なる場合（および決定が下される場合）、意見が説明および議論されます。 したがって、意思決定の「過剰管理」の感覚はありません。



私たちはしばしば（ほとんど常に）難しい選択をします。



まず 、新しい機会と既存の機会の開発の間の選択。

明確な基準はありません。これはすべて必要であり、何も犠牲にすることはできません。

バランスを維持しようとします。 積極的に使用される機能は、常に開発に対する多くの願いを生み出します。 私たちは、効果的な使用のために非常に不足しているものと、効率を劇的に高めることができるものを強調しようとしています。 しかし、ユーザーとアプリケーション開発者が既存の機能の開発を求めるものだけを実装する場合、「開発」は戦略的で有望な方向で「オーバーボード」のままになります。



第二に、信頼性、パフォーマンス、および新機能の改善の選択。

また、難しい選択。 もちろん、両方が必要です。

現在のニーズのレベルを評価し、合理的なバランスを見つけようとします。

現在、たとえば、信頼性とパフォーマンスの問題は非常に高い優先度を持っています。 これにはかなり具体的な理由があります。



一方では、企業環境で1C：Enterpriseを使用すると、スケーラビリティ、信頼性、パフォーマンスの要件が常に高まります。 実装はますます増えています（競合ユーザーの数、単位時間あたりの操作量、機能の量などに応じて）。 同時に、アクセシビリティ要件も増加しています。 許容される技術的中断が削減され、エラーの価格が高くなっています。



一方、クラウドモデルへの移行には、スケーラビリティと信頼性の向上も必要です。 クラウドへの移行における小規模企業向けに設計された大規模なプログラム（1つではなく数千の企業で動作）は、すでに完全に異なるレベルの信頼性とスケーラビリティを必要としています。



さらに、コンピューターの回転処理が遅くなりました。 つまり、新しい機能（多くの便利で便利な機能を含む）は、コンピューター6〜7および10歳でも動作するはずです。 また、最適化に多額の投資をする必要があります。



第三に、現在のニーズと有望な開発との間の選択。

一般に、新しい品質または大きな新しいメカニズムを取得したい場合、それを実装するのに多くの時間（月、年）がかかることが明らかです。 そして現在、非常に重要かつ非常に緊急なニーズが存在する中で、私たちは有望なタスクと方向性に多大な努力を注いでいます。 おそらく今、それらはそれほど緊急に必要ではないかもしれませんが、もし彼らが今やられなければ、彼らは明日も明後日もなくなります。 そして、彼らはすでに重要になることができます。



たとえば、 Webクライアントの作成と開発に多大な努力を払っていると非難されたとき、彼らは言った-見て、ほとんどの人が1C Webクライアントを使用せず、大多数が使用するものにより良いリソースを投資している。 ただし、Webクライアントの開発は非常に重要な領域であると考えています（そして引き続き検討します）。 本格的なウェブクライアントがなかった場合-競合他社と比較して大幅に低下するため、ブラウザでの作業時に完全な機能の存在が必要な場合、当社の製品を導入できませんでした。 そして、この事実は間違いなく、結果としてすべてのユーザーに悪影響を及ぼします。 しかし今、私たちには重要な競争上の優位性があります。 Webインターフェイスとネイティブインターフェイスの両方があります。 さらに、Webインターフェースの開発に追加の労力は必要なく（両方のインターフェースは同じアプリケーションに基づいてプラットフォームによって生成されます）、両方のインターフェースはほとんど同じに見えます。



また、現在のIT開発動向も。 （有益なことをするのではなく）ユーザーにとって私たちの時間の無駄だと思われる場合、事前にそれらを考慮に入れる必要があります。 ユーザーが声でそれらについて叫び始めたときにそれらをサポートし始めたら、手遅れになります。



したがって、私たちの仕事は、現在のニーズを満足しながら、合理的な割合で視点の仕事と方向を組み合わせることにあります。



典型的な手法と計画アプローチは、有望な分野の選択にはうまくいきません。 しかし、これはおそらく別の問題です...



第四に 、受け取った希望と新しいアイデアの間の選択。



たとえば、世界を（ITだけでなく）変える最も壮大なテクノロジーは、ユーザーの希望からではなく、アイデアから現れます。 たとえば、オフィスソフトウェアを使用します。 ワードプロセッサは、一般に、ユーザーの願いから生じた完全に明白なものです-「タイプライターが欲しいのですが、コンピューター上に」。 しかし、スプレッドシートのようなものは、誰も望んでいないことはほとんどない素晴らしい発明です。 そして、他のテクノロジーで利用可能な既成の願いや解決策をとらなかったが、アイデアを思いついて実行したときに、そのような例は十分にあります。 そして、それは非常に大きな効果をもたらしました。 そのため、たとえば、 データ交換と分散情報ベースのメカニズムとデータ構成システムが生まれました。 そして、 構成オブジェクト （ビジネスオブジェクト-ディレクトリ、ドキュメント、情報レジスタなど）の概念は 、1C：Enterpriseプラットフォームの基盤であり、開発チームのアイデアとして生まれました。



開発者のアイデアは、受け取った願いと同じくらい重要だと考えています。

もちろん、選択して実装したアイデアが実際に大きなメリットをもたらすことが重要です（そしてこの責任を理解しています）。 つまり、どのようなメリットがもたらされるかを理解するまで、アイデアを実行に移しません。

「制限条項」はどのように影響しますか？

希望を記録する期限は、決定に影響を与えるべきではありません。

このような苦情に出くわすことがよくあります。「5年前に尋ねられましたが、まだやっていません。」



はい、「5年前に質問」は議論ではないと考えています。

願いは、キューでもスタックでもありません。



現時点では、各段階で優先順位を評価する必要があると考えています。

状況は非常に急速に変化しています。 5年前に有用だったものは、今ではあまり有用ではないかもしれませんし、有害かもしれません。



そして、最も重要なこととして、選択は、他の可能なタスクの現在のセットおよび開発の方向と比較して行わなければなりません。 また、現時点では現時点ではありますが、常に将来を考慮しています。 つまり、私たちは今日、明日、そして明後日に必要なものを評価します。



たとえば、現在の段階で何らかのメカニズムで何かを実装することができなかった場合、残りの未実現の機能は次の段階の計画に自動的に分類されませんが、他の潜在的なタスクと同じ立場で検討されます。



ちなみに、5〜10年前に受け取った希望を体系的に実行し始めると精神的に想像するなら、それは非常に面白いでしょう。

特定のリクエストに対するリクエストの数をどの程度考慮しますか？

一般に、考慮します。 しかし、これは主要な基準ではありません。 これは、優先順位の選択に関する追加情報です。 アピールの数が願いの重要性を示すことができるオブジェクトがあり、それができない、または非常に小さい程度にできるオブジェクトがあることを理解しています。

タスクの複雑さはどうですか？

それは考慮されますが、まったく簡単ではありません。



多くの場合、「なぜそれをしなかったのか、それを行うのに数時間かかるので」と聞きます

まあ、まず、多くの場合（非常に頻繁に）、この外部評価では開発の現実を考慮していません。 小さな変更を完全に設計するには（異なるシステムメカニズムの異なる状況での影響を考慮するため）、実際の実装よりも大幅に時間がかかることがよくあります。 まあ、別の重要な側面。 頭に浮かぶ最初のソリューションを実装する余裕はありません。 プラットフォームのメカニズムは長年にわたって数百のアプリケーションに関与しているためです。



したがって、問題を解決するためのいくつかのオプションを検討し、最も正しいものを選択する必要があります。



第二に、実際に、より簡単で高速な操作を正確に選択する必要がある理由は明らかではありません。 何をする必要があるかがより重要であると思われます。 繰り返しますが、より簡単なことをすべて行うと想像してください。 どのようなシステムになりますか...



特定の時点で実行できるため、計画に小さなタスクを含めることがあります。現時点では、2つのスケジュールされたタスクの間に小さなタイムアウトが必要です。 しかし、これらはまれなケースです。



計画に含めたい小さなタスクを分析すると、複雑さ（および変更自体の規模）が予想よりもはるかに大きくなることがわかります。 場合によっては、これによりタスクが計画から除外される可能性があります。 たとえば、期待される効果がそのような努力またはそのような重要な変更で十分に大きく見えない場合。



優先順位の選択に対するアプローチの1つは次のとおりです。

• ユーザーとアプリケーション開発者が現在抱えている最も深刻な問題を解決するタスクが選択され、
• 作業の改善に最大の効果をもたらすタスクが選択されます（私たちの評価および相談した相手の評価に従って）。
• 両方のグループの「最も」のグループは、楽観的な時間支出によって割り当てられた時間に間に合うように、一定の割合（たとえば、均等）で計画に含まれます。

たとえば、次のアプローチも使用します。

• 特定の（最初に専門家によって選択された）一連のウィッシュが選択され、
• リクエストごとに、5ポイントスケールの優先度評価が入力されます。
  
  
  • ユーザーの観点から
  • 適用されたソリューションの開発者（私たちとパートナー）の観点から、
  • プラットフォーム開発チームの観点から。
• 受信した番号は合計され、受信した優先度に従って希望がソートされます。

これにより、カウンターのさまざまな側面からのビューを考慮することができます。 このカウンターには、少なくとも3つの側面（ユーザー、アプリケーション開発者、プラットフォーム開発者）がいます。

結局、一種のキャスティングまたは競争です。



希望、アイデア、重要なニーズは表彰台に基づいて構築され、その魅力を示しています。 そして、それらを評価し（ユーザー、開発者、および私たちの意見を考慮に入れて）、最も魅力的なものを選択します。 キャストには複数のツアーが含まれることがあります。



たとえば、100人の応募者のうち、20人のファイナリストが選択され、20人から5人の受賞者が選択されます。 そして残りは次のコンテストを待っています。



説明された方法と要因に加えて、もちろん、計画にも影響するいくつかのより多くの要因（より一般的な）があります。



もちろん、意思決定は、専門家を抱える現在の状況に影響されます。

たとえば、優先度によって選択された2つのタスクが同じ専門家の積極的な参加を必要とする場合、そのうちの1つを延期する必要があります。



それでも、定期的に「緊急導入」が発生します。 たとえば、ブラウザの開発者は、アプリケーションの要件を変更することを決定しました。 ここでは、計画をすばやく確認する必要があります。 幅広いサポート対象プラットフォーム（オペレーティングシステム、DBMS、ブラウザ、モバイルオペレーティングシステムなど）を考えると、残念ながらこれはそれほどまれなことではありません。

自動化について

タスクを実装し、エラーを処理するための集中化された非常に詳細な自動化プロセス（タスクトラッキング、バグトラッキング）があります。 選択プロセスはより複雑です。 ある時点で、願いを選択して優先順位を付けるための統合された自動化システムを実装しました。 非常に複雑であることが判明しましたが、開発チームの実際のニーズをカバーしていませんでした。



現在、希望自体は特定のレジストリに記録されていますが、希望の選択と優先順位付けは単一のツールではなく、特定の自動化手法と方法を使用して各コマンドによって個別に行われます。



おそらくいつかこの問題に戻るでしょう。



一般公開されている公開ウィッシュリストはまだ作成していません。

これはかなり複雑な問題であることが判明しました（技術的にではなく、方法論的に）。

希望の収集に関して、 1cFresh.comサービスの一部として、アプリケーションユーザーのアイデアを収集するメカニズムを実装しました。 それは非常にうまく機能します。 そこのプラットフォームにも（ユーザーに直接見える部分について）多くの願いがありますが、もちろん、このリソースは主に適用されたソリューションの機能に焦点を当てています。



一方、プラットフォームでは、エラーを公開するためのリソースを作成しました（ https://bugboard.v8.1c.ru ）。 ちなみに、それもそれほど単純ではありませんでした。



優先順位に関する現在の意見を理解するために、特定のトピックの希望に関する専門家を対象としたフォーラムでターゲットを絞った投票を手配することがあります。 通常は、何らかの方向で計画を開始し、情報が不足していると感じたときにこれを行います。



希望が公開される公共の場所はありませんが、可能性のあるすべてのソース（サポートライン、フォーラム、パートナー、開発者、およびセミナーでのユーザーとのコミュニケーション）から慎重に収集します。 すべて記録しました！ :)



おそらく、パブリックリソースの作成の問題に戻るでしょう。



アイデアや希望を選択するためのすべての利用可能な方法により、私たちの仕事はより広くなります。 書かれたすべての希望から最も必要なものを選択するだけでなく、開発者とユーザーに大きな価値をもたらし、世界をより良い場所にする新しいものを作成します！



結局のところ、共通の目標を策定することができ、通常は非常に単純です。 私たちにとって、これは世界最高のビジネスアプリケーション開発プラットフォームを作成することです。



一般に、私たちの状況での開発方向と実装された機能の選択は、非常に魅力的で難しいタスクです。 多くの願いがあります。 たくさんのアイデアがあります。 たくさんやりたい！ そして、私たちの世界をより良い場所にする最適なセットを選択する必要があります。