archivo

Archivos Mensuales: diciembre 2009

Osborne era una empresa fabricante de ordenadores en la década de los 80 sobre la que existía la leyenda de que entró en bancarrota por el preanuncio de que su empresa iba a desarrollar (todavía no estaban construidos) una nueva generación de ordenadores que mejoraba sustancialmente a la que existía (y comercializaba en esos momentos), supuestamente ese anuncio provocó que las ventas del producto se congelaran, ya que los usuarios en su inmensa mayoría decidieron esperar a que esa nueva gama de ordenadores saliera al mercado.

El toque de leyenda lo da el hecho de que los problemas financieros que tuvo Osborne se debieran exclusivamente a eso, ya que posteriormente se indicó que la fuente principal de problemas surgieron cuando se intentó acabar con el stock de componentes de la generación anterior, que obligó a la empresa a realizar una inversión de la que no se recuperó.

Todo esto dió lugar a la aparición del concepto denominado efecto Osborne, aplicándose a aquellas situaciones donde el anuncio de nuevas versiones o versiones mejoradas de un producto provocan un efecto negativo en las ventas o en la adopción del producto que se está comercializando en la actualidad, ya que los posibles compradores o usuarios del mismo prefieren esperar a que aparezca la nueva versión.

Ejemplos de efecto Osborne lo podemos encontrar por todos lados e incluso en nuestra vida diaria. De hecho hace poco tuve la oportunidad de conocer un producto que podría resultar interesante para la organización en la que trabajo, no obstante, no recomendé a los responsables de tomar la decisión de implantarlo ya que era mejor esperar a versiones sucesivas (que se liberarían a corto/medio plazo) que iban a implementar funcionalidades que sí que nos resultarían más interesantes que las que tiene ahora. Tal vez si no hubiera conocido a priori el roadmap del proyecto hubiera recomendado que se empezase a probar el producto en mi organización.

También se comenta que Microsoft tuvo algo de efecto Osborne con Windows Vista cuando se anunció Windows 7.

¿Es siempre malo anunciar las próximas novedades en tus productos? Desde mi punto de vista no y además en ocasiones puede ser hasta necesario. Dependerá como siempre de muchas variables: el mercado, los competidores, los usuarios potenciales, el tiempo que falta para la liberación de las novedades, las características de las novedades, el retorno de la inversión y/o stock del producto actual, etc… Si no se tiene en cuenta esos factores podría darse el caso de que no se consiguiera recuperar la inversión de la versión actual de los productos o de que la competencia reclame la atención de los usuarios.

Anuncios

Cuántos proyectos ambiciosos de desarrollo de software no se han llevado a cabo o, ejecutándose, no han llegado a tener éxito por falta de implicación de la alta dirección. Cuántas empresas han visto mermadas su productividad y/o han perdido mercado por no haberse adaptado a tiempo a los cambios provocados por la evolución de las TICs.

La informatización de los procesos de negocio es algo fundamental para la competitividad de cualquier organización, por lo que pensar que las TIC es un servicio cualquiera y no un elemento fundamental para el funcionamiento de la organización es un error que afecta directamente al balance de la compañía.

Por este motivo insisto mucho en que el entorno ha cambiado y que quien se suba antes y mejor al carro de las TIC tendrá mucho ganado, como es lógico no es el único factor, pero sí se trata de uno muy importante. Esto provoca por un lado que los responsables TIC de la organización deben tener voz y voto en los órganos de dirección de una organización y no a través de un responsable de área cuya competencia sean las TIC y otras tantas cosas más, sino a través de un responsable especializado que sea la persona sobre la cual recae el día a día de la gestión de las TIC en la organización, no actuar de esta manera implica que se diluya la problemática que puede tener la gestión TIC con otras problemáticas que pueda tener ese responsable de área en otros aspectos objeto de su competencia y por tanto obviarse en determinadas circunstancias situaciones de riesgo o situaciones estratégicas que pueden tener un impacto importante en la organización. También es necesaria una mínima formación en la importancia de las TIC para el resto de personas que componen los órganos de dirección, porque sin ella no terminarán de reconocer la necesidad y la importancia de las nuevas tecnologías integradas en los procesos de negocio de la organización, ya que en muchos casos estas personas habrán crecido en su carrera profesional en un entorno de competencia o de mercado donde las TIC no tenían la trascendencia que tienen ahora.

