Developers y gente de IT Operations

Yo estoy en operaciones, y a desarrollo no los pescamos ni pal webeo, principalmente porque trabajan como el shuto, jamás mandan la documentación y nunca hacen las pruebas, cuando nos obligan a hacer cambios por gerencia, les decimos ok. pero es tú responsabilidad, el 90% de las veces tenemos que volver atras porque a los "genios" se les olvido algo.
Tengo para los angelitos el TFS más actual para gestion de codigo pero ni lo mean.
Bueno en fin, en como dos empresas conozco areas de desarrollo que funcionan como debieran, en todas las demás se hace a la chilean wey.

Harima dijo:

Yo estoy en operaciones, y a desarrollo no los pescamos ni pal webeo, principalmente porque trabajan como el shuto, jamás mandan la documentación y nunca hacen las pruebas, cuando nos obligan a hacer cambios por gerencia, les decimos ok. pero es tú responsabilidad, el 90% de las veces tenemos que volver atras porque a los "genios" se les olvido algo.

Haz clic para expandir...

A la mierda itil, las buenas prácticas y todas las normas para asegurar un buen cambio en la plataforma productiva. Todo eso por equipos de desarrollos desordenados con jefes de proyectos que trabajan al olfato y no con normativas. La huea la hacen a pulso, con pruebas como la mierda y con cero documentación.

A mi me ha tocado varias veces pelear con operaciones de distintas empresas.
Me molesta un poco la actitud de endiosarse y que las cosas tienen que ser de una manera y seria.

Me ha tocado recordarles que informatica nace para ayudar a los usuarios a hacer sus tareas.
De hecho les he tenido que argumentar que en la parte tributaria(que es a lo que nos dedicamos aca) los usuarios podrian llevar sus cuentas y calculos en papel y tener que hacer las declaraciones al SII por medio de papel y seria algo completamente valido; que el dpto de TI en este ambito podria no existir y la empresa igual tendria que pagar sus impuestos.

Entiendo perfectamente que la seguridad y la disponibilidad son cosas fundamentales para el buen funcionamiento de los sistemas TI, pero cuando las politicas del dpto. TI entorpecen las labores naturales de otros dptos.(area tributaria) hay consulto si nuestros procesos los pueden aislar y dejarnos trabajar tranquilos y si no se puede nomas, se pasa a hablar con alguna generencia y se les explica lo que se necesita para poder hacer el trabajo.

GORDIO dijo:

A mi me ha tocado varias veces pelear con operaciones de distintas empresas.
Me molesta un poco la actitud de endiosarse y que las cosas tienen que ser de una manera y seria.

Me ha tocado recordarles que informatica nace para ayudar a los usuarios a hacer sus tareas.
De hecho les he tenido que argumentar que en la parte tributaria(que es a lo que nos dedicamos aca) los usuarios podrian llevar sus cuentas y calculos en papel y tener que hacer las declaraciones al SII por medio de papel y seria algo completamente valido; que el dpto de TI en este ambito podria no existir y la empresa igual tendria que pagar sus impuestos.

Entiendo perfectamente que la seguridad y la disponibilidad son cosas fundamentales para el buen funcionamiento de los sistemas TI, pero cuando las politicas del dpto. TI entorpecen las labores naturales de otros dptos.(area tributaria) hay consulto si nuestros procesos los pueden aislar y dejarnos trabajar tranquilos y si no se puede nomas, se pasa a hablar con alguna generencia y se les explica lo que se necesita para poder hacer el trabajo.

Haz clic para expandir...

Ese es un vicio del área de operaciones el creer que la plataforma es de ellos. Si, tienen la responsabilidad de que la plataforma ande ok (no lo olvidemos), pero se les olvida que la plataforma es de la organización y sirve a los objetivos de la organización. Si la organización dice que entra un sistema nuevo que va a consumir x recursos, pues te aguantas y le asignas los recursos requeridos.

Con respecto a las normas, yo he trabajado tupido y parejo con normas desde el lado de Operaciones y desde el lado de Desarrollo y si, las normas son una paja pero cuando haces gestión es un mal necesario. Además las normas te aseguran dormir tranquilo, y que cuando alguien se vaya de vacaciones la organización siga funcionando sin sobresaltos.

Estos problemas se suelen producir por pelotudos a ambos lados. En Operaciones el pelotudo flojo que no quiere cambiar nada por que implica mas trabajo y que incluso estorban cuando uno quiere hacer pruebas reales.... Y en desarrollo los pelotudos que no entienden que deben hacer pruebas de todo, en especial cuando modifican "ligeramente" la versión que trabajaba perfectamente (no si solo es un cambio en el display) y terminand dejando la embarra por no probar los "cambios paqueños".

