¿Cómo manejan las "compañías de software personalizado" la deuda técnica?

¿Qué son las "compañías de software personalizado"?

Por "compañías de software personalizado" me refiero a las compañías que hacen su dinero principalmente construyendo trozos de software personalizados. Ejemplo son agencias o empresas de middleware , o contratistas / consultores como Redify .

¿Qué es lo contrario de las "compañías de software personalizado"?

Lo opuesto al modelo de negocio anterior son las empresas que se centran en productos a largo plazo, ya sean aplicaciones de escritorio / móviles desplegables o software SaaS.

Una forma segura de acumular deuda técnica:

Trabajo para una empresa que intenta centrarse en un conjunto de productos SaaS. Sin embargo, debido a ciertas restricciones, a veces terminamos cediendo a la voluntad de ciertos clientes y terminamos construyendo bits de software personalizado que solo se pueden usar para ese cliente.

Esta es una forma segura de incurrir en deudas técnicas. Ahora tenemos que mantener un poco de software que no agrega nada a nuestro producto principal.

Si el trabajo personalizado es una forma segura de generar deuda técnica, ¿cómo lo manejan las agencias?

Eso me hizo pensar. Las empresas que no tienen un producto central como centro de su modelo de negocio, bueno, siempre están haciendo un trabajo de software personalizado. ¿Cómo hacen frente a la noción de deuda técnica? ¿Cómo no los lleva a la bancarrota técnica ?

Si puede doblar los requisitos específicos del usuario en algo que será útil para todos, genial. Si el cliente está dispuesto a pagar los costos de soporte continuo para la función, también es excelente. Pero si usted es un equipo pequeño y se encuentra luchando por admitir todas sus funciones, no hay más remedio que tomar algunas decisiones difíciles sobre las funciones que menos necesita, y luego invertir algo de tiempo en eliminarlas de su base de código.

SaaS lo coloca en una buena posición para recopilar estadísticas de uso. Si aún no lo has hecho, deberías considerar el uso de herramientas para poder seguir la pista de quién está usando qué. Nuestra experiencia es que los clientes más idiomáticos suelen ser también los más disfuncionales; ese tipo que pisoteó y contuvo el aliento hasta que le diste un botón de exportación a MS-Access probablemente no lo haya usado en más de un año. Algunas características se mantienen activas aunque solo un cliente las esté usando, porque ese cliente es ruidoso y amenaza con llevar su negocio a otro lugar cada vez que algo no le satisface. La interrupción de la función puede costarle un cliente ahora, pero el tiempo que consume en el soporte de esa función puede costarle docenas de clientes a lo largo de los años. Es una medida de la calidad de su equipo de gestión,

Cuando suspenda una función, asegúrese de anunciar la decisión a sus clientes (o al menos a los afectados) con suficiente antelación, en cualquier lugar entre seis meses y tres años es razonable. De hecho, si acepta crear características específicas para el usuario, puede intentar que su personal de ventas establezca una fecha de vencimiento desde el principio. Llámelo "soporte de por vida" y deje en claro que cuanto más lo quieran, más dinero les costará. Intente proporcionar soluciones alternativas a sus clientes para que no se queden vacilantes cuando una característica se active, por ejemplo, un script que convierta sus archivos XML exportados a formato de acceso MS, o un pequeño consejo sobre cómo elegir un mejor RDBMS.

Algo que nos ha funcionado como medida preventiva es que se envíe un informe de nuestro equipo de ventas a nuestro equipo de desarrollo y administración mensualmente. Este informe cubre los comentarios de los clientes: qué características son las más populares, qué características son las más solicitadas, qué características propuestas generan la mayor cantidad de comentarios. Esto es interesante si usted es un desarrollador, pero el beneficio real es para el equipo de ventas, que ahora está pensando un poco más sobre cada función en el contexto de la imagen más grande, en lugar de enviar un flujo interminable de solicitudes de funciones y priorizar en qué cliente fue el más ruidoso. El efecto ha sido hacer que nuestro personal de ventas sea más estricto cuando se trata de solicitudes de nuevas características en una negociación porque son más conscientes de dónde cada característica podría encajar en la propuesta de valor general de nuestro producto.

