January 2009 - Artículos
Muchos no encontrarán nada nuevo en lo que voy a decir, pero me veo con ganas de comentarlo porque aunque a veces pueden parecer cosas obvias, me encuentro por un lado mucho desconocimiento general en las empresas acerca del propio desarrollo del Software y ya de paso, tampoco está nada mal hacer un repaso general a los conceptos propios de la cadena de desarrollo del Software.
Dejando de lado a las metodologías y las arquitecturas, por debajo hay algo que es prácticamente idéntico a cualquier desarrollo del Software, ya sea en Java, en .NET, en ensamblador y en lo que se nos ocurra decir.
Ese "algo" es muy repetitivo,... como una cadena de montaje, de ahí que se me haya ocurrido titular a esta entrada como cadena de desarrollo Software.
Cuando trabajamos en proyectos Software y dentro de un equipo de trabajo, tiene un valor muy importante que la información fluya.
Tareas como comentar el código son fundamentales, un rollo sí (lo admito y levanto la mano el primero), pero una tarea obligada y necesaria para el bien común (pensad siempre que haceis una tarea en la palabra equipo ;-) ).
Pero si decimos que la información debe fluir... ¿qué pensáis que es el código fuente de un desarrollo Software?.
Pues justamente eso, información. Información que en este caso está traducida a modo de instrucciones o comandos, pero no deja de ser información. Información que hay que pulir, cuidar y preparar, como si de un documento Microsoft Word o similar se tratara a la hora de preparar una documentación o preparar una oferta.
Así que si queremos compartir esa información y trabajar de forma colaborativa entre varias personas, lo lógico es pensar en productos tipo Visual Studio SourceSafe y como no, Visual Studio Team Foundation Server y sus complementos.
Este tipo de productos nos permitirán colaborar entre los miembros de un equipo y compartir los avances del proyecto sin supuestamente, tropezar unos miembros con otros dentro de las mismas parcelas o porciones de código (sin pisarnos el trabajo sin querer).
Sin entrar en más detalles (que entradas y contenidos hay para hacerlo), el desarrollo del Software se inicia con unos documentos necesarios previos (requerimientos, diseño técnico, etc).
Con posterioridad y ya más metidos en harina, no debemos limitar las tareas tan solo a colaborar y compartir el avance del proyecto.
Por supuesto, debemos tener siempre en mente las pruebas unitarias, otras de las tareas de obligado cumplimiento (otro rollo sí, pero también tan necesario para el desarrollo Software como el respirar para vivir).
Hay o existen muchas partes muy importantes. Aquí estamos desmenuzando las principales a vista de pájaro. Los detalles son muy profundos evidentemente.
Otro de esas partes generales es que continuando con nuestro proceso o con nuestra cadena de desarrollo del Software, el repositorio de código debe generar un resultado final. A ese resultado se le denomina build.
A veces esa build se ve y se toca (interfaz de usuario).
En otras ocasiones, esa build existe pero ni se toca ni se ve de forma directa o casi física (un ensamblado o un servicio que debe ser consumido). Esta es quizás la parte más amarga del desarrollador, ya que en muchas ocasiones la gente de alrededor piensa en que estas tocándote las narices porque no se ve "nada" cuando en realidad, por debajo hay un gran monstruo.
Aún y así y continuando con la cadena de desarrollo del Software, esas partes separadas de builds, pueden ser reutilizadas en un producto para empaquetarlo como versión final de un producto.
De ahí extraemos o debemos extraer una nueva etapa en la cadea, la etapa de las pruebas funcionales.
Hemos partido del código, de sus pruebas, de sus builds, y finalmente de la creación de un producto, pero... ¿hace realmente ese producto lo que esperamos que haga de acuerdo a los requerimientos?.
Las pruebas funcionales o el cumplimiento de las tareas de acuerdo a los requerimientos deben ser cubiertas de forma completa. Es decir, que el producto final haga lo que tiene que hacer tal y como estaba pensado que lo hiciera.
Cuando todo eso ha sido superado de forma positiva, debemos poner el producto en el entorno de producción.
Evidentemente, aquí surgen muchas puntualizaciones que deben ser realizadas como por ejemplo tener entornos de prueba y entornos de producción parejos o lo más similares posibles. Aquí a veces, las máquinas virtuales juegan papeles fundamentales, aunque para algunos escenarios es más recomendable utilizar un entorno físico exacto al que va a tener producción.
Pero como todas estas palabrejas pueden parecer un poco extrañas, lo mejor es mostrar una imagen que explique claramente todo este popurrí de conceptos e ideas.
Por suerte, hoy me he encontrado en Internet una imagen que explica de forma excelente esto que os comento. Como me ha parecido tan bueno, me he animado a escribir esta entrada dejándoos para el final, la imagen que resumen esto que he querido compartir con vosotros.
Pensad siempre en dos palabras complementarias que estarían por encima de todas estas tareas... EQUIPO y PERSONAS.
Microsoft ha publicado el SDK de Oslo en su versión CTP de Enero de 2009.
Este SDK contiene información de alto interés para el desarrollador, como documentación, ejemplos, modelos Oslo escritos en "M", herramientas que nos permitirán generar nuestros propios modelos, incluyendo la herramienta de Oslo en nombre clave IntelliPad.
La descarga del SDK es en inglés, y tiene un tamaño cercano a los 12 Mb.
Los requerimientos son Microsoft .NET Framework 3.5 SP1, Microsoft Visual Studio 2008 y Microsoft Excel 2007 con el soporte de .NET Framework activado (necesario para instalar y ejecutar el complemento de "M" para Excel.
Como repositorio, se necesita tener instalado Microsoft SQL Server 2008 Express Edition o superior.
Aquí os dejo una captura de la herramienta de modelado Quadrant que mostró David Chapell en el último Tech·Ed en USA y que nos facilita las tareas de definición e interactuación con los modelos.
Respecto a SOA, aquí va una estructura típica SOA:
Finalmente, me gustaría poneros o recordaros aquí el roadmap de Oslo:
Y ahora a disfrutar.
Espero que podais disfrutar este material. :-)
Referencias:
Enlace Web: Información oficial de Microsoft Oslo.
Enlace Web: Algo de información sobre SOA (en español).
Enlace Web: Introducción a M y Quadrant (en inglés).
Enlace de descarga: Microsoft Oslo SDK - CTP Enero 2009 (Inglés - aproximadamente 12 Mb).
De vez en cuando, uno lee cosas en Internet que desconocía o que podrían hacerle reflexionar sobre algunas cosas. Eso es lo que me ha pasado a mí hoy.
Supongo que más de uno lo habrá leído ya, pero por si acaso, el siguiente artículo del diario El Mundo que tiene por título el mismo de esta entrada, se podría resumir en un... no es oro todo lo que reluce...
Referencias
Enlace Web: El cuento de la lechera 2.0 (El Mundo)
Sobran los comentarios. La imagen de esta entrada será por primera vez más grande que todo el texto de la misma.
Mark Russinovich ha publicado una nueva versión de su conocida utilidad ZoomIt.
La nueva versión (ZoomIt 3.01) puede ser encontrada en la página web de descargas de Microsoft.
Referencias:
Enla Web: Explicación de qué es ZoomIt (Elías Mereb)
Enlace de Descarga: ZoomIt v3.01
Enlace Web: sobre Mark Russinovich (wikipedia)
Acceso a la página oficial de MAD.NUG.
El próximo 22 de enero de 2009 MAD.NUG comienza su andadura del 2009 con un evento novedoso.
Primer evento del año 2009: 22 de enero de 2009
MAD.NUG empieza el año de forma diferente a como lo había hecho siempre.
La novedad no es que tengamos un evento, porque eso ya se sabe que es lo lógico.
La novedad es el tipo de evento que vamos a preparar para el primero del año 2009, y digo el tipo de evento, porque va a ser un evento de tipo mesa redonda, donde no habrá ponentes, ya que los ponentes serán las propias personas que acudan a la mesa redonda.
La idea es que entre todos debatamos "formas" de hacer las cosas, "compartamos" nuestras experiencias, "defendamos" nuestros puntos de vista, y "aprendamos" de nuestras propias opiniones contrarestándolas con las opiniones de otras personas. Es decir, nos enriquezcamos juntos.
Difícil por no decir imposible, es que saquemos en claro alguna conclusión concluyente del tema debatido en la mesa redonda, pero lo importante es sacar conclusiones propias. Cada uno tendrá las suyas, o a lo mejor, salimos de allí con más dudas que soluciones, pero si salimos con dudas, es porque realmente habremos aprendido más cosas de las que estábamos dispuestos a aprender.
Hemos tratado también el tema de grabar las ponencias, pero hemos visto que es más que complicado grabar un debate además de no servir para mucho, ya que lo que sirve de verdad es la interactuación entre todos.
Sobre grabar los eventos de ponentes, es algo que sabemos debemos mejorar y empezar desde ya... ese es uno de nuestros deseos para el 2009.
Finalmente, deciros que en cuanto tengamos más detalles del evento (reserva, tema concreto, etc) os lo haremos saber antes del 22 de enero.
Y... ¡que no se me olvide!. Si quieres venir a MAD.NUG a presentar "lo que sea" que tenga relación con IT por supuesto, serás bienvenido/a.
Por lo pronto... ¿te atreves a venir a debatir el 22 de enero próximo?.
Referencias:
Enlace Web: información oficial de MAD.NUG
Introducción
En los últimos meses me he estado "comiendo" la cabeza de una forma exagerada con respecto a la programación de aplicaciones Web con ASP.NET, bien lo sabe Miguel Sierra al que he hecho alguna pregunta que amablemente me ha respondido (¡gracias!). Pero sobre todo debido a que debo abordar diferentes proyectos y la toma de decisiones afecta a muchas variantes que no es cuestión de explicar detenidamente aquí.
Indudablemente, mi mente está puesta de forma inicial en AJAX y en RIA dejando de lado el tradicional desarrollo de aplicaciones Web (de las de toda la vida), y es ahí justamente donde empiezan mis problemas.
Por un lado Microsoft Silverlight me encanta con respeco a algunos de sus competidores, pero hasta que no estuviera soportado en cualquier entorno de ejecución y en cualquier navegador, no terminaría de satisfacer mis necesidades. Así que Microsoft Silverlight puede ser ejecutado en cualquier navegador Web, y los problemas surgen entonces con la indexación de búsquedas de cara a los buscadores Web y con el soporte a diferentes entornos de ejecución.
El proyecto Mono está ayudando muchísimo en esta línea con su Moonlight, pero aún hoy sigue siendo un problema sin resolver al 100%.
Con esta tesitura inicial, me veo obligado a redirigir mis pensamientos y esfuerzos hacia otra dirección. La dirección que me he marcado es la programación tradicional de toda la vida con orientación AJAX pura. La interactuación del usuario es para mí fundamental y que el refresco de la información dentro de la aplicación Web no fuerce el refresco de toda la aplicación Web sino solo de la parte de la aplicación que debe ser refrescada. En otras palabras, acercar la RIA al usuario.
Las dudas
Y aquí como no, aparecen nuevas dudas.
He estado mirando si es mejor o podría ser mejor ponerse manos a la obra con los controles AJAX de Microsoft o no, pero una vez más, no terminan de satisafacer mis ansias por tener una aplicación que ofrezca una experiencia rica al usuario y se convierta a una RIA pura. Ayudan, pero no termina de convencerme.
Así que me pongo a buscar por Internet, y llega a mi cerebro una cantidad de información que es capaz de agotar a cualquiera.
Me entero de la existencia de MVC (modelo vista controlador) y pienso si debería pensar en usar MVC para desarrollos grandes y para modelar el desarrollo de mis aplicaciones. De momento, no hablamos de presentación, RIA ni AJAX, pero esto empieza a traumatizarme porque me abre más dudas que soluciones. Una vez más, debo desbloquear la toma de decisiones y puesto que el desarrollo Web siempre ha funcionado como lo conocemos hasta ahora, veo que MVC puede ayudarme enormemente para desarrollos Web grandes, como los que tengo que iniciar, pero que provocarían un aprendizaje obligado que no estoy dispuesto a costear en estos momentos (el tiempo apremia... como siempre). Además, pese a que es mejor usar MVC de cara al mantenimiento de la aplicación Web en proyectos de gran envergadura, si el desarrollo con el ASP.NET tradicional se hace ordenadamente, se puede llegar a un control y rendimiento similar respecto al mantenimiento. Por esa razón, deshecho la idea de usar MVC y la dejo aparcada para más adelante, para futuros proyectos, aunque siempre y antes de empezar el proyecto, se puede volver a pensar en MVC, así que ya veremos que pasa finalmente.
Pero como no hay dos sin tres, aparece una nueva sigla en escena... MVP (modelo vista presentación). Miro y remiro un poco, pero aquí sí que prefiero dejarlo para más adelante.
Como dije antes, buscando por Internet recibí muchísima información y eso en parte me venía muy bien, pero por otro lado, llegaba a agobiar un poco.
Lo más importante de todo lo que llegué a ver, era lo relativo a los AJAX Frameworks.
Un AJAX Framework es un framework que tiene por objetivo, facilitar el desarrollo de aplicaciones Web utilizando AJAX. Hasta aquí bien, pero claro, cuando nos ponemos a mirar como usar un AJAX Framework, es posible que nos topemos con una lista bastante grande de ellos. Entre ellos aparecen AJAX Frameworks para JavaScript, ASP.NET, Java, PHP, etc. En nuestro caso nos interesa todo lo relativo a ASP.NET, y aquí vemos que podemos usar tanto los AJAX Frameworks de JavaScript como los AJAX Frameworks de ASP.NET puros.
¿Qué camino debemos tomar?
La pregunta entonces es... ¿cuál utilizar?.
Y aquí nuevamente empezamos a "comernos" la cabeza nuevamente.
La lista no es pequeña... Backbase, ExtJS, jQuery, Ra Ajax, Prototype, Yahoo! UI o YUI, DOJO, etc. Hay incluso algunos de los que muy pocos habrán oído hablar.
Por suerte, hay personas que ya se ha encontrado con los mismos problemas que yo, y que sus aportes ayudan a veces a hacer parte del camino. No todo porque yo por lo menos me baso en no creerme nada de lo que me cuentan (si estuviera leyendo esto tampoco me creería nada de lo que os estoy contando, porque es mejor verlo cada uno por sí mismo), pero me ayuda sin lugar a dudas a no dar palos de ciego o a minimizar el tiempo en encontrar una posible solución. Así que por suerte, me he encontrado con un fichero pdf que corresponde con una matriz (bajo mi punto de vista obsoleta) que compara el uso de AJAX Frameworks en aplicaciones ASP.NET.
También existe una comparativa dentro de la página de Ra Ajax que puede resultar interesante igualmente. No me cuadran los datos obtenidos para jQuery, pero es bueno tenerlo en cuenta por si acaso.
El caso es que he estado mirando pros y contras y me he topado con varias conclusiones. De todas las que he visto, oído, etc., las que más me gustan son Ra Ajax, ExtJS y jQuery además de los propios controles de AJAX de ASP.NET que son muy sencillos de utilizar. Por esa razón, he filtrado y he sacado unas conclusiones muy personales sobre este tema (cada uno que saque sus propias conclusiones, no existen balas de plata).
Lo que he visto de Ra Ajax me ha gustado, pero honestamente, es la que menos conozco, y como dice el refrán, más vale lo malo conocido que lo bueno por conocer.
Las librerías ExtJS me encantan, me chiflan, pero... las veo complejas, muy pesadas y lentas. Sé que hay compresores de librerías JavaScript, pero es una excusa. Por otro lado, la integración con Visual Studio no existe, y aunque hay rumores de que la versión 3.0 que está a punto de aparecer va a tener un diseñador propio y una "posible?" integración con Visual Studio, eso no se puede asegurar de momento y prefiero dejarlo en "standby".
jQuery es para mí tan valioso como ExtJS, pero hay algo que me gusta mucho más. Por un lado, jQuery "pesa" menos y es más ágil, y hay más proyectos y ejemplos de implementación de jQuery para ASP.NET, no como en el caso de ExtJS. Por otro lado, y quizás más importante, jQuery se puede usar con Visual Studio, se puede aplicar Intellisense en el desarrollo, y los planes de Microsoft con ASP.NET es adoptar jQuery (1) y (2), lo cuál me hace pensar en que el soporte está asegurado. Finalmente, tenemos jQuery UI para ayudarnos en la interactuación con controles en la Web.
Por otro lado, la independencia del navegador Web es fundamental y más aún que se pueda interactuar con la aplicación Web en cualquier sistema operativo, algo que Silverlight no me puede ofrecer 100%.
Por otro lado, hay algo que me molesta bastante con respecto al proceso de JavaScript y es que Microsoft Internet Explorer 7 es más lento de procesar que otros navegadores de la red. Espero que Microsoft Internet Explorer 8 sea más rápido al trabajar con JavaScript, pero no es ningún impedimento y sigue siendo siempre mucho más rápido que una aplicación Silverlight o Adobe Flex.
Ahora bien,... partiendo de mi predilección personal por jQuery y ExtJS, ¿conviene usar jQuery, ExtJS y AJAX ASP.NET como un todo?.
Mi posicionamiento es, o utilizamos jQuery o utilizamos ExtJS, pero ¿los dos?. ¿Es realmente necesario?.
Sobre AJAX ASP.NET es tan sencillo de utilizar, que minimiza enormemente algunos desarrollos o parte de ellos, además, podemos utilizarlo sin problemas con un AJAX Framework, por esa razón, igual compensa utilizar AJAX ASP.NET con jQuery o bien AJAX ASP.NET con ExtJS.
Lo que no me termina de convencer es usar el popurrí de ExtJS, jQuery y ASP.NET AJAX en el mismo proyecto.
¿Alguna opinión y/o experiencia que compartir?.
Referencias:
Enlace Web: RIA Frameworks
Personalmente no me gusta mucho la Microsoft Enterprise Library, no como a otros, pero reconozco que para diferentes tareas o acciones puede resultar muy útil.
Recordemos que Microsoft Enterprise Library, está formado por un conjunto de bloques de aplicación reutilizables que realizan acciones comunes y que pueden ser utilizados global o independientemente en los desarrollos de nuestras aplicaciones Software.
La versión 4.1 de Enterprise Library en inglés y de casi 32 Mb fue lanzada el pasado mes de Octubre de 2008 e incluye bloques de aplicaciones para Caching, Cryptography, Data Access, Exception Handling, Logging, Policy Injection, Security, Validation, y Unity.
Dentro de MSDN, podemos encontrar información acerca de esta nueva versión de Microsoft Enterprise Library y de versiones anteriores, como por ejemplo en este enlace.
Para acceder a las novedades o información de Microsoft Enterprise Library 4.1 en MSDN, podemos hacer clic en este otro enlace.
Dentro de Microsoft Enterprise Library 4.1, encontraremos un bloque de aplicación denominado Validation.
El Validation Application Block, nos permite crear reglas de validación para nuestros objetos de negocio que podrán ser utilizados a lo largo de las diferentes capas de nuestra aplicación.
En todo esto, Microsoft ha decidido publicar un HOL (Hands On Labs) sobre Microsoft Validation Application Block, que nos ayudará a lo largo de 13 tutoriales escritos en inglés, a avanzar en el conocimiento de este bloque de aplicación.
Los laboratorios están escritos en inglés y ocupan casi 5 Mb. Los primeros 11 laboratorios están focalizados en aplicaciones Windows, los dos últimos en aplicaciones Web, y el último, además de en aplicación Web, utilizando WCF, lo cuál puede resultar incluso útil para entender como funciona WCF.
Aparte de todo esto, no puedo dejar de aprovechar la ocasión para mencionar el Unity Application Block, del cuál os dejo un enlace con información en las referencias de esta entrada.
Referencias
Enlace Web: Información sobre Microsoft Enterprise Library 4.1
Enlace de Descarga: Microsoft Enterprise Library 4.1 (31 Mb - Inglés - Octubre 2008)
Enlace Web: Información sobre Validation Application Block
Enlace de Descarga: HOL - Validation Application Block 4.1 (5Mb - Inglés)
Enlace Web: Información sobre Unity Application Block
Introducción
Hay un aspecto que en particular le he dado siempre un valor muy alto en cualquier empresa en la que he estado, y en la que prácticamente a ninguna he visto aplicar de hecho. Sí de palabra o tímidamente, pero nunca de acción. Supongo que es porque a nadie le gusta escuchar las críticas o los errores, y en muchas ocasiones escuchar incluso la verdad, cerrándose en un "yo lo sé todo, no necesito que nadie me diga nada". Me refiero al brainstorming.
Transparencia, confianza, apoyo, motivación, son algunos de los aspectos muy muy importantes en el día a día y en trabajos relacionados directa o indirectamente con las TI, ya que es un campo en el que es facilísimo pasar de la euforia al estrés, presión o apatía.
No obstante, es casi siempre necesario tener una retroalimentación y en su caso una formación concreta para abordar determinados problemas, sobre todo cuando nos encontramos atascados.
Por esa razón, en nuestro sector es muy frecuente escuchar hablar de mentoring y coaching como valores diferentes, aunque hay personas que los confunden, y otras, que no saben exactamente en qué consisten o cuales son sus diferencias más concretas.
Es casi siempre menos dañino para un responsable, recibir retroalimentación y sugerencias, ideas o consejos de fuera que desde dentro, desde sus compañeros y subordinados. Pero en otras ocasiones no queda más remedio que recibir la ayuda del exterior.
Coaching
Por un lado, coaching es quizás a priori el término más cotidiano o familiar para nosotros, y tiene como objetivo principal lograr eficazmente una serie de metas por parte del entrenador (o coach) y el grupo de personas que deben estar implicadas en la consecución de dichos objetivos. Pensemos en cualquier equipo deportivo.
Pero si profundizamos en la teoría del coaching de una forma más profunda, quizás este término sea más desconocido para todos nosotros, y es que se entiende por coaching a las preguntas que el entrador hace con el fin de lograr que el cliente (coachee) pueda reflexionar y obtener el máximo rendimiento a sus problemas con la mente puesta en lograr la consecución de los objetivos marcados. Esta explicación como podrás ver, difiere ligeramente con la explicación del término coaching que hemos dado anteriomente.
El coachee por su parte, suele contar con la información adecuada y extensa que le permite resolver sus problemas, además de su propia experiencia. La dificultad con la que se encuentra el coachee es que en muchas ocasiones no sabe como enfrentarse a esos problemas o en castellano plano, no sabe por donde empezar a meter la cuchara.
Si acercamos esta explicación al día a día nuestro, veremos al coachee esa persona que sabe del negocio, que tiene el conocimiento del negocio muy bien estructurado en su mente, que sabe lo que quiere, pero que no sabe como lograr llegar a buen puerto pese a tener una amplia experiencia personal y profesional.
Si esta explicación la metemos de lleno en el desarrollo Software, veremos como coachee a esa persona de la empresa "X" que tiene una aplicación desarrollada en no se qué lenguaje o tecnología obsoleta, que desea migrarla a .NET (por ejemplo) y que tiene un conocimiento del negocio bestial, pero que en realidad, su mayor problema o dificultad es que no conoce .NET, no sabe qué cosas necesitaría para empezar, y lo que es más importante, no sabe qué tiene que hacer para crear un nuevo producto con esa nueva tecnología que aglutine toda la lógica de negocio e ideas que el coachee o cliente tiene, junto a aquellas nuevas necesidades que han ido apareciendo en los últimos años.
Podemos poner mil y un ejemplos no solo orientados al desarrollo, y es que el tópico de que el cliente no sabe lo que quiere, es falso. El cliente sabe lo que quiere, el problema es que no sabe si es eso lo que quiere o no y tiene dudas de como lograr sus objetivos, y ahí es donde en gran parte, entra en juego el coaching o entrenador, que nunca debe revelar su propia experiencia y sí dejar que el coachee aprenda de sus propios conocimientos, marcándole eso sí, unas pautas que le servirán para lograr sus hitos.
Como bien dice la wikipedia sobre el término coaching, el entrenador asiste al coachee a aprender de sí mismo. En sí, lo que busca el entrenador es la implicación del coachee en su problemática (algo que a buen seguro hace) pero tratando de que aprenda a resolver el problema o los problemas que tiene basándose en una serie de pautas que le ayuden a orientar la solución o soluciones adecuadamente.
Las 5 pautas generales que indica la entrada de la wikipedia que hay que seguir sobre coaching serían: Observar, Tomar conciencia, Determinar los objetivos, Actuar y Medir.
En sí, es una técnica cortante, ya que se puede conseguir el efecto contrario si el coaching no es una persona experimentada, o aún peor, un "vende motos" o "vende humo" como es muy frecuente encontrar en el mercado.
Mentoring
A mentoring se la conoce también como mentorship, cuya palabra inglesa puede acercarse más a su significado más puro, el de la relación.
En sí, mentoring tiene como objetivo crear un vínculo de relación en el que una persona especializada, ayuda a otra persona no especializada o menos especializada, a llevar a cabo una tarea o un conjunto de tareas que le permitan aprender profesionalmente en un camino "mano a mano" con el mentor.
La base del aprendizaje es la experiencia del mentor, algo que existe en el coaching, pero con la diferencia de que el coaching nunca expresa su experiencia al coachee y es el coachee el que aprende de su propia experiencia y conocimientos, mientras que en el caso del mentorship, el mentor sí especifica su experiencia, conocimiento, consejos y trucos para que el mentee o aprendiz aprenda y pueda continuar su camino sin ayuda del mentor en cuanto tenga la base de conocimiento suficiente.
Cada vez que se habla de mentorship, a mí me gusta poner el ejemplo del polluelo que sale del huevo. Al principio no podrá volar por sí mismo, tampoco tendrá su cuerpo preparado para ello, pero un día, cuando esté bien alimentado y preparado, podrán enseñarle a hacerlo y será independiente, pudiendo volar por sí mismo cuando desee. El mentorship trata de ayudar al aprendiz para que consiga y logre satisfactoriamente su meta.
Relación entre Coaching y Mentoring
Llegado a este punto, hay quien afirma que un mentor es en sí un coach o entrenador, y de hecho hay una estrecha relación, tan estrecha que podríamos responder a esa pregunta que sí. Pensemos que un coach y un mentor, tienen el objetivo de facilitar el logro de los objetivos del coachee o mentee.
Sin embargo, un coach no tiene porqué ser un mentor. El mentor tiene una serie de cualidades que no tiene porqué tener un coach cuando de coaching se refiere. Por ejemplo, un mentor se suele apoyar y mucho, de su propia experiencia, la cual basa para que el cliente o mentee logre sus objetivos.
Brainstorming
Para que un brainstorming o lluvia de ideas sea efectivo, debe realizarse sin compromisos, totalmente abierto a críticas, entre un grupo de personas lo suficientemente grande o amplio como para recabar opiniones e informaciones variadas, y con buen sentido del humor y relajados, ya que a veces, durante la lluvia de ideas se pueden decir cosas que no tienen porqué gustar a otras personas presentes o no en la sesión de lluvia de ideas.
El punto más importante es el de estar abierto a sugerencias y a críticas. Por lo general, a nadie le gusta que le digan lo que tiene que hacer y mucho menos sacarle los colores delante de más gente.
El objetivo de la lluvia de ideas es la de criticar constructivamente el presente o pasado, apoyándose en los aspectos futuros que se podrían agregar.
En la base del coaching y del mentorship, está el brainstorming y la retroalimentación.
Mi opinión es que antes de que abordemos un proceso de coaching o mentorship (siendo nosotros un aprendiz), es hacer una especie de examen de conciencia, análisis previo personal y profesional, basado en la sinceridad, y con aportes sinceros de tipo brainstorming.
Muchas empresas reciben coaching o mentorship sin haber analizado previamente nada de lo que tiene alrededor. Muchas veces, los propios empleados, compañeros y subordinados, tienen la solución, y en otras ocasiones, tienen pautas o directrices que ayudarán a adoptar o conseguir los objetivos mucho más rápidamente con ayuda de un coachee o un mentor.
¡Feliz Año 2009 a todo el mundo!.
Empezaré esta primera entrada del 2009 con un sitio web que me parece muy interesante y que quiero compartir con vosotros.
Se trata de un sitio web donde podremos encontrar un montón de herramientas, enlaces e información acerca de todas esas cosas que necesitaremos o podremos necesitar cuando estamos desarrollando aplicaciones.
Lo cierto es que en el mercado hay multitud de herramientas, pero muchas de ellas desperdigadas por ahí.
En esta web, se aglutinan casi todas las de la red, unificándolas en un único sitio, algo muy muy útil.
Referencias
Enlace Web: Visual Studio Gallery - Sitio Web