¡Hola! Me llamo Alexei Piankov, soy el programador principal en la empresa Sportmaster. Diré de inmediato que "principal" no significa "el más importante de todos los programadores", no, es solo un título, una encantadora traducción de "Senior+".
En la empresa Sportmaster he estado trabajando desde 2012, y durante este tiempo el equipo de desarrollo ha creado muchas soluciones interesantes desde un punto de vista técnico. Pero hoy me gustaría hablar sobre nuestro trabajo con un enfoque en cómo reflexionamos en situaciones ambiguas.
En este artículo no habrá soluciones técnicas específicas (ni nada técnico en general) que deban ser tomadas y aplicadas en su proyecto. Más bien, es una reflexión sobre el trabajo realizado. Hubo momentos especiales que nos impactaron como equipo: nos unieron, nos templaron y nos pusieron a prueba. Sobre esos momentos, sobre la atmósfera de trabajo en el equipo, sobre nuestras trampas y una serie de trampas psicológicas en las que a veces nos metemos, intentaré hablar hoy.
Y comenzaré precisamente con el año 2012.
Llegué en 2012 con el objetivo principal en ese momento: trabajar en nuestro sitio insignia. En ese momento, era un "monstruo de Frankenstein": una parte del equipo trabajaba con nuestro antiguo sistema, que no manejaba muy bien las cargas (Bitrix), mientras que la otra parte del equipo (donde estaba yo) intentaba implementar un nuevo sistema que habíamos escogido por el criterio de "Dado que es el e-commerce más caro del mundo, lo adoptamos". Resulta que "intentamos implementar" — porque el sistema se resistía ferozmente, y por cada aspecto que logramos desentrañar, siempre surgía una "sorpresa" en respuesta. Trabajamos mucho, pero avanzábamos a la velocidad de un caracol.
Personalmente, la gota que colmó el vaso fue conocer el código de un método en este "e-commerce más caro del mundo", cuando varias horas de trabajo concentrado en un bug complicado resultaron en que la causa se encontraba en algún custom-tag que se ejecuta al generar HTML en JSP. La tarea de este custom-tag es mostrar la suma de ciertas cantidades. No está mal, para eso están diseñados estos custom-tags. Pero la sorpresa estaba en que, al hacer esto, se modifican algunos datos en la base de datos, lo que afecta el comportamiento en las siguientes páginas, y si se presiona F5, la llamada se repetía, lo que rompía la consistencia de los datos. Además, lo hacía de tal manera que se manifestaba solo después de varios pasos, en la tercera página de la secuencia. No, no estoy en contra de que haya un "maestro ninja" en el equipo que con su código mantenga a los colegas en alerta. Pero que así sea en la biblioteca del sistema más caro.
Era viernes. Y el sábado y el domingo los pasé con un colega en la oficina con el objetivo de entender qué tareas establece el negocio ante el sistema hoy y qué tareas podría inventar en un año. Por lo tanto, cómo las resolveríamos si no estuviéramos atrapados en las limitaciones de este sistema sumamente costoso y frustrante.
Dicho y hecho. Creamos un piloto en el que establecimos las bases para el desarrollo del nuevo sitio de Sportmaster. Muchas de estas ideas se han asentado y ahora mismo su continuación está activa en el sitio.
Etapas del piloto y plazos
2 días. Hicimos un microprototipo — durante el fin de semana trasladamos nuestra base a ElasticSearch, implementamos la búsqueda facetada. ¡Voilá! En ese mismo sistema adquirido, tal configuración "consumió" 2 semanas. ¡Y aquí fue literalmente en un par de horas! Además, funciona más rápido. ¡Y más rápido por un factor considerable!
2 semanas. Estamos "desarrollando" el prototipo, añadiendo funcionalidad para una entrega personalizada adecuada.
Por ejemplo, si un usuario tiene varios descuentos y promociones que son relevantes solo para él, entonces en los resultados de búsqueda de productos se debe mostrar el precio exacto que se puede obtener aplicando todos los beneficios disponibles de la manera más ventajosa.
Con las promociones no es tan simple. Por ejemplo, compré esquís, ahora hay un 40% de descuento en el gorro, pero se cancela el descuento de bienvenida del 10% en todo el pedido. Sí, este es un caso real 🙂 Y para configurar tal promoción en el sistema de compras, se pagaron 3 consultas con el proveedor, gracias a las cuales obtuvimos muchos ejemplos de cómo realizar diferentes promociones. Muy diplomáticamente y, considerando el costo de las consultas, es una buena economía.
Mostramos al negocio una demo detallada. Prometieron montar el piloto rápidamente y enseguida se pusieron a trabajar.
2 meses. El proyecto piloto lo hacemos en forma de un sitio web en vivo con búsqueda en el catálogo. La búsqueda con facetas, los resultados de la búsqueda — con descuentos personales, el piloto se parece casi al sitio de Sportmaster, y los productos que subimos son los mismos. ¡Una maravilla!
Agregamos "Elocuencia:100" de nuestro jefe de departamento, ¡y la presentación al negocio es un éxito total! Nos dan carta blanca para desarrollar la plataforma de eCommerce nosotros mismos.
Y eso significa, mantengan al equipo, chicos, mantengan el presupuesto, ¡genial!
2 años. Lanzamiento del sitio en producción. Sí, fue largo. Todo lo que supimos hacer entonces, lo probamos solo a la escala del prototipo. Dos personas forman fácilmente un equipo cohesionado. Además, las tareas que "tuvimos que completar" eran en gran medida pequeños ajustes a "Hello World" en nuevas tecnologías. Generábamos nuevas hipótesis fácilmente, las verificábamos rápidamente, no llegábamos a acostumbrarnos y, por lo tanto, las "matábamos" sin remordimientos. Cuando llegamos a 10 personas, por inercia extrapolamos nuestra velocidad de trabajo a todos los demás. E hicimos promesas de plazos de ejecución que equivalen a la idea de la perfección multiplicada por nuestro entusiasmo.
¿Situación familiar? 🙂
Entonces, ¿ya saben lo que va a pasar después?
Trampa №1. "El extrapolador genial"
Es obvio que las nuevas tecnologías se ven muy geniales en las presentaciones y funcionan perfectamente en aplicaciones como "Hello World". Pero la realidad suele estar un poco más lejos.
Así que. Tomamos una biblioteca, escribimos un montón de código de aplicación. Consideramos que las pruebas unitarias son una carga (somos geniales y estamos trabajando a la velocidad del sonido, el código es moderno y demás). Cambiamos y mejoramos la API sobre la marcha — ¿qué pruebas serias en este caso? Y todo esto bajo el lema de "hemos optimizado genialmente el proceso de desarrollo" (sí, ahora da miedo incluso describirlo).
Y luego todo es bastante obvio.
Estamos lanzando una nueva versión en uat. Los chicos del negocio están listos para probar todo y hacer clic en los botones. A veces, lo hacen de manera bastante creativa: algo falla. Sería bueno averiguar qué se ha hecho para solucionar esto. Pero al otro lado de la pantalla no hay un tester exhaustivo que te presentará todas las características del entorno teniendo en cuenta el clima de la región, sino un cliente del negocio. Simplemente dice "no funciona". Y eso significa que está insatisfecho. Pregúntale y él dirá terrible insatisfecho!
Entonces, para reproducir el bug, hay que ir y probar todo a ciegas. Por supuesto, no hemos ignorado ninguna queja y hemos corregido todo. Abandonamos tareas planificadas, pero "apagamos el fuego".
Así que nos hemos cavado un nuevo agujero.
Trampa Nº2. "Estajanovista"
Te llega un bug bastante desagradable. Comienzas a investigar. No logras resolverlo, te enojas, intentas nuevamente, otro fracaso, aclara todo lo que puedes, sigue sin ser lo correcto, piensas en lo viejo que ya eres y en que todos tienen hijos e hipotecas, vuelves a intentarlo, de nuevo no es lo adecuado. Varias tazas de café, y todo se repite. 12-14 horas de trabajo continuado — casi normal. Y cuando ya todos están al límite — ¡bam! ¡la iluminación!
Puede que, desde afuera, la evaluación de la efectividad de un día así se vea clara y correcta. Pero desde adentro — puede ser diferente.
En mi caso, la impresión de ese trabajo era "Soy genial, soy asombroso, lo resolví". No siempre de manera consciente, pero inconscientemente — ¡siempre!
Y te vuelves adicto a esto, sin bromas. Así que, las métricas internas de éxito se desplazan del resultado a la cantidad de esfuerzo aplicado y el nivel de los logros que has alcanzado, cuán intensamente has sufrido al intentar resolver el problema.
Probablemente, esta sea la trampa más terrible.
Lo que viene será más fácil y divertido 🙂
Trampa Nº3. "El poder de Hello world"
Nuestro stack tecnológico de esa época: ElasticSearch, Hazelcast, Pentaho, freemarker (y los probados Java, Spring, Tomcat, nginx). Freemarker no proporcionaba mensajes de error muy informativos. Sin embargo, tuvimos que parchear ElasticSearch, Hazelcast, Pentaho varias veces — encontrábamos casos donde no funcionaban como indicaba la documentación.
Un comienzo fácil y los rápidos beneficios de la nueva tecnología son buenos, pero generan euforia y disminuyen la vigilancia. Porque la nueva tecnología tiene errores, necesariamente tiene errores. Y si aún no se han escrito sobre ellos, alégrate, te tocará ser el pionero que inevitablemente encontrará algo defective y buscará en Google o en Stack Overflow. Por supuesto, se pueden encontrar errores en productos establecidos, pero en los nuevos es mucho más fácil.
A pesar de todas las dificultades, hemos salido a producción. Sí, con retrasos. Sí, no muy estable. Pero en general, sin catástrofes.
Así que una vez más señalaré las trampas en las que se distorsiona la percepción saludable del proceso de trabajo.
- «El extrapolador genial». Impresionados por los éxitos actuales, seguimos adelante y extrapolamos con alegría la velocidad de desarrollo a los próximos proyectos.
- «El trabajador incansable». Trabajamos arduamente, estamos satisfechos con nosotros mismos, pero no nos damos cuenta de que los problemas que resolvemos son consecuencia de nuestros errores personales / descuidos / negligencias. Trabajos no realizados.
- «La fuerza del Hola Mundo». Nos apresuramos a implementar en producción todo lo nuevo e interesante.
Por qué todo salió bien
Por supuesto, no he enumerado todos los errores que hemos tenido durante este tiempo, pero sí los más comunes, probables para cualquier tipo de proyecto. Identificar errores de esta manera ayuda a evitarlos en el futuro.
Un poco sobre cómo logramos crear una mini-startup dentro de la empresa y convencer al negocio de abandonar el sistema comprado en favor de algo hecho a medida.
Condición nº 0. Un clima saludable en la empresa. No se trata solo de los "ojos brillantes" de los empleados y la comunicación en condiciones estresantes de recolección de cookies, no. Se trata de todas las interacciones.
Condición nº 1. Creer en lo que haces. En serio, no creo que tuviéramos ninguna oportunidad si hubiéramos realizado el piloto sin desmantelar el sistema comprado "hasta el tornillo", es decir, tomando distancia y subconscientemente sabiéndolo que este sistema es mejor y nos superará.
Lo que hicimos: 1) entendimos el sistema comprado, con su ayuda resolvimos las principales solicitudes del negocio 2) elaboramos una lista de tareas que no solo existen ahora, sino que también surgirán en el futuro previsible 3) seleccionamos la solución que se ajusta mejor. Y entonces, nuestra evaluación de la solución fue una evaluación de expertos.
¿Nos darían algo si simplemente llegáramos y dijéramos: “chicos, todo es una tontería, no queremos lidiar con esto y decidimos hacerlo desde cero”? Difícilmente. Además, la respuesta sería tal que se recordaría bien 🙂
Condición №2. Comenzamos con un primer paso pequeño. Generamos la primera hipótesis y la verificamos. Se puede gastar tiempo personal en esto. Si no deseas invertir tu tiempo, entonces no deberías embarcarte en tal empresa. Y si no quieres verificar una pequeña hipótesis y prefieres hacerlo desde el principio de manera impresionante y brillante, ¡mantente alejado de esas personas!
Tuvimos suerte y la primera hipótesis funcionó. Pero esto no siempre sucede. Por ejemplo, en uno de los siguientes proyectos, cuando impulsamos una administración en el marco de un piloto similar, solo funcionó la opción 18. Y los primeros 17 enfoques fueron en vano. Por cierto, en la historia de la creación de la administración, los giros argumentales estaban a la altura de las telenovelas brasileñas, porque el equipo estaba formado por chicos que ya eran veteranos, verdaderos "zorro viejos".
Condición №3. Creamos un MVP y buscamos las frustraciones del tomador de decisiones. Por supuesto, puede que ya esté reflejando horror en su rostro por el simple hecho de que le traes alguna idea por trigésima vez. Pero aun así. Y necesariamente mostramos cómo resolvemos sus problemas con nuestro producto.
Condición №4. Rápidamente hacemos un piloto que se ve aproximadamente como el resultado final. Hacerlo todo perfecto es tentador, pero puedes caer en el perfeccionismo, lo que resultará en que, en lugar de un piloto, quieres mostrar una versión piloto de un producto ya ideal. Y eso no existe. Así que simplemente hazlo, al menos, con palos.
Condición №5. Producto. El proyecto crece, obtiene financiación, llegan especialistas con sólida experiencia.
Y si eres un clásico emprendedor de start-ups, este es el momento en el que tienes que salir disparado. Porque los vuelos fáciles por las cimas y la sensación de bienestar general se disipan rápidamente.
La salida a producción es un choque con cargas reales, la integración con decenas de sistemas, y al crear una nueva funcionalidad, al mismo tiempo, dentro del soporte, mejoras las versiones antiguas. Todo esto son desafíos mucho más serios que solo inventar una idea y resolver al menos un problema del cliente.
Este es el momento en el que suceden los desafíos y se desarrollan las habilidades.
Gracias por leer. ¡Feliz nuevo código!
Fuente: habr.com
