archivo

Archivos Mensuales: noviembre 2009

Uno de los aspectos positivos que tiene el fútbol es que su universalización permite que las analogías o metáforas que se realicen tomándolo como referencia sean más fácilmente comprensibles por todos. Hoy quiero hablar sobre la autoconfianza y el factor tan importante que es para conseguir resultados.

Muchas veces se dice: «este equipo está enrrachado» o «los delanteros funcionan a base de rachas», ¿cuál es una de las razones principales para conseguir esa racha de buenos resultados? La autoconfianza o lo que es lo mismo creer es sí mismos. Cuando un equipo está en racha es capaz de ganar a equipos a los que casi nunca gana y cuando un goleador está en racha es capaz de meter goles hasta sin querer (también sucede el caso contrario, cuando un delantero está negado no es capaz incluso de meter un gol ni quedándose solo sin portero delante de la portería).

Cuando uno cree en sí mismo, todo resulta más fácil, por ese motivo es conveniente que cada persona articule los mecanismos necesarios para proteger esa confianza en uno mismo y en el ámbito de una organización es importante que las decisiones y comportamientos que tienen que realizar los responsables de equipos de trabajo, contribuyan al incremento de la confianza individual de cada empleado y del equipo del que forman parte.

La autoconfianza se puede ver afectada por múltiples factores: estado de ánimo, problemas personales, problemas laborales, proyectos que no terminan de salir bien, ventas que no se culminan, crecimiento insuficiente respecto a la competencia, trato injusto, objetivos que no se alcanzan, no sentirse escuchado, etc, etc, etc…, aunque la pérdida de confianza en uno mismo es un estado mental y por tanto podría ser perfectamente controlable por un individuo, no hay que olvidar que somos seres humanos y por tanto, un universo de sentimientos y sensaciones, que van más allá en muchas ocasiones de un análisis racional. Por tanto todas estas variables hacen que la autoconfianza sea un elemento variable y dependerá de la fortaleza y experiencia del individuo hacer que sea lo más estable posible y se vea afectada de la menor manera por factores externos. Es muy importante este detalle, aunque factores externos puedan generar pérdida de confianza, quien realmente crea la misma somos nosotros mismos, que somos los que procesamos esa información y «decidimos» que baje nuestra confianza, por tanto somos nosotros mismos los que tenemos la llave de nuestra confianza y por tanto si se tiene el entrenamiento adecuado se puede evitar que factores externos puedan hacer mella en la misma. Como es lógico esto no es nada sencillo, de hecho yo, pese a que he escrito todo esto, soy consciente de que existen factores externos que pueden condicionar mi confianza y que por tanto tengo que trabajar mucho todavía en este asunto, pero considero un primer paso la toma de conciencia de que realmente la solución a este problema se encuentra dentro de uno mismo.

En el ámbito de los equipos de trabajo hay que potenciar aquellos elementos que permitan incrementar la confianza del equipo en general y de cada individuo que lo conforma en particular. Desde mi punto de vista, uno de los elementos que más favorece la autoconfianza es dar al equipo y a cada persona un trato lo más justo posible, es decir, la confianza no se genera de manera artificial diciendo que las cosas se están haciendo bien, cuando lo mismo la realidad indica todo lo contrario, sino actuar de manera racional y decir que las cosas se están llevando a cabo en condiciones cuando así sea e indicar lo contrario cuando no sea así, intentando explicar todo de la mejor manera posible y tomando decisiones constructivas. Por tanto, si un equipo de trabajo o un empleado sabe que su trabajo se va a medir de manera justa, su autoconfianza aunque fluctúe se mantendrá dentro de unos parámetros razonables. Como es lógico, el trato justo no es mágico y si los resultados no llegan, se terminará por romper ese equilibrio y caer en una situación de pérdida de confianza, que dará lugar a situaciones, salvo que se tomen medidas, donde esa pérdida de confianza continúe o se incremente.

Dentro de ese trato justo, se encuentra la posibilidad de dar nuevos retos profesionales de mayor nivel a aquellas personas que se lo hayan ganado con su trabajo diario.