Tener un código modular con muchas pruebas automáticas lo ayudará cuando esté pirateando funciones en su producto y hackearlas nuevamente, pero en última instancia no se trata de una cuestión de programación sino de gestión. Escribir código para hacer una venta es un juego de tontos.

Cuando me enfrento a solicitudes de desarrollo personalizadas, las filtro a través del filtro genial que divide las solicitudes en 3 pilas:

1. cosas increíbles que serán útiles para todos y son relativamente fáciles de implementar
2. cosas increíbles que serán útiles para todos y que son difíciles de implementar
3. una estúpida de las cosas que solo se necesitan para este cliente que realmente no las necesita de todos modos

• La categoría 1 se implementa en el ciclo de desarrollo actual.
• La categoría 2 se implementa en el próximo ciclo de desarrollo.
• La categoría 3 obtiene una cotización de 1 mes de tiempo de desarrollo después del cual la mayoría de los clientes se dan cuenta de que su solicitud no vale la pena.

Honestamente, esto nunca falló y no creo que terminemos implementando ninguna de las características de categoría 3. Y, por supuesto, ninguno de los clientes caminó (las ventas no me habrían permitido lograr esto de otra manera :)

(Esta experiencia fue en una empresa ISV)

Debido a ciertas restricciones, a veces terminamos cediendo a la voluntad de ciertos clientes y terminamos creando fragmentos de software personalizado que solo se pueden usar para ese cliente.

Su problema no es que esté creando código que se usa para un solo cliente. El problema es que está incorporando código que se usa solo para un cliente en un producto que está vendiendo a muchos otros clientes que no necesitan esa funcionalidad.

Las empresas que no tienen un producto central como centro de su modelo de negocio, bueno, siempre están haciendo un trabajo de software personalizado. ¿Cómo hacen frente a la noción de deuda técnica? ¿Cómo no los lleva a la bancarrota técnica?

Entregan el producto. Y luego siguen adelante. Cuando está desarrollando un producto bajo contrato, todo lo que hace en ese proyecto es para ese cliente. Cualquier deuda técnica que pueda haberse acumulado durante el desarrollo se convierte en un problema del cliente una vez que finaliza el contrato, y el desarrollador pasa a otro proyecto para otro cliente.

Eso no significa que esté bien hacer un trabajo horrible, por supuesto. Su objetivo número uno es hacer que su cliente quiera seguir trabajando con usted, y hacer un trabajo de calidad es la forma de llegar allí. Tampoco significa que la deuda técnica no sea un problema para los desarrolladores de contratos. Incluso si escribe constantemente un código limpio, es probable que lo contraten en algún momento para trabajar en un proyecto que ya ha acumulado un montón de deudas. Eso puede ser bueno (el cliente quiere pagarle para que limpie el desorden) o no (el cliente no tiene idea de qué tan malo es el código y no entiende por qué "solo" agregar algunas características más va a tomar tanto tiempo )

No estoy de acuerdo con la premisa de que el trabajo personalizado está garantizado para generar deuda técnica. Evitar la deuda técnica no significa evitar ciertos tipos de funcionalidad, significa evitar rigidez innecesaria, problemas de dependencia y cosas que hacen que una base de código sea difícil (es decir, costosa) de cambiar. La funcionalidad personalizada no implica nada de esto, solo implica una base estrecha para la funcionalidad. Por lo tanto, la clave es tener en cuenta la lógica más común y reutilizable posible de la implementación, dejando el material personalizado y único como su propio módulo independiente que se puede implementar para el cliente solicitante.

Por ejemplo, supongamos que tenía una entrega que era una aplicación web interna que sus clientes instalarían en una intranet. Un día, llega un cliente y le ofrece conducir un camión de basura lleno de dinero hasta su empresa si crea una versión para ellos que tenga una aplicación de escritorio "cliente rico" en lugar de una interfaz de navegador. Bueno, si su sistema está bien diseñado y sus dependencias bien administradas, esto es solo una cuestión de reutilizar el dominio, el acceso a datos y los componentes de servicio mientras se crea un nuevo componente de presentación. La deuda técnica no es una consideración, aunque solo tenga un cliente que quiera regresar a 1999 y tenga una aplicación de escritorio para esto.

