👩🏼‍✈️ 🏎️ 👨🏻 ソフトウェア製品の実装。ビジネスコンサルタントの仕事の特徴。パートIII。ファイナル ✌🏻 ♂️ 🧢

知識を得るだけでは十分ではありません。それらのアプリケーションを見つける必要があります。願うだけでは十分ではありません。

ゲーテ

中小企業のビジネスコンサルタントの仕事に関する私の一連の記事の読者に、私が以前に言った記事であなたに思い出させたい：

新しいクライアントとの作業を開始する方法、彼の会社の機能を理解する方法、新しいソフトウェア製品を選択する方法。
製品を提示し、選択した顧客を説得する方法
ソフトウェア製品の実装段階でのビジネスコンサルタントの仕組み。

新しいソフトウェアへの移行は、ほとんどの場合、中小企業のビジネスコンサルタントの仕事の根底にあることを思い出させてください。多くの理由があります。また、新しいより効率的な作業スキームには、新しいソフトウェアが必要であり、ほとんどの場合、ビジネスの自動化が不十分であり、顧客の問題などに対する効果的なソリューションを提供するために必要な分析が不足している

新しいソフトウェア製品を導入する過程で、ビジネスコンサルタントは会社の部門向けに更新された作業スキームも作成します。

新しいソフトウェアには十分に強力な分析機能があり、まさにこのビジネスに必要な分析機能を備えているため、作業のすべての段階で制御と会計のレベルが向上しています。
各ユニットの作業に関するドキュメントが作成されています。これには、新しいソフトウェア製品を使用するための指示だけでなく、ユニットの作業に関する一般原則、専門家向けの職務記述書なども含まれています。
自動化のレベルが上がり、その結果、作業プロセス全体の速度と効率が向上します。
必要に応じて、作業の過程で、ビジネスコンサルタントは、スタッフの変更の可能性を含め、ユニットの近代化、ユニット間の相互作用について提案します。

ビジネスコンサルタントの仕事は、新しいソフトウェア製品を導入するだけでなく、ビジネス上の問題を解決することであるということを理解することは非常に重要です。したがって、一部の部門または個々の専門家が十分に効率的に作業していないことがわかった場合、作業を最適化する方法を知っている場合は、この問題についてクライアントに提案し、プロジェクトで作業するプロセスでそれらを実装するようにしてください。ほとんどの場合、ビジネスの問題を解決するためにビジネスコンサルタントを招待し、変更の必要性は明らかであるため、ビジネスヘッドは作業の最適化に関する私の提案を承認します。そして、次の段階、システムのテスト運用とプロジェクトの終了についてお話したいと思います。

試運転

そのため、ソフトウェア製品が完成し、クライアントの要望を可能な限り満たしています。さらに、ほぼすべてのドキュメントが作成されました。プログラムの動作を注意深くチェックする時が来ました。つまり、テスト操作。
原則として、試験は残留物の移送直後に開始し、定期的に実施できます。しかし、より多くのデータが新しいプログラムに導入されるほど、テストプロセスは改善されます。この段階はベータテストと呼ばれます。開発者とユーザーによるソフトウェア製品のテスト。

ベータテスト-製品のほぼ最終バージョン（通常はソフトウェアまたはハードウェア）を集中的に使用して、製品の市場への最終リリース（リリース）の前に大量にエラーを除去するために、操作の最大エラー数を特定します消費者に。社内の開発者やテスターが実施するアルファテストとは異なり、ベータテストには、製品の前述の予備バージョン（いわゆるベータバージョン）にアクセスできる製品の将来の一般ユーザーからのボランティアが含まれます。
ウィキペディア

本質的に、ベータテストは、既に準備ができているソフトウェア製品のテストです。同時に、実際に使用するには早すぎます。ユーザーに提供する前に、エラーの質の高い検索を行う必要があります。

テスト操作を開始するために必要な要因：

