Mentalidad del desarrollador en proyectos de crecimiento

Dominar muchas tecnologías y saber cómo crear servicios complejos y altamente cargados resulta no ser suficiente cuando eres desarrollador en una startup o un proyecto en crecimiento. En mi carrera, he estado involucrado en muchos proyectos en crecimiento y creé dos startups desde cero. En este artículo, compartiré mis experiencias sobre en qué centrarme durante el desarrollo y por qué el perfeccionismo arruina incluso las mejores ideas.

Las herramientas son un medio, no un fin

Para todo desarrollador, lanzar un proyecto por sí solo es un gran desafío. Es muy natural sentir que necesitas hacer todo a la perfección. Me tomó un tiempo darme cuenta de que el deseo de perfeccionismo es a menudo el reflejo del miedo a que mis colegas me juzguen por una "impresión" adicional o por no usar un patrón o herramienta; y aquí va: el servidor de producción colapsará, los clientes se quejarán, me despedirán y el mundo llegará a su fin.

Cualquier herramienta, patrón o lenguaje de programación es solo una herramienta , no un objetivo. Pregunta más a menudo: ¿Por qué necesito esto ahora? ¿Qué proporcionará? ¿Qué métricas mejorará? Por ejemplo: ¿por qué configurar un linter ahora? ¿Por qué personalizar CI/CD ahora? Si realiza una implementación 10 veces al día, probablemente la necesite. Si implementa una versión una vez por semana o por mes, lo más probable es que no lo haga. Si la personalización de CI/CD llevará mucho tiempo, pero no acelerará el desarrollo ni aportará valor al proyecto ni a los clientes, ¿debería implementarse ahora?

En un proyecto favorito, tiene sentido probar algo nuevo: mejorar sin cesar la estructura del repositorio y el código, experimentar con patrones, etcétera. En este caso, las herramientas que implementamos son el objetivo . El objetivo principal de un proyecto de producción es entregar valor a los clientes. Los clientes nunca sabrán que utilizamos comillas dobles en lugar de comillas simples y singletons, y que no existe ningún código físico.

La refactorización es necesaria sólo cuando aumenta la velocidad de desarrollo y el rendimiento, reduce los errores o desbloquea el trabajo pendiente.

El compromiso con la calidad debe perseguir los objetivos del producto, no su deseo de perfeccionismo. Por eso es importante recordar: un desarrollador en un proyecto en crecimiento nunca es un perfeccionista.

El valor empresarial es lo primero

Para un desarrollador de un proyecto en crecimiento, es esencial comprender el valor comercial. Cuando estás acostumbrado a ser un desarrollador habitual que codifica sólo según especificaciones ya preparadas, al principio puede resultar un desafío.

Cuando el producto apenas está naciendo, el valor para los usuarios aún no está demostrado, pero el valor a demostrar existe en la mente de las partes interesadas. En esta etapa, puedes cometer el error de sobrecargar el código base con lógica innecesaria. Por ejemplo, debe escribir un manejador de pedidos. Creas una tabla con pedidos en la base de datos y una segunda tabla con tipos de pedidos, aunque todavía solo hay un tipo.

Digamos que se hace esto porque la parte interesada insiste en que algún día esta lógica podría ser necesaria. En realidad, es posible que nunca sea necesario. No genere entidades innecesarias si no tienen ningún valor ahora y, lo que es más importante, no pierda tiempo ni dinero en eso.

Se podría formular una pregunta razonable: "¿Voy a discutir con una parte interesada?" Bueno, a veces lo harás. Las partes interesadas esperan un análisis detallado. Las características específicas de los proyectos en crecimiento suelen ser la falta de recursos, por lo que los desarrolladores deben tener habilidades analíticas. Es necesario validar constantemente el valor de las características del producto, ya que su viabilidad depende literalmente de ello.

Si se esfuerza, la empresa se quedará sin recursos y usted archivará el repositorio.

Haga muchas preguntas: "¿Por qué implementar esta función ahora? ¿Deberíamos resolver este problema ahora? ¿Existe este problema?" Es exactamente lo mismo que se describió anteriormente con las tecnologías. Ser capaz de hacer las preguntas correctas revela su profesionalismo. Sólo necesita dedicar su tiempo y recursos comerciales a cosas que realmente aporten valor a sus clientes.

