¿Cómo debo describir el proceso de aprender el código de otra persona? (En una situación de facturación) [cerrado]

Editar: Justin Cave hizo un buen punto de que este tipo de comunicación debería estar al frente en mis citas / estimaciones. En este caso, todavía estoy interesado en saber qué tipo de lenguaje usa la gente para describir las actividades de 'aprendizaje de código existente'. Especialmente para una empresa que no ha tratado con contratistas de software antes. Finalizar edición

Tengo un contrato para actualizar un software interno para una gran empresa. La compañía ha solicitado múltiples funciones adicionales y algunas correcciones de errores. Este es mi primer trabajo de estilo independiente.

Primero, necesitaba familiarizarme con el funcionamiento de la aplicación: la aprendí como si fuera un usuario.

Luego, tuve que aprender cómo funcionaba el software. Comencé con conceptos amplios, y luego me limité a los detalles necesarios antes de trabajar en cada corrección de errores y función.

Al menos al comienzo del proyecto, me llevó mucho más tiempo aprender el código existente que escribir las características adicionales.

¿Cómo puedo describir el proceso de aprendizaje del código existente en la factura? (Esta parte de la empresa generalmente hace cosas internamente, por lo que no tiene mucha experiencia tratando con contratistas de software como yo, y me temo que es posible que no entiendan la sobrecarga de aprender el código de otra persona). No quiero simplemente agregar el tiempo de aprendizaje a la actualización de la función real, porque en algunos casos esto haría que una 'tarea simple' pareciera que me llevó demasiado tiempo. Quiero dividir la factura en pasos relevantes y comunicar que estoy cobrando por la gran sobrecarga de aprender el código de otra persona antes de poder agregar el mío.

¿Existe una forma estándar de describir este tipo de actividad al facturar un trabajo?

Facturaría tareas como "Revisar la funcionalidad existente" y / o "Revisar el código existente". Dependiendo de la complejidad de las nuevas características, agregaría una tarea de "Diseño xxx" que incluiría el tiempo que paso descubriendo los puntos de integración en el código existente.

Creo que es una buena idea dejar claro al cliente que hay algunos gastos generales para poner al día a un nuevo consultor, y que, si están contentos con el resultado, continuar trabajando con el mismo consultor probablemente les ahorrará dinero.

Diagnóstico de problemas.

Es un término familiar, si alguna vez arregla su auto o acude a un médico, el diagnóstico es un término común para descubrir qué está mal. También es preciso, tienes que pasar por debajo del capó y ver cómo todo está conectado para descubrir qué no funciona. Realmente es similar a trabajar en un motor sin el manual, y la compañía fue y fabricó el motor sin mirar otro motor antes (por lo que es probable que sea único).

Una línea de pedido larga o extrañamente redactada obtendrá más preguntas que realmente no desea. El "diagnóstico de problemas" es un concepto más o menos universalmente entendido.

Nada en una factura a un cliente debe ser una sorpresa para el cliente. Teniendo en cuenta eso, espero que ya establezca la expectativa con el cliente de que inicialmente pasaría una fracción significativa de su tiempo para familiarizarse con la aplicación tanto desde la perspectiva del usuario como desde la perspectiva del desarrollador. Y sus estimaciones para las primeras características con suerte especificaron que incluían una cantidad de tiempo decente para familiarizarse con el código.

Si ya ha establecido esa expectativa con el cliente de que la mayor parte del tiempo en la factura inicial se gastará en familiarizarse con la aplicación, no debería importar demasiado cómo la incluya en la factura. Use el lenguaje que utilizó al proporcionar las estimaciones y establecer las expectativas. Si solo está tratando de comunicar esto ahora, tiene un problema.

En mi calidad de profesional independiente, probablemente llamaría a esto algo así como "Asimilación del conocimiento", en el sentido general. Y, esto se habría incluido en cualquier estimación proporcionada inicialmente al cliente.

Puede que no lo ayude aquí, pero para referencia futura, le sugiero que haga de esto una tarea más activa en el futuro. Por ejemplo, facture al cliente por el tiempo que pasó revisando y agregando comentarios al código no comentado, agregando pruebas unitarias al código no probado, etc. Estos son ejemplos de tareas que agregan al menos un poco de valor mientras facilitan su comprensión de la base del código .

Incluso si no hay mucha diferencia entre leer y leer mientras se documenta, su cliente probablemente tendrá una pequeña preferencia psicológica por estas tareas más "activas". Y, en realidad, podría aprender más al documentar el código de otra persona que simplemente al leerlo. (Este ciertamente será el caso si escribe pruebas contra su código).

Si hace esto, puede tener una línea de pedido de factura que diga algo como "Asimilación de conocimiento y prueba / documentación de código heredado".

Editar: En su situación como se describe, honestamente probablemente me comería el costo de esta actividad. No puedo hablar con sus finanzas, y no pretendo presumir, pero cuando esté comenzando, valoraría mucho más acumular testimonios y clientes satisfechos que algunas horas de facturación. Si eso significa una tasa efectiva más baja al principio, puede ser una buena inversión. Comer algunas horas facturables a largo plazo es probablemente un pequeño precio a pagar por un cliente satisfecho que cree que recibió un batido justo.

Arreglando un error: análisis de causa raíz.

Nueva característica: análisis, diseño, integración y pruebas.

Introducción de nuevos errores: seguridad laboral. :)

Con un cliente al que le gusta entender cómo funcionan las cosas y me escucha con ojos soñadores, iría con una recta Codebase Familiarization. Ya le habría explicado en qué flujo de dolor me está metiendo, y la ventaja de venir a buscar nuevas actualizaciones.

Con el otro tipo de cliente ... (el mismo trato, pero evidentemente no escucha ni una sola palabra de lo que digo ) Me gustaría decir algo como:

• Planning Phase

• Intervention Planning

  (En realidad, usaría este, pero escribiría eso en italiano, en el que suena mucho mejor)

• Entonces tal vez... Solution Planning

Me gusta la Diagnosisparte de la Problem Diagnosissugerencia anon, pero Problemno me parece correcta. Puede estar abierto a críticas leves, sesgadas, ignorantes y superficiales ... que pueden dejar un mal sabor de boca.

Ya sabes, todos quieren lanzar un dardo al consultor externo, y lo hacen. (... como si no fuera lo suficientemente bueno para entender la raíz del problema mientras hablaba con ellos, y tuviera que facturar su falta de idea, o Dios sabe qué)

Mi mecánico me envía una factura "Cambiar aceite, chispa plus, revisar filtros, rotaciones de llantas. Reparar sonajero del motor, prueba en carretera .....

Piezas (detalladas),

Trabajo x @ $ y / hora = z)

Él no interrumpe el trabajo, tú tampoco deberías. Factura las horas totales y describe lo que hiciste.