الأربعاء، 28 ديسمبر 2011
CodeCamp - Introducción a Windows Phone
Andrés Felipe González uno de los asistentes al CodeCamp 2011 grabó la sesión introductoria al Track de Windows Phone, les comparto el audio esperando les resulte de utilidad. Además les recuerdo que el material y presentación del Hands on Lab están publicados en Avanet.
الاثنين، 19 ديسمبر 2011
Get Certified To Get More in Life...
Since certifications came into recognition, there have been some who have debated whether certifications are worth pursuing or not.
Statistics have proved time and again that certs lead to promotions and raises. A survey of 700 networking professionals in Networkworld.com tells what we already know – 60% of professionals said that their certifications led to a new job, 56% said they got raise, and about 29% said they got a promotion with their company.
الثلاثاء، 13 ديسمبر 2011
De metodologías, amistad y contratos de software
Bien, quien lo diría que hoy encontraría inspiración para escribir este tema que tanto tiempo lleva guardado en mi cabeza, y es que como ustedes saben, a mi me gusta hablar de ingeniería de software, experiencias y de todas esas situaciones "humanas" alrededor del tema y que finalmente terminan por impactar la calidad el software.
Yo diría que hoy quiero hablar de otro de esos temas éticos (no juzgables) que ocurren en esto de hacer software, y bueno ni soy experta ni es un tema que atañe solo a la industria de software, solo tengo el sentimiento a flor de piel para hablar de sus consecuencias.
Voy a contar a modo de historia, cada uno de los recuerdos que tengo en mi memoria, ...
Había una vez... nah, no sé ni que decir, veamos...
Otra vez estábamos ahí, frente a un bug de esos que lo dejan a uno pensando como demonios pasó,
¿Cómo pudo llegar algo así a producción? Después de horas de buscar la el problema, la razón fue un error de un desarrollador, una decisión de esas típicas que se tomaban, por darles un ejemplo, tan simple como dar una longitud fija a un vector, cosa que finalmente limitaría el proceso de negocio.
¿Quien le dijo que lo hiciera? ¿Donde está escrito?... la defensa, nadie, tampoco nadie dijo que "no podía hacerlo"... se dio una gran discusión, en el barrullo se escuchaban frases como: ¡Siempre es lo mismo!, ¿Por que no llamamos otro proveedor? ¡No podemos seguir así!, yo guardaba silencio en realidad en ese momento no tenia mucho que opinar.
Después de bastante tiempo perdido la conclusión fue, que nosotros teníamos la culpa, aunque no entendía bien por qué teníamos la culpa de que un programador tuviese malas practicas y asumiera cosas que no se le habían dicho, pero la conclusión era que nosotros teníamos que corregir la forma en que hacíamos las solicitudes para proteger a los desarrolladores de sus "errores conocidos".
El jefe dijo: ustedes ya saben como son, ya saben que cosas siempre hacen mal, entonces, escriban las cosas que no deberían hacer, para que esto no vuelva a suceder, "nosotros somos los responsables del negocio". El ambiente se notaba sombrío y en desacuerdo pero la reunión finalizó. Al salir alguien me susurró:
- Esto nunca va a cambiar, son amigos.
- ¿Amigos? ¿Quienes? - pregunté
- Los proveedores son amigos del jefe
Ese día fue la primera vez que entendí todo, entendí mil razones acerca de por qué no sucedía nada, cada repetida vez que algo mal salía y era culpa de una mala práctica por parte de algún proveedor, así que vamos al post.
El mundo de las influencias en un planeta árido, no comprensible en todas las ocasiones, a hoy yo no sé si por amistad uno termina negociando su ética o simplemente haciéndose el de la vista gorda.
Solo es un punto para concluir una vez más como hacer software es menos mágico y más humano, desde no ser capaz de solicitar calidad por lo que pagas por que a ti mismo te parece poco, sacrificar la arquitectura de un proyecto por años solo por dejarlo en manos de uno de tus amigos, hasta poner en peligro un escenario de negocio, son cosas de las que no se tiene conciencia hasta que no genera un problema real y que es observado por gente externa. Eso de pagar poco me resulta todo un dolor de cabeza, de modo que si un proveedor acepta un contrato en que la tarifa es baja, yo debo aceptar que haga un mal trabajo? Por Dios! Y en premio que hacemos? Les pagamos más? Será que así se van a corregir los vicios de fondo de sus programadores?
La calidad de software tiene un matiz más que no está en estándares ni libros, y tiene que ver con quien es el que elige cuales personas estarán a cargo de tus proyectos, cómo después de extensos procesos de selección solo quedan quien alguien quiere que quede en un lugar.
Que ser amigo de alguien no significa hacerlo mal, es cierto, como tampoco lo es que por elegir un amigo para realizar un trabajo se tenga que disminuir la exigencia sobre los productos y procesos realizados, y no hacer ni el intento de encontrar otras opciones.
¿A que costo se cede la salud de un negocio solo por ofrecer un contrato de software al proveedor equivocado?
Este post suena muy sentido pero no es más que un vago recuerdo, lástima verlo repetidamente en tantas personas e instituciones.
Yo diría que hoy quiero hablar de otro de esos temas éticos (no juzgables) que ocurren en esto de hacer software, y bueno ni soy experta ni es un tema que atañe solo a la industria de software, solo tengo el sentimiento a flor de piel para hablar de sus consecuencias.
Voy a contar a modo de historia, cada uno de los recuerdos que tengo en mi memoria, ...
Había una vez... nah, no sé ni que decir, veamos...
Otra vez estábamos ahí, frente a un bug de esos que lo dejan a uno pensando como demonios pasó,
¿Cómo pudo llegar algo así a producción? Después de horas de buscar la el problema, la razón fue un error de un desarrollador, una decisión de esas típicas que se tomaban, por darles un ejemplo, tan simple como dar una longitud fija a un vector, cosa que finalmente limitaría el proceso de negocio.
¿Quien le dijo que lo hiciera? ¿Donde está escrito?... la defensa, nadie, tampoco nadie dijo que "no podía hacerlo"... se dio una gran discusión, en el barrullo se escuchaban frases como: ¡Siempre es lo mismo!, ¿Por que no llamamos otro proveedor? ¡No podemos seguir así!, yo guardaba silencio en realidad en ese momento no tenia mucho que opinar.
Después de bastante tiempo perdido la conclusión fue, que nosotros teníamos la culpa, aunque no entendía bien por qué teníamos la culpa de que un programador tuviese malas practicas y asumiera cosas que no se le habían dicho, pero la conclusión era que nosotros teníamos que corregir la forma en que hacíamos las solicitudes para proteger a los desarrolladores de sus "errores conocidos".
El jefe dijo: ustedes ya saben como son, ya saben que cosas siempre hacen mal, entonces, escriban las cosas que no deberían hacer, para que esto no vuelva a suceder, "nosotros somos los responsables del negocio". El ambiente se notaba sombrío y en desacuerdo pero la reunión finalizó. Al salir alguien me susurró:
- Esto nunca va a cambiar, son amigos.
- ¿Amigos? ¿Quienes? - pregunté
- Los proveedores son amigos del jefe
Ese día fue la primera vez que entendí todo, entendí mil razones acerca de por qué no sucedía nada, cada repetida vez que algo mal salía y era culpa de una mala práctica por parte de algún proveedor, así que vamos al post.
El mundo de las influencias en un planeta árido, no comprensible en todas las ocasiones, a hoy yo no sé si por amistad uno termina negociando su ética o simplemente haciéndose el de la vista gorda.
Solo es un punto para concluir una vez más como hacer software es menos mágico y más humano, desde no ser capaz de solicitar calidad por lo que pagas por que a ti mismo te parece poco, sacrificar la arquitectura de un proyecto por años solo por dejarlo en manos de uno de tus amigos, hasta poner en peligro un escenario de negocio, son cosas de las que no se tiene conciencia hasta que no genera un problema real y que es observado por gente externa. Eso de pagar poco me resulta todo un dolor de cabeza, de modo que si un proveedor acepta un contrato en que la tarifa es baja, yo debo aceptar que haga un mal trabajo? Por Dios! Y en premio que hacemos? Les pagamos más? Será que así se van a corregir los vicios de fondo de sus programadores?
La calidad de software tiene un matiz más que no está en estándares ni libros, y tiene que ver con quien es el que elige cuales personas estarán a cargo de tus proyectos, cómo después de extensos procesos de selección solo quedan quien alguien quiere que quede en un lugar.
Que ser amigo de alguien no significa hacerlo mal, es cierto, como tampoco lo es que por elegir un amigo para realizar un trabajo se tenga que disminuir la exigencia sobre los productos y procesos realizados, y no hacer ni el intento de encontrar otras opciones.
¿A que costo se cede la salud de un negocio solo por ofrecer un contrato de software al proveedor equivocado?
Este post suena muy sentido pero no es más que un vago recuerdo, lástima verlo repetidamente en tantas personas e instituciones.
الأحد، 4 ديسمبر 2011
Los usuarios y la gobernabilidad de IT
Una vez más escribo del día de día, nada es una mejor inspiración aunque en términos prácticos uno preferiría que su vida no fuera el ejemplo de todas esas cosas que no deberían pasar.
Este concepto a pesar de lo "obvio" no es manejado por muchas personas, por eso les dejo aquí una pequeña definición: El término "gobernabilidad " define la capacidad de una organización para controlar y regular su propio funcionamiento con el fin de evitar los conflictos de intereses relacionados con la división entre los beneficiarios y los actores.
“Gobernabilidad” es un término genérico que se puede utilizar de diversas formas acuerdo al contexto.
La expresión “Gobernabilidad” política se utiliza en casos de interacción entre el Estado (gobierno) y la Sociedad (ciudadanos y empresas privadas). Cuando se trata de una compañía o de un grupo industrial, hablamos de "gobernabilidad corporativa"
* Tomado de: http://es.kioskea.net/contents/systeme-d-information/it-gouvernance-si.php3
Tengo que confesarles que cuándo escuché el término la primera vez, y eso de que todos los jefes de la compañia se reunian en el comité de Gobernabilidad, me pareció exagerado ¿Un comité de gobernabilidad de IT? ¿Por qué? La razón es simple, al existir muchos proyectos y recursos que administrar, es necesario darle orden, en especial por que las peticiones al área de IT son un caudal constante y creciente en las organizaciones y los recursos (tiempo, dinero y personas) somos limitados.
Hay que decir que muchos usuarios son pacientes o les toca serlo, yo tengo un proyecto actualmente con más de 200 días de espera por ser iniciado y a mi usuario no le toca más que sonreir cada vez conmigo y lanzarnos bromas al respecto de que quizá ni las predicciones Mayas de 2012 nos dejen terminarlo. Antes de continuar con la razón de contarles mis aventuras en este post, tengo que mencionar que igual la gobernabilidad deberia darse en cual escenario asi los recursos y proyectos no fueran muchos.
Un comité de gobernabilidad se encarga de definir las prioridades que debe atender IT, esto aunque a veces es frustrante para los que nos dedicamos a hacer, tiene mucho sentido, ya que por política o necesidad, son las personas que dirigen la organización las que llevan el rumbo del negocio y cuándo no hay forma de atender todo el tiempo, no es IT la que pone el rostro para decir que no tenia como hacerlo, si no que los usuarios debían definir que debía atenderse, y eso cambia sustancialmente la respuesta cuándo el momento de los reclamos llega, ya que en dicho comité tienen en cuenta además las metas anuales, las personas disponibles y el dinero disponible, en el caso del lugar donde trabajo, con respecto al dinero disponible hay una expectativa que llenar que siempre me ha parecido curiosa y que he visto en otros lugares, y es, que el presupuesto destinado para un año debe gastarse, no debe sobrepasarse ni debe ahorrarse, todo debe invertirse, y es una métrica muy importante para todos, en esa vía planear mensualmente al comité de gobierno las necesidades de inversión y los proyectos pendientes, es más un "estrategia" que una simple lista que ordenar, los usuarios velan por sacar adelante sus proyectos más apremiantes a veces también sus caprichos, pero el equilibrio se establece cuando además está IT y los altos directivos, IT luchará por innovar, actualizar y mantener sus actuales sistemas, y la alta dirección decidirá que de todos esos puntos de vista es lo que se debe hacer.
El título de este post hace alusión a los usuarios, la razón fue algo que viví con un proyecto hace poco, el proyecto llegó, era muy pequeño sin embargo de impacto en la imagen de la compañía, pero técnicamente era algo "simple" de resolver a los ojos de usuario. Al listar las necesidades funcionales, la teoría de los usuarios se confirmaba, era simple, el problema tenia que ver con "quien iba a construirlo" y "que tecnologías usarían" para que dicho proyecto apalancara la estrategia general de la compañía. Me disculparán si hablo como en clave, es evidente que no puedo hablar del proyecto abiertamente.
Ahora bien, al llegar la solicitud a mi, contemple la posibilidad incluso de hacerlo yo misma, los usuarios trajeron su proveedor sugerido, un absoluto desastre por cierto, estos sabían más de anatomía de pollos, pero estaban dispuestos hasta a trabajar gratis con tal de ser proveedores de la compañía, nada habla más mal de un proveedor así. Por otro lado decidimos ver varios proveedores y entre ellos nos encontramos uno, que además de dar una rápida solución al proyecto, garantizaba el futuro de la organización estableciendo una estrategia para el tema, ya que lejos de proveer una solucíón particular, tenía una plataforma genérica para afrontar ese y otros muchos problemas. Un momento, si nos ponemos en contexto, el tamaño del proyecto, el tiempo y el dinero disponible, ese podría ser el proveedor soñado pero, no el proveedor para un proyecto de ese tamaño, ya que el costo se multiplicaría por 100, créanme por 100 si no es más. Así se intentaron ver varios proveedores, algunos simplemente escucharon la necesidad y sus propuestas jamás llegaron, no tengo idea si el problema estuvo en el tamaño del proyecto, pero en 1 mes no alcanzamos a encontrar un proveedor con una propuesta coherente tecnológicamente hablando que a su vez lo fuera en costos.
De repente el proyecto cayo en el olvido, a mi me asignaron otras prioridades al no encontrar el proveedor y no volví a saber del tema, luego de unas semanas revisando la prensa interna vi el anuncio del proyecto ya en producción, me pude quedar de una sola pieza lo único que podía pensar es que habían aceptado la propuesta de aquel proveedor incoherente (nada espero más que no lo hayan hecho) sin embargo, el tema me quedó muchos días en la cabeza hasta terminar aquí escribiendo, una queja más de las que abundan en la red por parte de ingenieros de sistemas contra los usuarios.
Analizando lo sucedido desde el punto de vista de gobernabilidad, lo que hacen los usuarios es dejar de afectar el presupuesto de IT que parece tan luchado y simplemente, poner de su propio presupuesto, contratar a quien mejor les parece que les prometa que lo que quieren sale rápido y ya, para un usuario ese parece ser el fin de su vida, cumplir sus caprichos a como dé lugar, el futuro es típico y repetitivo, la mala selección de un proveedor, el hecho de que la área de negocio que contrata el proveedor, no sepa como manejar contratos de software o que debe exigir metodologías y artefactos para el software que se crea, empieza a crear un nuevo sistema fantasma, con el tiempo el proveedor es tan malo que lo único que ocurre es que ellos terminan por darse cuenta de su error y despedirlo, y el proyecto jamás llego a ningún lugar. ¡Momento! ¿Ningún lugar? Ese ningún lugar es el área de IT donde se le tendrá que dar soporte a un proyecto abandonado, sin documentación y con seguro las peores prácticas de programación jamás vistas, por que como los usuarios se la creen que el software es un producto de masa empaquetado que tiene una receta de ingredientes, entre ellos magia, jamás se percataron de si estaba bien hecho o no.
Mi pregunta hoy ya no va como siempre contra la responsabilidad de los ingenieros de sistemas y el si conocen o no buenas practicas de software, hoy arremeto contra los usuarios, contra aquellos que como nosotros deberían alinearse y evolucionar y dejar de creer que el software es una mezcla de deseos y magia que naturalmente produce los efectos que se desean y que así como en sus diferentes campos de acción hay procesos que respetar, también los hay en el área de IT.
Solo queda arremeter contra alguien más contra los empíricos proveedores que hacen este tipo de cosas, que eticamente saben son incorrectas pero que les importa un bledo y que evidentemente solo les importa ganarse un contrato y no atender coherentemente las necesidades de los usuarios y negocios a los que se presentan, sin siquiera detenerse profesionalmente a pensar en el tema de hacer bien su trabajo.
En fin, aquí no hay moraleja, este caso es del día a día en muchas organizaciones, comprensible es que los protocolos restan oportunidades al negocio, a las que se debe reaccionar con tecnología, pero quizá la salida no es actuar a punta de caprichos su no crear áreas de reacción inmediata para este tipo de proyectos y no solo áreas consumidas por el soporte a los sistemas de producción y que nunca tenemos el tiempo para apalancar al negocio en los nuevos escenarios tecnológicos.
Espero sus comentarios, hasta la próxima.
Sorey ;)
Imagen tomada de: http://reporteciencianl.com/2011/06/retos-de-la-gobernabilidad/
“Gobernabilidad” es un término genérico que se puede utilizar de diversas formas acuerdo al contexto.
La expresión “Gobernabilidad” política se utiliza en casos de interacción entre el Estado (gobierno) y la Sociedad (ciudadanos y empresas privadas). Cuando se trata de una compañía o de un grupo industrial, hablamos de "gobernabilidad corporativa"
* Tomado de: http://es.kioskea.net/contents/systeme-d-information/it-gouvernance-si.php3
Tengo que confesarles que cuándo escuché el término la primera vez, y eso de que todos los jefes de la compañia se reunian en el comité de Gobernabilidad, me pareció exagerado ¿Un comité de gobernabilidad de IT? ¿Por qué? La razón es simple, al existir muchos proyectos y recursos que administrar, es necesario darle orden, en especial por que las peticiones al área de IT son un caudal constante y creciente en las organizaciones y los recursos (tiempo, dinero y personas) somos limitados.
Hay que decir que muchos usuarios son pacientes o les toca serlo, yo tengo un proyecto actualmente con más de 200 días de espera por ser iniciado y a mi usuario no le toca más que sonreir cada vez conmigo y lanzarnos bromas al respecto de que quizá ni las predicciones Mayas de 2012 nos dejen terminarlo. Antes de continuar con la razón de contarles mis aventuras en este post, tengo que mencionar que igual la gobernabilidad deberia darse en cual escenario asi los recursos y proyectos no fueran muchos.
Un comité de gobernabilidad se encarga de definir las prioridades que debe atender IT, esto aunque a veces es frustrante para los que nos dedicamos a hacer, tiene mucho sentido, ya que por política o necesidad, son las personas que dirigen la organización las que llevan el rumbo del negocio y cuándo no hay forma de atender todo el tiempo, no es IT la que pone el rostro para decir que no tenia como hacerlo, si no que los usuarios debían definir que debía atenderse, y eso cambia sustancialmente la respuesta cuándo el momento de los reclamos llega, ya que en dicho comité tienen en cuenta además las metas anuales, las personas disponibles y el dinero disponible, en el caso del lugar donde trabajo, con respecto al dinero disponible hay una expectativa que llenar que siempre me ha parecido curiosa y que he visto en otros lugares, y es, que el presupuesto destinado para un año debe gastarse, no debe sobrepasarse ni debe ahorrarse, todo debe invertirse, y es una métrica muy importante para todos, en esa vía planear mensualmente al comité de gobierno las necesidades de inversión y los proyectos pendientes, es más un "estrategia" que una simple lista que ordenar, los usuarios velan por sacar adelante sus proyectos más apremiantes a veces también sus caprichos, pero el equilibrio se establece cuando además está IT y los altos directivos, IT luchará por innovar, actualizar y mantener sus actuales sistemas, y la alta dirección decidirá que de todos esos puntos de vista es lo que se debe hacer.
El título de este post hace alusión a los usuarios, la razón fue algo que viví con un proyecto hace poco, el proyecto llegó, era muy pequeño sin embargo de impacto en la imagen de la compañía, pero técnicamente era algo "simple" de resolver a los ojos de usuario. Al listar las necesidades funcionales, la teoría de los usuarios se confirmaba, era simple, el problema tenia que ver con "quien iba a construirlo" y "que tecnologías usarían" para que dicho proyecto apalancara la estrategia general de la compañía. Me disculparán si hablo como en clave, es evidente que no puedo hablar del proyecto abiertamente.
Ahora bien, al llegar la solicitud a mi, contemple la posibilidad incluso de hacerlo yo misma, los usuarios trajeron su proveedor sugerido, un absoluto desastre por cierto, estos sabían más de anatomía de pollos, pero estaban dispuestos hasta a trabajar gratis con tal de ser proveedores de la compañía, nada habla más mal de un proveedor así. Por otro lado decidimos ver varios proveedores y entre ellos nos encontramos uno, que además de dar una rápida solución al proyecto, garantizaba el futuro de la organización estableciendo una estrategia para el tema, ya que lejos de proveer una solucíón particular, tenía una plataforma genérica para afrontar ese y otros muchos problemas. Un momento, si nos ponemos en contexto, el tamaño del proyecto, el tiempo y el dinero disponible, ese podría ser el proveedor soñado pero, no el proveedor para un proyecto de ese tamaño, ya que el costo se multiplicaría por 100, créanme por 100 si no es más. Así se intentaron ver varios proveedores, algunos simplemente escucharon la necesidad y sus propuestas jamás llegaron, no tengo idea si el problema estuvo en el tamaño del proyecto, pero en 1 mes no alcanzamos a encontrar un proveedor con una propuesta coherente tecnológicamente hablando que a su vez lo fuera en costos.
De repente el proyecto cayo en el olvido, a mi me asignaron otras prioridades al no encontrar el proveedor y no volví a saber del tema, luego de unas semanas revisando la prensa interna vi el anuncio del proyecto ya en producción, me pude quedar de una sola pieza lo único que podía pensar es que habían aceptado la propuesta de aquel proveedor incoherente (nada espero más que no lo hayan hecho) sin embargo, el tema me quedó muchos días en la cabeza hasta terminar aquí escribiendo, una queja más de las que abundan en la red por parte de ingenieros de sistemas contra los usuarios.
Analizando lo sucedido desde el punto de vista de gobernabilidad, lo que hacen los usuarios es dejar de afectar el presupuesto de IT que parece tan luchado y simplemente, poner de su propio presupuesto, contratar a quien mejor les parece que les prometa que lo que quieren sale rápido y ya, para un usuario ese parece ser el fin de su vida, cumplir sus caprichos a como dé lugar, el futuro es típico y repetitivo, la mala selección de un proveedor, el hecho de que la área de negocio que contrata el proveedor, no sepa como manejar contratos de software o que debe exigir metodologías y artefactos para el software que se crea, empieza a crear un nuevo sistema fantasma, con el tiempo el proveedor es tan malo que lo único que ocurre es que ellos terminan por darse cuenta de su error y despedirlo, y el proyecto jamás llego a ningún lugar. ¡Momento! ¿Ningún lugar? Ese ningún lugar es el área de IT donde se le tendrá que dar soporte a un proyecto abandonado, sin documentación y con seguro las peores prácticas de programación jamás vistas, por que como los usuarios se la creen que el software es un producto de masa empaquetado que tiene una receta de ingredientes, entre ellos magia, jamás se percataron de si estaba bien hecho o no.
Mi pregunta hoy ya no va como siempre contra la responsabilidad de los ingenieros de sistemas y el si conocen o no buenas practicas de software, hoy arremeto contra los usuarios, contra aquellos que como nosotros deberían alinearse y evolucionar y dejar de creer que el software es una mezcla de deseos y magia que naturalmente produce los efectos que se desean y que así como en sus diferentes campos de acción hay procesos que respetar, también los hay en el área de IT.
Solo queda arremeter contra alguien más contra los empíricos proveedores que hacen este tipo de cosas, que eticamente saben son incorrectas pero que les importa un bledo y que evidentemente solo les importa ganarse un contrato y no atender coherentemente las necesidades de los usuarios y negocios a los que se presentan, sin siquiera detenerse profesionalmente a pensar en el tema de hacer bien su trabajo.
En fin, aquí no hay moraleja, este caso es del día a día en muchas organizaciones, comprensible es que los protocolos restan oportunidades al negocio, a las que se debe reaccionar con tecnología, pero quizá la salida no es actuar a punta de caprichos su no crear áreas de reacción inmediata para este tipo de proyectos y no solo áreas consumidas por el soporte a los sistemas de producción y que nunca tenemos el tiempo para apalancar al negocio en los nuevos escenarios tecnológicos.
Espero sus comentarios, hasta la próxima.
Sorey ;)
Imagen tomada de: http://reporteciencianl.com/2011/06/retos-de-la-gobernabilidad/
الاشتراك في:
الرسائل (Atom)