Por tanto, la informática debe estar siempre alineada con los objetivos de la organización y a cambio la organización debe darle a la misma el papel y el respaldo que se merece, esta situación permite conseguir un equilibrio muy provechoso, lo contrario es entrar en una situación de desequilibrio y falta de control, que provocará que en muchos casos se dediquen esfuerzos TICs en asuntos que no son trascendentes para el funcionamiento de la organización, descuidando otros aspectos importantes que sí pueden provocar consecuencias económicas directas o indirectas en el funcionamiento de la institución.

Como ya he comentado en otros artículos estoy totalmente a favor del uso de software libre en entornos corporativos y particulares y que tanto las administraciones públicas como las empresas privadas deberían tener entre sus estrategias la progresiva utilización de este tipo software mediante la sustitución de su equivalente propietario en todos aquellos casos en los que el nuevo software proporcione unas funcionalidades iguales o mejores que el anterior.

Digo progresiva, porque la sustitución de unos productos por otros (y esto es extensible a cualquier sustitución de un software por otro, por tanto es un caso general y que no depende que el nuevo software sea libre) requiere de una planificación y de un proceso de gestión del cambio (e incluso en muchas ocasiones de soporte) que en muchos casos es costoso, sobre todo si el cambio afecta a un buen número de empleados, es decir, no se puede de la noche a la mañana pasar de utilizar un producto a utilizar otro, ya que puede afectar entre otras cosas a la productividad de los empleados. También digo progresiva porque si se van a sustituir varios componentes software por otros y hay que hacer para cada uno de ellos el proceso que acabo de indicar, en muchos casos será conveniente realizar la sustitución de forma escalonada. También es necesario tener en cuenta que existirán organizaciones que por sus características particulares sea bastante complicado el cambio de un software por otro y que provoque que el mismo se realice de forma muy pausada o bien que se descarte.

Pero una cosa es eso y otra olvidar que los Departamentos de Informática deben dar un servicio al resto de la organización y que ese servicio debe ser lo más óptimo posible, es decir, hay que evitar la experimentación en circunstancias que afecten a la productividad y por tanto si se va a sustituir un producto por otro, y centrándonos en concreto en la sustitución de un software propietario por uno libre, se debe tener claro (además de que es necesario un proceso de transición como el que se indicó en el párrafo anterior) que el nuevo producto permite proporcionar un servicio igual (o casi igual) o mejor que el anterior. Si no es así, salvo circunstancias que habría que estudiar caso por caso (por ejemplo, el coste de licencia de un producto propietario es muy grande y su sustitución por un producto de software libre, provoca una pérdida de algunas funcionalidades importantes que afectan, por ejemplo a alguna de las siguientes variables: disponibilidad, seguridad, productividad, etc…, pero el impacto de las mismas traducido en términos económicos es menor que el pago de las licencias del producto propietario), lo mejor es quedarse con el software propietario que se esté utilizando del cual sabemos que está dando un servicio y lo está haciendo haciendo bien.

Muchas veces se plantea el debate si es mejor que las empresas de desarrollo de software muestren una estructura organizativa vertical u horizontal.

Mi experiencia profesional se ha basado en organizaciones donde la estructura es vertical y esto puede condicionar un poco mi opinión sobre este tema, no obstante, antes de escribir este artículo le he dado una pensada a esta disyuntiva y voy a tratar de ser lo más objetivo posible, pero sin olvidar lo que la experiencia me ha enseñado.

Desde mi punto de vista el factor más determinante es el tamaño de la empresa. Una empresa muy pequeña funcionará mejor horizontalmente (además de que le será complicado mantener costes de estructura elevados, salvo que siendo pequeña consiga una facturación muy importante) y una empresa de cierto tamaño será complicada de gestionar si lo horizontal predomina sobre la vertical, ya que al fin y al cabo habrá que tomar decisiones, gestionar múltiples equipos de trabajo, tratar con diversos clientes, realizar tareas comerciales, etc… y no todo el mundo podrá, estará preparado o tendrá la voluntad de hacer todo tipo de tareas. ¿Cuál es el tamaño a partir del cual se encuentra el punto de ruptura entre lo horizontal y lo vertical? Creo que es difícil generalizar y dependerá en gran medida de las características del personal que componga la organización, cuanto más compromiso tengan con la empresa y más flexibles sean a la hora de asumir tareas y competencias, más sencillo será seguir manteniendo una estructura eminentemente horizontal, pese a que crezca el número de empleados.