Los responsables de equipos de trabajo tienen que intentar conocer el estado de ánimo de los miembros del mismo, eso resulta fundamental, ya que los trabajadores no son máquinas y es necesario que cada cual reciba en lo posible aquello que necesita. Esto que acabo de contar es muy difícil, ya que los responsables de equipos de trabajo estarán tan apretados de tiempo que les resultará complicado llegar a ese nivel de detalle con los miembros de su equipo y también se requiere la colaboración del empleado para hablar sobre su estado de ánimo y sus problemas (no es necesario entrar en detalle, no es cuestión de dar información que pueda afectar a la intimidad del individuo).

Los responsables de equipos de trabajo, también tendrán que evaluar las relaciones y comportamientos entre los miembros del equipo e intentar buscar un ambiente de trabajo bueno en el que además predomine el respeto y la profesionalidad. Tampoco es fácil, ya que además de requerir un conocimiento profundo del equipo, requerirá de toma de decisiones, en muchos casos desagradables.

Si un equipo de trabajo dedica el esfuerzo necesario y además tiene calidad y confianza, los resultados terminarán llegando más pronto que tarde.

Hace unas semanas tuve la oportunidad de ver un documental que echaron en su día en Documentos TV llamado «El crédito de los pobres», en el que se pueden ver diversos ejemplos de las consecuencias positivas que tiene en familias del tercer mundo que han podido emprender negocios gracias al sistema de microcréditos. Os recomiendo que si tenéis la oportunidad veais este documental.

Antes de ver el documental, ya tenía conocimiento de la existencia del sitio web de Kiva y finalmente me he decidido hoy a aportar mi granito de arena a labor que se realiza a través de dicha organización realizando un par de microcréditos de 25$ para ayudar a un par de entidades formadas por emprendedores y emprendedoras de América Látina.

Un aspecto importante de todo esto es que se tratan de préstamos, no de donaciones, de hecho una de las razones por las cuales ha tenido éxito el sistema de microcréditos es precisamente que el receptor del mismo tiene que poner el empeño suficiente en su negocio para poder devolver el crédito y tener la posibilidad en el futuro de recibir otros créditos. Cuando reciba la devolución de estos créditos utilizaré el dinero para volver a realizar otros créditos que ayuden a otras personas.

Os animo a que veais el documental, ya que os permitirá situaros en lo que es esto de los microcréditos y si tenéis la posibilidad de contribuir a que emprendedores de otros países sin las posibilidades económicas que podemos tener nosotros puedan llevar una vida mejor, lo que tendrá a su vez beneficios dentro de la comunidad en la que viven.

Quien toma decisiones tiene siempre dos posibilidades, acertar o equivocarse, esto es como tirar penalties, lo falla o lo marca quién lo tira. Debido a mi trabajo tengo que tomar muchas decisiones y como ya he dicho en bastantes artículos de este blog, no soy infalible y me equivoco muchas veces y me seguiré equivocando.

No obstante hay una variable que se repite bastante y es que muchas de las equivocaciones que he tenido han sido provocadas por tomar las decisiones de forma precipitada. Es cierto que en bastantes casos, tengo que tomar decisiones en poco tiempo, pero en otros casos la precipitación fue provocada por mi impulsividad o por creer tener las cosas claras. Estoy seguro que si me hubiera parado a pensar más tiempo, algunos de esos errores no se hubieran producido.

Pensar más una decisión no asegura acertar, pero por lo menos da la oportunidad de interpretar una situación o un problema desde otras perspectivas y esa visión crítica o diferente permite reducir el número de errores.

Por todo lo anterior me he planteado reducir el número de decisiones precipitadas, no obstante no es algo que me resulte sencillo, pese a que dependa al 100% de mi (en aquellos casos en los que no tenga que tomar una decisión en cuestión de minutos) ya que el carácter influye mucho y en bastantes ocasiones la cabra seguirá tirando al monte y provocará decisiones precipitadas. En cualquier caso, ahí queda mi propósito.

De todos es sabido que cuanto antes se solucione un problema en un proyecto de desarrollo de software, menos coste tiene para el mismo y de ello salen beneficiados tanto proveedor como cliente.

Por ese motivo resulta esencial que un proyecto sea sólido desde la base, siendo la misma el análisis funcional, lo que hace que sea muy importante la figura del analista que es la persona o grupo de personas (si el proyecto es grande) que se tienen que encargar de entender, interpretar y traducir lo que el usuario demanda, sentando las bases de los posteriores procesos de diseño y construcción del sistema de información.