残り物はすべて転送済みです。
主な改善が行われました。
顧客側には、テストを担当できる人がいます。

最後の段落はよく見る価値があります。古いプログラムを非常によく知っており、新しいソフトウェア製品について詳しく知っている顧客側の人の助けが必要になります。作業の最後に、実装が成功したこと、ソフトウェア製品が正常に動作したこと、プロジェクトを終了できることを確認できるのはこの人です。

当然、会社の長があなたのサービスの代金を支払い、通常は誰か他の人があなたの仕事を引き受けます。会社の責任者は従業員から、ソフトウェア製品の詳細なチェックを含む責任者を任命します。その結果、この従業員は、作業が本当に効率的に行われ、プロジェクトを閉じて支払いができることを経営者に報告します。あなたと彼の両方にとって、この担当者が最初からテストに参加することが最善です。

テスト操作は、複数の反復で実行できます。

原則として、ソフトウェア製品をテストした人は誰でも、テストは常に一定の反復回数で構成されていることを知っています。ここでの作業のスキームは簡単です：

プログラムをチェックした
検出されたエラー
これらのバグを修正
もう一度作業を確認しました

このサイクルは、ソフトウェア製品の品質が顧客を完全に満足させるまで、必要な回数繰り返されます。

トレーニングと同時にテスト操作を実施できます

一方、この決定は非常に危険です。多くの場合、会社の従業員はすでに変更を受け入れることを強く求められており、新しいプログラムが適切に機能していないこと、十分に機能していないことがわかった場合、この抵抗はさらに大きくなります。

一方、このアプローチは時間を節約するだけでなく、作業の初期段階で多くの欠点を特定するのに役立ちます。トレーニング中に、人々は質問をし、特定のアクションを実行する方法、ある種のレポートまたはドキュメントを取得する方法を尋ねますが、新しいプログラムにはそのような解決策がないことを理解しています。これはあなたにとって非常に便利です。以前見逃していた仕事のいくつかの重要なポイントが明らかになるからです。

また、ユーザーがトレーニングとテストを組み合わせたときに否定的でないようにするには、次の2つの条件を満たすことが重要です。

部門の従業員は、特定のユニットの作業に必要な基本機能が準備できたときにのみ、ソフトウェア製品にアクセスできます。完全に「未加工」のバージョンを表示することはできません。ユーザーには最終バージョンに近いオプションが表示されます。
常に作業が進行中であることをユーザーに説明し、感謝の気持ちで質問やコメントを受け入れ、プログラムとの共同作業の結果に応じて、必要なツールが表示されることを示します。これにより、ユーザーの誤解や抵抗を避けることができます。

ソフトウェアをテストするとき、およびトレーニング中は、主に1〜2人の従業員と作業することが最善です。トレーニング中に強調し始めた人、他の人よりもソフトウェア製品をよく知っている人もテストに参加する必要があります。これにより、彼らはプログラムについてより多くのことを学び、結果に自信を持つことができ、テストプロセスの資格のあるヘルパーがより多く得られます。

テスト運用中にドキュメントを準備する必要があります

さまざまな部門や従業員のためにかなり大量のドキュメントを作成する必要があります。そして、この問題にすぐに対処し始めるほど、より良い結果が得られます。原則として、テスト操作で一部のモジュールまたはプラグインの準備ができていて、顧客のすべての要件を満たしていることが示された場合、顧客のためにすでに指示を書くことができます。

統合テスト

多くの場合、新製品を導入するだけでなく、他のソリューションと統合する必要があります。たとえば、クライアントとの作業を効果的に自動化するには、多くの場合、1C製品の一部をサイトに統合する必要があります。

そして、テスト中に両方のソフトウェア製品を使用することが非常に重要です。さらに、将来このサイトで作業する専門家は、サイトで作業する必要があります。そして、1Cの側から、1Cに入ったときにこの情報を処理する人がテストに参加します。