Esta es una pregunta algo compleja de responder porque, como muchas cosas, realmente depende de las circunstancias del proyecto, el nivel de control que tiene la compañía contratada, si el software personalizado ha sido administrado por la compañía contratada durante todo su ciclo de vida, la cantidad de "interferencia" de otras personas con acceso a la base del código, la actitud de todas las personas involucradas, la complejidad del proyecto y las metodologías utilizadas ... Realmente podría continuar.

Todos los sistemas tienen un grado de deuda técnica. En algunos casos, esto puede no ser particularmente notable debido a los esfuerzos diligentes por parte de los desarrolladores que trabajan para mantener siempre una base de código limpia, sin embargo, ningún sistema es perfecto y un rediseño importante puede hacer que un problema aparentemente inocente pero de larga data sea evidente. Entonces, ¿cómo manejan esto las empresas contratadas?

En muchos casos no lo hacen. A menudo, el software será escrito por una empresa, luego modificado por otra, y no es inusual ver que la base del código se desordene realmente ya que cada compañía bajo contrato trabaja con un plazo ajustado y no justificará el tiempo para mantener el código limpio ( y a veces apenas probado) si esto significa que podrían arriesgarse a perder una fecha límite.

En otros casos, encontrará empresas que no solo administran bien su proyecto contratado, sino que de alguna manera encuentran el tiempo para dejar la base de código existente en un estado mejor de lo que lo encontraron. Hacen esto a menudo con una planificación cuidadosa, identificando fuentes de deuda técnica, generalmente aquellas que tendrán un mayor impacto en el trabajo nuevo, e idean estrategias para proporcionar casos de prueba y modificaciones que contribuyan a administrar la deuda técnica y tengan en cuenta todo esto en el cronograma del proyecto. .

¿Ser un software personalizado garantiza una deuda técnica en lugar de escribir un producto central? La respuesta corta es no, sin embargo, es probable que la deuda técnica se acumule si no se trata activamente. Esto es lo mismo que con cualquier otro proyecto de software. Si controla el proyecto por completo a lo largo de su ciclo de vida, entonces tiene una mejor oportunidad de lidiar con la deuda técnica. De lo contrario, tendrá que lidiar con la deuda técnica que puede haberse acumulado del código que la compañía anterior dejó atrás.

Por otro lado, si su pregunta fuera preguntar si escribir software independientemente de su modelo de negocio es una garantía de deuda técnica. La respuesta sería absolutamente. La verdadera pregunta es cómo cualquier compañía maneja la deuda técnica. ¿Dejar que se acumule y tratar con él a una hora programada, o administrar una base de código limpia de manera continua para pagar la deuda técnica lo antes posible? Esa respuesta se reduce a las prioridades individuales de una empresa, y si la deuda técnica incurrida es financieramente relevante.

El software personalizado no es una garantía de deuda técnica, pero sí sirve a dos maestros.

Una compañía de software personalizado creará una pieza de software exactamente adaptada a la tarea en cuestión, la entregará y mantendrá si es necesario. El software verdaderamente personalizado a menudo no necesita nuevas características agregadas muy a menudo.

El problema descrito en esta pregunta es cuando las compañías de productos incorporan características personalizadas en un producto genérico. Si el producto fuera totalmente personalizado, solo se movería cuando cambiaran los requisitos del único cliente. Si el producto fuera completamente genérico, se movería solo cuando se agreguen nuevas características para hacerlo más atractivo. Pero cuando tiene una característica personalizada en un producto genérico, tiene dos fragmentos de código, en contacto cercano, que se mueven a diferentes velocidades. Al igual que las placas tectónicas que causan terremotos, la interfaz entre estos fragmentos de código es un "punto caliente", propicio para los problemas.