Utilizamos componentes y frameworks para el desarrollo de nuestros proyectos. Tenemos componentes/marcos de terceros (tanto de código abierto como cerrado) y elementos heredados encima de ellos. A veces, nuestro cliente requiere desarrollar un software que incluya agregar nuevas características a esos componentes y marcos; en tales casos, es muy claro: solicitamos el pago del 100% por los costos de desarrollo/adaptación/mejora de esos componentes y marcos.
Pero luego hay casos en los que descubrimos que algún componente tiene un error y prohíbe completar la tarea de desarrollo encargada. A veces es más pesado: podemos descubrir la falla de diseño en nuestro marco que implica incluso rediseñar/reelaborar algunas partes del mismo. Por supuesto, hacemos y completamos tales arreglos, pero son bastante costosos, los costos de desarrollo no son despreciables. Mi pregunta es: ¿cómo informar a la gerencia de dichos trabajos y cómo facturar dichos trabajos de desarrollo al cliente? Por un lado, tales trabajos fueron requeridos por los trabajos de desarrollo encargados. Por otro lado, estos trabajos también pueden considerarse como: 1) inversiones de la empresa (por lo que no se puede facturar directamente al cliente); 2) pérdidas por la deuda técnica (y tampoco se puede facturar al cliente).
En realidad, sería bueno poner esto en una imagen más amplia de cómo se facturan y se informan los trabajos de desarrollo. Por ejemplo, ¿qué pasa con la contabilidad del trabajo del desarrollador que se gasta en la comunicación con el cliente con respecto al contenido de algunas características? ¿Qué pasa con el tiempo para las reuniones con el cliente. ¿Qué hacer con el tiempo que requiere el desarrollador para asimilar el diseño y el código base de los desarrolladores anteriores? Existen lineamientos sobre la estimación de costos, pero hay pocos sobre cómo contabilizar esos costos (inversión versus costos operativos) y cómo informarlos a la gerencia y al cliente.
En mi opinión, cualquier mano de obra necesaria que se haya agotado para construir el producto terminado o proporcionar un servicio entregable sería imputable a ese proyecto como un gasto directo. La prueba sería, ¿realizaría un empleado la tarea cuestionable si no fuera por el producto que se produce? Si la respuesta es no, entonces debería ser un gasto directo para el proyecto. Sería un gasto indirecto si la mano de obra se hubiera gastado sin importar qué, beneficiando así a muchos proyectos y clientes. Siempre hay excepciones, advertencias y matices, por lo que estoy seguro de que alguien podría citar un ejemplo de algo que puede no encajar exactamente en mi prueba, por lo que se recomendaría una regla general pero evaluada caso por caso.
En cuanto a su segunda pregunta, todas esas tareas de apoyo e indirectas deberían / deberían incluirse en su estimación de trabajo de la tarea principal. Entonces, si planea, digamos, seis horas de esfuerzo directo para martillar un juego de clavos, puede incorporar una o dos horas más para informar, hablar con el cliente, informar a su jefe, mirar fijamente el clavo que no puede alcanzar con tu martillo, etc.
Sin embargo, una advertencia podría ser que tenga una reunión estándar semanal, mensual o cualquier otra reunión en la que desee realizar un seguimiento de los cargos por separado. En tal caso, crearía un paquete de trabajo separado e incorporaría horas en ese paquete de trabajo y los empleados que participen en ese paquete lo cobrarían por separado que quizás sus códigos de cargo principales. Pero como puede ver, es una elección comercial basada en cómo desea contabilizar sus dólares. Por lo general, mi práctica es separar las tareas de tipo de apoyo que son de naturaleza más general y constante mientras tengo otras tareas de apoyo que están más directamente relacionadas con una cuenta o paquete de trabajo para simplemente incluir el trabajo general de esa cuenta/paquete. De lo contrario, los códigos se vuelven onerosos y difíciles de administrar.