Apostar por una solución vertical o una solución horizontal, es como apostar por el negro o por el blanco olvidando toda la gama de tonalidades intermedia.

En una solución vertical, salvo determinados puestos que por sus características no será posible, es necesario que cuando sea preciso determinados puestos realicen tareas que puedan estar por debajo o incluso por encima de sus funciones, es decir, si la empresa, el proyecto, el equipo de trabajo lo necesita, hay que olvidarse de galones y tener la flexibilidad suficiente para echar una mano donde sea preciso. Esta flexibilidad, permitirá dotar de mayores características horizontales a una organización vertical.

En una solución horizontal, es necesario que determinados puestos se responsabilicen de determinadas tareas, ya que será necesario personas que tomen decisiones (aunque intente consensuar algunas de ellas), que representen la empresa ante clientes, ya sea para el seguimiento de proyectos o para actividades comerciales, que planifiquen y organicen, etc… Es decir, pese a que se intente mantener equipos de proyecto homogéneos, siempre será necesario que no haya un desequilibrio entre el número de empleados que tienen que realizar estas funciones y los que realizan las tareas propias de producción de software. Estas características, permitirá dotar de mayores características verticales a una organización predominantemente horizontal (digo lo de prediminante, ya que salvo empresas de desarrollo de software, muy, muy pequeñas todas tendrán una componente vertical).

Por tanto, como en tantas otras cosas, ¿qué es mejor si una organización vertical y horizontal? La respuesta es que depende y que habrá que tener en cuenta factores como el tamaño, la facturación y las características de los empleados (entre otros) para poder decir si a una organización le viene mejor una estructura eminentemente vertical u horizontal, pero que en cualquier caso, hay que intentar conseguir estructuras lo suficientemente flexibles que permitirán, independientemente del tipo de organización elegida, darle el componente horizontal o vertical que le falta y que será fundamental para conseguir el mejor aprovechamiento posible de los recursos humanos existentes e incrementar la adaptabilidad ante las diversas contingencias que se pueden producir en el día a día de funcionamiento de la organización.

En muchas ocasiones cuando se busca un producto que implemente una determinada funcionalidad, antes de contactar con alguna empresa, se realiza una búsqueda en Internet para obtener información de las distintas posibilidades que ofrece el mercado.

Esa búsqueda inicial, dará probablemente con un conjunto de alternativas, las cuales pasarán a ser estudiadas antes de decidir la compra o no de una determinada solución. Por tanto, resulta muy importante, entrar inicialmente en el mayor número de esos posibles conjuntos de alternativas, ya que incrementará las posibilidades de éxito.

Imaginemos la siguiente situación: estoy interesado en adquirir un producto X y empiezo a buscar referencias y comentarios del producto en la red. Si de un producto se habla muy poquito o casi nada y si además accedo al sitio web oficial del producto y no encuentro prácticamente referencias, las posibilidades de que esa alternativa quede descartada son amplias.

Que el producto tenga poca repercusión en la red o que no se publiquen las referencias, no tiene por qué indicar que el mismo sea malo, lo mismo es la mejor solución que existe en el mercado, pero eso hay que transmitirlo de alguna manera, de ahi la importancia que tiene el marketing en todo esto. Los lectores habituales de mis artículos ya sabéis que soy muy machacón en este asunto, todos conocemos casos de productos con una calidad más que discutible que son líderes de mercado o que tienen un índice de ventas muy significativos por el simple hecho de haber utilizado una política óptima de comunicación del producto y sus referencias. Por tanto, no basta con hacer un buen producto, no basta con hacer el mejor producto, si se quiere vender hay que ir más allá y utilizar todos los medios que se tengan al alcance para transmitir eso a todo el universo de clientes potenciales.

Wikipedia se encuentra en plena campaña de obtención de fondos para su funcionamiento a corto plazo. He echado varios vistazos a la página donde se recoge el historial de las distintas contribuciones individuales y he podido comprobar como gente de todo el mundo está tremendamente comprometida con Wikipedia, haciendo aportaciones que van desde 1$ o 1€ hasta cantidades mucho mayores, cada cual a la altura de sus posibilidades.

Después de verlo, he hecho también una modesta contribución personal, que estoy seguro que con el esfuerzo de todos, permitirá a Wikipedia conseguir los fondos necesarios para continuar en funcionamiento y seguir avanzando en los distintos proyectos en los que participa y en los distintos servicios que proporciona. Os animo a que si tenéis posibilidades hagáis vuestra donación al proyecto, como os he comentado basta con que sea 1$ o 1€.

