Hola Mi nombre es Oleg y soy desarrollador frontend en Alfa Bank. Quiero contarles una pequeña historia filosófica: sobre el enfoque de ingeniería para el desarrollo, sobre mi primer trabajo y el rastrillo que recolecté allí, sobre por qué los checklisters son muy importantes (y salvan vidas).
Y también sobre cómo continuar trabajando productivamente y no profundizar en muchas tareas pequeñas y no muy.
Todo comenzó con el caos.
En mi primer trabajo (no Alpha, no) de alguna manera me llevaron e inmediatamente me arrojaron a la tronera, dijeron, chico, ahora haces CRM, la composición está allí. Qué hacer y cómo hacerlo: no lo entendí en absoluto. ¿Qué hacen generalmente en tal situación? Así es: corren hacia sus colegas y comienzan a consultar con ellos cómo entregar el código al servidor, cómo están las cosas con el git, qué prácticas usamos y cuáles no, y así sucesivamente. Este enfoque me ayudó, y constantemente aconsejo a otros que lo hagan. Pregunte, haga preguntas, incluso si le parece obvio, especifique lo que necesita ser aclarado. Esto es normal No es normal no preguntar.
Mi siguiente paso fue usar libros. Porque cuando estaba respondiendo preguntas y obteniendo respuestas como "Yuzay linter", me sorprendí pensando que sé cómo hacer todo esto, pero no entiendo por qué. Estaba sinceramente interesado en saber dónde crecen las piernas en todos los procesos, y decidí buscar ayuda en los libros. "Código puro", "Código perfecto": en general, fui al conjunto estándar, donde dicen que la función no debe tener más de 30 líneas. Debo decir de inmediato que no ayudó a entender todo y controlar el caos.
Sí, comencé a escribir notablemente más limpio, pero el caos en forma de un montón de tareas, que normalmente no podía resolver, no desapareció. Los colegas decidieron ayudar con consejos sabios como "Amigo, simplemente no tienes suficiente ventaja, leamos acerca de la ventaja aquí y todo estará bien contigo, si le das el Scrum-master también".
Pues si. Ágil solo es algo bueno. Pero cuando trabajas en equipo. Y el borde de una cara es un poco extraño. Empecé a cavar más, encontré libros kaizen. Y luego conocí la teoría de la restricción del sistema y el libro "Propósito". Probablemente muchos lo lean, por lo que señalaré brevemente que uno de los mensajes principales aquí no es mejorar todo en todas partes e inmediatamente, sino primero encontrar un problema y solucionarlo. Solucionado: busca el siguiente y arréglalo. El autor llegó a esto a través de enfoques de ingeniería, porque los ingenieros hacen algo como esto: buscan un problema y lo resuelven.
Bien, esta es la letra, acerquémonos a la práctica.
En la vida
Supongamos que tiene algún tipo de proceso esférico en el vacío en el que hay un diseñador, front-end y probador. El diseñador dibuja diseños y botones en un día, el front-end funciona en tres días con esto y el probador necesita dos días. Parece ser un esquema simple e inmediatamente queda claro dónde mejorar el proceso, en el front-end, porque su trabajo lleva más tiempo. Es decir, el punto de optimización es encontrar la etapa más lenta del proceso.
Pero este es un ejemplo simple con tres variables. Por supuesto, el trabajo es a menudo diferente. Y muy diferente. El proceso se complica cuando tienes un back-end, documentación, CI / CD y otros artilugios importantes.
Y luego no será posible tomar y decir de inmediato qué proceso es el más lento y dónde comenzar. Aquí, el proceso de optimización de la etapa más lenta se verá así:
- Debemos encontrar la restricción, la más lenta.
- Decide cómo usarlo tanto como sea posible.
- Subordinar todo a la decisión.
- Desarrollar (expandir) la restricción.
- Regresa y repite.
Puede sonar desordenado, así que escribiré con más detalle.
¿Qué hacer? ¿Tienes alguna tarea paralela con la que estés ocupado?
En este caso, buscará la ruta más larga por días en total. En la imagen de arriba son unos 6 días. Comience con él, con este proceso más largo. Resulta que en este ejemplo mejorarás el backend, porque lleva 4,5 días. Esto tampoco es tan difícil, pero cuando llegas a esto y comienzas a hacerlo, notas que la vida se vuelve más fácil.
Volveré a ejemplos de mi caos laboral. Obtuve muchas tareas y no tuve tiempo. Me di cuenta de que hay una limitación en la interfaz (es decir, en mí), que el problema no está en el probador, porque encuentra errores, es decir, de mi lado. Para hacer algo al respecto, comencé a pensar cómo usar esta restricción.
Y decidió que necesitamos cambiar el proceso para que solo haya un punto de entrada: una persona que tome decisiones sobre si haremos la tarea o no. Debido a que hubo casos en que una persona vino y dijo: Oleg, necesitamos mover el botón aquí un poco a la derecha. Y luego otro. Y en media hora alguien más con una tarea similar. Y parece que pequeñas cosas y basura, pero al final cosí por completo, tratando de complacer a todos.
Ahora trato de hacer no más de 2 tareas en paralelo (en paralelo, y no simultáneamente). Anteriormente, podía darle una tarea al probador e ir a hacer lo siguiente, pero si el probador encontraba un error, tenía que verificar, recordar y cambiar a qué código estaba escrito allí, lo que es más difícil de lo que parece cuando cambias a menudo. Y en general, el cambio es costoso. Intenta no hacer más de 2 tareas en paralelo. 3 tareas ya son una forma de coser.
Pensemos cómo subordinar todo lo demás a la decisión. Parece lógico, sí, que si hay tantas tareas, ¿no necesita tirar una diapositiva? Por ejemplo, espera que una persona realice tres tareas de aproximadamente la misma complejidad en tres días. Si en dos días de cada tres solo realizó una tarea, lo más probable es que no se ajuste al plan, por lo que arrojarle más tareas desde arriba es algo desmotivador.
Más sobre restricciones
Por supuesto, las restricciones se pueden ampliar. En nuestro ejemplo, contrata otro frente. También es lógico, más frentes: tendrán tiempo para completar más tareas. Entonces la restricción será transferida a otro lugar.
También hay un enfoque en el que expanden no el número de unidades, sino sus competencias. Tengo un ejemplo vivo: el probador podría ayudarme en la parte delantera si supiera la parte delantera. En mi colega, el maestro scrum comenzó a escribir la interfaz por su cuenta, porque estaba interesado, hizo algunas funciones allí con un brillo, y se divirtió y el equipo ayudó. No insto a hacer esto en casa, porque el resultado puede ser muy diferente, pero como ejemplo, existe ese enfoque, sí, y a veces funciona.
Lista de verificación
Los checklisters realmente ayudan a hacer la vida más fácil. Esta
lista de verificación para Alfa-Bank ahora ayuda mucho en mi trabajo
, donde hay bastantes etapas que deben completarse.
Las listas de chek incluso salvan vidas, les daré un pequeño extracto del libro
“Comprenda los riesgos. Cómo elegir el curso correcto ":
En los albores de la aviación, los pilotos volaban en aviones que no estaban tan equipados con equipos técnicos como lo están hoy. Las listas de verificación comenzaron a usarse en la Fuerza Aérea de los EE. UU. Solo después de que quedó claro que el bombardero B-17 es un avión demasiado grande y no puede ser controlado por una sola persona. En 2009, cuando ambos motores se detuvieron en el vuelo 1549 de US Airways inmediatamente después de despegar del aeropuerto de La Guardia, los pilotos realizaron todas las acciones de la lista de verificación en tal emergencia, incluido un intento de reiniciar los motores. Los asistentes de vuelo, nuevamente de acuerdo con las listas de verificación, supervisaron estrictamente la preparación adecuada de los pasajeros para un aterrizaje de emergencia. Las listas de verificación como estas son una forma simple y económica de aumentar la seguridad.
En medicina, se observa una imagen diferente. Cada año, el mal uso de los catéteres venosos centrales causa aproximadamente 80 mil casos de infección del torrente sanguíneo y, como resultado, aproximadamente 28 mil personas mueren en unidades de cuidados intensivos en hospitales estadounidenses. Y aquellos pacientes que logran sobrevivir pasan una semana adicional adicional en promedio en cuidados intensivos. El costo total del tratamiento de tales infecciones se estima en $ 2.3 mil millones por año. ¿Qué puede salvar a estas personas? ¿Mejores medicamentos para tratar infecciones, mejores tecnologías? La respuesta es: mejorar la cultura de los errores.
En 2001, Peter Pronovost, del Hospital Johns Hopkins, elaboró una lista de verificación simple para que los médicos de reanimación verifiquen si estas medidas podrían reducir la propagación de la infección. Aquí hay cinco pasos sucesivos diseñados para evitar que ingresen bacterias peligrosas al paciente:
1) lavarse las manos con jabón;
2) tratar la piel del paciente con antiséptico de clorhexidina;
3) cubra al paciente con una sábana estéril;
4) use una máscara estéril, sombrero, delantal y guantes;
5) aplique material estéril sobre el catéter después de insertar el catéter en la vena.
En esta lista, cada una de las medidas de protección era bien conocida, no contenía nada nuevo. Pronovost preguntó a las enfermeras que trabajaban en su unidad de cuidados intensivos para ver si los médicos seguían estas 5 reglas. Las enfermeras informaron que al instalar un catéter, más de un tercio de todos los pacientes tenían una o más de estas reglas no seguidas. La tasa de infección del torrente sanguíneo en el hospital en ese momento era del 11%.
Pronovost convenció a la administración del hospital de permitir que las enfermeras detuvieran a los médicos si no cumplían alguna de las cinco medidas prescritas. Esta innovación revolucionaria violó la estructura jerárquica en la que el personal paramédico (principalmente mujeres) no tenía derecho a dar instrucciones a los cirujanos (principalmente hombres). Después de un año, durante el cual se siguieron estrictamente estas instrucciones, la tasa de infección del torrente sanguíneo en pacientes hospitalarios disminuyó de 11% a 0 (!). Y durante los siguientes 15 meses, solo se notaron 2 casos de dicha infección. Solo en este hospital, la lista de instrucciones previno 43 infecciones, 8 muertes y ahorró $ 2 millones.
Para demostrar que el efecto de usar la lista de verificación no se limitaba a su hospital, Pronovost convenció a más de cien unidades de cuidados intensivos en Michigan para participar en un estudio conjunto a gran escala. Es importante tener en cuenta que cada uno de ellos desarrolló su propia lista de acciones que es más relevante para su cultura.
Las unidades de cuidados intensivos que participaron en el estudio informaron que anteriormente tenían un total de 695 casos de infección del torrente sanguíneo debido al uso de catéteres. Solo 3 meses después de comenzar a usar las listas de verificación en la mayoría de los departamentos, la tasa de infección del paciente se redujo a cero. Las unidades de cuidados intensivos restantes también lograron reducir significativamente este indicador durante el año y medio durante el cual se realizó el estudio. Este programa a gran escala para salvar vidas se implementó sin el uso de tecnologías costosas y sin aumentar el número de personal del hospital.Es decir, cada uno de estos puntos era conocido, esto no es una especie de novedad u otra cosa. Peter simplemente lo diseñó en formato de lista de verificación y lo hizo obligatorio. Eso es todo.
Intentamos mejorar no solo nuestros resultados, sino también los resultados de otros, por lo que actualizamos constantemente nuestra lista de verificación de trabajo. Si de repente olvidé algo y no hice algo en el proceso, lo puse en la lista de verificación para no olvidar la próxima vez. Anteriormente, los modelos a menudo se devolvían al diseñador para que los retrabajaran, aunque dijo que entendió de inmediato todo y que lo haría bien, y después de eso solo nos pidió una lista de verificación, tiré un pedazo para el diseño, y se hizo más fácil.
Ordene mi lista de verificación por acción: 1 acción = 1 elemento de la lista de verificación. Lo principal aquí también es no descansar mucho y no entrar en las listas de verificación por el bien de las listas de verificación. Page Make Up es un buen punto. Los “controles de maquillaje”, incluso más, ayudarán a no olvidarse de los controles y sus matices.
Una lista de verificación puede ser jerárquica: diseño de página -> diseño de página -> diseño de página.
¿Por qué la codificación no es suficiente?
Se necesitan pruebas. Pero no siempre son necesarios. Por ejemplo, haces un aterrizaje una vez y no planeas volver a él más tarde; entonces no tiene sentido empujarlo muy fuerte. Puede cubrir selectores con unidades o usar end2end, pero las pruebas unitarias para el resto son una pérdida de tiempo.
Pero por eso la codificación no es suficiente. Una vez más, un ejemplo del primer trabajo: tuve que cambiar algo, fui a mis colegas y les conté, me respondieron que estaban ocupados. Y mi sprint está ardiendo. Y no hay nadie para ayudar. Como resultado, comenzó a comprenderse a sí mismo en competencias adicionales.
Suponga que tiene alguna buena habilidad, por ejemplo, trabajar con CI / CD. El diseñador le dio el diseño y se fue de vacaciones, tuvo un par de ediciones o preguntas, pero hasta que regrese de vacaciones, eso es todo, el proceso vale la pena. Amplíe sus habilidades, porque si el punto débil del proceso está en el lado del diseño, bueno, el diseñador está cosido por varias razones, puede ayudarlo. Este es un conjunto adicional de conocimiento, pero se puede dominar. Por supuesto, no estoy hablando de reemplazar completamente a un especialista, estoy hablando de habilidades básicas.
Conclusiones
Es útil abordar el asunto como ingeniero. Incluso si su trabajo no es de naturaleza ingenieril. Le permite no introducir todo sin pensar en una fila, sino encontrar un problema e introducir solo lo que contribuye a su solución.
Necesidad de comunicar y discutir soluciones. La comunicación es en principio difícil de sobreestimar. A veces surgen problemas debido a la llamada iniciativa silenciosa. Tuvimos un caso cuando nos dieron un desarrollador .Net y una tarea simple para que él escribiera pruebas. Rápidamente escribió todo, pruebas, pruebas unitarias, selecciones, y luego, por alguna razón, comenzó a hacer algo más allá de lo que estaba en la tarea. Aparentemente, en la creencia de que esto nos será útil. Como resultado, todo lo que hizo nos hizo pasar mucho tiempo en sincronización adicional, y luego todo esto fue a la basura en esencia. Solo por problemas básicos de comunicación. No hagas eso.
Bueno, una lista de libros útiles:
- Teoría de restricción del sistema (E. Goldratt)
- Gestión de proyectos de cadena crítica (E. Goldratt)
- Gemba kaizen: una forma de reducir costos y mejorar la calidad (M. Imai)
- Gestión ágil: liderazgo y gestión de equipos (A. Jürgen)
- Programación extrema explicada (K. Beck)
Una presentación detallada se puede encontrar
aquí .
¿Usas listas de verificación, las consideras necesarias? Si tiene algún enfoque para mantener o crear una lista de verificación, comparta los comentarios.