En mi antigua pega estaba en las dos caras de la moneda. Había un área de soporte TI general, y a su vez mi área era soporte TI de una unidad específica.
Los TI de arriba no eran muy prolijos con su pega, los software eran externalizados y funcionaban pésimo, tenían errores de años de antigüedad, y muchas falencias, documentación inexistente.
Nuestros clientes eran reacios a la implementación de los cambios, cando implementaron el software en su primera versión, algunos jefes se opusieron rotundamente, y pusieron varias trabas, hasta que se acostumbraron y se dieron cuenta que hacía su pega mas fácil .

En una conocida entidad financiera que transa valores son expertos en hacer esos cambios y volverlos atrás el sábado en la tarde

Los problemas que tuve cuando estaba en la vereda de Desarrollo es que la gente de Operaciones tenía miedo al cambio, a lo que pudiera pasar, y exigían un informe exacto de que huevada iba a ocurrir en la plataforma cuando se pusiera el producto en producción. Nosotros hicimos pruebas y más pruebas, agregamos una prueba de estrés y además documentación funcional y operativa (que ni la usaban, me llamaban igual porque les daba paja leer) e informes del impacto estimado, pero igual ustedes saben que no se puede prever todo.

nibal2 dijo:

En mi antigua pega estaba en las dos caras de la moneda. Había un área de soporte TI general, y a su vez mi área era soporte TI de una unidad específica.
Los TI de arriba no eran muy prolijos con su pega, los software eran externalizados y funcionaban pésimo, tenían errores de años de antigüedad, y muchas falencias, documentación inexistente.
Nuestros clientes eran reacios a la implementación de los cambios, cando implementaron el software en su primera versión, algunos jefes se opusieron rotundamente, y pusieron varias trabas, hasta que se acostumbraron y se dieron cuenta que hacía su pega mas fácil .

Haz clic para expandir...

Por mentalidad como esa varias instituciones grandes están hasta el copi amarrados con software antiguo, obsoleto, porque cuando tuvieron oportunidad de cambiar les dio susto, y ahora el cambio es muy costoso en tiempo, riesgo y plata. En Transantiago todavía tienen algunos sistemas con MySql 4 sobre Windows 2003.

Zuljin dijo:

Documentación funcional y operativa (que ni la usaban, me llamaban igual porque les daba paja leer)

Haz clic para expandir...

Yo me pase casi una semana entera trabajando a full para crear documentación de calidad del primer software que hice, y los usuaurios nunca lo leyeron.

En operaciones somos DIOX, le guste o no a los simples mortales.

El tema va por todos lados, si los implicados hicieran la pega bien el otro lado no le queda otra que hacer su pega bien, pero como siempre existe la chilean wey por las partes, al final es un cacho, la gente no documenta, el otro lado no lee y asi se suman, al final los sistemas andan hasta por ahi no mas, siempre con pifias.

tambien existe la presion de los pares, me acuerdo que llego un desarrollador, usaba el TFS, mandaba el paquete con la documentacion (hasta con las pruebas) y plan de accion en caso de fallas (asi de prolijo el tipo), creo que nunca le rechazamos al principio un cambio, pero despues se le pegaron las malas costumbres de los otros desarrolladores y hasta ahi quedo la buena comunicacion.

Con empresas externas hemos tenido super malas experiencias, en especial porque son un desfile de compadres que los cambian como calcetines, y cada vez hay que explicar todo desde cero, los compadres no manejan ni su propia documentacion, minimo que si les vas a ofrecer tu producto a una empresa, valida que le vendiste primero.

nibal2 dijo:

Yo me pase casi una semana entera trabajando a full para crear documentación de calidad del primer software que hice, y los usuaurios nunca lo leyeron.

Haz clic para expandir...

Yo haria documentacion, pero tengo a mis compañeros de trabajo pa hacer eso... , ademas asi transmito conocimiento.
Mi vida es sacar cachos, inventar nuevos metodos y/o mejoras en el software. Ademas de adaptarme a lo que se le ocurre a nuestros parlamentarios y luego al SII.

GORDIO dijo:

Yo haria documentacion, pero tengo a mis compañeros de trabajo pa hacer eso... , ademas asi transmito conocimiento.
Mi vida es sacar cachos, inventar nuevos metodos y/o mejoras en el software. Ademas de adaptarme a lo que se le ocurre a nuestros parlamentarios y luego al SII.

Haz clic para expandir...

yo pase por algo parecido, pero en mi caso fue del SII /Cepet al HMRC (Inglaterra)

Wena @gatoloco , yo hago varios desarrollos pa Cepet
Y pucha que me hacen rabiar los clientes

Cuando le preguntas al DBA si salió todo OK después de migrar los sistemas de BD en producción.

GORDIO dijo:

Wena @gatoloco , yo hago varios desarrollos pa Cepet
Y pucha que me hacen rabiar los clientes

Haz clic para expandir...

Jajaja tu me conoces.