Hola, escribí una guía de compilación vs compra específicamente dirigida a los desarrolladores. Básicamente es un modelo de toma de decisiones.
La guía del desarrollador para servicios de construcción y compra
Definir un proceso para seleccionar objetivamente soluciones locales o compradas
- Cómo construir mi propio software
- ¿Cuál es la configuración ideal de una computadora portátil / software de Windows para un adolescente que aprende a codificar juegos en C ++?
- ¿Cómo se sienten los ingenieros de Silicon Valley por haber sido engañados debido al amplio cartel de fijación de salarios?
- Pruebas de software: ¿cómo se mide la efectividad de una prueba? ¿Y cómo se compara eso con su costo?
- ¿Cómo decide una cotización para un gran proyecto de software?
Para casi todos los componentes de aplicaciones funcionales o arquitectónicas, hay una gran cantidad de ofertas ‘como servicio’. Vemos la infraestructura como un servicio (IaaS), backend como servicio (BaaS), SaaS, PaaS … y parece que a diario se agrega un nuevo ‘aaS’.
¿Qué tienen en común todos estos servicios? Bueno, aspiracionalmente prometen darle a usted, el ingeniero, (1) más libertad para concentrarse en su producto principal, (2) un tiempo de comercialización más rápido y (3) soluciones listas para producción para operaciones de ingeniería complejas y repetibles.
A veces este es el caso. A veces no lo es. El objetivo de esta guía es proporcionar un conjunto racional de criterios objetivos para evaluar si debe crear o comprar un servicio en particular.
¿Qué es construir? ¿Qué es comprar?
Construir no necesariamente significa que estás haciendo algo desde cero. Significa que está combinando código personalizado, bibliotecas de código abierto y experiencia individual / comunitaria para construir una solución para su caso de uso. Esta solución es algo que diseñará, construirá, ejecutará, mantendrá y escalará internamente.
Por otro lado, comprar no necesariamente significa que está comprando una solución completa e inmediata para su caso de uso. Representa con mayor precisión la compra de un servicio definido que agrega un valor casi inmediato a su caso de uso. Por lo general, la viabilidad del servicio en sí estará garantizada por el vendedor y no necesitará diseñar y construir el servicio en sí. Sin embargo, dependiendo del tipo de servicio adquirido, puede elegir ejecutarlo y escalarlo internamente. En general, descargará la ejecución, el mantenimiento y la escalabilidad al vendedor.
La mente del desarrollador
Antes de continuar, restablezcamos nuestro estado de ánimo.
Muchos desarrolladores tienen egos fuertes, y eso generalmente es un atributo de empoderamiento. Los egos fuertes le dan a los desarrolladores la confianza para poder atravesar obstáculos complejos, enfocarse durante días y semanas a la vez y cultivar industrias completamente nuevas. Sin embargo, hay una delgada línea entre la confianza razonable y la irracional.
“¡Puedo construir ____ en ____ días!”
“¡Decir ah! ¡Puedo construir un mejor ____ en un fin de semana! ”
“Esto es muy caro. Solo voy a construirlo “.
Con frecuencia vemos y escuchamos estos comentarios en foros de desarrollo, agregadores como Reddit y HackerNews, y en nuestras interacciones cotidianas. Si no lo decimos, entonces algunos de nosotros probablemente lo pensamos de vez en cuando. Oye, a veces probablemente tengamos razón, pero muchas veces, nuestra reacción inicial impulsada por el ego nos aleja de los criterios objetivos que aplicamos a nuestra práctica general de programación.
Al evaluar qué construir frente a comprar, o qué proporción elegimos, es fundamental que restablezcamos nuestro estado de ánimo y abordemos nuestra solución de la manera más abierta y objetiva posible. Excluyendo a los puristas, a nadie le importa si pudimos construir nuestro producto desde cero o si integramos inteligentemente una serie de soluciones compradas juntas. Lo que importa es si nuestro producto funciona y ofrece un valor excepcional a los clientes.
Con el proceso de toma de decisiones de construcción vs compra, responderemos a la pregunta: “¿Cómo entregamos un valor excepcional a nuestros clientes de manera rápida, eficiente y prudente?”
Modelo de toma de decisiones de construcción vs compra
Paso 1: identifique y clasifique el alcance funcional de su producto
Su equipo se ha encargado de crear una plataforma de comercio electrónico que permita a los usuarios votar y rechazar productos. Entonces, ¿cuáles son las características funcionales y arquitectónicas de su producto?
Funcional
- Servicio de mercado
- Servicio de votación
- Servicio de exhibición de productos
- Servicio de gestión de inventario
- Servicio de transacciones
- Servicio de administración de cuentas de comprador, vendedor y administrador
- Buscar, filtrar, refinar servicio
Arquitectura y proceso
- Bases de datos
- Servidores
- Balanceadores de carga
- Entorno de desarrollo / Control de versiones
- Integración continua / Tubería de entrega
- REST / API en tiempo real
- Marco Frontend
- Controles de implementación / Pruebas AB
Si bien estos no son conjuntos de características integrales, el punto importante es que existe una clara distinción entre las características principales del producto (mercado, votación) y la arquitectura necesaria de sistemas y procesos (entorno de servidor, canalización de CI / CD). Hay características que son exclusivas y exclusivas de su producto, y hay características arquitectónicas que se encuentran en casi todos los sistemas de aplicación modernos.
Su trabajo es identificar cuáles de estas características son propiedad de su plataforma y cuáles son soluciones probadas replicables. Para hacer esto, haga las siguientes preguntas:
- ¿Cuáles son las características principales propietarias que hacen que mi aplicación sea única?
- ¿Qué servicios de arquitectura necesito para mi andamio de plataforma?
- ¿Cómo será mi canal de desarrollo ideal?
Tenga en cuenta que todavía no estamos solucionando o decidiendo qué construir frente a comprar. Estamos identificando y categorizando la funcionalidad de nuestro producto.
Paso 2: defina el alcance del trabajo y concilie las restricciones
Según su categorización de características en el paso 1, es hora de definir el alcance del trabajo para construir cada característica.
Primero, detalla y prioriza la funcionalidad detallada para cada característica:
- ¿Cuál es el alcance funcional mínimo para que la característica sea viable?
- ¿Cuál es el alcance funcional ideal para la función?
- ¿Es esta una característica que necesito ahora? ¿O puede esperar?
En segundo lugar, para cada característica, responda las siguientes preguntas de compilación para el alcance funcional mínimo e ideal:
- ¿Cuántos recursos para desarrolladores tengo disponibles para construir esta función? Mantener esta característica?
- ¿Puedo utilizar expertos en dominios para ayudar a diseñar esta función?
- ¿Alguien en mi equipo ha construido esto antes?
- ¿Cuánto tiempo para diseñar (A), construir (B), probar ©, implementar (D), mantener (E) esta característica?
- ¿Construir esto desviará recursos de otra cosa?
- ¿Necesito contratar recursos adicionales? Si es así, ¿cuál es el desglose de costos?
- ¿Cuál es el costo de infraestructura para ejecutar esto internamente?
Tercero, para cada característica principal, responda las siguientes preguntas de compra para el alcance funcional mínimo e ideal:
- ¿Cuál es mi presupuesto mensual para este servicio?
- ¿Cómo anticipo que mi presupuesto cambiará con el tiempo?
- ¿Puedo utilizar expertos en dominios para ayudarme a evaluar la mejor solución?
- ¿Qué recursos de desarrollador tengo disponibles para integrar y configurar la solución?
- Si corresponde, ¿tendré los recursos para autohospedar, ejecutar, mantener y escalar el servicio?
Paso 3: divergencia de la solución
¡Ahora podemos llegar a lo bueno! En este paso, no estamos decidiendo qué construir o comprar; más bien, estamos agregando un inventario de opciones.
Primero, recorra las interwebs, obtenga referencias y evalúe el ecosistema de la solución. ¿Otros equipos han construido esto con éxito? ¿Lo han comprado con éxito? ¿Cuáles son las historias de horror y éxito?
En segundo lugar, cree una matriz de comparación de compilación vs compra. Asegúrese de anotar los costos mensuales, de infraestructura y de mantenimiento a largo plazo. Tenga en cuenta el tiempo inicial y continuo necesario para cada solución de compilación o compra (¡tener híbridos de compilación / compra también es excelente!).
Paso 4: convergencia de la solución
Comience a reducir sus opciones.
Recuerda que comprar no significa magia instantánea lista para usar. Siempre hay costos de construcción asociados con la compra:
- Sandboxing y examen técnico inicial
- Integración y configuración
- Configuración y puesta a punto
- Formación operativa y incorporación de personal.
Del mismo modo, la construcción no significa necesariamente que todo esté hecho desde cero, pero sí significa que usted asumirá los costos de mantenimiento continuo, escalado y depuración. También deberá capacitar al personal y desarrollar nuevos procesos operativos.
Paso 5 – Construye o compra o ambos
Elija una opción de solución primaria y secundaria para cada característica. De esta manera, tendrá un plan de respaldo si la solución principal no funciona. Es absolutamente crítico que involucre a su equipo durante el proceso de selección y haga que los criterios de selección sean transparentes.
Paso 6 – Desarrolle pautas para la reevaluación
Es probable que la solución que haya seleccionado para el día 1 de su producto no se ajuste a su producto en el día 600. Esto está bien, pero debemos ser capaces de anticipar y evitar cualquier problema de escala futuro. Para hacer esto, establezca puntos de referencia cuantitativos y cualitativos para desencadenar una reevaluación de escala de compilación frente a compra. Por ejemplo, estamos seguros de que nuestra solución arquitectónica actual nos permite manejar hasta 500k conexiones simultáneas con facilidad, pero nuestro modelo de crecimiento actual pronostica conexiones de 2 millones en 8 meses. Cuando comenzamos a acercarnos a la marca de 300k, esto desencadenará otra evaluación de compilación vs compra para que podamos evitar cualquier problema a escala. Esta reevaluación debe incluir:
- ¿Qué hemos aprendido sobre las necesidades de nuestro producto en los últimos X meses?
- ¿Qué ha sido más difícil de lo previsto? ¿Qué ha sido más fácil?
- ¿Cómo ha cambiado nuestro grupo de recursos y conocimiento?
- ¿Han cambiado las competencias centrales de nuestro producto?
- ¿Hay algo nuevo y mejor por ahí?
Reflexiones finales: pruébalo a tu manera
Bueno, esto parece mucho trabajo. Incluso puede llevar un día o varios días evaluar una característica. Pero de manera realista, cuando tenemos en cuenta el ciclo de vida completo de su producto, unos pocos días iniciales pueden ahorrarle meses y mucho dinero en el futuro. Esos pocos días también pueden hacer o deshacer su producto.
Personalice su proceso de evaluación de compilación vs compra para satisfacer las necesidades de su organización. Aunque una gran empresa es muy diferente a una startup, las métricas de evaluación siguen siendo muy similares. Agregue o elimine métricas, codifique un proceso más refinado o cree el suyo desde cero.
De cualquier manera, es importante recordar que construir un producto exitoso es muy difícil, así que no lo haga más difícil de lo necesario. Deje que su decisión sea impulsada eligiendo la solución adecuada para su producto, en lugar de la solución adecuada para usted.
Fuente original