Hacer un buen análisis es una tarea bastante compleja, ya que resulta muy complicado obtener todos los requerimientos del usuario desde etapas muy tempranas, ya que por regla general el usuario empieza a descubrir el detalle de todo lo que quiere cuando empieza a utilizar el producto ya construido con ejemplos reales de su día a día de trabajo (también suelen comentar nuevos requisitos o enmendar requisitos previos, en otras etapas conforme se le vaya presentando la evolución del proyecto, de hecho no es malo que se corrijan, ya que cuanto más avanzado esté el proyecto, el esfuerzo de hacer los cambios es mucho mayor). De hecho es prácticamente inevitable no hacer evolutivos que solventen esos flecos que no se detectaron en análisis para dejar el producto lo más próximo posible a lo que los usuarios necesitan y demandan. Como consecuencia de lo anterior, y como es lógico, se puede considerar que un análisis funcional es más bueno conforme sea menor el número de ajustes que haya que hacer en etapas posteriores del proyecto.

Es importante matizar que un proyecto de desarrollo de software no es una barra libre y que es importante que el usuario conozca sus responsabilidades en el proceso de definición del sistema y que no se pueden estar cambiando de requisitos continuamente, como tampoco podría estar cambiando frecuentemente de opinión si le están construyendo una casa. Todo lo anterior además hay que compatibilizarlo con que todas las partes están interesadas en el que el proyecto vaya a buen término, por lo que tampoco es una buena política ser inflexibles en la modificación del catálogo de requisitos, porque si el resultado final no es el que quiere el usuario, el sistema de información tendrá muchas papeletas para no ser utilizado. Equilibrio complicado: evitar que los usuarios modifiquen continuamente requisitos y tener un poco de mano izquierda cuando se planteen esos cambios. Como ese equilibrio es complicado de mantener y es fuente frecuente de conflictos, hay que intentar que el análisis tenga la mayor calidad posible.

Hacer un análisis funcional por tanto es una tarea compleja, a lo que hay que sumar que en muchos casos hay que aprender mucho sobre el proceso de negocio que se pretende informatizar, para entender de mejor manera lo que el usuario demanda, ya que resulta todo más fácil si el lenguaje que se utiliza es el mismo. En muchas ocasiones esos procesos de negocio son tremendamente complejos y además se dispone también de poco tiempo para entenderlos, teniendo en cuenta que por regla general y como he comentado muchas veces en mi blog, los proyectos informáticos suelen estar infravalorados (por el que contrata y/o por el que es contratado (para conseguir el contrato)).

Dado que el análisis funcional consiste en abstraer un conjunto de necesidades de los usuarios es muy importante la implicación de los mismos y eso no siempre se consigue. Si los usuarios no están implicados, por muy buen analista funcional que tenga el proyecto, las probabilidades de que este salga mal crecen exponencialmente. Evidentemente un buen analista puede paliar esos huecos que deja el usuario e incluso conseguir una mayor participación de los usuarios, pero más tarde o más temprano los problemas aparecerán y al final siempre termina pagando el proyecto (en primera instancia) y el que lo desarrolla (en segunda). Por todo lo anterior, se puede pedir que un analista funcional aprenda un proceso de negocio complejo, que consiga extraer de los usuarios lo que buscan y necesitan y que además lo haga en un tiempo record, pero lo que no se le puede pedir es que haga magia y resuelva problemáticas que le trascienden, como el caso que he comentado de la inacción de los usuarios en determinados proyectos, siendo esa falta la implicación la primera causa de que un análisis no salga bien y por tanto una de las causas más importantes del fracaso de un proyecto y no se trata en este caso de tirar pelotas fuera y ponerme del lado de mis colegas de profesión, se trata de algo que he podido vivir en diferentes proyectos de manera muy directa.

Nadie es infalible y un analista funcional tampoco lo es. Habrá errores (independientemente de que la causa de los mismos sea provocada por circunstancias adversas en el proyecto o no), puede que en este proyecto sean muy pocos y que en otros sean mayores, por eso es importante que el analista lo tenga asumido desde un principio, como también lo es que de esos errores se debe aprender y que resultarán fundamentales en la formación del mismo. Al final esos errores terminan curtiendo y permiten que cada vez los análisis que se realicen sean mejores. Por tanto, la experiencia resulta importante. En cualquier caso, suponer un análisis perfecto es suponer que en un proyecto se dan circunstancias ideales y que todas las variables que pueden influir en que las cosas vayan mejor o peor, están todas a favor.