最善の解決策は、すべての人を1つの部屋に集め、共同で包括的なテストを実施することです。

たとえば、注文の注文を処理する完全なサイクルを確認するには、調達部門のスペシャリストと営業部門のスペシャリストをまとめる必要があります。販売部門は、複数の顧客注文と購買部門のスペシャリスト（顧客注文に基づいたサプライヤーへの注文）を作成します。その後、商品が到着し、販売が行われます。すべての段階がはっきりと見えており、それぞれの場合、作業は彼の作業プロセスのすべてのニュアンスを知っている専門家によって実行されます。

別の例。 1CとZoho CRMを統合します。同時に、連絡先が1CのZohoで作成されます-連絡先担当者。セールスマネージャーの1人がZohoで顧客カードを作成し、他の1人が1C環境で動作します。 Zohoから受信したデータに基づいて、1Cのマネージャーは連絡先とパートナーを作成します。

会社の仕事のスキームが、両方のマネージャーがZohoと1Cの両方で働くようなものである場合、テスト中に場所を変更することは理にかなっています。

多くの場合、連絡先とリードの作成は異なる従業員の間で分割されます。ただし、通常は1人で行っても、テスト用に2つ取ってこの作業を共有することをお勧めします。そのため、システムをより正確にチェックでき、ご存じのように「1つのヘッドが優れており、2つのヘッドが優れています」。

また、すべてのテストでは、プロジェクトをホストする責任者を招待する必要があることを忘れないでください。もちろん、現時点で忙しい人は参加を主張する価値はありませんが、機会があれば参加させてください。そうすれば、プログラムの仕組みを理解しやすくなります。

ソフトウェア製品をテストするまでに準備ができていることをもう一度思い出してください。いくつかのエラーまたは欠点が含まれている場合があります。ただし、ユニットの作業に必要なすべての機能が存在する必要があります。また、テストをできる限りワークフローに近づけるようにしてください。

テスト段階へのプログラマーの参加

すぐにはっきりと言います：プログラマーはテストプロセスに参加しません。絶対に。決して。彼はエラーを修正し、改善に取り組んでいます。しかし、テストは彼の仕事ではありません。私の友人が言うように-ITスペシャリストの最終テストを決して信用しないでください。

一度自分でそのような間違いを犯したら、プログラマーを信頼し、彼の言葉から仕事を受け入れました。それからこれは真実ではないことに気づきました。クライアントの前に仕事の質を担当するのは、コンサルタントであるあなたです。さらに、テストはプログラマの仕事とは関係ありません。はい、彼は自分でいくつかの間違いを明らかにします。それでも、これは彼の仕事ではありません。

私が個人的に使うテストの最初の段階。はい、これはかなり退屈で、最速のプロセスではありません。しかし、このようにして、ソフトウェア製品の作業と特定のビジネスの改善に精通し、作業の品質を個人的に確信します。

エラーを検出した場合、エラーに関する情報をプログラマーに渡し、プログラマーがエラーを修正し、テストを繰り返します。そして、私が結果に個人的に満足した場合にのみ、責任者とプロセスのすべての参加者とのテストのために新しいリリースをもたらします。

その結果、すべての関係者はソフトウェアの操作に精通しており、誰もが定性的に機能することを理解しており、定性的にタスクを完了したことを確認する準備ができています。

テストの落とし穴

テスト段階で最も難しいのは、ワークフローを整理することです。テストに参加しなければならない従業員は、主要な仕事で忙しく、それらを同時に集めることは非常に困難です。一方、従業員自身からの反対に直面するかもしれません。テストに参加することは従業員にとって追加の負担であるため、これは驚くことではありません。さらに、一般的に人々は変化に抵抗する傾向があります。

したがって、各部門で最初に行うことは、テストの責任者を任命することです。

