Làm thế nào tôi nên mô tả quá trình học mã của người khác? (Trong tình huống lập hóa đơn.) [Đã đóng]

Chỉnh sửa: Justin Cave đã đưa ra một điểm tốt là loại giao tiếp này phải được đưa lên phía trước trong trích dẫn / ước tính của tôi. Trong trường hợp này, tôi vẫn muốn biết loại ngôn ngữ mà mọi người sử dụng để mô tả các hoạt động 'học mã hiện tại'. Đặc biệt là với một công ty chưa từng giao dịch với các nhà thầu phần mềm trước đây. Kết thúc chỉnh sửa

Tôi có hợp đồng nâng cấp một số phần mềm nội bộ cho một công ty lớn. Công ty đã yêu cầu bổ sung nhiều tính năng và một vài sửa lỗi. Đây là công việc theo phong cách tự do đầu tiên của tôi.

Đầu tiên, tôi cần phải làm quen với cách ứng dụng hoạt động - tôi đã học nó như thể tôi là một người dùng.

Tiếp theo, tôi phải học cách phần mềm hoạt động. Tôi bắt đầu với các khái niệm rộng, và sau đó thu hẹp vào chi tiết cần thiết trước khi làm việc với từng tính năng và sửa lỗi.

Ít nhất là khi bắt đầu dự án, tôi mất nhiều thời gian hơn để tìm hiểu mã hiện có so với khi viết các tính năng bổ sung.

Làm cách nào tôi có thể mô tả quá trình tìm hiểu mã hiện có trên hóa đơn? (Phần này của công ty thường làm những việc nội bộ, vì vậy không có nhiều kinh nghiệm giao dịch với các nhà thầu phần mềm như tôi và tôi sợ họ có thể không hiểu được chi phí học tập của người khác). Tôi không muốn chỉ dành thời gian học tập để nâng cấp tính năng thực tế, bởi vì trong một số trường hợp, điều này sẽ tạo ra một 'nhiệm vụ đơn giản' trông giống như nó khiến tôi mất quá nhiều thời gian. Tôi muốn chia hóa đơn thành các bước có liên quan và thông báo rằng tôi đang tính phí cho việc học mã của người khác trước khi có thể thêm mã của riêng mình vào đó.

Có một cách tiêu chuẩn để mô tả loại hoạt động này khi thanh toán cho một công việc?

Tôi sẽ lập hóa đơn cho các tác vụ như "Xem lại chức năng hiện có" và / hoặc "Xem lại mã hiện có". Tùy thuộc vào độ phức tạp của các tính năng mới, tôi sẽ thêm tác vụ "Thiết kế xxx", bao gồm thời gian tôi dành để tìm ra các điểm tích hợp vào mã hiện có.

Tôi nghĩ rằng đó là một ý tưởng tốt để nói rõ với khách hàng rằng có một số chi phí lớn để đưa một nhà tư vấn mới tăng tốc - và rằng, nếu họ hài lòng với kết quả này, tiếp tục làm việc với cùng một nhà tư vấn sẽ có thể cứu họ tiền bạc.

Chẩn đoán vấn đề.

Đó là một thuật ngữ quen thuộc, nếu bạn đã từng sửa chữa ô tô hoặc đi khám bác sĩ, chẩn đoán là một thuật ngữ phổ biến để tìm ra điều gì sai. Nó cũng chính xác, bạn phải đi dưới mui xe và xem mọi thứ được kết nối như thế nào để tìm ra những gì không hoạt động. Nó thực sự giống như làm việc trên một động cơ mà không có hướng dẫn sử dụng, và công ty đã đi và chế tạo động cơ mà không cần nhìn vào động cơ khác trước đó (vì vậy nó có thể là duy nhất).

Một mục hàng dài dòng hoặc có từ lạ sẽ nhận được nhiều câu hỏi hơn mà bạn thực sự không muốn. "Chẩn đoán vấn đề" là một khái niệm ít nhiều được hiểu.

Không có gì trên hóa đơn cho khách hàng nên gây ngạc nhiên cho khách hàng. Do đó, tôi hy vọng rằng bạn đã đặt kỳ vọng với khách hàng rằng một phần đáng kể thời gian của bạn ban đầu sẽ được sử dụng để làm quen với ứng dụng cả từ góc độ người dùng và từ góc độ nhà phát triển. Và ước tính của bạn cho một vài tính năng đầu tiên hy vọng đã chỉ định rằng chúng bao gồm một lượng thời gian kha khá để bạn tự làm quen với mã.

Nếu bạn đã đặt kỳ vọng với khách hàng rằng phần lớn thời gian trên hóa đơn ban đầu sẽ được sử dụng để làm quen với ứng dụng, thì bạn không nên liệt kê chính xác cách bạn liệt kê nó trên hóa đơn. Sử dụng bất kỳ ngôn ngữ nào bạn đã sử dụng khi cung cấp các ước tính và đặt kỳ vọng. Nếu bạn chỉ đang cố gắng truyền đạt điều này bây giờ, bạn đã gặp vấn đề.