De todo lo comentado en los párrafos anteriores se extrae que es importante que un analista funcional sea un buen comunicador, primero con el usuario ya que resulta fundamental que el usuario conozca todo lo que hemos entendido y cómo se pretende llevar a cabo (no conseguir eso es ir a ciegas) y segundo con el equipo de proyecto ya que tiene que trasladar a documentación y hacerles entender la interpretación de lo que el usuario quiere y cómo lo quiere.

Un buen análisis funcional no asegura el éxito del proyecto, ya que la ejecución técnica del mismo también tiene un peso importante, pero lo que sí es seguro es que si el análisis funcional no es bueno, la ejecución técnica difícilmente puede salvar las deficiencias del mismo y tocará corregir el producto una vez construido y además, por regla general, en diferentes evoluciones, lo cual es muy costoso y tampoco asegura que ese árbol que empezó torcido, termine por enderezarse.

Hay muchos jefes de proyecto o gerentes que ni lo dudan, en el momento en que un proyecto se detecta que se puede ir en lo económico (o directamente ya se ha ido) se ponen en contacto con el cliente para intentar buscar una solución. La solución suele pasar siempre en primer lugar por pedir más dinero y si no es posible por intentar reducir el alcance.

Mi opinión al respecto es que buscar una renegociación de los acuerdos de un proyecto cuando existen desviaciones debería ser algo obligatorio para cualquier responsable de proyectos de una empresa de desarrollo de software, eso sí, no vale en todas las circunstancias, aplicado el intento de renegociación sin unas razonas objetivas puede provocar que, en ocasiones, sea peor el remedio que la enfermedad.

En el proceso de renegociación hay que tener en cuenta que, siempre, siempre, tiene la sartén por el mango el que paga y que por muy hábil que sea la persona que negocia o muchas razones que tenga, la sartén siempre la tiene quién paga, lo cual lo pone en unas condiciones muy ventajosas en el proceso de negociación (y casi todos los clientes saben que tiene ventaja y no todos los proveedores que buscan una renegociación son conscientes de esta circunstancia).

¿Es malo que el cliente tenga la sartén por el mango? Evidentemente nunca es bueno negociar en desventaja, pero por lo menos si se es consciente de quién tiene todas las de ganar, se sabe de qué va el juego y eso es un tanto a favor, ya que por lo menos se es consciente de cómo se debe enfocar la renegociación (al menos, en términos generales).

Como ya dije en el post, Lenguajes distintos, personas distintas, no se puede abordar un proceso de renegociación igual con todo el mundo, ya que cada persona es distinta, por lo que una estrategia que puede ser apropiada para un individuo, para otro puede producir el efecto contrario. Por eso es importante conocer lo mejor posible al interlocutor o posibles interlocutores.

Por regla general, la gente tiende a ser sensata (aunque el grado de sensatez puede verse afectado en función de lo que la renegociación afecte a la cartera) si se exponen argumentos sensatos, es decir, si se demuestra que se ha trabajado bien, que se ha ido haciendo todo lo que se ha pedido, que se ha ido informando convenientemente del avance del proyecto (por eso insisto tanto en la importancia de la comunicación con los clientes) y que el proyecto efectivamente tiene un alcance que supera lo previsto inicialmente (o que se han producido una serie de circunstancias ajenas al equipo de desarrollo, perfectamente demostrables, que han provocado una desviación de los costes del proyecto). Otro aspecto importante es que si se van a producir desviaciones el cliente las conozca cuanto antes, de la misma manera que conozca lo bien que se está trabajando, de esta manera se evita la situación de «sorpresa» que puede tener la solicitud de una renegociación si no hay indicios previos de que pueda ser necesaria.

Si se disponen de esos argumentos, la renegociación tiene más posibilidades de llevarse a cabo con éxito (no hay una fórmula que asegure que la negociación salga en los términos deseados) y digo, más posibilidades, ya que dependerá de muchas circunstancias llegar a un acuerdo que sea plénamente satisfactorio. En cualquier caso, siempre hay que intentar salir mejor que como se llegó (y en el peor de los casos igual), si se intenta renegociar con las manos vacías (desviaciones provocadas por una actitud negligente del equipo de proyecto, por una oferta que no se ajustaba a la realidad, etc…) lo mismo se salé mucho peor.

