他人のコードを学習するプロセスをどのように説明すればよいですか？ （請求状況の場合。）
編集：ジャスティン・ケイブは、この種のコミュニケーションが私の見積り/見積もりの前にあるべきであると良い点を述べました。この場合、私はまだ「既存のコード学習」活動を説明するために人々がどのような言語を使用しているかを知りたいと思っています。特に、以前にソフトウェア請負業者を扱ったことがない企業にとっては。 編集の終了
大企業向けに社内ソフトウェアをアップグレードする契約を結んでいます。同社は複数の機能の追加といくつかのバグ修正を要求しました。これは私の最初のフリーランススタイルの仕事です。
まず、アプリケーションのしくみに慣れる必要がありました。ユーザーのように学びました。
次に、ソフトウェアがどのように機能するかを学ぶ必要がありました。私は幅広い概念から始め、次に各バグ修正と機能に取り組む前に必要な詳細に絞り込みました。
少なくともプロジェクトの開始時には、既存のコードを学ぶのに、追加機能を書くよりもずっと長くかかりました。
請求書で既存のコードを学習するプロセスをどのように説明できますか？ （会社のこの部分は通常、社内で仕事をしているため、私のようなソフトウェア請負業者との取引経験があまりなく、他の誰かのコードを学習するオーバーヘッドを理解していないのではないかと心配しています）。実際の機能のアップグレードに習得するだけの時間は必要ありません。これにより、「単純なタスク」が長くかかりすぎたように見える場合があるためです。請求書を関連する手順に分割し、自分のコードを追加する前に、他の誰かのコードを学習するための大きなオーバーヘッドを請求していることを伝えます。
ジョブの請求時にこの種のアクティビティを説明する標準的な方法はありますか？
「既存の機能の確認」や「既存のコードの確認」などのタスクを請求します。新機能の複雑さに応じて、「設計xxx」タスクを追加します。これには、既存のコードへの統合ポイントを理解するために費やす時間を含めます。
新しいコンサルタントの速度を上げるのにオーバーヘッドがあることをお客様に明確に示すことは良い考えだと思います。そして、彼らが結果に満足している場合は、同じコンサルタントとの作業を続けることで節約できる可能性があります。お金。
問題の診断。
これはおなじみの用語です。自動車を修理したり、医者に行ったりした場合、診断は何が悪いのかを理解するための一般的な用語です。それはまた正確です。何が機能していないのかを理解するために、内部を調べ、すべてがどのように接続されているかを確認する必要があります。それはマニュアルなしでエンジンに取り組むのと本当に似ており、会社は以前に別のエンジンを見ることなく行ってエンジンを作りました（それはおそらくユニークです）。
長いまたは奇妙な言葉の広告申込情報には、本当に望まない質問が多くなります。 「問題の診断」は、多かれ少なかれ普遍的に理解されている概念です。
顧客への請求書には、顧客にとって驚きであってはなりません。ですから、ユーザーの視点と開発者の視点の両方から最初にアプリケーションに慣れるのに時間の大部分が費やされることを、顧客とすでに期待していることを期待しています。そして、最初のいくつかの機能の見積もりでは、コードに慣れるために十分な時間が含まれていると期待されています。
最初の請求書のほとんどの時間はアプリケーションの理解に費やされることを顧客にすでに期待している場合、それを請求書にどのように記載するかはそれほど重要ではありません。見積もりを提供し、期待を設定するときに使用した言語を使用します。これだけを伝えようとしているだけなら、問題があります。
フリーランサーとしての私の立場では、これを一般的な意味で「知識同化」のようなものとおそらく呼ぶでしょう。そして、これは最初に顧客に提供される見積もりに含まれているでしょう。
ここでは役に立たないかもしれませんが、今後の参考のために、これを将来のよりアクティブなタスクにすることをお勧めします。たとえば、コメントを付けていないコードへのコメントやコメントの追加、テストされていないコードへの単体テストの追加などに費やした時間を顧客に請求します。これらは、コードベースの理解を促進しながら、少なくとも少しの価値を追加するタスクの例です。 。
文書化中の読み取りと読み取りの間に大きな違いがない場合でも、顧客はおそらくこれらのより「アクティブな」タスクを少し心理的に好みます。そして、実際に他の人のコードを文書化することにより、単にそれを読むことよりも多くを学ぶことができます。 （これは確かにあなたが彼らのコードに対するテストを書く場合のケースです）。
これを行うと、「知識の同化とレガシーコードのテスト/ドキュメント化」のような請求書項目を作成できます。
編集：あなたが述べたような状況では、正直に言ってこの活動の費用を多分食べます。私はあなたの財務状況について話すことはできませんし、推定するつもりもありませんが、あなたが始めているときは、数時間の請求よりも、お客様の声と顧客を満足させることに非常に高い価値を置いています。それが早い段階で実効的に低いレートを意味する場合、それは良い投資かもしれません。長期的に請求可能な時間を食べることは、おそらく彼または彼女が公正な揺れを持っていると思っている満足した顧客に支払うための小さな価格です。
バグの修正：根本原因の分析。
新機能：分析、設計、統合、およびテスト。
新しいバグの紹介：ジョブセキュリティ。 :)
物事がどのように機能するかを理解し、夢のような目で私に耳を傾けるクライアントがいるなら、私はストレートCodebase Familiarizationを使います。私はすでに、彼が私に課している苦痛の流れ、およびさらなるアップグレードのために私に来ることの利点を彼に説明しました。
他のタイプの顧客の場合...（同じ扱いですが、彼は明らかに私が言っている単一の単語を聞いていません）私は次の行に何かを行きます：
Planning PhaseIntervention Planning（私は実際にこれを使用しますが、イタリア語でそれを書いたほうがいいです）
- では、多分...
Solution Planning
DiagnosisによるProblem Diagnosisの提案のanonの部分は気に入っていますが、Problemは適切に聞こえません。それは、穏やかで、偏見があり、無知であり、表面的な批判にさらされる可能性があります。
誰もがダーツを外部コンサルタントに投げたいと思っています。 （...彼は彼らと話をしながら問題の根本を理解するのに十分ではなく、彼の無知を請求しなければならなかったか、または神は何を知っているか）
私の整備士から請求書「オイル交換、sparkプラス、フィルター、タイヤの回転を確認します。エンジンのガタつきを修正し、路上テストを行います...
パーツ（項目別）、
労働x @ $ y /時間= z）
彼は労働を壊しませんし、あなたもそうしません。合計時間を請求し、あなたがしたことを説明してください。