Muchas personas piensan en los problemas que les preocupan antes de dormir o al despertar. Yo no soy la excepción. Esta mañana, me surgió un pensamiento en la cabeza. de Habr:
Un colega en el chat compartió una historia:
Tuve un cliente increíble hace dos años, justo cuando comencé a afrontar la 'crisis' en limpio.
El cliente tiene dos equipos en su grupo de desarrollo, cada uno se ocupa de una parte del producto (así, en términos generales, el back office y el storefront, es decir, el software que trabaja en la creación de pedidos y el software que se encarga de la ejecución de pedidos), integrándose entre sí ocasionalmente.
El equipo de back office se encontraba en una situación muy complicada: seis meses de errores continuos, los propietarios amenazan con despedir a todos, contrataron a un consultor y después a otro (a mí). Por cierto, el segundo equipo (el storefront) estaba funcionando bien y continuó haciéndolo, el que tuvo problemas fue el de back office, que anteriormente también había trabajado bien. Los equipos están en diferentes oficinas y se acostumbraron a dar quejas unos sobre otros.Razón: el front y el back son un mismo sistema, con muchas dependencias, los equipos en diferentes oficinas no se comunicaban entre sí. Los propietarios estaban siempre 'mirando' el storefront, por lo que tenían nuevas funciones, ideas y control. Había un chico multifuncional, una especie de combinación de BA, diseñador y 'tráenos café'. Este chico, sin que su equipo se diera cuenta, realizaba un montón de pequeñas tareas como 'avisar al segundo equipo sobre el despliegue', 'actualizar la documentación', y así la rutina, hasta 'añadir en Jira los números de versiones y componentes'. Pero el chico no escribía código y en un momento los propietarios decidieron optimizarlo y lo despidieron. Para el equipo del storefront, no cambió nada, simplemente dejaron de añadir y actualizar documentos, y el equipo de back office se encontró en una situación en la que los lanzamientos del storefront rompían algo para ellos, y eso era su problema, y si los lanzamientos de ellos rompían algo del storefront, nuevamente era su problema, porque el storefront estaba bajo la mirada de los propietarios 🙂
Lo que me llamó la atención de este comentario y lo que encontrará quien busque en el título — más abajo.
He estado desarrollando aplicaciones web durante 20 años, por lo que para mí, el front-end y el back-end no son solo palabras. Estas son cosas muy interconectadas. Por ejemplo, no puedo imaginar una situación en la que el front se desarrolle de manera totalmente (o muy marcada) separada del back. En ambos lados operan con los mismos datos y realizan operaciones muy similares. Tengo una idea aproximada del volumen de información que se intercambia entre los desarrolladores de ambos equipos para coordinar el desarrollo, así como de cuánto tiempo y con qué frecuencia se deben llevar a cabo estas coordinaciones. Los equipos no pueden dejar de comunicarse estrechamente, incluso estando en diferentes zonas horarias. Sobre todo, teniendo en cuenta la existencia de JIRA.
Sé que es inútil avisar a los desarrolladores de back-end sobre el despliegue del front. La nueva versión del front no puede romper nada en el back, pero al revés, sí. Son los desarrolladores del front los que están interesados en notificar a los desarrolladores del back que necesitan funcionalidad nueva o modificada. El front depende de los despliegues del back, no al contrario.
¿Qué niño, que "tráenos café" no puede ser un BA (si entendemos BA como "analista de negocios"), y un BA no puede ser "niño, tráenos café". Y, por supuesto, "ingresar números de versión y componentes en JIRA" sin discutir con los equipos de desarrolladores, ni el "niño" ni el BA pueden. Es como poner el carro delante del caballo.
Dado que el "niño" fue despedido, estas funciones, desde "tráenos café" hasta "ingresar en JIRA", debieron redistribuirse entre otros miembros de los equipos. En un grupo establecido, los flujos de información y roles están fijados; si una persona que desempeña uno o varios roles sale del escenario, los otros miembros del grupo todavía tendrán la necesidad de recibir información habitual de los roles conocidos. Simplemente no pueden dejar de notar que la información necesaria para el trabajo ha dejado de llegar a ellos. Es como un adicto que no puede dejar de notar la interrupción del suministro de drogas. Y así como un adicto busca y encuentra otros canales, los miembros del grupo intentarán encontrar fuentes de la información que necesitan de "ese" lado y nuevos ejecutores de los viejos roles. Y seguramente encontrarán. Al menos a alguien que, en su opinión, debería proporcionarles la información que necesitan.
Incluso si asumimos que los canales de información habituales han fallado, y quien debería no considera que tenga que hacerlo, entonces los desarrolladores de backend, amenazados con despidos, no ocultarán durante seis meses las razones de sus fracasos al propietario, sabiendo que sus errores provienen de la falta de la información necesaria. Los propietarios no se quedarán "paralizados" durante medio año, viendo que antes la información necesaria "estaba en la grasa", y ahora nadie la introduce ahí. Y el primer consultor difícilmente fue tan poco profesional como para no hablar con los desarrolladores de backend y no identificar la fuente del problema: la falta de coordinación entre los equipos. Esa es la verdadera razón de las desgracias descritas, no el despido del "chico".
La simple falta de comunicación entre los desarrolladores es una causa típica de muchos problemas en el desarrollo y más allá. No es necesario ser un consultor excepcional para descubrirlo. Basta con ser simplemente sensato.
Creo que toda esta historia es inventada y presentada de manera atractiva. Bueno, no completamente inventada; todos los elementos están tomados de la vida (frontend, backend, desarrollo, chico, café, "grasa", …). Pero están conectados de tal manera que en la vida real no se encuentra tal construcción. Por separado, se puede encontrar todo esto en el mundo que nos rodea, pero en esta combinación, no. Ya mencioné por qué.
Sin embargo, está expuesta de una manera muy creíble. Se lee con interés y hay una participación personal involucrada. Sentimientos hacia el "chico-multiusos", un pequeño mecanismo no reconocido de una gran máquina (¡eso soy yo!). Condescendencia hacia los desarrolladores, tan inteligentes y experimentados, pero no viendo más allá de su propia nariz (¡están justo a mi alrededor!). Un ligero sarcasmo hacia los propietarios, los nobles ricos que se han hecho "heridas" con sus propias manos y no entienden las causas (¡es igualito a mi dirección!). Desdén por el primer "consultor", que no pudo encontrar una fuente de problemas tan simple (sí, vino recientemente un tipo con gafas, caminaba con un aire inteligente), y una exuberante unión con el "verdadero" consultor, que fue el único capaz de evaluar el verdadero papel del chico-multiusos (¡es decir, ¡yo!).
¿Sientes una satisfacción interna después de leer este comentario? ¡Nuestro papel como pequeños engranajes en un gran mecanismo no es tan pequeño de verdad! Está maravillosamente expresado, aunque no sea cierto. Pero, ¡qué agradable regusto queda!
No sé quién es el colega ni en qué chat compartió esta revelación con su compañero. y por qué el colega mkrentovskiy decidió publicarlo bajo el artículo "" del destacado autor de Habr ‘que, entre otras cosas, se encuentra en primer lugar en el ranking de Habr en este momento!), pero reconozco que el colega mkrentovskiy lo hizo de una manera excepcional. El mensaje del comentario y el estilo de redacción coinciden tanto con el mensaje y el estilo de otras publicaciones nmivan‘que se podría pensar que el consultor de crisis del comentario y el protagonista de muchas publicaciones nmivan‘son la misma persona.
He leído bastantes publicaciones de Ivan Belokamentsev desde que el autor comenzó su actividad en Habr (en 2017). Algunas incluso con mucho gusto (, ). Tiene un buen estilo y una presentación interesante del material. Sus historias son muy parecidas a historias de la vida real, pero tienen prácticamente cero posibilidad de ocurrir en la realidad Sinceramente, no creo que las publicaciones de Ivan hayan mejorado Habr. Pero su ranking y
los comentarios No entiendo tu queja. Habr ha estado en decadencia desde hace mucho, y el autor da un poco de chispa y levanta el ánimo de los lectores) sacando el recurso de la profundidad.
Sí, Habr no es una caridad, Habr es un proyecto comercial. Habr es un espejo que refleja nuestros deseos. No son mis deseos personales ni los deseos de cada visitante individual, sino la suma de todos nuestros deseos — el "promedio del hospital". Y Ivan Belokamentsev siente mejor que nadie lo que necesitamos todos en conjunto, y nos lo ofrece.
Quizás no habría escrito este artículo si no hubiera comenzado a ver la serie "
El Joven Papa".
"" (c)Es de la serie. Y es sobre nosotros.
La realidad creada por el Creador ya no nos fascina.
Por Dios, la Naturaleza, el Gran Estallido — como quieras. La realidad existe. A nuestro alrededor e independientemente de nosotros.
Dios, naturaleza, gran explosión — como quieras. La realidad existe. Está a nuestro alrededor y es independiente de nosotros.
Vivimos en ella de acuerdo con las leyes de la naturaleza (el designio de Dios). Comprendemos las leyes (el designio) y aprendemos a utilizar la realidad en la que vivimos para vivir aún mejor. Verificamos nuestras conjeturas con la práctica, descartando las incorrectas y manteniendo las relevantes. Interactuamos con la realidad y la cambiamos.
Y hemos tenido mucho éxito en esto.
Hay muchas personas en el planeta. Muchísimas. Con la productividad actual, no necesitamos sobrevivir más — una minoría puede proveer a la mayoría con todo lo necesario. La mayoría, sin embargo, necesita ocupar su tiempo. Históricamente, el excedente de recursos destinado a la creatividad iba a parar a las más talentosas (o más audaces, que también es talento). Sin embargo, ahora hay tantos recursos libres que todos los que tienen algo de talento pueden acceder a ellos, independientemente de su nivel. Comparen cuántas películas se estrenan anualmente en todo el mundo y cuántas de ellas son realmente buenas. Cuántos libros se escriben y cuáles se pueden leer. Cuánta información se publica en internet y cuánta de ella es útil.
¿Por qué es tan popular la profesión de informático? Porque en IT se puede desperdiciar una inmensidad de recursos y nadie se dará cuenta (recuerden el problema del año 2000, por ejemplo). En IT se pueden desarrollar aplicaciones durante años que quedarán obsoletas incluso antes de su lanzamiento, se pueden intentar integrar componentes incompatibles y lograr que funcionen, se puede reinventar la rueda una y otra vez, o se puede simplemente empezar a dar soporte a programas en Fortran, que ya estaba cubierto de musgo hace 20 años. En IT se puede pasar toda una vida y no hacer nada útil. Y lo más importante: ¡nadie lo notará! Ni siquiera tú mismo.
A pocos de nosotros nos queda la oportunidad de dejar una huella en la industria de IT. Y dejar un buen recuerdo será aún más difícil para la mayoría. Los resultados de nuestro trabajo se devaluarán en los próximos 10-20 años como mejor escenario, o incluso antes. Y definitivamente no durante nuestra vida (si llegamos a la edad de jubilación). No podremos mostrar a nuestros nietos los sistemas informáticos en los que trabajó su abuelo en su juventud. La gente simplemente olvidará sus nombres. Al principio de mi carrera, administraba estaciones de correo. bajo "". Estoy a 20 años de mi jubilación y a 10 de tener nietos, pero ya ahora la mayoría de ustedes no ha oído hablar del "software de correo electrónico destacado de mediados de los años 90" ("paquete de software de correo electrónico de mediados de 1990").
Puede que en realidad no seamos conscientes de la futilidad de nuestra carga IT, pero en nuestro subconsciente buscamos huir hacia un lugar donde nos sintamos cómodos. A mundos ficticios, donde el uso de Scrum y Agile siempre resulta en productos que dominan el mundo con su utilidad durante décadas. Donde no somos simplemente pequeños engranajes de grandes mecanismos, sino engranajes sin los cuales los grandes mecanismos se rompen. Donde nuestra vida no transcurre en la fútil realización de tareas rutinarias, sino que está llena de creatividad y creación, cuyos resultados podemos apreciar.
Huyendo hacia estos maravillosos mundos imaginados por alguien, nos alejamos de nuestra propia ineptitud en el mundo real. Buscamos consuelo en ellos.
Buscamos consuelo también en Habré. Y Iván nos lo proporciona aquí.
Fuente: habr.com
