人間としてOA製品の過程で経験した穴【チェーン家編】

 ， ， 

システムの問題:

1、レポートのクエリーが遅い、他の応用速度を引きずる

解決策:まず、レポート・クエリーとインタフェース・フォーム・クエリーは、読み取り専用ライブラリで実行できます.また、レポート・クエリーでは、クエリーの量が最大ですが、クエリーの遅延データ(毎日1回同期)をサポートする必要があります.インタフェース・フォーム・クエリーでは、情報量は小さいが、リアルタイム・クエリーの最新情報を満たす必要がある.クエリーの頻度が頻繁であるため、キャッシュの設計が必要です.システム機能設計では、レポート・クエリーとインタフェース・フォーム・クエリーも区別します.

2、原価計算に関わるため、組織が責任者を交換するたびに、新しい同名組織(orgidが異なる)を作成し、元の組織を閉じて名前を変更する必要があります。

解決方法:“組織-計算組織”を創立して、1対Nの構造、1つの組織のライフサイクルの中で複数の計算組織を含んで、システムは計算組織の各サイクルと対応する責任者を記録します.組織は現在の責任者を記録します.

3、組織ID(orgid)に関連して書かれたルールの一部は、組織アーキテクチャの調整に関連するたびに、関連の影響をチェックする必要がある。

解決方法:まず2の方法で組織アーキテクチャの調整を保証し、組織自体idが変わらない.次に、IDに書き込む必要があるルールについては、統一された構成インタフェースで、強調表示され、柔軟に修正できることをお勧めします.また,複雑なビジネスルールに対しては,単独のfuncを確立して処理し,type値を返す.システムの基本論理は異なるtypeに対して、異なる処理方式を適用するだけである.

4、システムロジックの上でいくつかelseのデフォルトの規則を設計して、一部のシーンは考慮していません。

解決方法:デフォルトのルールを慎重に使用し、特にいくつかの重要なデータの場合、ソースは対応するtypeに一致する必要があります.プリセットシーンを超えた場合は、エラーを報告し、処理しないことを示す必要があります.そうでないと、予期せぬシーンでシステムの結果がエラーになります.

5、財務計算のシナリオは毎月3日に実行し、先月末までのデータソース情報に従って処理する必要があるが、データソース情報は毎日更新される。

解決方法:レプリケーションにより、月末に現在の時刻の情報をバックアップし、必要に応じて使用を取得します.

6、開発した人材募集ライブラリは、データ量が比較的大きいため、インタフェースで照会したフォームの内容は、ソートルールを追加させないように開発されている。

解決方法:ES検索エンジンを採用し、クエリー性能を向上させる.(空間で時間を変える)時効性の要求が高くないデータについては,夜の空き時間に並べ替えを完了することができ,推奨システムを参照する.インタフェースに含まれるテーブル全体のクエリーを減らす機能.(タスク総数表示など)

7、プロセスはシステムの中で死んで、いったん業務ロジックが調整されると、開発に力を入れてシステムの下層配置を修正する必要がある。

解決方法:人事異動など、特に発展中の企業では、プロセスが安定しにくい.構成可能なプロセス管理システムと構成機能を採用することは、価値があります.しかし、いくつかの安定したプロセスについては、カスタマイズ、使用インタフェースやインタラクションなどを改善し、頻繁な調整による異常を避ける必要があります.したがって、システム設計時に、カスタマイズと構成の両方を両立させる必要があります.簡単な承認、文書類のプロセスについては、汎用的で柔軟な承認チェーン管理プラットフォーム(署名/承認システムのような)を行うことをお勧めします.

8、開発には常にデータ処理を行う必要があり、多くの時間を費やす

解決方法:データ処理のたびにスクリプトをgitに配置し、アーカイブを分類して記録します.開発は順番にデータ処理をし、集中して時間を作る.

ビジネス上の問題:

1、権限管理の混乱

解決方法:組織、組織木と職場に厳格に従って対応権限を配置し、単独で人に配属する権限を避ける.同時に、一人一人のポジション名を規範化し、ある人の権限に問題がある場合、ポジション名が合理的かどうかを監視する.(会社は職場、対応する職責範囲を明確に定義する必要がある)

2、一部の機能がオンラインになった後、他のモジュールの機能に影響を与えた

解決方法:システム機能が開発を確認する前に、開発する需要をすべての関連部門に知らせる必要がある.システム機能の開発後、需要部門に連絡してUATテストを行う必要があり、業務側はより広範なシーンをテストする必要がある.すべての関連部門に、新しい機能のオンライン時間を通知します.製品は、最終的な実装の結果が予想と異なること、特にフロントエンドのインタラクションを避けるために、テストに参加する必要があります.

3、いくつかの大きな需要があって、開発は理解していないで、時間と問題を評価することができません

解決方法:大きな需要と計画は、開発に事前に通知し、開発に準備をさせる必要がある.いくつかの古いシステムやよく使われていないシステム、機能の調整についても、開発を事前に知らせる必要があります.開発が容易で予め理解しておく.

4、部門のドキュメントが欠けている。古いシステムやよく使わないシステム、機能については、コードを調べて理解する必要がある。

解決方法:製品は需要問題PRDを保存し、アップロードし、製品の原型を完備する必要がある(重要).開発自身も関連システムのドキュメントを残して、特に各仕事の異動、以上の材料の引き継ぎをしっかりと行います.

5、製品テストの開発に関する仕事のポイント

開発の仕事の鍵:細かく、周到な思考技術の実現である.開発時間が正確かどうかを評価することは、開発が専門的であるかどうかの結果指標である.製品の仕事の肝心な点:需要に対する徹底的な分析は、製品の肝心な仕事の一つであり、達成する効果ははっきりと開発に聞かせることができ、理にかなっていて説得力がある.テストの仕事の鍵:テストは考えが足りないことを恐れます.テストに対する要求は些細な測定ではない.重要なプロセスと重要な機能を必ず区別します.重要な機能について考慮を怠ってはいけない.

6、どのように需要に対応するか

より上のレベルの人を探してコミュニケーションすると、あるリーダーの計画に由来する需要がある可能性がありますが、具体的に伝えた人は本当の需要に伝わっていません.多角度、多角度の需要を理解し、同時に聞くと明らかになる.仕事自体がビジネスに価値がなければ、それを最適化する必要はありません.

7、需要の説明方法

業務、製品に対して、業務シーンによって需要(用例法)を述べ、開発に対して、インタフェース構造と機能に従って述べるべきである.

製品の需要分析と設計のいくつかの見方

1、需要の設計は区別する必要がある:核心と補助モジュール2、核心の設計は業務に対して十分な理解を必要とし、未来の発展に対して一定の予想がある.一度決めたら、ほとんど変わらない.開発業務機能の実現における最下層フレームワークである.良い考え方は、需要要素を細かく分解すればするほどよくなり、コアが何なのかを分析し、属性表、操作表、プロセス記録表の違いと作用範疇を考慮することです.3、補助モジュールの設計は相対的に柔軟で、敏捷な開発の構想を参照することができて、多反復のモードを採用して、テストと開発の循環は行います.4、製品のリスクコントロール:システム性リスク、安全性リスク、操作性リスク、プロセス性リスク.5、システム性リスク:開発中、異常を管理する必要がある.操作性リスク:大量のユーザーテストと試運転を行い、操作側にヒントを与え、応用論理の面でユーザーが「不正」な操作を実行することを制限する.プロセス性リスク:設計モニタリングの一環、品質検査の一環、専門ツールを採用してプロセスモニタリングを行い、プロセスが自己交渉しているかどうかを検査する.