He echado mucho de menos aportaciones empresariales, si le echáis un vistazo a la página de benefactores, veréis que la participación de empresas es testimonial, algo que no termino de entender muy bien, sobre todo teniendo en cuenta que apostar por Wikipedia es apostar a favor de corriente y que proporciona imagen, insisto, no hay nada más que ver la relación de contribuciones individuales para darse cuenta de esta circunstancia.

Wikipedia proporciona un servicio que no tiene precio, gracias a la colaboración de miles de voluntarios en todo el mundo, que se encargan de crear nuevos artículos y de mejorar los ya existentes. Evidentemente hay muchas cosas que mejorar, como la necesidad de conseguir puntos de vistas neutrales sobre muchas materias, intentar incrementar cada vez más la calidad de los artículos, llegar al mayor número de lenguas posibles, así como mejorar en cantidad y calidad de los distintos materiales multimedia, etc… No es una circunstancia fácil, ya que el proyecto es inmenso, pero estoy seguro que con el paso de los años, Wikipedia irá mejorando en estos aspectos y proponiendo nuevos proyectos de gran interés para todos.

Una de las pesadillas de las empresas de desarrollo de software es la confusión (queriendo o sin querer) que existe en muchas casos entre los conceptos de mantenimiento correctivo y evolutivo. ¿Por qué pesadilla? Porque la garantía de los desarrollos afecta sólo a los mantenimientos correctivos y por tanto no se facturan y en muchas ocasiones se “cuelan” evolutivos como mantenimientos correctivos y se convierte en trabajo adicional para las empresas, no previsto y que en muchas ocasiones requiere un notable esfuerzo y que, por supuesto, no se cobra.

Un mantenimiento correctivo es aquel que tiene como objetivo solventar una deficiencia en un componente del sistema de información (puede ser software o documental). Entiéndase deficiencia como algo que debería funcionar o estar correcto y que no lo está.

Un mantenimiento evolutivo es aquel que pretende modificar algo que funcionaba o estaba correcto, con el objeto de aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario o por otras causas como pueden ser, por ejemplo, cambios normativos.

El problema está en la definición de qué es lo que debería funcionar o estar correcto en el sistema de información, es decir la delimitación clara de la frontera entre el correctivo y evolutivo. Y no es algo que esté nada claro en muchos casos, ya que por ejemplo, eso que esa funcionalidad que dice el cliente que debería estar y no contempla el programa, ¿es algo que se ha sacado ahora de la chistera o realmente se contempló en la definición y análisis del sistema de información?, ¿es algo que no se ha interpretado correctamente en el análisis?, ¿es algo que se suponía que se podía extrapolar del análisis aunque no aparezca explícitamente?.

Es cierto que hay muchos casos que las incidencias son de cajón y son correctivos y en la mayoría de las situaciones no dan problemas ni para el cliente, ni para el proveedor, que será consciente que son fallos suyos y los solucionará. También es cierto que hay evolutivos que son muy complicados de colar como correctivos, ya que una cosa es que la pared tenga que estar pintada de blanco o de color crema, que el pomo de la puerta sea plateado o dorado o que incluso el suelo sea de marmol o porcelánico y otra que te intenten comprar un piso de cuatro dormitorios por el precio de uno de un dormitorio. Sin embargo entre un caso (correctivos claros) y otros (evolutivos claros) hay todo un abanico de posibilidades que la mayoría de las veces dan lugar a conflicto (estos serán menos si el presupuesto del proyecto es holgado, el cliente es bueno, el proyecto se trata de una inversión para intentar conseguir más negocio con el cliente o a través del producto que se ha desarrollado, etc…).

Como ya he comentado en algún artículo en caso de conflicto casi siempre tiene las de perder el proveedor y lo más importante es tener asumida esa circunstancia. Eso no quiere decir que se deba decir a todo que sí, pero es más fácil negociar si no se pierde el tiempo en intentar remar a contracorriente.

Habrá negociación porque en los proyectos de desarrollo de software suelen cometer fallos las dos partes cliente y proveedor. Por esta razón siempre digo que las dos partes deben ser flexibles, ya que todos cometemos errores y además la naturaleza de los procesos de desarrollo de software no es rígida, sino en sí, un proceso evolutivo.