ほとんどの場合、責任者を選ぶとき、会社の経営陣の参加なしでやろうとします。理想的なオプション：責任者の任命に原則的に同意し、候補者を選択します。もちろん、彼らは同意する必要がありますが、候補者のリストを責任者に持ち込み、人々がこの作業に参加することに反対していないことを知らせると、マネージャーはほとんど問題なく候補者を承認します。

これは実際にはどのように起こりますか？人が良い接触をして、本当に彼を納得させることができると思うならば、私はそのように行動しています。必要な従業員が明らかに抵抗している場合は、経営陣を通じて彼を担当者として任命するという問題を解決する必要があります。

自分を覚えて従業員に説明することが重要です。もちろん、あなたは上司ではなく、管理上のレバレッジはありませんが、プロジェクトを最終段階に進める準備はできています。

同時に、ビジネスコンサルタントは人々を納得させることができると信じています。マニュアルは最後の手段としてのみ連絡する必要があります。「上から」の管理上の決定は、人々との接触を確立する助けにはならず、場合によってはその逆も成り立ちます。この作業が行われることを人々に納得させることを学び、それを行うのに最も適していると思われるのは従業員です。

積極的な抵抗に直面している場合、例外として、リーダーを関与させることができます。その後、通常、次のことが行われます。リーダーは、特定の人の責任者としての任命を個人的に確認します。最も難しい場合は、リーダー、あなた、および従業員の3人の会話があります。しかし、そのようなことはまれな例外であるべきです。ほとんどの場合、従業員の非常に積極的な抵抗の場合でさえ、1〜2回のそのような会話の後、協力の拒否は独力で停止します。

ボイコット：アクティブおよびパッシブ

あなたが遭遇するかもしれない最も一般的な従業員の抵抗オプションの1つはボイコットです。ここでは、余分な仕事をしたくない責任者だけでなく、原則として従業員の抵抗についても話します。ユニット全体がこのように「ストライク」することもあります。

心配しないでください、そのような反応は正常です。これらの人々の靴に身を置く。彼らは冷静かつ習慣的に働き、責任を知り、習慣的な行動に従事しました。そして、変化をもたらすビジネスコンサルタントがやって来ます。従業員はトレーニングを受け、新しいソフトウェア製品を習得する必要があります。さらに、それらの責任はしばしばいくらか変化し、管理の制御はほとんど常に上昇します。これは、とりわけ、新しいレベルの自動化がその目的に向けられているためです。また、場合によっては、ビジネスコンサルタントの登場後、部門の再編成や解雇が行われることもあります。

さらに、従業員の目にこれらのすべての変更とトラブルを犯したのは、ビジネスコンサルタントです。プロジェクトでは、私は灰色の枢機inalと見なされることが多く、もちろん、彼らは私を好きではありません。これは正常です。人間性では、変化に抵抗します。中国人でさえ、「あなたは変化の時代に生きている」という呪いを持っていることを忘れないでください。

したがって、ボイコットに直面している場合、心配する必要はありません。これはあなたの仕事で最も一般的な瞬間です。ボイコットの兆候をタイムリーに認識し、この問題を効果的に解決できることが重要です。

したがって、ボイコットには2つのタイプがあります。

アクティブ
受動的

抵抗の積極的な選択肢は、シンプルで明示的で理解しやすいものです。あなたの目の中の男は、彼があなたに反対していると宣言します。時には脅威にさえ到達します。そして、ここでも、この人はあなたに対して個人的に何もしません。彼はあなたが擬人化する変化に反対しています。そのような人は納得できる場合もありますが、多くの場合、問題はリーダーを通じて解決されます。

受動的ボイコットを特定するのはより困難です。一方で、誰も反対せず、誰もが協力する準備ができています。一方、必要な人を集めることはほとんど不可能です。彼らは、緊急の仕事で忙しく、絶えず欠席し、最後の瞬間に他のことをすることを余儀なくされます。