Với tư cách là một người làm việc tự do, tôi có thể gọi thuật ngữ này là "Đồng hóa tri thức", theo nghĩa chung. Và, điều này sẽ được bao gồm trong bất kỳ ước tính nào được cung cấp ban đầu cho khách hàng.

Nó có thể không giúp bạn ở đây, nhưng để tham khảo trong tương lai, tôi khuyên bạn nên thực hiện điều này nhiều hơn một nhiệm vụ tích cực trong tương lai. Chẳng hạn, lập hóa đơn cho khách hàng về thời gian bạn đã trải qua và thêm nhận xét vào mã không nhận xét, thêm kiểm tra đơn vị vào mã chưa được kiểm tra, v.v ... Đây là những ví dụ về các nhiệm vụ thêm ít nhất một giá trị trong khi tạo điều kiện cho bạn hiểu về cơ sở mã .

Ngay cả khi không có nhiều khác biệt giữa đọc và đọc trong khi viết tài liệu, khách hàng của bạn có thể sẽ có một sở thích tâm lý nhỏ cho các nhiệm vụ 'tích cực' này. Và, bạn thực sự có thể tìm hiểu thêm bằng cách ghi lại mã của người khác hơn là bạn chỉ cần đọc nó. (Đây chắc chắn sẽ là trường hợp nếu bạn viết bài kiểm tra đối với mã của họ).

Nếu bạn làm điều này, bạn có thể có một mục hàng hóa đơn có nội dung như "Đồng hóa kiến ​​thức và Kiểm tra mã tài liệu kế thừa".

Chỉnh sửa: Trong tình huống của bạn như được mô tả, tôi thực sự có thể ăn chi phí của hoạt động này. Tôi không thể nói chuyện với tài chính của bạn và tôi không có ý đoán, nhưng khi bạn bắt đầu, tôi đã đặt giá trị cao hơn rất nhiều vào việc chứng thực và làm hài lòng khách hàng hơn một vài giờ thanh toán. Nếu điều đó có nghĩa là một tỷ lệ thấp hiệu quả trong thời gian đầu, nó có thể là một khoản đầu tư tốt. Ăn một số giờ có thể thanh toán trong thời gian dài có lẽ là một cái giá nhỏ để trả cho một khách hàng hài lòng nghĩ rằng anh ta hoặc cô ta có một sự rung chuyển công bằng.

Sửa một lỗi: phân tích nguyên nhân gốc rễ.

Tính năng mới: phân tích, thiết kế, tích hợp và thử nghiệm.

Giới thiệu các lỗi mới: bảo mật công việc. :)

Với một khách hàng thích tìm hiểu cách mọi thứ hoạt động và lắng nghe tôi với đôi mắt mơ màng, tôi đi thẳng Codebase Familiarization . Tôi đã giải thích cho anh ấy những dòng đau đớn mà anh ấy đặt tôi vào, và lợi thế của việc đến với tôi để nâng cấp thêm.

Với một loại khách hàng khác ... (đối xử tương tự, nhưng rõ ràng anh ta không nghe một từ nào tôi đang nói ) Tôi sẽ đi với một cái gì đó trên dòng:

• Planning Phase

• Intervention Planning

  (Tôi thực sự sử dụng cái này, nhưng tôi viết nó bằng tiếng Ý, trong đó nghe có vẻ hay hơn)

• Sau đó có thể... Solution Planning

Tôi thích Diagnosisphần Problem Diagnosisgợi ý của anon, nhưngProblem âm thanh không phù hợp với tôi. Nó có thể mở ra cho những lời chỉ trích nhẹ nhàng, thiên vị, thiếu hiểu biết và hời hợt ... có thể để lại một hương vị xấu phía sau.

Bạn biết đấy, mọi người đều muốn ném phi tiêu vào nhà tư vấn bên ngoài, và họ làm được. (... Giống như anh ta không đủ tốt để hiểu được gốc rễ của vấn đề trong khi nói chuyện với họ, và phải lập hóa đơn cho sự không biết gì của mình, hoặc chúa mới biết điều gì)

Thợ máy của tôi gửi cho tôi một hóa đơn "Thay dầu, tia lửa cộng, kiểm tra bộ lọc, vòng quay lốp. Sửa chữa động cơ, kiểm tra đường .....

Các bộ phận (chia thành từng nhóm),

Lao động x @ $ y / giờ = z)

Anh ấy không phá vỡ lao động, bạn cũng không nên. Hóa đơn cho tổng số giờ, và mô tả những gì bạn đã làm.