Socios tecnológicos y de producto
Para fabricantes de software y empresas de producto que necesitan un equipo de ingeniería junto al suyo durante años y no durante un sprint. Un módulo del que somos responsables de principio a fin, una plataforma que ayudamos a operar o un segundo equipo que lleva la hoja de ruta que usted no puede cubrir con su personal, con las mismas personas durante el tiempo suficiente para aprender el dominio.
Distinto de comprar un proyecto
Un proyecto tiene un final, y todo lo relativo a cómo se dota de personal se deriva de ello: se asigna a las personas, se aprende el dominio lo justo para terminar y el conocimiento se va con ellas. Un producto no termina. Lo que necesita de un equipo externo es continuidad, interés en que la arquitectura sobreviva los próximos dos años y personas que se opongan cuando un atajo vaya a costar más después de lo que ahorra ahora.
Esa es la relación que describe esta página. Comercialmente suele parecerse a un equipo dedicado; lo que la convierte en una alianza es que respondemos de un resultado en su producto y no de una lista de tickets.
De qué solemos ser responsables
Un módulo del que somos responsables de principio a fin
Una parte acotada de su producto: la capa de integraciones, la parte de informes, la superficie de administración, el cliente móvil. Somos responsables de ella en su base de código, conforme a su arquitectura, y respondemos de sus defectos y no de un número de tickets.
Un segundo equipo en la hoja de ruta
Todo lo que sabe que debería construir y no puede cubrir con su personal. Un equipo paralelo que trabaja en sus repositorios y sus rituales, de modo que la hoja de ruta avanza en dos frentes en lugar de reducirse a uno por repriorización.
La plataforma subyacente
Infraestructura cloud declarada en Terraform, pipelines, entornos, observabilidad y trabajo de bases de datos y seguridad. La parte para la que un equipo de producto nunca tiene tiempo y cuya falta nota cada semana.
Llevar un producto antiguo al presente
Un producto que se vende pero que ha dejado de poder modificarse. Nueve relevos hasta ahora, el más antiguo escrito en 2008, siempre empezando con una revisión de solo lectura y una lista escrita de riesgos y no con una propuesta de reescritura.
Qué hace que funcione una alianza larga
Personas que se quedan
Los proyectos aquí duran años y no sprints, y el conocimiento del dominio se queda con las mismas personas. El peor resultado para un socio es pagar dos veces la misma curva de aprendizaje.
Su arquitectura, no la nuestra
Estamos acostumbrados a asumir lo que un producto ya utiliza en lugar de empujarlo hacia lo que casualmente conocemos. Un equipo socio que no deja de proponer una reescritura es un equipo socio que ha dejado de ser útil.
Reglas que sobreviven a un traspaso
Las pruebas se entregan con la funcionalidad, la build termina con cero warnings, la seguridad es de denegación por defecto y la infraestructura es código. El código escrito así es código que sus propios ingenieros pueden asumir.
Un propietario por dato
Los valores derivados se calculan una vez y se consumen en todas partes. En un producto con varios equipos, la verdad duplicada es el error que se descubre seis meses después y que no se puede explicar a un cliente.
Cobertura que es nuestra, no facturada
La revisión de arquitectura, una segunda mirada en las pull requests y la cobertura durante las vacaciones proceden de BigTree108 y no de su presupuesto.
Su propiedad intelectual en todo momento
Cada especialista cede el producto de su trabajo a la empresa antes de tener acceso, y se cede a su vez a usted, de modo que nada en una alianza larga complica quién es el propietario del producto.
Operamos un producto propio
Todo lo que usamos internamente, desde la contratación y la incorporación hasta el control de horas, los contratos y la facturación, es una única plataforma sobre el stack que ofrecemos a los socios: .NET sobre Azure Functions, Angular, Azure SQL, Terraform. No es una pieza de portafolio; es el sistema del que depende la empresa, y hemos convivido con nuestras propias decisiones de arquitectura el tiempo suficiente para saber cuáles eran erróneas.
Ese es el criterio que realmente compra un socio de producto. El caso de estudio describe qué hace y cómo está construido.
Cómo empieza
Con algo pequeño y reversible. Un ingeniero en una parte acotada de su backlog, o una revisión de solo lectura de la parte del producto con la que se siente menos cómodo, entregada como una lista escrita de riesgos por orden de impacto en producción. Ambas son formas baratas de comprobar si leemos su base de código como querría que lo hiciera un socio.
A partir de ahí, la forma habitual es un equipo dedicado que crece con la hoja de ruta. Si con el tiempo prefiere ser propietario del equipo, el Build-Operate-Transfer son las mismas personas con un traspaso escrito en el contrato.
¿Necesita un segundo equipo en su producto?
Envíenos el producto, la parte de la hoja de ruta que no deja de retrasarse y, si puede, un enlace a un repositorio. Recibirá las preguntas que aún tenemos, un enfoque y un presupuesto en un plazo de un día laborable.