ここでは、説得や企業経営を通じて行動することもできます。同時に、人々と口論する必要はありません。これは一般に受け入れられません！また、ここであなたが主人であることを示すことはできません。あなたはメインではありません。あなたには直接の力はありません。しかし同時に、あなたはリーダーの意志の継続です。特定のタスクのために雇われたことを従業員に説明してください。そのため、マネージャーもあなたに尋ねます。そして、従業員の抵抗のためにあなたのために設定されたタスクを解決できない場合、この事実を隠さないでしょう。

通常、これは人々が考えて協力し始めるのに十分です。しかし、同様の説明が機能しない場合、残っているのは頭に行くことだけです。そして、それはすべて人次第です。彼は指導者の命令に従うか、おそらく、解任されます。はい、変化への抵抗が従業員と別れなければならないポイントに達したとき、私はしばしばそのようなオプションに出くわしました。

人を好きになり、彼らとコミュニケーションをとる。私はよく従業員と非公式にコミュニケーションを取り、昼食のために彼らと一緒にカフェに行き、お茶やコーヒーを飲みます。したがって、私は連絡を取り、車ではなく、不快なプロセスの具体化ではなく、自分の仕事をする人だけを見ようとします。

しかし、何であれ、あなたはあなたの不動も示さなければなりません。従業員は、このプロジェクトが実装され、正常にタイムリーに実装されることを理解する必要があります。どんなに。

自分の弱さや不安を決して見せないで、間違いを認めましょう！

自分を専門家として位置付けていることを忘れないでください。ビジネスをより良く構築する方法を知っており、作業プロセスの再構築に参加する準備ができているのはあなたです。人々はこれを見て、経営陣がすでに決定を下していることを理解し、変化は避けられないことに同意します。

しかし、あなたも生きている人であり、あなたは間違っている可能性があります。そしてもちろん、会社の従業員は間違いなく間違いに気づき、質問を始めます。どうする決して嘘をつかない、言い訳をしないでください。落ち着いて正直に言う：「私は間違っていた。」覚えておいてください。トレーニング段階では、「わからない」と言うのをためらわないでください。ここでも状況は似ています。

はい、あなたは専門家です。はい、あなたは多くのことを知っており、どのように特定のビジネスの機能を理解し、欠陥を特定し、それらを修正するのを助けたかを知っています。しかし同時に、あなたは生きている人です。しかし、間違いを犯すのは人間の本性です。したがって、質問の場合の理想的な解決策は、エラーを正直かつ冷静に認め、それを短時間で修正することです。したがって、芽の問題を破壊することにします。

また、プログラマを責めようとしないでください。間違いを犯したのはプログラマーであることが誰にでも明らかだったとしても。あなたとあなただけがプロジェクトに責任があることに注意してください。プログラマーが間違っていて、あなたが彼の仕事を受け入れた場合、問題はあなたにあります。私は、他の誰かを非難することは受け入れられないと信じています;私は、クライアントと「これらのプログラマーは愚かである」と議論することは受け入れられないと信じています。そして、私はいつも間違いのせいは私のものだと率直に言っています。そして私のものだけ。

プロジェクトの責任はあなたにあることを忘れないでください。あなたはこの仕事に対して報酬を受け取ります。そして、すべての否定性もあなたにあるべきです。もちろん、最初はすべてのネガティブさをあなたに負わせるのは難しいです。クライアントがいくつかの間違いや短所に遭遇すると、クライアントから否定的な態度を取り、変更に不満を抱いている従業員から否定的な態度を取ります。しかし実際には、徐々に慣れてきています。

私は個人的にこの否定性について何も悪いことは見ていません。これは私の仕事です。そして、私はすべての感情が私としてではなく、人としてではなく、私がもたらし、擬人化するプロセスに向けられていることをよく覚えています。したがって、私も感情を知覚します。その後、彼らは理解し、感謝しますが、今のところ彼らにとっても困難です。