Otra de las cosas que he aprendido en estos años, todavía escasos, de experiencia profesional, es que la Ley de Murphy castiga sin piedad a los proyectos de desarrollo de software en cualquiera de sus ámbitos (desarrollo, gestión, etc…) y quien piense lo contrario que recuerde todas aquellas demos donde todo parecía controlado y algo fallaba (no necesariamente el sistema de información que se iba a enseñar).

Por ese motivo, intento que en la medida de lo posible queden en los proyectos los menores cabos sueltos posibles, ya que una cadena es tan fuerte como su eslabón más débil. El hecho de intentar no dejar cabos sueltos, no quiere decir que no se sea consciente de que siempre se quedarán algunos sin atar, algunos de forma inconsciente y otros por no haber sabido detectarlos o haber tomados decisiones equivocadas. Lo importante de todo esto es que si se está en la mano resolver un problema en un proyecto, la decisión más adecuada desde mi punto de vista no es huir hacia adelante sino resolver el problema (independiente de que sea costoso o complejo) porque tarde o temprano pasará factura.

En cualquier caso, tampoco es conveniente tomar eso como una regla general sin pensar en las características del proyecto que se está desarrollando (técnicas, económicas, temporales, etc…), porque en un mundo tan complejo como el desarrollo de software, siempre habrá excepciones y circunstancias donde la solución más lógica no es la más adecuada o donde la solución que funciona en muchos casos no funciona en un proyecto concreto. Por tanto es importante siempre minimizar el número de cabos sueltos, resolverlos lo antes posible cuando son detectados y aplicar siempre el sentido común a la hora de priorizar la resolución de problemas y la propia evolución del desarrollo.

Tener en la plantilla de tu organización, personal con un alto nivel técnico es muy positivo, de hecho es una condición importante para alcanzar el éxito en la misma. No obstante, a esos galácticos, cuya función principal debe ser pensar en innovación y desarrollo por un lado y por el otro dedicarse a resolver las tareas más complejas de los proyectos, por otro, se les suele dar otras responsabilidades como la gestión de proyectos, gestión económica, gestión de recursos humanos, etc… No digo que este perfil de personas no sea capaz de hacerlo, es más, mucho de ellos lo harán extraordinariamente bien, lo que pasa es que la cabra tira al monte y las personas con alto nivel técnico siempre tiran a la técnica y pueden olvidar otras tareas que son absolutamente necesarias en el puesto que le han asignado, es decir, si ya eres jefe de proyecto, no te puedes centrar exclusivamente en la solución técnica del proyecto o incluso programar, sino en cuidar otros aspectos como la gestión de recursos del proyecto, costes, relación con clientes y/o usuarios, comunicación, gestión comercial, etc…

A los galácticos hay que acompañarlos por personas que teniendo el conocimiento necesario del negocio, tengan otras habilidades y que sean el complemento que requieren ellos y la organización para que la maquinaria funcione.

La falta de comunicación es una fuente de problemas ya que como nadie tiene una máquina para leer el pensamiento, al final, cada cual interpreta una determinada situación a su manera y generalmente, si existe un conflicto, la interpretación además, en la mayoría de los casos tenderá a ser negativa, lo cual tenderá a agravar las circunstancias.

Cuando el problema se presenta, la falta de comunicación no lo va a solucionar, por lo menos, a corto plazo, después el tiempo puede borrar cosas y poner las cosas en su sitio, pero todo ese tiempo que ha pasado, es tiempo perdido.

La comunicación no garantiza resolver un problema, pero el hecho de que no sea infalible no quiere decir que no sea un buen recurso para eliminar un problema o un malentendido o ayudar al menos a relativizarlo o contextualizarlo y además ayudará a que la bola de nieve no siga creciendo, ya que el silencio es un acelerante.

¿Puede la comunicación empeorar un problema? Depende del uso que se le quiera dar a esa bandera blanca, es decir, si se quiere utilizar para arreglar una situación o si se quiere utilizar para atizar a la otra persona.

La comunicación es un instrumento que puede ser empleado o no, que en el caso de ser empleado, puede ser utilizada correctamente o provocar efectos negativos, con sus pros y sus contras, entiendo que los beneficios que puede aportar superan a los riesgos y que permite evitar problemas y malos entendidos y que en el caso de que se produzcan ayudan a eliminarlos.

Por todo lo anterior considero que la comunicación es esencial en un proyecto de desarrollo de software, siempre será mejor un exceso de comunicación que su ausencia y siempre será mejor andar con certezas que con suposiciones.

