Hola Mi nombre es Alexey Pyankov, soy el programador jefe de Sportmaster. Diré de inmediato que "principal" no significa "el más importante de todos los programadores", no, esto es solo un nombre, una traducción tan encantadora para "Senior +" ".
He estado trabajando en Sportmaster desde 2012, y durante este tiempo el equipo de desarrollo ha tomado muchas decisiones que son interesantes desde un punto de vista técnico. Pero hoy me gustaría hablar sobre nuestro trabajo con un énfasis más en cómo razonamos en ciertas situaciones ambiguas.
Este artículo no tendrá soluciones técnicas específicas (y, de hecho, algo técnico) que deberían ser tomadas y aplicadas en su proyecto. Más bien, es una reflexión sobre el trabajo realizado. Hubo momentos tan especiales que nos influenciaron como equipo: se reunieron, se moderaron y se les probó la fuerza. Trataré de contarte sobre estos momentos, sobre la atmósfera del trabajo en equipo, sobre nuestro rastrillo y una serie de trampas psicológicas en las que a veces nos metemos.
Y comenzaré en 2012.
Llegué en 2012 con el objetivo principal en ese momento: trabajar en nuestro sitio web 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), en otra parte del equipo (donde incluí) intentaron introducir un nuevo sistema, que fue elegido según el criterio "Una vez este es el comercio electrónico más caro del mundo, lo tomamos ". Fueron ellos quienes "intentaron implementar", porque el sistema se resistía desesperadamente, y por cada momento que se resolvió, hubo una "sorpresa" en respuesta. Trabajaron mucho, pero avanzaron a la velocidad de un caracol.
Para mí personalmente, la gota que colmó el vaso fue conocer el código de un método en este "comercio electrónico más caro del mundo", cuando varias horas de trabajo concentrado en un error complicado condujeron al hecho de que el motivo se encontró en algún lugar de la etiqueta personalizada, que funciona cuando Generación html en jsp. La tarea de esta etiqueta personalizada es mostrar la suma de algunos valores. Esto no es malo; las etiquetas personalizadas están destinadas a esto. Pero la sorpresa se ocultó en el hecho de que algunos datos en la base de datos cambian, el comportamiento en las siguientes páginas está vinculado a esto, y si presiona F5, la llamada se repite, esto viola la consistencia de los datos. Además, violó de tal manera que apareció solo después de unos pocos pasos, en la tercera página de la secuencia. No, no me importa que tal "maestro ninja" estuviera en el equipo y con su código apoyara la atención de colegas en buena forma. ¡Pero así, en el sistema más caro!
Eso fue el viernes. Y un colega y yo pasamos el sábado y el domingo en la oficina para determinar qué tareas plantea la compañía para el sistema hoy y qué tareas puede realizar en un año. De acuerdo con esto, ¿cómo los resolveríamos si no fuéramos conducidos al marco de uso de este sistema más costoso y rentable?
Apenas dicho que hecho. Hicimos un piloto en el que sentamos las bases para el desarrollo del nuevo sitio web de Sportmaster. Muchas de estas ideas han echado raíces y en este momento su continuación está girando activamente en el sitio.
Fases piloto y plazos
2 dias Hicimos un microtrototipo: durante el fin de semana estamos superando nuestra base en ElasticSearch, estamos haciendo una búsqueda por facetas. Woah la! En el mismo sistema comprado, tal configuración "comió" 2 semanas. Y aquí, ¡en solo un par de horas! Sí, y funciona más rápido. Y más rápido por orden.
2 semanas Estamos aserrando un prototipo, agregando funcionalidad para una entrega personalizada adecuada.
Por ejemplo, el usuario tiene varios descuentos y promociones que son relevantes específicamente para él; luego, en los resultados de búsqueda de los productos, debe mostrar exactamente el precio que se puede obtener utilizando todos los bollos disponibles de la manera más rentable.
Con las acciones, no todo es tan simple. Por ejemplo, compré esquís, ahora hay un descuento del 40% en un sombrero, pero al mismo tiempo, se cancela un descuento del 10% en todo el pedido. Sí, sí, este es un caso real :) Y para configurar dicha promoción en el sistema de compra, se pagaron 3 consultas con el proveedor, como resultado de lo cual obtuvimos muchos ejemplos de cómo hacer otras promociones diferentes. Muy diplomático y, dado el costo de la consulta, muy bueno económicamente.
Mostré al negocio una demostración detallada. Prometieron armar rápidamente al piloto e inmediatamente se pusieron a trabajar.
2 meses Proyecto piloto: lo hacemos en forma de un sitio en vivo con una búsqueda de directorio. Busque con facetas, resultados de búsqueda: con descuentos personales, el piloto se parece casi al sitio de un Sportmaster, y completamos los mismos productos. Cariño!
Agregamos la "Elocuencia: 100" de nuestro jefe de departamento, ¡y la presentación al negocio se lleva a cabo en Hooray! Nos dan carta blanca para desarrollar la plataforma de comercio electrónico nosotros mismos.
Y eso significa, mantener, chicos, equipo, mantener, chicos, presupuesto. Genial!
2 años Retiro del sitio web en producción. Si mucho tiempo Todo lo que sabíamos entonces, lo probamos solo en la escala del prototipo. Dos personas forman fácilmente un equipo cohesionado. Y las tareas que "interrumpimos", en general, fueron pequeños dopila de "Hello World" en nuevas tecnologías. Generamos fácilmente nuevas hipótesis, las probamos rápidamente, no tuvimos tiempo de apegarnos y, por lo tanto, sin remordimientos, las "mataron". Cuando nos convertimos en 10 personas, inercia extrapolamos nuestra velocidad de trabajo a todos los demás. Y prometieron tales plazos para la tarea, que son iguales a la idea de lo bello, multiplicados por nuestro entusiasmo.
¿Una situación familiar? :)
Entonces, ¿ya sabes lo que sucederá después?
Trampa No. 1. "Extrapolador-resistente"
Está claro que las nuevas tecnologías se ven muy bien en las presentaciones y muestran excelentes resultados en la aplicación de la categoría "Hola Mundo". Pero la realidad suele estar un poco más lejos de esto.
Entonces aquí. Tomamos la biblioteca, escribimos un montón de código de aplicación. Consideramos que las pruebas unitarias son una carga (somos geniales y apostamos por supersónico aquí, el código es moderno, etc.). Cambiamos y modificamos constantemente la API sobre la marcha, bueno, qué tipo de pruebas hay, en serio. Y todo esto bajo el lema de "optimizado el proceso de desarrollo" (sí, ahora da miedo incluso describirlo).
Y luego todo es bastante obvio.
Lanzamos una nueva construcción en UAT. Los muchachos del negocio van alegremente a probar todo esto y presionan botones. A veces presionan de manera muy creativa, algo se cae. Luego ve y descubre lo que hicieron por esto. Pero, por otro lado, el monitor no es un probador tedioso que despliega todas las características ambientales para usted, teniendo en cuenta el clima en la región, pero el cliente está fuera del negocio. Él simplemente "no funciona". Entonces, él es infeliz. Pregúntale, ¡y será terriblemente infeliz!
Luego, para reproducir el error, debes ir y explotar todo. Por supuesto, no ignoramos una sola queja y arreglamos todo. Lanzaron las tareas planificadas, pero "extinguieron el fuego".
Así que nos cavamos el siguiente hoyo.
Trampa número 2. "Stakhanovets"
No obtuviste el error más agradable. Empiezas a entender. No funciona - ira - un intento de solucionarlo de nuevo - otro fastidio - especificas todo lo que es posible - nuevamente no es que pienses en el hecho de que ya eres viejo y todos tienen hijos y una hipoteca - lo intentas de nuevo - no otra vez. Unas tazas de café, y todo se repite. 12-14 horas seguidas es casi la norma. Y ahora, cuando todo ya está en su límite: ¡explosión, inspiración!
Quizás, desde el exterior, la evaluación de la efectividad de ese día sea visible bien y correctamente. Pero desde adentro, puede ser diferente.
En mi caso, la impresión de tal trabajo fue "Terminé, estoy bien, me retiré". No siempre conscientemente, sino inconscientemente, ¡siempre!
Y siéntate, no es broma. Resulta que las métricas internas del éxito del movimiento se desplazan del resultado al número de esfuerzos aplicados y al nivel de las hazañas que logró, cuánto sufrió, tratando de resolver el problema.
Esta es probablemente la peor trampa.
Además será más fácil y más divertido :)
Trampa número 3. "El poder de Hello world"
Nuestra pila de tecnología de ese período: ElasticSearch, Hazelcast, Pentaho, freemarker (y Java, Spring, Tomcat, nginx). Freemarker no informó mensajes de error de manera muy informativa. Pero ElasticSearch, Hazelcast, Pentaho tuvieron que ser reparados varias veces; encontramos talentosos casos en los que no funcionaban según lo especificado en la documentación.
El inicio fácil y el pan de jengibre rápido del uso de la nueva tecnología es bueno, pero introducen la euforia y reducen el estado de alerta. Debido a que la nueva tecnología contiene errores, necesariamente contiene errores. Y si aún no ha escrito sobre ellos, regocíjese, depende de usted convertirse en el pionero que recoge algo torcido de todos modos y se va a google o en SO. Por supuesto, lo "torcido" se puede encontrar en productos probados, pero en los nuevos es mucho más fácil.
A pesar de todas las dificultades, entramos en producción. Sí, con retrasos. Sí, no muy estable. Pero en general, no hay desastres.
En total, observo una vez más trampas en las que se distorsiona una percepción saludable del proceso de trabajo.
- "Extrapolador-resistente" . Impresionados por los éxitos actuales, vamos y extrapolamos alegremente la velocidad de desarrollo a los próximos proyectos.
- "Stakhanovets" . Trabajamos por el desgaste, estamos satisfechos con nosotros mismos, pero no nos damos cuenta de que los problemas que resolvemos son consecuencia de nuestros errores / defectos / negligencias personales. Trabajos para no hacer.
- "El poder de Hello world" . Nos apresuramos a presentar todo lo más nuevo e interesante en producción.
¿Por qué funcionó?
Por supuesto, no enumeré todos los errores que tuvimos durante este tiempo, pero sí los más comunes y probables para un proyecto específico. Esta corrección de errores ayuda a evitarlos en el futuro.
Un poco sobre cómo generalmente logramos crear una mini-startup de este tipo dentro de la empresa y convencer a la empresa de pasar del sistema ya comprado a algo de su propia clase.
Condición No. 0 . Clima saludable en la empresa. Este no es solo el "ardor en los ojos" de los empleados y la sociabilidad en condiciones estresantes de extracción de cookies, no. Esto se trata de todas las interacciones.
Condición No. 1 . Cree en lo que haces. En serio, no creo que tendríamos al menos alguna posibilidad si tuviéramos que tomar un piloto sin tener que entender el sistema comprado "al grano", es decir, retroceder e inconscientemente sabiendo que este sistema está más fresco y ocupado con nosotros.
Lo que hicimos: 1) descubrimos el sistema de compra, con él resolvimos las solicitudes básicas del negocio 2) hicimos una lista de tareas que no solo existen ahora, sino que serán en el futuro previsible 3) seleccionamos una solución que se adapte mejor. Y luego, nuestra evaluación de la decisión: fue una evaluación de expertos.
¿Nos darían algo si simplemente viniéramos y dijéramos "muchachos, toda esta basura, no queremos lidiar con esto y decidimos hacer lo nuestro desde cero"? Apenas Y la respuesta habría sido recibida en una forma que es bien recordada :)
Condición No. 2 . El primer paso es pequeño. Generamos la primera hipótesis y verificamos. Puedes dedicar tu tiempo personal a esto. Si no quieres perder el tiempo, entonces no deberías dedicarte a eso. Y si no quieres probar una pequeña hipótesis, pero quieres hacerlo de inmediato de manera genial 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 el administrador fue promovido como parte de un piloto similar, solo la 18a opción funcionó para nosotros. Y se desperdiciaron los primeros 17 enfoques del proyectil. Por cierto, en la historia con la creación del área de administración, los giros y vueltas de la trama estaban al nivel de las series brasileñas, porque el equipo estaba formado por muchachos, para ese entonces ya veteranos, verdaderos "verdugos rallados".
Condición No. 3 . Hacemos MVP y buscamos dolor en el tomador de decisiones. Por supuesto, el horror ya puede reflejarse en su rostro por el hecho de que le traes algún tipo de aventura por enésima vez. Pero aun así. Y asegúrese de mostrar exactamente cómo resolvemos sus problemas con nuestro producto.
Condición No. 4 . En la rodilla, rápidamente hacemos un piloto que se parece al resultado final. Hacer que todo sea realmente genial es tentador, pero puedes encontrar el perfeccionismo, por lo que resulta que, en lugar de un piloto, quieres mostrar una versión piloto de un producto ya ideal. Pero ellos no existen. Así que solo haz al menos palos.
Condición No. 5 . Producto. El proyecto está creciendo, obteniendo finanzas, los expertos vienen con una sólida experiencia.
Y si eres una startup clásica, entonces este es el momento en que debes culpar con un silbato. Porque los vuelos ligeros en la parte superior y una sensación de bondad general de lo que está sucediendo se dispersan rápidamente.
Entrar en el producto es una colisión con cargas reales, integración con una docena de sistemas, y cuando cree una nueva funcionalidad, finalizará las versiones antiguas como parte del mantenimiento. Todos estos desafíos son mucho más serios que pensar en una idea y resolverla, aunque bien, pero solo un problema del cliente.
Estos son desafíos y el crecimiento de habilidades ocurre precisamente en esta etapa.
Gracias por leer Happy New Code!