クライアントとの関係の正確性に関するもう1つの重要なポイント。「彼は彼の義務に対処していない、彼は解雇されなければならない」と決して言ってはいけない。それはあなたには関係ありません。あなたはいくつかの重要なことを知らないかもしれません。人はタバコを吸って飲むことができますが、たぶん不快な人です。これはすべてあなたに関係ありません。したがって、詳細、作業、およびそれに関連するものについてのみ話します。あなたが従業員の仕事に満足していない場合は、そのような状況では彼は対処できないと言ってください。特定のプロセスとその課題について話します。あなたは、この従業員またはその従業員の性格だけでなく、彼の専門的な資質も気にしません。あなたが彼を訓練することは重要です。これに焦点を当て、リーダーシップに焦点を当てます。

テスト完了

もう一度、テストプロセスの手順を繰り返します。

プログラマーによるテスト。作業を引き渡す前に、プログラマーは特定したエラーを修正します。
テストはあなた自身のものです。クライアントの次のリリースを設定する前に、可能な限り詳細にプログラムの動作を個人的にテストします。
プロジェクトの責任者との共同テスト。この担当者と一緒に、完了した作業を詳細に確認するか、改善の品質を確認し、すべてが機能することを確認します。
プロセスの直接参加者によるテストは、実際の作業に可能な限り近いモードで行われます。人々は新しいソフトウェア環境で責任を果たします。彼らは、システムがいかに便利かつ正しく機能するかをチェックします。

そして最後に、すべての準備が整い、ほとんどのエラーが特定されたら、最大数の従業員にシステムへのアクセスを許可する必要があります。人々が2つのシステムで並行して作業できるようにします。すべてを複製する必要はありません。ただし、可能であれば、両方のシステムで作業する必要があります。したがって、ソフトウェア製品は完全なベータテストを受けます。十分に大きな負荷のある動作モードでマルチユーザー環境の動作を確認する。

この段階では、いかなる場合でも、プロセスの通常の参加者に連絡を与えないでください！

従業員からの質問はすべて、担当者に渡さなければなりません。この時点で、この従業員はあなたとほぼ同じくらいソフトウェアを知っているはずです。彼はさまざまな質問に答え、新しいプログラムでこれまたはその作業を実行する方法を提案できるはずです。一般的に、責任者のトレーニングのレベルは、現在の作業に関する質問のレベルで、プロジェクトの終わりにあなたに気付くことができるようなものでなければなりません。

プロジェクトの開始

したがって、テストは成功し、誰もがこれに同意します。次に何が起こるか：

システムにはすでに現在の残高があり、ディレクトリに記入されており、必要なすべてのドキュメントとレポートがあります。
必要なすべての統合が存在し、効率的に機能します。
作業に必要なすべてのドキュメントがあります。さらに、クライアントがあなたの観点から重要なドキュメントを要求しなかった場合は、自分でそれを知らせてください。彼がこの文書またはその文書を拒否する場合は、電子メールでの連絡などにより、この情報をテキスト形式で修正してください。
サーバーは動作するように設定されています。また、すべてのプラグインをクライアントに転送しました。

これらのすべてのポイントが完了したら、システムを起動できます。

起動は閉じられたプロジェクトではないことを理解することが重要です。これもお客様に説明してください。ローンチ後も、プロジェクトの複雑さに応じて、1〜2週間そこにいます。

会社の従業員は、しばらくの間新しいプログラムで働き、それに慣れ、すべての機能を理解する必要があります。そして、あなたが古いプログラムへの出発後に彼らが戻らないと確信している場合にのみ、プロジェクトは完了したとみなされます。

この段階では、最大限に作業し、ほとんど常にプロジェクトに参加する必要があります。作業の質を管理し、助け、プロンプトを出し、最新の変更を加える必要があります。そして今、それどころか、普通の従業員にも電話を任せることができます。常に連絡を取り合う必要があります。