Los hackathons son un gran ejemplo que muestra cómo la comprensión del valor empresarial influye en el resultado. En un tiempo limitado, se debe presentar una solución no ideal pero viable a un problema claramente definido. Cuando los desarrolladores se inspiran en el proyecto y entienden claramente por qué lo hacen, el resultado es bueno incluso en 2 días.

El plan depende de los riesgos

Imagina un juego de estrategia: tienes un leñador y un recluta. El objetivo es crear un guerrero. Primero, el leñador debe recolectar madera y construir cuarteles, donde el recluta puede aprender entrenamiento militar. Para cosechar la madera, el leñador necesita llegar al bosque a través de una parte inexplorada del mapa. A juzgar por el mapa, se puede llegar al bosque en un día de juego, la tala de madera llevará aproximadamente medio día y la construcción del cuartel llevará una semana. Entonces el cuartel aparecerá en unos diez días.

El leñador tarda casi un día en llegar al bosque, pero de repente el río bloquea el camino. El objetivo cambia: tenemos que construir una presa, un puente o un barco para llegar al otro lado, o quizás sea mejor buscar bosques en otros lugares. La evaluación prematura conduce a un fracaso en la estrategia. Si el explorador hubiera explorado primero una parte no descubierta del mapa, este riesgo podría haberse evitado.

Un desarrollador experimentado reconoce riesgos que no son obvios para las partes interesadas: integraciones con servicios de terceros, la complejidad de ampliar la base del código, etc. Es tu responsabilidad evaluar los riesgos y advertir sobre ellos. La mayoría de las veces las partes interesadas desconocen estos riesgos, pero afectan la evaluación, que es importante para ellos.

Una tarea de ejemplo: integrar su servicio con un servicio de pago. En primer lugar, configure el servicio de pago, obtenga acceso e investigue dónde pueden salir mal las cosas. Antes de integrarse, comprenda cómo integrarse. Es mejor dedicar un día a la investigación que descubrir después de dos o tres semanas de desarrollo que la función no se puede terminar a tiempo o que la integración ha fallado porque el servicio de pago ha cambiado los términos o ha desactivado el soporte para la función necesaria. .

Después de calcular los riesgos, es necesario planificar el trabajo y proporcionar una estimación del tiempo para la tarea. Este es el marco que uso:

• Escriba escenarios o visualícelos a bordo: por ejemplo, el usuario hace clic en un botón y se descarga el documento. Elija enfoques que comprenda.

• Analizar cómo podría funcionar el guión desde un punto de vista más técnico. Cuantas más opciones, mejor. Evalúo las opciones y elijo una solución potencialmente escalable con riesgos minimizados que resolvería el problema más rápidamente.

• Divida los escenarios en partes lógicas que deban codificarse.

• Estima cada parte en días y luego multiplícala por el coeficiente 1,11. Este es mi coeficiente mágico personal, que es mi cumpleaños el 11 de octubre. Esto, por supuesto, es una broma (o no). Mi consejo es añadir un par de días o incluso semanas adicionales a la estimación, dependiendo del alcance del proyecto. Si bien intentamos prever tantos riesgos como sea posible, algunos no se pueden prever. Es mejor hacer las cosas antes que no tener éxito.

  
  

  No tenga miedo de dar una estimación mayor: cuando una parte interesada le pregunte: "¿No puede hacerlo más rápido?" No se limite a responder "No", sino justifique el motivo. Hable sobre los riesgos, demuestre escenarios y dé ejemplos. La parte interesada debe comprender que usted ha analizado el problema y no simplemente lo ha evaluado al azar.

Aspecto importante: tu estado de ánimo también es un riesgo. Planifica tus vacaciones y vigila tu salud mental para mantenerte motivado y no agotarte: es tu responsabilidad.

MVP no es una nave espacial

La pregunta "¿Cómo crear un MVP?" Me ha molestado toda mi carrera. Suena simple: producto mínimo viable.

Definición de Wikipedia:

Un producto mínimo viable (MVP) es una versión de un producto con las características suficientes para que lo puedan utilizar los primeros clientes, quienes luego pueden proporcionar comentarios para el desarrollo futuro del producto.

A menudo he observado que cuando necesitas construir un MVP, a veces termina más bien como construir una nave espacial que requiere una cantidad ridícula de tiempo. El objetivo principal en la etapa MVP es obtener comentarios rápidos del cliente y, basándose en estos comentarios, acordar con las partes interesadas si "seguimos recto" o "giramos a la derecha". La mejor manera de recopilar comentarios son las métricas. Es genial si tienen éxito sin ellos, pero si no es así, al menos sabrás por qué.

Les hablaré de mi primer MVP. Encontré muchas herramientas y marcos: UML, patrones de diseño, hoja de ruta, puntos de historia, especificación de requisitos del sistema, ADR, pruebas de interfaz de usuario, etc. Decidí usarlos todos porque estos marcos se usan dentro de grandes empresas y escuché sobre ellos en conferencias, conferencias y YouTube.

El objetivo del servicio era almacenar datos sobre ejecuciones de prueba. Preparé una hoja de ruta para un año, dibujé una arquitectura detallada en UML , dediqué mucho tiempo a elegir un marco para el backend, configuré un sistema para pruebas y registros en Sentry y calculé la carga para muchos usuarios en lugar de los 10 esperados. -15. Quería hacer el proyecto perfecto.

La primera versión tardó 6 meses en completarse. Se podían ver todos los lanzamientos y gráficos y descargar informes, pero hubo un problema con la recopilación de datos. Dos o tres veces por semana aparecía un informe roto, lo que hacía imposible utilizar el servicio, pero seguí obstinadamente el plan.

Durante los siguientes años, tuve muchos proyectos diferentes e intenté lanzar mi startup. Aprendí sobre marketing, ventas y dolor del cliente. La experiencia cambió mi forma de pensar y me permitió desarrollar los enfoques que comparto en este artículo. Describiré una tarea reciente para demostrar cómo funcionaron en la práctica.

Necesitaba acelerar el método API, lo que molestaba a los usuarios por su lentitud. El plan era trasladarlo a un servicio separado del monolito, donde hubo dificultades debido a muchas integraciones con servicios internos y estructuras de datos. Este proyecto fue experimental; nadie sabía si la aceleración era posible.

Por supuesto, podría seguir adelante y sugerir reescribir todo y hacerlo perfecto. Comencé investigando el monolito y los servicios internos e investigué los riesgos de las integraciones. Luego creé una estrategia usando un diagrama simple en Miro, dividí todo en iteraciones y solo entonces comencé a trabajar.

De vez en cuando surgían problemas con las integraciones, de los que el interesado era el primero en enterarse. Primero que nada, los resolvimos. Sí, todavía había deudas técnicas en el proyecto: linters, pruebas incompletas, esquemas antiguos en la base de datos, pero el problema de los clientes se resolvió.

Todas las iteraciones alcanzaron el objetivo y, en el cuarto intento, alcanzamos el 100%. Se necesitarían 10 iteraciones para reescribir todo desde cero, pero incluso en menos tiempo obtuvimos un servicio escalable que resolvió el problema. La única cuestión es el enfoque.

Códice de un desarrollador en un proyecto en crecimiento

• Deja de lado el perfeccionismo. Si bien el mundo está lleno de tecnologías que resuelven problemas, no es necesario saberlo todo para que los proyectos sean útiles para las personas.

• Utilice soluciones ya preparadas siempre que sea posible.

• El valor empresarial es lo primero. Los usuarios no vienen por un producto, vienen por una solución a su problema.

• Evaluar los riesgos desde el inicio y comunicarlos a las partes interesadas de manera clara.

• Haz planes a corto plazo. Si la tarea ha estado atrasada durante dos años, lo más probable es que los usuarios no la necesiten.

• Recopile comentarios y métricas de todas las formas posibles. Las métricas son una forma confiable de encontrar puntos de crecimiento.

• Se pueden lograr soluciones escalables incluso cuando no se utilizan los patrones de ingeniería "correctos" desde el principio.