Una de las cosas con las que frecuentemente solemos toparnos los desarrolladores, consultores y tecnócratas en general, es con la administración de permisos y seguridad en las redes. Si se tiene una empresa pequeña, unos 25 empleados en plan Fabrica de Software, pues.. lo normal es que todos los desarrolladores sean administradores locales, se establezca una política para subir cambios a un entorno de Desarrollo común, estable. Pasadas las pruebas del equipo de desarrollo, pasamos a un ambiente de pre-producción donde otras personas ejecutan sus test. Esto.. en plan pequeño.
Que sucede cuando nuestra compañía es una empresa de mas de 100 empleados, con personas con computadores portátiles, y donde hay tercerizados (esto es, nuestra empresa sub-contrata a otras empresas para labores específicas)? Cómo se determinan los privilegios administrador/usuario avanzado/colaborador/solo lectura?
En mi recorrido, creo que una práctica sana sería: los desarrolladores como usuarios restringidos en sus equipos, pero con una máquina virtual con la que puedan "trastear" y desarrollar. Políticas de supervisión de navegación en el proxy para limitar las cosas que pueden acceder (dudo que Youtube tenga algo interesante para un programador). Si el requerimiento es prohibir a los usuarios estar todo el dia conversando por MSN/GTALK (que me parece iluso, uno puede ser tan o incluso mas productivo y usar estas herramientas), algun cliente de mensajería que puedan usar los miembros del equipo de desarrollo, pero que no permita comunicación web (algo tipo MS Comunicator). Un servidor de fuentes, y una política acertada de cambios en servidores (a desarrollo puede ser diaria, mientras que a otros entornos, semanales o mensuales). A los miembros tercerizados, se les pudiese crear un "grupo" de Active Directory con pemisos similares a los del grupo de desarrollo local.
El asunto que vendría a complicar todo es: quien maneja el AD? personal de la empresa, o se subcontrata? esto es un asunto espinoso, ya que hay empresas en las que la burocracia y procedimiento de cambios en ambientes de explotación, suelen demorar mucho y pasar por tantos niveles, que mas que controlar la seguridad, entorpecen el desarrollo y mantenimiento de aplicaciones.
jueves, 24 de septiembre de 2009
martes, 15 de septiembre de 2009
Rompiendo los ladrillos
De jovencito, recuerdo mi fascinación por los tipos que rompían ladrillos a punta de golpes: Manos, cabeza, piernas, rodilla. Todo era permitido. Me los imaginaba super fuertes. Un día, mi primo, que de eso sabía bastante, me indicaba no lo rompes solo con una parte del cuerpo, sino con todo el cuerpo. El peso ejerce un enorme poder al momento de transmitir algo....
Recuerdo también la "estela de la destrucción": los ladrillos que estaban arriba tenian pequeñas fracturas que a medida que se descendía, era mayor. Hasta llegar a los últimos ladrillos que quedaban desmenuzados.
Ya de "mayorcito" me he fascinado al ver como ese mismo fenómeno se repite en las oficinas. El Jefe Superioris está haciendo algo y le falla un sistema (digamos, un hipervínculo no se muestra en una página web). Comienza el proceso de "estela de destrucción": el dichoso jefe transmite a un gerente de primera linea (el CIO, el responsable de TI, etc, etc etc) la "incidencia" con un "sabes que me pasó esto". Empieza allí el calvario: "ya te envío a alguno de los muchachos para que lo resuelva" o "Que raro? ese comportamiento no es normal". Sigue un "vamos a escalarlo con el personal apropiado para verificar el porqué ocurre eso". Frases acartonadas van y vienen cual manual de protocolo. Y así comienza la estela. El gerente de primer nivel le dice al de segundo "el Jefe me manifestó que hay algo en la aplicación X que no le funciona". El de segundo al de tercero: "el jefe/dueño/manda más/chivo que mas mea/papá de los helados le dijo al gerente qe algo no le funciona". y sigue con un "el XXX le armó un rollo al gerente porque algo no le funcionó, y nos están presionando para que lo resolvamos lo mas pronto posible" hasta que llega al último nivel:
- Se presentó una incidencia, la aplicación falló totalmente (la desmesura de las palabras y lo exagerado de la situación) mientras la usaba el sr. Fulanito, se han encendido varias alarmas porque es algo que no salió en ninguna prueba...
- Disculpa, fulano... una pregunta..... según veo aquí, la incidencia es porque las palabras que constituyen un hipervínculo.. el mouse no cambia de puntero a la manito típica ni se subraya...
- Eso es correcto, pela_patatas_01
- Vale.. Es que.. según el correo enviado por el subgerente_posición_51 cuando la definición de requerimientos, dijeron que no querían que los hipervínculos tuviesen el subrayado ni el cambio del mouse, ya que querían que fuese un texto lo mas compacto, ultraliviano y que nada destacase por encima del resto de las palabras.....
Sorpresa, sorpresa. Comienza entonces una serie de reuniones con usuarios, gerents, desarrolladores, el Papa Juan Pabl.. ahh, que ahora es Ratzinger. Bueno.. en fin. La negociación típica de plazos, de eso no estaba en los requisitos iniciales, que el cambio cuesta tanto, que eso es mucho dinero para algo tan minúsculo, que si, que si no.. que es para el gerente, que se aprueban los 200 mil $ presupuestados... y al final, son los pobres programadores luchando para ver donde rayos estaba el condenado 'a href' que fallaba, con un plazo de 2 días, y si no lo cumples, corre que te despido!!
En fin.. que la terminan pagando los curritos, mientras que el jefe superioris se sorprende que el gasto de su departamento de TI se gaste 200mil $ colocando un 'a href'.. ahh.. no.. en un "proyecto de actualización, mejora y upgrade de las capacidades gráficas de la aplicación"...
Ya decía yo, El peso ejerce un enorme poder al momento de transmitir algo.... sobre todo si es el jefe superior quejándose de algo a los "mortales" que tiene por debajo en el organigrama
Recuerdo también la "estela de la destrucción": los ladrillos que estaban arriba tenian pequeñas fracturas que a medida que se descendía, era mayor. Hasta llegar a los últimos ladrillos que quedaban desmenuzados.
Ya de "mayorcito" me he fascinado al ver como ese mismo fenómeno se repite en las oficinas. El Jefe Superioris está haciendo algo y le falla un sistema (digamos, un hipervínculo no se muestra en una página web). Comienza el proceso de "estela de destrucción": el dichoso jefe transmite a un gerente de primera linea (el CIO, el responsable de TI, etc, etc etc) la "incidencia" con un "sabes que me pasó esto". Empieza allí el calvario: "ya te envío a alguno de los muchachos para que lo resuelva" o "Que raro? ese comportamiento no es normal". Sigue un "vamos a escalarlo con el personal apropiado para verificar el porqué ocurre eso". Frases acartonadas van y vienen cual manual de protocolo. Y así comienza la estela. El gerente de primer nivel le dice al de segundo "el Jefe me manifestó que hay algo en la aplicación X que no le funciona". El de segundo al de tercero: "el jefe/dueño/manda más/chivo que mas mea/papá de los helados le dijo al gerente qe algo no le funciona". y sigue con un "el XXX le armó un rollo al gerente porque algo no le funcionó, y nos están presionando para que lo resolvamos lo mas pronto posible" hasta que llega al último nivel:
- Se presentó una incidencia, la aplicación falló totalmente (la desmesura de las palabras y lo exagerado de la situación) mientras la usaba el sr. Fulanito, se han encendido varias alarmas porque es algo que no salió en ninguna prueba...
- Disculpa, fulano... una pregunta..... según veo aquí, la incidencia es porque las palabras que constituyen un hipervínculo.. el mouse no cambia de puntero a la manito típica ni se subraya...
- Eso es correcto, pela_patatas_01
- Vale.. Es que.. según el correo enviado por el subgerente_posición_51 cuando la definición de requerimientos, dijeron que no querían que los hipervínculos tuviesen el subrayado ni el cambio del mouse, ya que querían que fuese un texto lo mas compacto, ultraliviano y que nada destacase por encima del resto de las palabras.....
Sorpresa, sorpresa. Comienza entonces una serie de reuniones con usuarios, gerents, desarrolladores, el Papa Juan Pabl.. ahh, que ahora es Ratzinger. Bueno.. en fin. La negociación típica de plazos, de eso no estaba en los requisitos iniciales, que el cambio cuesta tanto, que eso es mucho dinero para algo tan minúsculo, que si, que si no.. que es para el gerente, que se aprueban los 200 mil $ presupuestados... y al final, son los pobres programadores luchando para ver donde rayos estaba el condenado 'a href' que fallaba, con un plazo de 2 días, y si no lo cumples, corre que te despido!!
En fin.. que la terminan pagando los curritos, mientras que el jefe superioris se sorprende que el gasto de su departamento de TI se gaste 200mil $ colocando un 'a href'.. ahh.. no.. en un "proyecto de actualización, mejora y upgrade de las capacidades gráficas de la aplicación"...
Ya decía yo, El peso ejerce un enorme poder al momento de transmitir algo.... sobre todo si es el jefe superior quejándose de algo a los "mortales" que tiene por debajo en el organigrama
jueves, 27 de agosto de 2009
El español como idioma de desarrollo
Apenas entraba a la universidad y recuerdo los cientos de errores que Borland C me daba cuando creaba variables "castellanas": 'año', 'adición', etc. Entendí entonces que en lo que respecta al código, el español no es un idioma.. 'bonito', sobre todo por el hecho de tener que interpretar caracteres 'extraños'. Recuerdo también un consejo que decía "los libros de tecnología en español son una utopía, porque cuando llegan a ver la luz, ya la aplicación a la que se refieren, es obsoleta o tiene varios parches encima". Por todo esto pues, siempre me he acostumbrado a las versiones "inglesas" de las cosas: Sistemas operativos, IDE's, Suites de oficina, documentación, etc.
Es que verdaderamente, eso de "ir a Definición", no me cuadra mucho (a pesar de que es muy literal y fácilmente deducible de "go to Definition"). Pero hay conceptos que verdaderamente escapan a mi mente, como el porqué una persona instala aplicaciones en inglés y luego aplica parches de idioma.. cuando va a programar en un lenguaje pseudo-inglés...
Algunas cosas inevitablemente deben ser en español (He conocido sitios donde por política, el nombre de tus métodos debe ser en inglés, y en otros sitios, en español -aunque sin acentos y sin ñ- o en portugués). Usualmente, una de ellas es la documentación / Comentarios de código. Sin embargo pues.... colocarlos en inglés tampoco está mal (sobre todo si se trabaja en equipos con varias locaciones internacionales). Y verdaderamente tiene su ventajas trabajar en inglés, sobre todo el hecho de no tener que descargar paquetes adicionales de idioma (uno para Office, otro para Sistema Operativo, otro para el Framework).. y empiezas a acumular megas y megas de "paquetes" para simplemente poder leer "Archivo" en vez de "file"...
Tiene sentido esto?
Es que verdaderamente, eso de "ir a Definición", no me cuadra mucho (a pesar de que es muy literal y fácilmente deducible de "go to Definition"). Pero hay conceptos que verdaderamente escapan a mi mente, como el porqué una persona instala aplicaciones en inglés y luego aplica parches de idioma.. cuando va a programar en un lenguaje pseudo-inglés...
Algunas cosas inevitablemente deben ser en español (He conocido sitios donde por política, el nombre de tus métodos debe ser en inglés, y en otros sitios, en español -aunque sin acentos y sin ñ- o en portugués). Usualmente, una de ellas es la documentación / Comentarios de código. Sin embargo pues.... colocarlos en inglés tampoco está mal (sobre todo si se trabaja en equipos con varias locaciones internacionales). Y verdaderamente tiene su ventajas trabajar en inglés, sobre todo el hecho de no tener que descargar paquetes adicionales de idioma (uno para Office, otro para Sistema Operativo, otro para el Framework).. y empiezas a acumular megas y megas de "paquetes" para simplemente poder leer "Archivo" en vez de "file"...
Tiene sentido esto?
lunes, 24 de agosto de 2009
Sobre la ética profesional
YO siempre he tratado de ser comprensivo con las personas, sus motivaciones y su forma de hacer las cosas. Espero no haber juzgado a nadie, ni haberle ofendido durante mis cortos 28 años de vida. Sin embargo, hay varias cosas que he observado, que me han afectado directamente y que me gustaría compartir.. y están relacionadas con ese sitio donde pasamos 9 hrs al día (incluyendo el almuerzo) de lunes a viernes...
Recientemente cambié de empleo. Nada fuera de lo corriente en esto. Las motivaciones de siempre. Al salir de la que fue mi empresa durante dos años, me tocó entregar el portátil que tenía asignado. 1 hr antes de entregarlo, procuré eliminar mis archivos personales, dejar todos los archivos y código fuente en repositorio compartido, verificar (de forma doble) que no tuviese archivos "sueltos", que todos los Login/passwords estuviesen en una hoja al momento de entregar todo, para que mi reemplazo o el que sea, pueda acceder de forma "libre" e "inmediata" a lo que fueron mis cosas. Reconozco que durante 2 años he instalado ciertos programas que aunque no estaban en la lista, me ayudaban a desempeñar mis funciones: Firefox, programas para comparar versiones y un laargo etc.
Sin embargo, en el nuevo empleo me he conseguido con un portátil, fuera de lo "estándar". Perteneció a otra persona, y como "logicamente" hubiese hecho, eliminó muchos programas que en principio no debieron estar ahi: clientes P2P (como Ares y eMule), MP3 y videos. Aun así, empleé un par de días en limpiar la compu de reproductores multimedias (VLC, QuickTime, VideoRa etc), Programas de transferencia de datos con Celulares/Moviles.
Entiendo que muchas personas guarden con gran recelo el "secreto profesional". Tal vez porque no soy 100% Microsoft y mas bien soy un anarquista, nunca me ha gustado llevarme el código fuente conmigo. Aquí hay un punto interesante: los pro-Software libre dicen "el código es de todos, distribúyelo", mientras que los de Software privativo.. no. Sin embargo, como programador del lado "privativo" entiendo que el código no es de mi propiedad, sino que es propiedad del cliente o de la empresa para la que trabajo. Y como tal, debo dejar constancia de ello (notificar al jefe o al "heredero" la ubicación de los fuentes, etc). Inclusive, siempre he sido un fanático de dejar todo comentado, estructurado, con explicaciones cuando el código es medio confuso. Pero.. que carajo, eso es lo que YO hago, porque a lo largo de 7 años de trabajo, he tenido buenos compañeros y maestros que me han dejado esas enseñanzas... pero creo que a no todos nos enseñan igual....
Recientemente cambié de empleo. Nada fuera de lo corriente en esto. Las motivaciones de siempre. Al salir de la que fue mi empresa durante dos años, me tocó entregar el portátil que tenía asignado. 1 hr antes de entregarlo, procuré eliminar mis archivos personales, dejar todos los archivos y código fuente en repositorio compartido, verificar (de forma doble) que no tuviese archivos "sueltos", que todos los Login/passwords estuviesen en una hoja al momento de entregar todo, para que mi reemplazo o el que sea, pueda acceder de forma "libre" e "inmediata" a lo que fueron mis cosas. Reconozco que durante 2 años he instalado ciertos programas que aunque no estaban en la lista, me ayudaban a desempeñar mis funciones: Firefox, programas para comparar versiones y un laargo etc.
Sin embargo, en el nuevo empleo me he conseguido con un portátil, fuera de lo "estándar". Perteneció a otra persona, y como "logicamente" hubiese hecho, eliminó muchos programas que en principio no debieron estar ahi: clientes P2P (como Ares y eMule), MP3 y videos. Aun así, empleé un par de días en limpiar la compu de reproductores multimedias (VLC, QuickTime, VideoRa etc), Programas de transferencia de datos con Celulares/Moviles.
Entiendo que muchas personas guarden con gran recelo el "secreto profesional". Tal vez porque no soy 100% Microsoft y mas bien soy un anarquista, nunca me ha gustado llevarme el código fuente conmigo. Aquí hay un punto interesante: los pro-Software libre dicen "el código es de todos, distribúyelo", mientras que los de Software privativo.. no. Sin embargo, como programador del lado "privativo" entiendo que el código no es de mi propiedad, sino que es propiedad del cliente o de la empresa para la que trabajo. Y como tal, debo dejar constancia de ello (notificar al jefe o al "heredero" la ubicación de los fuentes, etc). Inclusive, siempre he sido un fanático de dejar todo comentado, estructurado, con explicaciones cuando el código es medio confuso. Pero.. que carajo, eso es lo que YO hago, porque a lo largo de 7 años de trabajo, he tenido buenos compañeros y maestros que me han dejado esas enseñanzas... pero creo que a no todos nos enseñan igual....
jueves, 20 de noviembre de 2008
Comentarios y algo mas
Uff. Tenia tiempo sin escribir. Bueno, espero poder retormarlo. Unas cuantas cosas han cambiado desde la ultima vez que lo hice. He cambiado las actividades que venia realizando (de soporte a una aplicacion desarrollando en VStudio 2005 con C# a soporte de Project Server y Portfolio server en general).
Un par de cosas que he visto recientemente, cuando me ha tocado dar el soporte a este par de herramientas, es la forma como algunas personas echan codigo. NO digo que todos lo hagamos igual... Echar codigo depende un poco de tu cultura, tu experiencia y muchas cosas mas. Pero he visto cosas interesantes, que espero poder colocar.
Una de ellas por ejemplo, es cuando desarrollan una aplicacion con un pedazo de codigo que nadie entiende... y nadie coloca ni un comentario ni nada por el estilo. Algo sencillo que diga:
/*
Desarrollado por: Daniel
Fecha: 20-Nov-208
Descripcion: Esta funcion recibe como entrada el identificador de persona, y se encarga de actualizar la edad que lleva hasta la fecha. Esto lo hace obteniendo la fecha de nacimiento de la persona, obtiene la fecha de hoy. Convierte estos valores a Milisegundos, los resta.. y la diferencia, la convierto luego a dias.
*/
Es increible la cantidad de veces que algo asi de sencillo puede facilitar la vida de un desarrollador/analista...
Un par de cosas que he visto recientemente, cuando me ha tocado dar el soporte a este par de herramientas, es la forma como algunas personas echan codigo. NO digo que todos lo hagamos igual... Echar codigo depende un poco de tu cultura, tu experiencia y muchas cosas mas. Pero he visto cosas interesantes, que espero poder colocar.
Una de ellas por ejemplo, es cuando desarrollan una aplicacion con un pedazo de codigo que nadie entiende... y nadie coloca ni un comentario ni nada por el estilo. Algo sencillo que diga:
/*
Desarrollado por: Daniel
Fecha: 20-Nov-208
Descripcion: Esta funcion recibe como entrada el identificador de persona, y se encarga de actualizar la edad que lleva hasta la fecha. Esto lo hace obteniendo la fecha de nacimiento de la persona, obtiene la fecha de hoy. Convierte estos valores a Milisegundos, los resta.. y la diferencia, la convierto luego a dias.
*/
Es increible la cantidad de veces que algo asi de sencillo puede facilitar la vida de un desarrollador/analista...
miércoles, 11 de junio de 2008
Salud laboral
En estos dias recibi un mail del Joex, con algo simpatico:
http://www.codinghorror.com/blog/archives/001115.html
Este caballero que escribe (algo polémico en sus comentarios) dice (a muy resumidas cuentas) dos cosas interesantes:
a) todo el que toca un monitor, es un cerdo
b) los componentes de trabajo (teclados, ratón, teléfono) pueden acumular una cantidad de asquerosidades enormes.
Como consultor, he tenido que ir a varios clientes, y no suelo mantener un puesto (o equipo/ordenador/computador) por mas de 1 año. Algunas de las cosas mas fantásticas que he visto:
http://www.codinghorror.com/blog/archives/001115.html
Este caballero que escribe (algo polémico en sus comentarios) dice (a muy resumidas cuentas) dos cosas interesantes:
a) todo el que toca un monitor, es un cerdo
b) los componentes de trabajo (teclados, ratón, teléfono) pueden acumular una cantidad de asquerosidades enormes.
Como consultor, he tenido que ir a varios clientes, y no suelo mantener un puesto (o equipo/ordenador/computador) por mas de 1 año. Algunas de las cosas mas fantásticas que he visto:
- Hoy en día son comunes los ratones ópticos. Sin embargo, no hace mucho eran "de bolita". Cuantas veces hubo que abrirlos para eliminar el sucio que se acumulaba en los rodillos sensores? en ocasiones había que insistirle con algún objeto afilado (destornilladores, llaves, etc) porque la mugre pegada, podía servir como cemento para una construcción anti huracanes.
- Particularmente tengo la manía de tomar el teclado y darle unos toques suaves, esto con el fin de hacer que salgan del mismo algunas impurezas que se quedan entre las teclas: cabellos, sucio, migas de comida. He llegado a conseguirme cosas horribles: creo que eran pedazos de uñas, de piel y de mocos....
- He visto y conocido personas que cuando hablan, tienen complejo de aspersor: llenan todo a su alrededor de saliva. He aprendido a evitarles, colocándome a un lado de ellos, de forma que cuando hablen, mi cara no sea un obstáculo para sus "salibasos". Sin embargo, hay algo horrible: cuando llenan tu monitor de su saliva y empiezas a ver los pequeños pixelados multicolores. Y algo mas horrible: cuando usan tu teléfono. Es que solo de pensar que luego yo pondré mi boca cerca de un sitio previamente ensalibado, me da algo....
- Muchas veces no estamos de acuerdo con nuestros trabajos. Y tratamos de hacerlos mas "agradables" personalizándolo y colocando objetos con los que nos identificamos. Pero todo tiene un límite. Me refiero a esas personas que colocan fotos de sus prim@s, herman@s, ti@s, lugares en los que estuvieron, novi@s, mascotas y un laaargo etc. Unas veces, las fotos estan puestas unas encimas de otras, que la foto original.. ni aparece.
- Continuando el punto anterior, recuerdo personas que para personalizar sus escritorios, colocaban cualquier cantidad de: peluches, llaveros, tazas de café (mugs), Al final, el espacio disponible dentro de su escritorio es mínimo, por lo que invadían los computadores: stickers (pegatinas, calcomanías o como quieran llamarle) adornando los monitores.
- El punto mas difícil de todos: los que llevamos la comida a la oficina en pequeños empaques plásticos (tupperware). He visto personas maniáticas que apenas terminan de comer, lavan sus envases, los secan con el papel de los baños y lo guardan íntegro. Pero he visto personas que dejan parte de la comida dentro del envase. Esto es algo personal, y que no afecta a mas nadie, salvo cuando esa persona deja dicho envase en la oficina, a la vista de los compañeros. Señores: la comida es orgánica, se descompone. He visto envases que han tenido hongos (blancos, verdes, negros, etc) porque su dueño los olvida dos, tres y hasta cinco días en la oficina
domingo, 30 de marzo de 2008
Puntos importantes sobre Conversión Monetaria
Después de conversión monetaria, me han quedado algunas cosas de aprendizaje. Son cosas que, desde mi punto de vista, aplican para todos los proyectos como consejos generales. Son
- Pruebas con los usuarios. Es probablemente uno de los más grandes pilares de un proyecto grande: El proceso de prueba con los usuarios. Debe ponerse especial cuidado en que el usuario certifique que sus aplicaciones sigan funcionando de la misma forma: Las pantallas se le deben presentar a los usuarios con una distribución lo más similar posible a la que se tenía antes de los cambios. De esta forma todas las Entradas/Salidas (input/output) deben permanecer de la forma más amigable posible para los usuarios.
- Interfaces. Hay que tener cuidado con los sistemas Legacy y las interfaces. Probablemente, junto con las pruebas de usuarios, son uno de los puntos más críticos de cualquier proceso de cambio grande. Debe asegurarse un proceso de pruebas lo suficientemente amplio, como para que todas las posibles entradas en un sistema se transfieran a otra: campos en numero, letras, boléanos. También hay que tener en cuenta que. Cualquier proceso que se lleva a cabo en uno de los sistemas que implique información de otro, debe ponerse a prueba.
- La conversión de la BD: inventario de campos. Hacer un inventario de los campos que se están convirtiendo, indicando el tipo: varchar, int, decimal, etc. Debe tenerse en cuenta la forma como se utilizan estos campos, y si son usados en procesos de interfaces.
- Dejar una documentación: aprovechar hacerla a partir de la revisión que se hizo. Esto es un punto importante, siempre y cuando no implique un mayor esfuerzo y dedicación del personal.
- Contrario a lo que muchas personas pensarían, soy partidario de que si algo funciona bien, déjalo bien. YO probablemente no soy muy incondicional de esto, puesto que trato siempre de arreglar el código ajeno cuando me toca editarlo. Sin embargo, en proyectos de recursos limitados con énfasis en tiempos y resultados, si algo funciona bien y no precisa cambios, es mejor dejarlos fuera del impacto. Esto aplica también a una tendencia marcada en algunas empresas, donde a raíz de cambios grandes, deciden implementar “algunas mejoras” que por lo general, lejos de ayudar al proyecto, complican las estimaciones.
Esto es todo por ahora. Trataré de colocar algunas cosas adicionales a medida que las recuerde
- Pruebas con los usuarios. Es probablemente uno de los más grandes pilares de un proyecto grande: El proceso de prueba con los usuarios. Debe ponerse especial cuidado en que el usuario certifique que sus aplicaciones sigan funcionando de la misma forma: Las pantallas se le deben presentar a los usuarios con una distribución lo más similar posible a la que se tenía antes de los cambios. De esta forma todas las Entradas/Salidas (input/output) deben permanecer de la forma más amigable posible para los usuarios.
- Interfaces. Hay que tener cuidado con los sistemas Legacy y las interfaces. Probablemente, junto con las pruebas de usuarios, son uno de los puntos más críticos de cualquier proceso de cambio grande. Debe asegurarse un proceso de pruebas lo suficientemente amplio, como para que todas las posibles entradas en un sistema se transfieran a otra: campos en numero, letras, boléanos. También hay que tener en cuenta que. Cualquier proceso que se lleva a cabo en uno de los sistemas que implique información de otro, debe ponerse a prueba.
- La conversión de la BD: inventario de campos. Hacer un inventario de los campos que se están convirtiendo, indicando el tipo: varchar, int, decimal, etc. Debe tenerse en cuenta la forma como se utilizan estos campos, y si son usados en procesos de interfaces.
- Dejar una documentación: aprovechar hacerla a partir de la revisión que se hizo. Esto es un punto importante, siempre y cuando no implique un mayor esfuerzo y dedicación del personal.
- Contrario a lo que muchas personas pensarían, soy partidario de que si algo funciona bien, déjalo bien. YO probablemente no soy muy incondicional de esto, puesto que trato siempre de arreglar el código ajeno cuando me toca editarlo. Sin embargo, en proyectos de recursos limitados con énfasis en tiempos y resultados, si algo funciona bien y no precisa cambios, es mejor dejarlos fuera del impacto. Esto aplica también a una tendencia marcada en algunas empresas, donde a raíz de cambios grandes, deciden implementar “algunas mejoras” que por lo general, lejos de ayudar al proyecto, complican las estimaciones.
Esto es todo por ahora. Trataré de colocar algunas cosas adicionales a medida que las recuerde
Suscribirse a:
Entradas (Atom)