たとえば、パン屋でソフトウェア製品を発売したとき、私は3日間1日3〜4時間寝ました。私はほとんど常に企業にいました。このプロジェクトを率いたプログラマーは、もっとリラックスできるでしょう。可能性のある欠点をすばやく修正するために、彼らは単に連絡を取り合う必要がありました。ベーカリーが24時間体制で働いていたという理由だけで、私はほぼ1日プロジェクトに費やし、さまざまな時間にさまざまなプロセスを制御する必要がありました。

また、クライアントは、この期間中、プロジェクトでの作業の最後の週、すべての改善とヘルプがプロジェクトの支払いの一部として無料である、またはむしろそうであることを正確に知って理解する必要があります。さらに、すべての作業は個別に支払われます。

なぜこれが重要なのですか？クライアントが数日であなたの助けが終了することを理解した場合、あなたはどんな行動にもお金を払わなければなりません、彼は本当に定性的に仕事のすべてのニュアンスをテストします、従業員はこの間にすべての質問を理解し、すべてが正常に機能することを確認しますそうしないと、非常に長い間、修正要求や質問を受けるリスクが生じます。すでに新しいプロジェクトが稼働しているので、そのプロジェクトとそのソフトウェア製品の詳細と機能を忘れることもできます。そして、あなたはまだ改善を求められます。明確な期限を設定しないと、人々は真剣にチェックを行わず、偶然問題が発見されたときに電話をかけ始めるからです。

これをクライアントに説明する方法は？仕事を終えた後、あなたはこのプロジェクトでプログラマを長い間維持することができません。まだ専門家の時間を払わなければならず、プロジェクトからの利益がそのような費用を許さないからです。過去のプロジェクトに常に携わることはできません。さもなければ、今のように生産的に新しいプロジェクトに没頭することはできません。さらに、あなたは結果を確信しています。また、プログラムをテストし、プロジェクトを受け入れた人々も確信しています。そして、ほとんどの場合、原則として改善は必要ないか、会社の業務に何らかの変更が生じたときにすでに必要であると理解しています。

率直に言って、仕事へのアプローチを自由に説明してください。中小企業は、あなたと同様にお金と時間を大切にする方法を知っている人です。したがって、あなたの議論は彼らに近く、理解できるでしょう。

産業開発。護衛

プロジェクトでうまく働いていれば、メンテナンスは実質的にゼロになります。さらに、私はほとんど常にリモートで護衛を費やしています。

これはどのように起こりますか：

1〜2人の顧客の専門家にタスクの説明方法を教えています。これにはjingプログラムを使用します。必要に応じて、問題を説明するテキストを含むスクリーンショットまたはビデオがタスクに追加されます。次に、この情報パケットが私に送信されます。
すべてのサポートは、作成、バグ追跡システムを介して行われます。これにはRedmineシステムを使用します。もちろん、これは必要ではありません。個人的にはとても便利です。

ですから、何かを変更する必要がある場合、クライアント側の専門家が書面で私のためにタスクを設定し、それを実装します。そして、月末（または月に2回）に、完了した作業に関するレポートを送信し、請求書を発行します。

もう一度思い出させてください。プロジェクトで良い仕事をした場合、そのような改善はまったくないか、単一の改善になります。したがって、護衛はあまり利益をもたらさない。

一方、これは非常に重要であり、メンテナンスは特に有益なプロセスではありません。 , .

: « , , , , ».

: , - , - . , - . :

, , .
. .
, , , .

, .

!

, . , , . , , , , .. など .

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

, . , , , , , . , , .
: - , , .

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

この一連の記事が、中小企業のビジネスコンサルタントの仕事、その特徴、落とし穴、ニュアンスを紹介するのに役立つことを願っています。私たちの国のこのニッチはまだ満たされていないことを思い出させてください。専門家が不足しているため、同僚になりたい人には質問に答えたりアドバイスをしたりする準備ができています。

ソフトウェア製品の実装。 ビジネスコンサルタントの仕事の特徴。 パートIII。 ファイナル

試運転