El planteamiento de un marco común de trabajo, se articule de la manera que se quiera (framework único, libros blancos de desarrollo, metodologías de calidad, guías de buenas prácticas, consensos entre los miembros de un departamento, etc…), desde mi punto de vista resulta de mucho interés para conseguir productos finales que a la larga sean más fácilmente mantenibles.

Todo lo anterior además debe ser compatible con el objetivo final de cualquier proceso de desarrollo de software que es la entrega de un producto que sirva al usuario y funcione, sin esta premisa, como ya he comentado en otros artículos, de nada valen que se cumplan todas o la mayoría de las iniciativas de calidad del software que acompañen al proceso de desarrollo, ya que el primer mandamiento que debe cumplir toda aplicación informática es la verificación de los requisitos del usuario (además de otros importantes como la usabilidad, seguridad, etc…) y por tanto que satisfagan sus necesidades.

No deben ser aspectos contrapuestos o incompatibles conseguir productos software que sirvan y funcionen y que sean acordes con un marco común de desarrollo, es más, resulta más que razonable que si tiene que haber excepciones sobre ese marco, las haya, siempre y cuando estén justificadas por el propio proyecto en sí. No aplicar esa flexibilidad, sería ir en contra de lo que es el propio proceso de desarrollo de software en sí, donde no todo es previsible o planificable y donde una solución concreta puede requerir una estrategia, una técnica o unos recursos no contemplados dentro de una metodología de calidad o de desarrollo y que no por ello se deberían impedir su utilización si permiten resolver el problema de manera eficiente.

Comenta el blog Genbeta, el «mal rato» que pasó Steve Ballmer en la reunión anual de accionistas de Microsoft, por las preguntas que le hicieron determinados accionistas.

Estas preguntas estaban centradas en la necesidad de mejorar en marketing para intentar relanzar la imagen de la compañía.

Creo que para todos es evidente que Microsoft tiene un grave problema de imagen, ya que se le ha asociado la imagen de enemigo del software libre, de elaborar productos más orientados a los resultados de la compañía que a los usuarios, de haber perdido capacidad innovadora (los dos factores anteriores, da un imagen como una empresa que desarrolla productos de una generación anterior), de ser un látigo para la competencia, etc…

A todo lo anterior hay que sumarle otros aspectos como el mal sabor de boca que han dejado algunos productos suyos como es el caso de Windows Vista o Zune.

En lo que respecta al problema de imagen Microsoft no ha sido víctima de nada, sino que esta misma empresa no ha enfocado nada bien sus campañas de marketing, ya que se han olvidado de que tienen competencia (este es el problema de quien está dominando de manera clara un determinado sector, como el de los sistemas operativos, desde hace muchos años). De esto, como he comentado en diferentes artículos se han aprovechado todos sus competidores. Un ejemplo de todo esto lo tenemos con la imagen de enemigo del software libre de Microsoft, tras la cual se han parapetado todas las actuaciones que han realizado gigantes como Apple, Google, Oracle, etc…, que aunque participen o subvencionen algunos proyectos de software libre, sus productos estrella y la línea principal de sus negocios se basan en software propietario puro y duro, que además lo seguirán siendo, salvo sorpresa, por muchos años.

El marketing es fundamental siempre y más en un entorno tan competitivo como en el que se mueve Microsoft. Apple ha sabido manejar muy bien los tiempos del marketing (de hecho tener algo que sea de Apple, se ha asociado a tener algo guay) y lo ha acompañado con productos sensacionales e innovadores, lo cual ha tenido un impacto muy importante en el mercado y, en consecuencia, en el balance de la compañía.

Microsoft debe reaccionar y no sólo en marketing, el entorno ha cambiado y ahora tiene competencia real y fuerte en todos los sectores, hasta incluso en el de los sistemas operativos, con productos de gran calidad y tremendamente innovadores. Si Microsoft no reacciona lo puede pasar muy mal, ya que lo más lógico es que dada la competencia que tiene, por ejemplo, en los sistemas operativos (Mac OS, Linux, próximamente Chrome OS), lo normal es que pierdan cuota de mercado, ya que hay más donde elegir y esa pérdida de cuota de mercado tendrá resultados directos sobre los balances de la compañía.

Yo espero que Microsoft reaccione, ya que necesitamos a esa empresa, necesitamos que exista una competencia viva en el sector, que proporcione innovación y cada vez mejores productos.