Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
si yo digo, miren, regla del sprint, si el cliente X baja por la tangente y se topa con el proyecto B, que al mismo tiempo desciende y asciende hacia la constelación de Leo y comienza a presentar esos, solo porque han ocurrido dos veces, y quiero que cambien las cosas por ese escenario que ocurran dos veces al año, estaría presentando impedimentos para algo que puede o no puede ocurrir. ¿Verdad?
aún en los escenarios que sí ocurren seguido, ocurren seguido, no sabemos cuál va a ser la mejor manera de proceder y cuando digo no sabemos es nosotros los ingenieros y por más que quieran ni los jefes ni los project managers, no saben mientras no avancemos x porcentaje y nos enfrentemos a ese problema. Entonces todas esas preguntas, sugerencias, dudas o cosas que creo que van a fallar
no las traigo a la mesa.
Hola a todos, bienvenidos a un episodio más de Dev & Ops, su podcast favorito donde hablamos de desarrollo, tecnología, DevOps y su cultura en general. Y como siempre, acompañado de mi buen amigo, co-host Juan Ramos, a quien le doy la bienvenida a un episodio más. Juan, bienvenido.
Juan (01:18)
Hola Douglas, ¿qué tal? ¿Cómo has estado vos? Yo aquí estoy bastante emocionado. De una plática más, estoy contento porque he arreglado un poco más mi cluster de servidores. Logré.
logré hacer algo que suena muy simple pero a mí me ha traído una paz mental increíble tenía un servidor que se estaba recalentando, es de esas plaquitas pequeñas tipo Raspberry Pi y se estaba calentando demasiado y logré pues ponerle unos hitsinks y le anexé un ventiladorcito ahí medio hechizo y listo ahora ya no pasa de
llega por mucho a 50 grados y ya puedo dormir tranquilo. Me regreso el alma.
Douglas (02:08)
Me gusta, me gusta, son de esas pequeñas victorias de cositas que a veces nos metemos a hacer y hasta que nos salen, tal vez no es la gran cosa, pero mientras nos salen no nos dejan dormir. Son problemas que tenemos las personas en tecnología, pero me alegra que haya concluido bien en tu caso. Y bueno, Juan, no sé qué te parece si hoy comenzamos con...
Juan (02:12)
No,
Exacto.
Douglas (02:33)
platicar del tema que queremos hablar hoy y es que hoy queremos hablar un tema un poco más de cultura DevOps. Hace mucho tiempo no tocamos un tema relacionado a cultura, hemos ido un poco más hacia la inteligencia artificial o un poco más a los temas técnicos con contenedores y ese tipo de cosas, que las personas que estamos en todo lo que tiene que ver DevOps, ya sea desarrollo o ya sea la parte de operaciones, nos topamos en nuestro día a día.
siempre está sí o sí en nuestro día a día es la cultura DevOps. De eso no nos lo quitamos. Si trabajas con un equilenguaje de programación van a ver día donde estás diseñando, el software no estás programando, van a ver día donde estás haciendo reportes, pero no necesariamente programando.
si trabajas con, en la nube ocurre lo mismo, no todo el tiempo estás administrando o haciendo operaciones en la nube, pero con la cultura DevOps, perdón, eso sí es nuestro día a día, porque tenemos que colaborar con el programador, con el de operaciones, tenemos que rendir cuentas, tenemos que interactuar con los project manager, con los stakeholder, etcétera, etcétera. Entonces, le hice bastante preámbulo al tema, porque lo que yo quiero sacar,
que discutamos hoy es cuál debe ser nuestra actitud como ingenieros, llámese ingeniero en programación o ingeniero en operaciones, ingeniero networking, ingeniero en base de datos, llámese el puesto que cada uno de los que nos ve y nos escucha tiene, cómo debemos reaccionar como ingenieros ante las metodologías ágiles.
ya sea que se está implementando una nueva metodología, un nuevo control en el manejo de los proyectos y las tareas en tu departamento o que llegamos a un nuevo equipo, ya está implementado y tengo que adaptarme a una metodología ágil o a una forma diferente en que la está haciendo un equipo. Ahora, ¿por qué es el tema Juan? Y es que aquí voy a contar algo que me está ocurriendo a nivel personal donde yo trabajo en field.
Actualmente se lleva como un mes, un mes y medio que se está implementando Sprints, ¿verdad? Sprints que es parte de metodología ágil en el departamento en el cual yo trabajo, que es un departamento obviamente de sistemas y de operaciones.
En lo personal Juan, en lo personal siento que no fue la movida correcta porque somos un departamento que tenemos guardias, que tenemos on call, que estamos pendientes de sistemas, caen alertas y eso nos hace desviarnos de nuestro día día para ir a ver alertas y reaccionar a ellas y responderle al cliente, a veces hacer un incident report de lo que ocurrió y mandárselo al cliente.
Aparte tenemos peticiones que caen con urgencia porque los que trabajamos en un departamento de sistemas y con infraestructura para hospedaje de sitios y aplicaciones web llegan a ese tipo de emergencias. Entonces, tienen... Ajá.
Juan (05:45)
Perdón Douglas,
no sé si tal vez nos podrías explicar un poquito mejor esa primera parte cuando mencionas que son guardias. O sea, cómo funciona eso en tu departamento. Mencionas que tienes algo de on call, pero tal vez, no sé si nos podrías dar un poquito más de detalles en eso.
Douglas (06:04)
Sí, sí, claro, gracias por preguntar eso porque si lo aclaramos. La guardia o el on-call, on-call es la manera de decirlo en inglés, no como el que está en llamada, el que está para a quien vas a llamar, recordemos que estos términos vienen desde hace muchísimos años en tecnología, no había WhatsApp, no había WhatsApp, verdad, entonces el que está on-call, de hecho, o estar de guardia es el término en español, es una persona o un departamento que está pendiente de recibir
Juan (06:14)
Ok
cuando no había WhatsApp.
Douglas (06:34)
alertas de sistemas cuando fallan o cuando están a punto de fallar, dependiendo de cómo esté configurado el monitoreo y la observabilidad. Esta persona o este departamento recibe la alerta y son los responsables de actuar inmediatamente porque estás cuidando del sistema de producción, estás de guardia. La persona recibe una alerta que se le dice un page
se le dice page porque hace mucho tiempo la gente tenía los pagers que son esos aparatitos que en la zona de Latinoamérica donde nosotros vivimos les decían los beepers.
que eran el Viper, que era la marca del dispositivo, así se llamaba, ¿no? Y se popularizó el nombre Viper. Aquí en Latinoamérica en realidad es un Pager, ese es el nombre del dispositivo. Antes recibían un Page porque lo andaban en cualquier lugar y, tengo que ir, conectarme y resolver. Entonces recibiste un Page, una alerta, a tu celular te cae por medio de llamadas, te cae por medio de Slack, te cae por todos lados.
Juan (07:14)
Sí.
Douglas (07:37)
para que puedas ver, puedas reaccionar y puedas actuar. Entonces en nuestro departamento hay un ingeniero, hay una rotación de 24 horas, entonces siempre hay un ingeniero que está de guardia, que está on call, recibiendo esas llamadas. Entonces, ¿qué ocurre Juan volviendo al tema? Perdón, ¿eso responde a tu pregunta? Sí.
Juan (07:55)
Sí, sí, sí, queda
más claro. Gracias.
Douglas (07:57)
Ok,
perfecto, gracias. Entonces, habiendo aclarado eso, en un departamento donde el ingeniero tiene que estar de guardia, que eso es incierto, hay días que te caen durante tu tiempo que estás de guardia, te caen 8 o 10 alertas y tienes que actuar a ellas, y veces pasan dos semanas y no recibís ninguna. Así funciona la guardia, aquellas personas que tienen la oportunidad de estar de guardia lo saben.
El día que queremos hacer algo más y esperamos que ojalá sea un día tranquilo, es el día que más alertas recibimos. El día que tenemos disponibilidad y ojalá que me caigan alertas para tener trabajo que hacer, ese día no cae nada. No son reglas que yo inventé. El universo así nos quiere tratar a los ingenieros. Pero en un departamento que tiene esas variables,
Juan (08:27)
Jajaja
Douglas (08:49)
Querer tener un sprint donde se asignan tareas antes de que empiece el sprint y se asignan estimados, ¿verdad? Y en base al estimado y en base a la hora de trabajo cada semana se define cuántas tareas vas a hacer antes de que comience el sprint es una movida difícil. En mi opinión no era la movida correcta. No estoy diciendo que no se pueda implementar sprints.
en un departamento de sistemas, no es eso lo que estoy diciendo, estoy diciendo que me parece a mí que no era la movida correcta, había que mover ciertas otras cosas, antes de implementar los sprints, sin embargo, sin embargo, se están implementando, ¿verdad?
En medio de eso, Juan, hay obviamente al principio un poco de caos, hay un poco de incertidumbre. Han habido un par de incidentes donde los ingenieros creíamos que los jefes y el project manager nos iba dar algo. el project manager creía que nosotros lo íbamos a hacer y existía desconexión. Hay que estar asignando estimados para cada tarea. Hay que estar diciendo, creo que me va tomar dos horas.
pero a veces es difícil hacer un estimado sin dedicarlo aunque sea una media hora como para ver qué se tiene que hacer. a veces el estimado se da la ligera, a veces o si se da un estimado muy grande entonces ahí viene el project manager o el jefe y te dice ¿por qué aquí pediste cuatro horas? Y hay que querer justificar algo que no tuve mucho tiempo para ver y sólo toca decir mira sé qué mínimo se va a hacer esto, esto y esto.
Juan (10:19)
Sí.
Jajaja
Douglas (10:36)
pero no sé qué más puede surgir, entonces no sé, puse cuatro horas, ¿verdad? Y ahí comienzan conflictos, ¿verdad? Donde a veces, a veces se hace de más o a veces se hace menos y uno como ingeniero siente que no importa qué pase, la culpa le cae a uno. Uno siente que no es de uno la culpa, pero sentimos que nos cae a uno. Uno dice, el jefe no va a aceptar su culpa o el project manager nunca acepta su culpa y por ahí se genera conflicto y...
Juan (11:05)
Bueno, eso cuando sos responsable.
Cuando no... No pasa nada.
Douglas (11:07)
Claro.
Bueno, y me gusta que lo digas, no porque puede haber actitudes hacia diferentes ángulos. Puede ser alguien que diga, a mí no me importa, yo voy a hacer lo que me digan y si va mal o si va bien, el ticket que me asignen es el resuelvo. Yo sé que tal proyecto tiene más urgencia, yo sé que el otro cliente tiene mayor prioridad, pero si me asignaron esa tarea, esta voy a hacer. sea, y justo eso lo que queremos discutir. Y yo, a medida avancemos, Juan, quiero comentar.
la diferencia entre lo que pienso y todo lo que he pensado sobre esta implementación de Sprints en el departamento en el cual yo soy parte, la diferencia entre lo que pienso y lo que he hecho, ¿verdad? Con toda la intención y el mejor deseo de que los Sprints funcionen.
Yo sé que hablé bastante Juan, pero quería poner el fundamento de por qué es la plática y esperamos, esperando siempre que esta plática y que nuestra experiencia le sea de valor a las personas que nos ven y nos escuchan. Pero tus primeras impresiones sobre el tema Juan, me gustaría saberlas.
Juan (12:18)
Bueno, primero que nada, siento que de hecho no hablaste lo suficiente. Eso es mi impresión. Porque, bueno, yo sé que a nosotros nos escuchan personas que están empezando en el área, están empezando en este maravilloso mundo de tecnología. Y probablemente no estén familiarizados con los términos de sprint. Aparte de eso, los sprints, al menos en mi experiencia, Douglas,
se implementan de maneras diferentes dependiendo de cada una de la empresa. Cada empresa, cada departamento a veces utiliza una metodología diferente.
y eso suele pasar. no sé, me gustaría que tal vez nos dieras un poquito más de... solo como para entrar en un mayor contexto. Sé que al final del día no es el objetivo de decir que lo que están haciendo está mal o está bien. Es más que todo como para entrar en contexto de qué es un sprint, cómo suele dividirse. Y bueno, de hecho, para no...
no tirarte la pelota tan rápido. Te puedo comentar cómo solemos hacerlo donde estoy yo, Donde estamos, solemos tener sprints que están divididos por entregables. En otras empresas donde he estado, son sprints semanales o bisemanales. Independientemente de lo que entreguemos, son sprints marcados por un tiempo. Actualmente, donde estoy, los sprints
Douglas (13:32)
Sí.
Juan (13:54)
son por entregables. un... ¿cuál es la palabra? Una iniciativa, así se le denomina. Y en esa iniciativa se definen todas las tareas y este es el sprint. El sprint tiene un inicio, un final y a cada tarea que nosotros asignamos, que en este caso, hecho, creo que lo he mencionado en otros episodios, somos los developers quienes creamos las tareas y los tickets y todo, asignamos un puntaje.
este puntaje en nuestro caso es en base a cuántos días nos tardaríamos en terminarlo por ejemplo si una tarea me tomaría mi yo creo que me va tomar un día en desarrollarlo y que esté listo pues entonces pongo 1 si me va a tomar medio día entonces sería punto 5 y así no en adelante esa es la manera que nosotros utilizamos para poner los sprints y
Y bueno, como decía, para dar un poquito más de contexto, en otros lugares donde estaba el puntaje ya no es por día, sino que es un estimado de la cantidad de esfuerzo que se va a realizar en la tarea, no ligado al tiempo, sino a qué tan difícil creo que sea. Y en otros lugares, vamos a ver si recuerdo bien.
No asignábamos un puntaje, hasta donde recuerdo. Sin embargo, los ordenábamos de manera en prioridades. Estos tickets tienen una mayor prioridad que estos y los voy realizando a la manera en que se vayan terminando. Y esos deberían bastarme para trabajar durante una semana.
Entonces por eso ahora te lanzo la pregunta, sea, ¿cómo suelen hacerlo? Y también lo pregunto por lo que mencionabas, ¿no? Tu departamento es diferente al departamento de un developer que tiene un feature, un bug o algo así. Entonces, ayudarnos a entrar en esos detalles, tal vez.
Douglas (15:55)
No está bueno, mira está bueno, la razón por la cual no quería yo tal vez ahondar mucho en la parte directa de lo que es Sprint y Agile es uno porque no soy la persona más indicada, no tengo un entrenamiento apropiado en todo lo que tiene que ver con metodologías ágiles, Scrum, como lo tendría un project manager que ha pasado por muchas certificaciones, entrenamiento, incluso hasta la universidad porque existe una maestría.
en administración de proyectos aquí en latinoamérica. Aunque por ahí salen los memes que lo único que tienes que saber es cómo preguntar cómo vas, por ahí salen los memes, no voy a profundizar en eso, pero esa es razón por la cual tal vez no quería profundizar, pero afrontarlo desde el lado como un ingeniero que trabaja por muchos años ya con diferentes metodologías ágiles. Ahora,
Juan (16:28)
Sí.
No,
Douglas (16:54)
Para encaminarme hacia tu pregunta, en nuestro caso básicamente lo que se lleva son sprints de dos semanas y la idea es trabajamos 40 horas a la semana, entonces quiere decir que el sprint son 80 horas para cada ingeniero. Básicamente es dividir, cuántas horas le sacamos para cuestiones administrativas, reuniones y cosas.
cuántas horas dejamos de buffer para emergencias cuando el que está de guardia y luego cuántas horas le asignamos a los diferentes proyectos, clientes, tareas que hay pendiente, etcétera y se van asignando las tareas. Entonces en palabras simples es eso, se cuentan esas 80 horas para cada ingeniero y yo decido de lo que está en mi sprint que hago cada día.
Y vamos haciendo el stand up todos los días, que el stand up es esa reunión diaria de rendir cuenta donde decís que hiciste ayer, qué vas a hacer hoy, si has tenido algún impedimento y tratar de discutirlo, es algo súper breve, que está programado para media hora todos los días.
A veces toma 10 minutos, a veces se pasa un poco, todo depende de qué ha habido, ¿verdad? Pero así es como nosotros manejamos los sprints. La parte por la cual esto es retante, Juan, es porque ese buffer que dejan para incidentes, para alertas, para el que está de guardia.
Juan (18:10)
Mm-hmm.
Douglas (18:23)
ese bien incierto. Comenzaron diciendo, le vamos a dejar porque mira cómo dividen el tiempo, el tiempo se divide, se le dice resourcing, aquí donde yo trabajo, es cuántas horas va estar un ingeniero asignado a X proyecto. Es lo mismo para programadores, como para sistemas, como para diseñadores, como para QA, se hace una hora resourcing.
Y la manera en que lo planean es, voy a hacer resourcing para Douglas, lo ocupo dos horas diarias en este proyecto, entonces me ponen diez horas, en esta semana de las 40 que tengo, diez horas para el proyecto X. Ahora, ya en la práctica, no es que voy a estar dos horas diarias en ese proyecto, en la práctica, un día le dedico cinco, otro día le dedico cuatro, el último día le dedico uno.
o a veces un día urgía yo ese día trabajé las 10 horas, ese día trabajé de más y ya terminé mis 10 horas. Pero la manera en que lo planifica el Project Manager son dos horas diarias. Para todas las personas que trabajamos en lo técnico sabemos que, realísticamente, eso es complicado. Porque si ya estás en la zona, programando, ya entraste a la zona, estás avanzando y se acabaron las dos horas del día, si vos pausas ahí,
el siguiente día que comences te vas a atrasar porque nos vuelve a tomar cualquier cantidad de entre cinco minutos a una hora, dependiendo del proyecto, volver a entrar a la zona y continuar, ¿verdad? Entonces eso no, realisticamente no funciona así. Ahora, de nuevo, con proyectos nos la arreglamos.
Yo me ajusto que día, en realidad no trabajo las dos horas diarias que dijeron, trabajo más horas un día y para el lunes, perdón, para el martes ya he terminado con mi tiempo asignado para proyectos X y Y y del miércoles en adelante trabajo en el proyecto Z y el proyecto beta por dar nombres, no cualquiera.
Pero con el... con el... la guardia, comenzaron lo mismo, nos vamos a dejarles una hora y media diaria para que... para la guardia. Entonces, claro, pasaron cuatro días y mientras estuve de guardia no cayó una sola alerta. Entonces ahora tengo... hora y media diaria son... ocho horas o siete horas y algo. No recuerdo. Entonces ya para el jueves no me ha caído nada.
Juan (20:38)
Ok
Douglas (20:59)
y ya para el viernes ya casi no tengo tiempo disponible porque he estado empujando el tiempo de estar de guardia entonces ahora viene el viernes a buscar que hago que no era parte del sprint o sacar del backlog porque no cayó una sola alerta entonces el siguiente sprint dijeron no bueno entonces mucho tiempo le vamos a dar una hora nada más para para estar de guardia y entonces esta semana y esto es real Juan, esto son anécdotas reales entonces ya esta semana
Juan (21:26)
Sí.
Douglas (21:29)
esas las cinco horas que tenían de guardia para el miércoles ya no tenían. Entonces es incierto, es difícil predecir eso, es difícil predecir eso porque hay incertidumbre, dependemos de alertas, dependemos de sistemas. De nuevo, nosotros somos un departamento un poco diferente, entonces por ahí es donde ha habido conflicto y por ahí es a lo que me estoy refiriendo con implementar los sprints, porque ha sido un reto.
y por qué creo que no se hizo como debió haberse hecho. Ahora, aquí la conversación Juan, al final no es tanto que creo, ya lo expresé, algunas cositas cambiaron, otras cosas no, no es tanto qué es lo que creo, sino ya que esa es la decisión de los gerentes, ya que esa es la decisión, ¿qué debo de hacer?
Juan (22:05)
Sí.
Douglas (22:28)
y por ahí voy, no sé si me logro explicar.
Juan (22:31)
Sí, Aún así, creo que lo que vos crees, como debería ser, también creo que es importante por tu experiencia, tanto creando y manejando los proyectos en otros lugares y en este mismo trabajo, tanto como por también tu experiencia de vos sos el que está ahí.
No, estás en el campo, estás en el lugar. Entonces sí es importante para los que no están escuchando y tal vez están en proceso de sugerir o crear estas metodologías ágiles. Pero también entiendo lo que decís. Al final del día, y esto siempre pasa en todos los trabajos, siempre pasa que hay algo en específico que desde nuestro punto de vista por X y Y emotivo,
no estamos del todo conformes o le vemos las aristas, tal vez esto se podría mejorar aquí, mejorar allá. Y a veces es complicado cómo abordarlo, cómo entrar en una armonía en este tipo de situaciones.
Y ahí va a depender mucho, tanto del equipo de trabajo en general como no solo también nuestra actitud, sino también la de nuestros superiores. Porque no es lo mismo expresar que tenemos una opinión, vamos a decir, y que nos ninguneen de entrada. A, es diferente, que nos escuchen y, OK, vamos a tomarlo en cuenta, vamos a revisar.
tal vez estamos en un periodo de prueba, etc. Hay muchas situaciones que se pueden dar. bueno, eso pasa. La verdad es que eso me hace recordar, Dulas, mientras estabas comentándonos cómo funciona, estaba recordando...
En los diferentes lugares donde he estado, las diferentes metodologías que se han hecho, como mencionaba, había una donde no teníamos puntos, había otra donde los puntos era un puntaje ahí calculado y donde estoy que el puntaje es envaseadillas. Y en cada uno he visto que la actitud de los demás compañeros varía de persona a persona. Porque yo creo, sea, no he visto yo a alguien que diga, wow, me encanta crear tickets y loguear tiempo.
Es algo que no nos gusta por el sentido de que no va tan ligado, o pareciera que no va ligado a lo que sí nos apasiona, es desarrollar código, diseñar sistemas, infraestructura, etc. Pero debido a eso, yo he visto que algunos se lo tomaban mejor, en mejor o en peor manera.
mi forma de abordarlo Douglas es un poco mixta, un poco de bueno es lo que hay y no me lo tomo así, a también pues bueno voy a tratar de jugar un poco y he estado en las posiciones también donde digo bueno sabes que no me interesa esto y lo voy a hacer el mínimo si he estado en esa posición donde realmente me
No sé cómo expresarlo, pero me genera rechazo la forma en cómo se maneja. Sí, sí me ha pasado. Pero también, no sé, Douglas, al menos en mi caso, no sé si ligarlo con la madurez que tenía en ese entonces o qué lo podría ligar. Eso también habría que analizarlo de alguna otra forma. Porque creo que lo importante aquí, como decías, bueno.
Esa es mi opinión, eso es lo que yo creo. Pero pues lo que está es esto. ¿Y ahora qué? ¿Nos ponemos a hacer pataletas y hacer rabietas? ⁓ cómo lo hacemos? Porque mientras lo comentabas, Douglas, me ponía a pensar, ¿cómo lo hacemos en el departamento de desarrollo? Si bien es muy parecido, hay muchas cosas que son bien diferentes a lo que vos comentabas. Y no estoy seguro.
cómo me sentiría yo en esa posición. Más que todo porque ya estoy muy acostumbrado a cómo se hace en el ambiente de F. Estoy seguro que si estoy en la situación, me tendría que acostumbrar. Pero no es algo a lo que estoy acostumbrado. Y, así es como funciona cada departamento. Pero, estoy desviando bastante. Al final del día. Sí, sí, o sea, al final a lo que voy es que
Douglas (27:11)
No, dale, dale.
Juan (27:18)
Depende mucho de la persona, depende mucho de los jefes. bueno, tal vez la práctica la podríamos, vamos a irla discutiendo, en qué podríamos hacer para mejorar la situación tanto para nosotros personalmente como a nivel colectivo, ¿no? Al equipo, ¿qué podríamos sugerir? ¿Cómo abordarlo con los demás personales, compañeros y superiores? Siempre se puede hacer algo, ¿no Douglas?
Douglas (27:45)
No, mira, de acuerdo, de acuerdo. la plática hacia esto va, no está divanando, esto es lo que estamos discutiendo y lo que está diciendo realmente es válido.
Yo creo que no hay por qué juzgarte cuando ha dicho que ha llegado en algunas ocasiones a tener la actitud de me vale. Además, al menos yo sé que no puedo juzgarte porque yo he tenido esa actitud en algunas etapas también. Estoy de acuerdo con vos que creo que tiene que ver con la madurez como profesional y como persona. Pero también hay una gran parte de la actitud de los jefes y los project managers. Cuando ellos se escuchan.
analizan lo que dijimos, las cosas que pensamos que no van a salir bien. Pero después de analizarlo, aun así concluyen en continuar, yo me siento tranquilo, pero ellos de verdad lo consideraron.
Juan (28:41)
Sí.
Douglas (28:41)
Entonces,
ya uno dice, OK, ellos llevan y entienden otras cosas que yo no entiendo. Entonces, se consideró mi sugerencia, vamos a continuar. Eso ya, pues ya mucho. Pero ya que dijiste de llevarlo, llevar la plática a qué hemos hecho para llevarlo bien y qué podemos aconsejar.
tal vez puedo comenzar un poquito yo de esta experiencia y esta experiencia es la que tengo fresca Juan, he pasado por este proceso antes vos ya dijiste que has pasado por él varias veces lo primero que yo estoy haciendo ahorita Juan es a pesar de que yo me siento convencido que como lo quieren manejar los jefes no va funcionar tengo un deseo genuino
de que me demuestren que me equivoqué. Yo, porque yo les he dicho, miren, yo creo que esto no va funcionar de buena manera, no, no, no, de una manera constructiva. Yo creo que esto va a fallar. Pero les fui honesto y lo que estoy diciendo ahorita se lo dije a ellos, pero de corazón se lo digo, quiero que este proceso me demuestre que estaba equivocado. Y estoy, Juan, comprometido en que funcione.
Estoy comprometido en que funcione. A pesar de las cosas que creo, entonces trato de levantar la bandera roja cuando creo que algo puede ser un problema, trato de seguir la instrucción que me están pidiendo, trato de acomodarme, trato de estar diciendo, hey, en estos escenarios, ¿cómo quieren que lo maneje? ¿Quieren que le diga al project manager? ¿Quieren que le diga a la persona del proyecto o al cliente que se comunique con ustedes? Estoy comprometido a que funcione.
Me gusta? No, no me gusta, pero soy un adulto y soy un profesional donde yo trabajo, no todo va a ser color de rosa y va a girar alrededor de mis necesidades y de lo que a me agrada o no me agrada. Y como profesional, debo de cumplir con el trabajo que se me asigna. Entonces estoy reconociendo que no me gusta, mas sin embargo...
me he comprometido a que funcione y te voy a decir ya comprometido en ello la primer cosa que hice es ya como en acción, dentro de la práctica de los Springs cuando dijeron presentan las cosas y este es el Spring y esto vas a hacer alguien tiene una duda, una preocupación y me surgieron 30
Juan (31:02)
Mm-hmm.
Douglas (31:22)
Me hicieron un número amplio, no fueron exactos, pero me surgieron un montón y todas válidas y todas con una posibilidad alta de que ocurran, más sin embargo traigo a la mesa solo las que veo que están de frente o que están cerquita.
Juan (31:40)
jajaja
Douglas (31:40)
Porque si yo digo, miren, regla del sprint, si el cliente X baja por la tangente y se topa con el proyecto B, que al mismo tiempo desciende y asciende hacia la constelación de Leo y comienza a presentar esos, solo porque han ocurrido dos veces, y quiero que cambien las cosas por ese escenario que ocurran dos veces al año, estaría presentando impedimentos para algo que puede o no puede ocurrir. ¿Verdad?
aún en los escenarios que sí ocurren seguido, ocurren seguido, no sabemos cuál va a ser la mejor manera de proceder y cuando digo no sabemos es nosotros los ingenieros y por más que quieran ni los jefes ni los project managers, no saben mientras no avancemos x porcentaje y nos enfrentemos a ese problema. Entonces todas esas preguntas, sugerencias, dudas o cosas que creo que van a fallar
no las traigo a la mesa. ¿Qué hacemos discutiendo 30 preguntas diferentes al principio? Perder tiempo y no arrancar. Entonces, solo traigo a la mesa las que están en este sprint, las que están ahí de frente o las que son demasiado evidentes y que eso va a ser un problema serio sí o sí. Entonces, de 30 dudas que tenía, presenté cuatro.
Juan (32:47)
Sí.
Douglas (33:03)
y eso nos ha ayudado a ir avanzando y a medida voy avanzando cada paso que damos de las 30 dudas y preguntas originales que tenía se le van agregando 3, 4 cada paso que damos pero voy presentando, voy trayendo la mesa solo las que están cerca no con la intención de que falle sino con la intención de que los sprints y adaptarnos a los sprints avance
avance y que con mayor información recopilada, con mayor experiencia en cómo funcionan los sprints, pueda yo presentar alternativas y puedan los project managers y jefes tener
experiencia de cómo poder responderlo. es una de las cosas que he estado haciendo, que he estado poniendo en práctica. ¿Me gusta Juan? No me gusta, no me gusta. Me incomoda trabajar en algo que siento que adelante, que cuatro pasos adelante puede fallar, pero me he adaptado a ello porque como te digo, soy un adulto, soy un profesional y las cosas no van a girar a como yo quiero. ¿Cuál es tu pensamiento al respecto?
Juan (33:44)
y
Sí.
Siento que es una manera muy interesante de abordarlo porque cuántas veces no nos vemos tentados a decir es que no, es que no va a funcionar y se los dije y tratar de a veces demostrar que tenemos la razón. Sin embargo, no es la mejor postura que podemos tomar. que tu posición es la más acertada, es OK.
y qué tal si yo estoy equivocado, bueno, vamos a verlo, voy a poner de mi parte y vamos a hacer que funcione. Creo que eso es lo mejor. Yo recuerdo muchas ocasiones donde todo mi grupo estábamos en contra de cómo se estaba haciendo. En retrospectiva, creo que era más como un rechazo a algo diferente, Porque no era la manera que solíamos hacer las cosas.
y teníamos este rechazo, pero en cierto momento uno tiene que caer en cuenta de bueno, esto lo están haciendo así por una razón, quieren hacer algo en específico, quieren tal vez atacar algún problema que vieron en el equipo, hay muchos motivos por los cuales realizar este sprint y lo primero que yo puedo recomendar es no...
no pensar que las metodologías ágiles están solamente para hacernos la vida imposible. No, realmente si tienen su valor, si tienen su objetivo. Y a veces cuesta verlo porque estamos, ¿cómo decirlo?, no sé si es la manera correcta, pero es como que estamos en la, hasta lo más bajo de la cadena alimenticia de ese proceso, donde estamos logueando obras, pero no vemos el para qué se utilizan.
No lo vemos a simple vista. Pero es hasta que nos toca llevar el control de algún proyecto, es cuando vemos, creo que sí es necesario algún tipo de control, sí es necesario algún tipo de manera de comunicación.
entre qué está haciendo cada quien. Recuerdo mucho a un amigo, gran amigo con el que todavía me llevo en el primer trabajo en el que estaba. Recuerdo que nosotros estábamos en el área de mantenimiento. Mantenimiento significa hacer bug fixes y arreglar pequeñas cositas del sistema que está actualmente. Aparte estaba otro grupo que era el de desarrollo. Ese era el que hacía cosas nuevas, features nuevos. Bien.
Como te podrás imaginar, es un departamento donde era más que todo reactivo a lo que sucedía dentro del sistema. Por eso mismo, era muy común que en una hora yo atendiera múltiples tickets, múltiples cosas. empezaron a solicitar que escribiéramos el tiempo que nos tomó cada uno de ellos. Y a veces sí se volvía.
engorroso, Porque era, bueno, tres minutos en este, cinco minutos en este otro, luego pasó un tiempo donde estuve haciendo algo un poco fuera de los tickets y luego otro y así no. Recuerdo mucho a mi compañero que a manera de protesta, literalmente protesta, escribía, 8 de la mañana, entrada, 12 de mediodía, almuerzo, 5 de la tarde, salida. Ese era su reporte. Bueno.
esa fue su manera, pero lo que a mí me causa mucha gracia ya hoy en día es que luego fue ascendiendo porque era un buen trabajador, simplemente esa era su protesta en su momento. Cuando ascendió y ahora tenía que él llevar el proyecto, bueno ahora él sí nos solicitaba, ok, escriban el ticket y pongan las horas y todo eso. Fue gracioso. Por eso...
Douglas (37:42)
Sí, sí.
Decime que vos le entregabas los reportes
igual a él, por favor.
Juan (38:00)
Perdí la oportunidad de hacerlo, fíjate. Sí. Es por eso que menciono que a veces es difícil verlo en su momento. Y pareciera que solo hasta que estamos en esa situación vemos la importancia de esto. Y ya lo hemos hablado en otros episodios donde.
llevar el control de los tickets y del tiempo realmente es muy, muy útil para poder manejar un proyecto. Y más estos proyectos grandes, por ejemplo, Douglas nos ha contado en el trabajo, son proyectos muy, muy complejos en la mayoría de las veces. Y por eso es necesario poner de nuestra cuenta. Yo, en lo personal, pues siempre he tenido problemas con las horas y termino logueándolas fuera de tiempo. Así que.
Lo que he estado haciendo actualmente, esto ya es mi yo actual, he estado obligándome a tener mayor control sobre esto. Y bueno, este es un consejo para si hay alguien que sea igual que yo, que se le va el pájaro y no tomo el control muy bien de los tiempos y escribir todos los detalles, los tickets y todo eso. Que también es...
es una consecuencia de, creo que ya lo he mencionado también, en mi trabajo pues son un poco más relajados diría en ese aspecto. Por ejemplo no me piden un tiempo específico de logueo. Simplemente, bueno, ¿qué hiciste en el ticket? Pero lo que estoy haciendo actualmente es, okey, estoy haciendo incluso un sistema donde pues...
genero un reporte de mis tiquets y empiezo a analizar cuál es tiene mayor prioridad, etcétera. Porque yo necesariamente, o sea, de verdad necesito mejorar esa parte. Entonces aquí vendría pues un consejo más. Toménganlo en serio.
Si están notando que realmente les cuesta trabajo porque les genera incomodidad, ahí es donde más tenemos que ver la manera de cómo hacer que no te generen incomodidad, que se vuelva como parte de tu pipeline, de tu proceso de trabajo. Porque, como decía, realmente es importante. También recuerdo, Douglas, en cierto momento me tocó hacer un proyecto y...
No era el jefe jefe, pero de cierta manera me tocaba organizar algunas cosas junto con otros compañeros. pues era necesario. Era necesario tener un control de qué hizo cada quien, cuándo lo hizo, en qué parte tuviste más problemas, etcétera, etcétera.
Realmente las metodologías ágiles siempre tienen este inconveniente, ¿no? de cómo se va a... No cómo se va a hacer, sino que genera un problema con los developers. Siempre, siempre, siempre.
Douglas (41:06)
Sí, sí, fíjate que me gusta todo lo que estás diciendo y realmente que me identifico, lo comparto. Es clave lo que decís de que debemos entender que es necesario el orden. Si recordas mis palabras al principio de la experiencia que actualmente estoy cruzando en el trabajo.
En ningún momento dije que es mala idea la implementación de los sprints. De hecho, no es que se ha trabajado mal, pero se necesita orden, se necesita más orden. Lo que yo dije es...
¿Cómo decidieron hacerlo? Creo que no es la manera apropiada. para comentar qué creo yo, y bien resumido, yo creo que lo primero hay que reestructurar y tener ingenieros solo de soporte, ingenieros que estén haciendo mantenimientos, que son tareas ya definidas, haciendo mantenimientos y que estén de guardia, rotándose. Tener ingenieros para eso y luego que estén los ingenieros
Juan (41:44)
Sí.
Douglas (42:11)
que trabajamos en proyectos, en tareas más grandes y el que está de guardia que haya un nivel 2.
donde los ingenieros más senior estemos en ese nivel 2, si el ingeniero de soporte no pudo resolver algo, que lo escale aquí en este de guardia, eso va a generar muchísimo menos interacción nuestra cuando estamos de guardia eso puede generar algo un poco más predecible al momento que caiga una alerta hacia nosotros y eso, con eso, con ese fundamento.
todo lo más que estamos haciendo, esa es mi opinión de cómo debería de hacerse. Y yo presenté los diferentes argumentos de por qué creo que debe de ser así, ¿no? Entiendo qué hay detrás de ello, entiendo qué hay detrás de ello, pero esa es la manera en creo, pero jamás he dicho que no se necesita, de hecho el orden es importante, es necesario y en base a eso, otra cosa que yo he hecho,
es entender que el project manager no tiene la culpa. Te voy a contar rapidito. Después del primer sprint, quien estaba de project manager, cambió de trabajo. Ya había cambiado de trabajo antes, él puso como dos semanas o tres de preaviso.
Juan (43:23)
cierto.
Douglas (43:35)
y cambió de trabajo. Vino un nuevo project manager y al pobre, normalmente Juan, las personas que comenzamos a trabajar en FIU, tenemos una semana de inducción, donde vemos las políticas de la empresa, donde vemos cómo pedir permisos, cómo manejar las horas, los pagos, introducción al departamento, y tenemos ese tipo de cosas. Y a partir de la segunda semana,
Juan (43:41)
jajaja
Douglas (43:59)
Comenzamos a recibir trabajo y nos dan un porcentaje. La segunda semana esperamos que la mitad del tiempo se pueda cobrar a un cliente, la otra mitad para que te adaptes y vas progresando. Hasta que luego de como un mes o dos meses ya se espera que la mayoría de tu tiempo se le pueda cobrar al cliente. Todos los ingenieros y todas las personas de hecho pasamos por ese proceso. El pobre project manager que contrataron...
Juan (44:19)
Mm-hmm.
Douglas (44:26)
a partir del segundo día, él tuvo que empezar a trabajar en serio. Y el hombre está queriendo asignar tickets mientras quiere entender cómo manejamos la tecnología y el stack, mientras quiere entender qué es lo que hace el cliente y cómo lo maneja, y a quién darle prioridad. Realmente, al pobre lo tiraron al fuego.
Juan (44:45)
a los leones
Douglas (44:46)
peor, a decir, lo tiraron
fuerte al fuego, no con mala intención, se necesitaba al final del día, pero eso causó Juan, está causando que tengamos que darle, dedicarle más tiempo en asignar estimados, nosotros el estimado es en horas, cuántas horas nos toma, si es menos de una hora, si es media hora es .5, pero es en horas.
Juan (45:03)
Ok.
Ok.
Douglas (45:08)
es diferente en todos los lugares, ya nos dijiste po, algunas, escucho gente que dice que, que tamaño de camisa y no sé por qué lo complican, no he escuchado eso acá, teacher sites, no he escuchado, SLXXL.
Juan (45:18)
esa es nueva para mi ok, no, SML ok
Douglas (45:27)
¿Por
qué es así? No sé. Yo no sé por qué no lo mantienen en minutos o en horas. Lo mínimo para mí es días, pero aún así, un día son 8 horas, O un día es la cantidad de horas que trabaja un ingeniero o una persona en su empresa. En fin, nosotros es en horas.
Juan (45:40)
Sí.
Douglas (45:51)
Y entonces hay que ponerle las horas, hay que dar estimados, hay que explicarle al Proyecto Mánoleor cosas de por qué este creo que tiene prioridad y por qué no tiene prioridad. Cosas que discutí con el Proyecto Mánoleor anterior quedaron en el aire porque no había otro gerente presente. Y entonces yo digo, hablé con el anterior tal cosa y quedamos en esto y me dicen, bueno, miráme, pero ahora el nuevo.
explicarle eso y yo les digo, yo soy honesto y les digo miren, no debería de ser así y quiero aclararlo, no debería de ser así Juan, o sea, el departamento debe de tener una transición y una base de datos y de conocimiento lo suficientemente buena como para que cuando transicionen
No tengo yo por qué volver a repetir cosas que ya se discutieron, no debería de ser así. Entonces yo les fui francamente y no debería de ser así. Mas sin embargo, no tengo por qué tener problemas en colaborar. Mientras ellos comprendan que va tomar más tiempo, voy a repetir una conversación, voy a repetir una explicación. Porque el hombre no tiene la culpa.
Él es un hombre, muy bueno realmente el chavo. Él tiene que hacer su trabajo al igual que yo. entender que las personas no tienen la culpa. En general, pues no hay culpables. Los jefes, los gerentes están buscando poner orden. Tienen que poner orden.
Juan (47:12)
No,
Sí.
Douglas (47:28)
Todos tenemos que dar contabilidad, todos tenemos que dar reporte de qué hacemos con el tiempo. Yo no puedo pretender hacer lo que quiera en el día y que nadie me pregunta qué hice y cómo lo hice. Los jefes, los herentes, deben de buscar la manera de que sea más efectivo el departamento y eso tiene que ver con usar el tiempo de los ingenieros de la manera más efectiva posible.
Me gusta Juan, voy a repetirlo, no me gusta. No me gusta, no lo disfruto, no me alegra, pero es lo que hay de frente y tengo que hacerlo de la mejor manera como profesional que soy. ¿Qué va surgir de ahí? Mi esperanza es que sea algo bueno.
Juan (48:15)
jajaja
Douglas (48:17)
ya sea que tal cual los gerentes vieron en su mente que van a funcionar los sprints, que funcionen tal cual como ellos dicen o que se adapte a una versión entre lo que ellos dicen, entre lo que yo he pensado, entre lo que han pensado otros ingenieros porque también otros ingenieros tienen una idea de que creen que es lo mejor y que de ahí salga algo bueno. Pero si no nos comprometemos todos, no va a funcionar.
¿Puedo yo hacerme para atrás, entrar en la actitud que he tenido en el pasado de decir no me interesa si me lo asignan los trabajos, si no me lo asignan no lo trabajo, si va a haber un problema es problema de ellos porque yo me voy a lavar las manos y decir estos son los tickets que me asignaron para el sprint, yo no le presté atención a aquello que iba fallar porque no me lo asignaron, ¿puedo entrar en ese juego? Sí, puedo entrar en ese juego, pero ¿quién le va a perjudicar? Puede que a mí, ¿qué tal que...
como dicen al perro más feo que le pega las pulgas si llega a dar un problema que ocupan después ir a alguien que tal que ese sea yo a pesar de que por más que me quiera lavar las manos entonces no es agradable no es divertido pero como profesionales no va a ser el 100 % de nuestro trabajo agradable tenemos que hacer también la parte fea la parte que no nos gusta con el propósito de que exista un orden
Juan (49:22)
Sí.
Douglas (49:42)
que podamos trabajar mejor.
Juan (49:44)
Yo creo que eso también va para los superiores, quienes toman la decisión de cómo se va hacer el sprint, cómo se va a hacer todo esto, porque también he visto en los comentarios, hay personas que nos ven y pueden tomar estas decisiones en su empresa. Yo creo que sí es muy importante lo que estábamos diciendo antes de escuchar.
y tomar en cuenta lo que nos están diciendo el equipo de trabajo en general. Yo creo que la mejor postura que puede tomar un jefe en este tema en específico es adaptarlo lo mejor que se pueda para que pueda obtener yo los resultados que necesito, o sea, ¿qué resultado necesito? Un reporte que me comunique cómo se está aprovechando el tiempo.
llegar a un punto medio con los developers para que no sea algo engorroso y no sea... ¿Cómo motivar a los trabajadores? Yo creo que tiene responsabilidad los jefes en ese aspecto de poder hacerlo. Claro, tampoco se va a hacer de... Si le preguntamos a un junior, ¿cómo querés que sea? No, pues yo no quiero poner obras. Ah, ok, como no quiere, entonces no. No, tampoco, ¿verdad? Pero...
Douglas (51:00)
Claro,
Juan (51:06)
ir iterando, ir mejorando lo que se pueda mejorar y ir lanzando DLCs a esta metodología. Ya dijimos, esto se hace diferente en cada empresa, aunque se supone que hay una... Bueno, como decía, yo tampoco soy un versado en los Agile, pero se hace de cierta manera diferente en cada lado, que, pues, ¿qué más da si también lo vamos adaptando a nuestra manera en nuestro equipo de trabajo? Si al final lo que queremos es...
tener un ambiente muy bueno. Lo que decías Douglas, ese es mi primer pensamiento al momento de tratar de adaptar lo que indica el trabajo. Lo tengo que adaptar porque es mi trabajo y lo puedo llegar a perder. Pero también, es como el punto número uno. El punto número dos, yo creo que al final del día, quien quiere trabajar en un lugar
donde siempre estamos de mal humor o siempre estamos como llevando la contraria y pues yo creo que nadie, ¿no? Entonces también es responsabilidad de nosotros generar ese ambiente de trabajo que sea un poco más o menos.
Ok, no nos gusta, bueno, pero ¿qué puedo hacer yo? Por eso también está a nivel grupal, como sugerimos, como mejoramos, pero también está a nivel personal. ¿Qué puedo hacer yo para hacerlo? Bueno, lo que voy a hacer entonces es todos los días, tal hora voy a dedicarme a escribir los logs en los tickets, etcétera. No, lo voy a hacer después de terminar cada tarea. Cada quien puede desarrollar su flujo de trabajo a la manera en que se adapte mejor, ¿no?
Yo antes tenía una libreta, me acuerdo, en ese empleo que te menciono de entrada, almuerzo y salida que tenía mi compañero. Ahí yo llevaba una libreta, la misma empresa la proporcionaba y ahí yo iba escribiendo y cada dos días, cada tres días, pues yo ingresaba eso al sistema. Y en ese momento me funcionaba. Entonces, a nivel personal cada uno de nosotros, porque los reportes eran semanales, cada uno de nosotros...
Douglas (52:56)
Ajá.
Juan (53:16)
tiene también la responsabilidad de esforzarnos, como decía Douglas, esforzarnos en que se haga de la mejor manera. Y bueno, también, como decía, para los que están tomando las decisiones, ver de qué manera se puede hacer. Si alguien como Douglas te dice, yo creo que va fallar por esto, ¿qué tal si lo intentamos hacer? Yo, desde afuera, Douglas, lo que veo es, qué mejor no lo intentamos? ¿Por qué no intentamos esta forma?
o bueno, hagamos un punto medio, de nuevo, es llegar a un acuerdo, no un común acuerdo, creo yo. Pero bueno, al final del día así son las empresas y toca buscarle lado, creo yo.
Douglas (54:02)
Si, asi es Juan, mira asi es, yo te puedo decir, yo me siento tranquilo porque han escuchado todas las opiniones, las han valorado, soy el primero en reconocer Juan de que no tienen por que tomar el 100 % de las opiniones que doy, es mas, no solo en esto, los sprints, todo, pueden que no tomen ninguna de las opiniones que doy, que la pongan en practica, si yo estoy en un lugar donde valoran
y analizan la opinión que doy, todas las que doy, ahí estoy bien. Porque tengo que reconocer que como ser humano es imposible que tenga la razón en todo. Yo tengo la buena intención y creo que tengo la razón, ¿verdad? No estoy actuando porque me cierro.
Sin embargo, tengo ese beneficio, mi opinión siempre es escuchada, siempre es considerada, reconozco que tengo un privilegio de estar en un trabajo así, no en todos los lugares es así, y aunque ninguna de las opiniones que de, consideren que tiene que ser puesta en práctica, como todas las analizaron, ahí estoy bien. Y yo creo entonces, Juan, para cerrar el tema, porque acá...
y peor si empezamos a quejarnos porque no es que no tenga quejas, no es que no tenga quejas, el tema es qué deberíamos de hacer y en eso estamos, pero no es que no tenga quejas. Pero para cerrar yo creo que mi mensaje final va a ser pongámosle buena actitud, seamos profesionales pongamos buena actitud, comprometámonos a lo que es nuestro trabajo, recordemos que nos pagan por ello.
Juan (55:20)
Sí, sí, no que quejarlos.
Douglas (55:45)
Recordemos que debemos de hacerlo de la mejor manera y entendamos que no siempre
o no todo de nuestro trabajo nos va a causar gran alegría y satisfacción. Sin embargo, es parte de y debemos de hacerlo. a cambiar por caso? ¿Va a cambiar por empresa, por persona? Sí, totalmente. Pero con nuestra actitud sea buscar hacerlo bien, buscar hacerlo con la mejor actitud, recordando que somos profesionales. Espero que lo que hablamos hoy les sea de valor, que se puedan...
identificar y que tal vez les pueda ayudar a tener la actitud correcta. Juan, ¿con qué mensaje te gustaría despedir?
Juan (56:28)
Bueno, me gustaría pedir diciendo algo similar, Es nuestro trabajo. Y algo que se me viene a la mente siempre con este tipo de situaciones. Recuerdo cuando estaba iniciando, estaba en el proceso de contratación. Ya estaba finalizando el proceso de contratación en la empresa en donde nos conocimos. Recuerdo que yo hice ciertas preguntas, ¿no? ¿Cómo se hace esto aquí? ¿Cómo se hace esto allá? ¿Qué ropa de usar? ¿Qué pasa si necesito hacer un permiso? Y la p-.
Muchacha de Recursos Humanos me dijo, OK, aquí asumimos que trabajamos con adultos profesionales. Así que no vamos a estar encima de ustedes, no vamos a estar haciendo así, porque asumimos que va ser su trabajo. Y eso siempre, desde esa vez lo he tenido en mi mente. Se supone que somos adultos profesionales, hay que actuar como tales. Y como decías Douglas, hay cosas que no nos van a gustar.
y hay que hacerlo porque al final del día creo que hay más cosas que nos gustan en este trabajo que las que no nos gustan así que a mal tiempo, buena cara y bueno, vez dentro de no sé cuánto, unos par de meses nos actualizas a ver cómo finalizó el proyecto en tu lugar a ver si sí estabas equivocado o no
Douglas (57:45)
Sí, no, ¿por qué no? Déjenos en los comentarios, las personas que nos ven y nos escuchan si les interesa saber cómo termina esta experiencia en el departamento en el cual yo trabajo actualmente y con gusto hacemos una segunda parte o una continuación y con aprendizajes, cosas positivas, cosas negativas para que mejoremos. Muchas gracias a todos por haber llegado hasta acá, muchas gracias por su atención, nos veremos en el próximo episodio. Adiós.