archivo

Archivos Mensuales: octubre 2010

Una empresa de desarrollo de software no puede ser la mejor en todo, ya que eso le implicaría contar con los mejores técnicos en cada área y además de contar con suficiente experiencia en proyectos de diferentes características con la tipología de clientes más variada.

Esto no lo consiguen ni siquiera las empresas grandes que pese a que tocan todos los palos hay áreas donde funcionan mejor que en otras: defensa, utilities, banca, administración pública, etc… y dentro de cada una de ellas servicios que hacen mejor: consultoría, desarrollo de software, técnica de sistemas, microinformática, etc… y son precisamente en esas áreas donde presentan sus mejores resultados, aunque muchas de ellas no renuncian a seguir progresando en otras donde no son tan fuertes, ¿por qué? pues porque uno de los problemas de la especialización es que la resistencia a los cambios es mucho menor, de manera que si la competencia te come mercado o el mercado se reduce, tienes más problemas para adaptarte y buscar soluciones alternativas.

Pero no todos son problemas, hay empresas de desarrollo de software (y en general de servicios informáticos) que les va muy bien con la especialización, sobre todo en sectores donde la competencia es menor (también lo suele ser el mercado) y ahí se han hecho muy fuertes, tanto que es muy complicado entrar.

Resulta lógico que no se pueda competir con especialistas en determinadas áreas, de hecho y me pongo yo como ejemplo, ya que no me siento preparado para dirigir proyectos tan críticos como puede ser el software de control de una central nuclear, de defensa, tráfico aéreo (entre otros), el motivo es que nunca he participado en ninguno y sería muy arriesgado, ya que aunque tenga experiencia en otra tipo de proyectos, no es lo mismo, tendría que formarme primero en los procedimientos para desarrollar este tipo de sistemas, entender el negocio e ir rodándome en proyectos de esas características. Todo se aprende, pero hay determinados tipos de tareas donde no es nada aconsejable hacer experimentos. Como se juegan muchas cosas en ese tipo de trabajos es normal que se acuda a especialistas, a empresas que tienen acreditada experiencia en el sector que ya se cuidarán de hacer el trabajo de la mejor manera posible.

¿Especialización o polivalencia? Las dos, ya que en ambas se puede ganar dinero y cada empresa es la que debe decidir qué rumbo tomar. Hay algunas que empezaron ofreciendo servicios generalistas y después conforme fueron consiguiendo determinados tipos de contratos y/o desarrollando determinado tipo de productos se fueron especializando, unas centrando la mayor parte de su fuerza productiva y comercial y otras compartiéndola con otras áreas de negocio u ofreciendo servicios informáticos de carácter general. Hay otras que nacieron a partir alrededor de un determinado producto y/o servicio y son especialistas en un sector concreto y no han tenido la necesidad de ofrecer otro tipo de servicios, otras sí que han ido diversificando su negocio, aunque se hayan centrado en su seña de identidad o en aquellas áreas donde son especialistas y pueden ser más competitivos.

Tendemos a pensar que si algo no se nos ha ocurrido a nosotros no se trata de una solución adecuada, algo que se ve todavía más agudizado si quien te proporciona la solución es alguien del que pensamos que no tiene el nivel o la experiencia necesarios como para que su opinión o sugerencia sea tenida en cuenta.

Esta visión es totalmente equivocada ya que cualquier persona puede proporcionar un enfoque distinto a un problema ofreciendo una solución o por lo menos una medida para atenuarlo o mejorar la solución actual. Es más, si la idea proviene de alguien de tu equipo de trabajo pues mucho mejor que si se nos hubiera ocurrido a nosotros mismos ya que viene a demostrar que todos tienen la capacidad de aportar y de sacar el trabajo adelante.

Si se rechazan las ideas de personal de tu equipo sin ni siquiera sopesarlas, no solo nos perderemos (que ya es mucho) sugerencias, mejoras y soluciones que redundarán en el beneficio del proyecto (o incluso del departamento y de la organización) sino que provocaremos desmotivación (y como la motivación tiene repercusión en la productividad, ésta también se verá afectada) tanto en la persona que ha intentado ayudar y en el resto del equipo ya que tendrán la sensación de que no se les tiene en cuenta y que las líneas de comunicación de abajo hacia arriba no funcionan de manera adecuada.

Por todo lo anterior, si dejamos el ego aparte y pensamos en sacar el trabajo adelante con éxito, si las ideas proceden de otros será tan beneficioso o más que si proceden de ti.

Cada vez disponemos de más información para poder tomar decisiones, estábamos en la sociedad de la información y ahora en la del conocimiento, está disponible desde múltiples vías, accesible a muchas personas y a partir de ella se puede extraer conocimiento y conciencia de la situación para que la decisión que tomemos esté sustentada en la mayor objetividad posible, ya que probablemente cuanto más datos tengamos a nuestra disposición convenientemente procesados más posibilidades existirá de que la decisión elegida sea correcta (o que entre las múltiples posibilidades que se nos ofrecen cojamos una que sea beneficiosa, aunque no sea la mejor).

El problema está en que en muchas ocasiones no podemos esperar a tener toda la información para tomar decisiones y en otros casos el acceso a la misma resultará excesivamente complicado o simplemente no será posible. Las decisiones hay que tomarlas en su momento, si se toman demasiado tarde, incluso contando con información más precisa, puede que no se llegue a tiempo para revertir una posible situación negativa.

Las decisiones deben partir de una base objetiva, formada por información de la situación, de la experiencia y de la formación (debe tener más peso la experiencia que la formación) y ser tomada en el momento adecuado, una vez que se interprete que no se puede esperar más para tomarla hay que dar el paso, aunque la información sea parcial (casi siempre lo será porque cada vez existirá una mayor disponibilidad de fuentes).

Los errores pueden tener trascendencia, incluso su acumulación podría afectar al puesto de trabajo, pero incluso así, lo más importante es intentar comprender por qué una decisión no ha producido los resultados que esperábamos, de esta manera nuestra experiencia se enriquecerá y tendremos unas bases más sólidas para un futuro.

Sucede en muchas ocasiones que sin ni siquiera haberse iniciado un conflicto, alguna de las partes pone todo el arsenal en escena. Esto es un error incluso con el conflicto en marcha y teniendo razón, así que nos podemos imaginar qué supone eso cuando no se sabe si habrá algún tipo de problema y si además no se tiene razón.

Si la reacción es exagerada se le están dando a la otra parte todos los argumentos, ya que has empezado atacando y encima enseñando las cartas. En la mayoría de los casos si tu estrategia es conocida le estás dando al contrario toda la ventaja para que te gane y si encima lo haces con vehemencia se te termina volviendo en tu contra ya que todos aquellos que no conocen de verdad la historia pensarán que te estás pasando (tengas o no tengas razón) y que estás exagerando, restándote credibilidad.

El mejor conflicto es aquel que no existe por lo que hay que intentar siempre que no se llegue a él, a veces se puede evitar y a veces no, pero por lo menos hay que buscar antes otras alternativas. En el caso de que haya conflicto hay que intentar ser lo más frío posible, algo que es complicado ya que implica tener un fuerte control sobre tus emociones y eso es muy difícil. Cuanto más frío se sea, mejor, ya que se evitará pasar del terreno profesional al personal, momento en el cual cualquier argumento que tengas, por bueno que sea, no servirá de nada, habrás perdido. Además si las emociones no te ciegan, te evitarán decir cosas de las cuales después te tengas que arrepentir aunque realmente no sientas o te creas lo que estás diciendo.

Hay veces también que se entra en conflicto por cuestión de orgullo o por intentar justificar lo injustificable, ni que decir tiene que estas situaciones hay que evitarlas porque no van a traer nada positivo, ya que no tienes absolutamente nada que ganar y mucho que perder. El orgullo visto de esta manera no sirve de nada, solo puede perjudicar, entre otras cosas porque es un orgullo de mentira ya que viene de la frustración o del desengaño, el orgullo de verdad es otra cosa.

Cuando hay conflicto o negociaciones complicadas hay que saber evaluar qué te estás jugando (¿merece la pena?), qué fuerza tienes en la misma (¿existe alguna forma de sacar algo positivo?), si el beneficio que se puede conseguir es pírrico o no es posible sacar algo positivo (o sentar las bases para conseguir algo positivo más tarde), ¿para qué entrar en debates que lo más probable es que no lleven a nada? (hay innumerables ocasiones en las que nos metemos en el fango por nada) y a partir de qué momento se puede dar por buena una solución (a veces es mejor plantarse que intentar conseguir mucho más de lo que se puede).

No todo el mundo sabe manejar correctamente este tipo de situaciones (a mi me queda muchísimo que aprender al respecto y estoy muy lejos de dominarlas todavía), negociar, mantener el tipo en situaciones difíciles entre cliente y proveedor, entre desarrolladores y usuarios, no es nada fácil. Hay personas que tienen más facilidad que otras para afrontar estas circunstancias, pero al final la experiencia marca mucho la diferencia, por ese motivo es importante que cuando en negociaciones complicadas o en situaciones de conflicto tomen las riendas aquellas personas de la organización más preparadas para ello y que en lo posible se vean acompañadas por esas otras que deben ir aprendiendo a desenvolverse en estas circunstancias.

“Lo importante es entregar el producto y cuanto antes mejor, después que pase lo que tenga que pasar… si es que pasa algo”.

Esto no es solo un pensamiento que tienen algunos proveedores de desarrollo de software sino que en muchos casos se convierte en una realidad. Es cierto que a veces no pasa nada, pero desde mi punto de vista es tentar mucho la suerte.

Es posible que el proyecto se entregue sin unos mínimos de calidad (en alguno o en muchos aspectos del proyecto) y que entre unas cosas y otra no se exija la garantía o no se pidan responsabilidades, pero tarde o temprano la aplicación que se ha entregado termina explotando, ya sea porque no funciona bien, porque algún requisito no funcional (sobre todo el rendimiento) afecta al correcto desempeño de los usuarios con la aplicación o porque después el mantenimiento del sistema es complicado y requiere un esfuerzo importante al tener mucha deuda técnica (o se dan todas esas circunstancias juntas y algunas más).

Cuando suceden estos problemas la confianza del cliente con respecto al proveedor se perderá y como es lógico la existencia de relaciones comerciales entre uno y otro se complicarán, es decir, lo mismo el proyecto ha salido rentable, pero lo mismo es difícil que eso vuelva a suceder con el mismo cliente.

Por otro lado, si se quiere conservar unas relaciones aceptables con el cliente o este tras la entrega empieza a tirar de la garantía tocará tirar partes de la aplicación y volverlas a hacer, lo que se puede convertir en una auténtica tortura ya que en muchos casos el sistema se habrá pasado a producción, por lo que los cambios serán urgentes y la exigente demanda de los usuarios marcará todo el proceso de mantenimiento correctivo, lo que provocará, al menos durante un tiempo, que el proyecto esté en una continúa situación de crisis, algo que es muy poco satisfactorio ya que lleva a trabajar un mayor número de horas, con mucha presión y los problemas terminan ocultando el buen trabajo que puede estar haciendo.

Al final, no hacer las cosas bien y querer tirar hacia adelante para preservar los beneficios del proyecto (o que las pérdidas no crezcan en demasía) termina costando más dinero que si se hubiera decidido hacer las cosas bien. Siempre es mejor intentar negociar con el cliente que tirar por la calle del medio, ya que a veces sale bien, pero las más, no tienen resultados positivos a corto, medio o largo plazo.

En el desarrollo de software es necesario medir, medir y medir. Un proyecto puede parecer que va bien pero los números pueden indicar todo lo contrario y cuanto antes se detecte el problema más posibilidades habrá de encontrar una solución. Si el problema se detecta demasiado tarde, lo mismo no existe siquiera margen de reacción.

Los números por sí mismos suministran información pero no son capaces de resolver ningún problema, simplemente te ponen por delante la realidad (no resto valor a las impresiones subjetivas porque quien lleva un cierto tiempo trabajando en esto sabe cuándo un proyecto empieza a ir mal, pero lo bueno de cuantificarlo es que tienes formas de demostrarlo y una base para poder tomar decisiones). Si los números no son buenos hay que actuar porque la tendencia general, salvo que en la organización se tenga muy asumido por los empleados la orientación al objetivo y la orientación a resultados (e incluso así) es que el proyecto vaya a peor.

Antes de tomar decisiones es necesario intentar tener toda la información disponible para poder conocer las causas que han llevado a esa situación:

– Proyecto mal vendido o mal estimado.
– Problemas en la fase de análisis.
– Malas decisiones en diseño y construcción.
– Mala comunicación con el cliente.
– Mala selección del equipo de proyecto.
– El equipo de proyecto no funciona.
– Falta de productividad, etc…

Una vez conocida la realidad del proyecto y el estado de sus números, toca lo más complicado, que no es otra cosa que mancharse las manos y habrá que intentar renegociar con el cliente (si es que es factible ese camino en función de su realidad actual), hacer modificaciones o reforzar en el equipo de proyecto (en función de la etapa en que se encuentre será posible o no), intentar conseguir una mejora de la productividad, etc… Algunas de estas alternativas pueden dar lugar a situaciones poco agradables: negociar o hablar con el cliente teniendo pocos argumentos a tu favor, sacar del proyecto o de la empresa personal que ha demostrado que no es válido, echar alguna bronca, etc…

Todo eso está en el sueldo de quien tiene que tomar esas decisiones y os aseguro que ese tipo de situaciones no les gusta a nadie tenerlas (porque nuestra tendencia natural es evitar la existencia de problemas), pero cuando no hay más remedio no queda otra que actuar. Por otro lado soy de la opinión de que a la gente hay que explicarle las cosas y ser claros, si se toman decisiones sin informar a quiénes están directa o indirectamente relacionados con las mismas, aún siendo justas, se estará dando lugar a posibles malas interpretaciones y malos entendidos que pueden resultar perjudiciales en el presente y en el futuro. Con respecto a lo anterior, es fundamental que esas explicaciones estén justificadas con números, con hechos, dejando el menor lugar posible a la subjetividad (que siempre habrá).

Las decisiones hay que tomarlas a tiempo, una buena decisión tomada tarde servirá para muy poco. Quien tira el penalty es el que lo falla, quien toma las decisiones también, pero esto es otra de las cosas que está en el sueldo.

¿Sirven para algo los casos de uso? En una charla con un grupo de amigos, uno de ellos hizo esa pregunta y se hicieron unos cuantos segundos de silencio.

Supongo que cada uno tendrá su experiencia y por tanto los casos de uso tendrán sus detractores y defensores. No es el objeto de este artículo analizar quién puede tener razón sino tan solo ofrecer mi punto de vista, acertado o equivocado.

Los casos de uso según Métrica versión 3, tendrían un doble propósito:

– Servir de herramienta para la especificación de requisitos ya que ayuda a los usuarios a reducir la complejidad de abstraer la aplicación que quieren que se desarrolle (o se mantenga).
– Guiar el proceso de desarrollo.

Tal vez no haya tenido suerte, pero en todo el tiempo que llevo en este negocio, no he tenido la oportunidad de estar en proyectos donde los casos de uso hayan resultado decisivos para la especificación de requisitos (es más, en la mayoría de las situaciones ha sido un producto que ha derivado de los requisitos o que se ha obtenido posteriormente) o para el proceso de desarrollo.

En lo que a la especificación de requisitos se refiere, los usuarios prefieren la especificación de requisitos en lenguaje natural (y ellos poder discutirlos) y trabajar con posibles interfaces de usuario. Los diagramas de casos de uso siguen siendo de otra galaxia y hay que explicárselos muy bien para que lo entiendan.

En mi opinión, para que los casos de uso tengan utilidad real hay que trabajar bien los diagramas y sobre todo realizar la especificación de cada caso de uso y eso requiere un gran esfuerzo importante en el momento en que la aplicación tiene una cierta complejidad y si se quiere que realmente el usuario entienda paso a paso las distintas funcionalidades que el desarrollador ha ido detectando en las distintas sesiones de recopilación de requisitos. Por supuesto, en todo lo anterior, es conveniente que el usuario esté asistido si así lo requiere, ya que es posible que tenga alguna duda en la interpretación de lo que está viendo y leyendo.

Es difícil encontrar organizaciones en las que existe departamento de desarrollo y departamento de sistemas en las que no haya habido o haya conflictos y eso es debido al diferente enfoque que cada cual da a su trabajo, cosa comprensible ya que se trata de tareas diferentes, a la falta de comprensión mutua y a la pérdida de visión de los objetivos del servicio que el departamento de informática debe dar, pasándose a una serie de objetivos personales que por muy buena voluntad que se tenga, en la mayoría de los casos, ponen freno, precisamente, a la consecución de dichos objetivos globales.

Como sabéis, yo pertenezco al área de desarrollo y podía ponerme la camiseta de los de mi equipo y empezar a repartir estopa, pero no sería justo porque de igual forma que conozco muchas de las debilidades de los departamentos de sistemas, conozco todavía más debilidades de los departamentos de desarrollo, algo lógico porque es donde centro mi actividad laboral. Creo que no sería constructivo un artículo ombliguista en el que todos lo que hacemos los desarrolladores sea bueno y todo lo que hacen los de sistemas sea malo, tampoco sería constructivo si no especificase los comportamientos de cada mundo que acertados o erróneos no son comprendidos por la otra parte.

Los desarrolladores tenemos que responder ante el usuario por los problemas relacionados con los sistemas de información, tanto los que se encuentran en producción como los que están en desarrollo y puedo asegurar que los usuarios no se caracterizan especialmente por su paciencia. Además sea cual sea la causa del problema siempre echarán la culpa al programa o programas que utilizan, aunque éste sea debido por circunstancias que nada tienen que ver con él. Si falla la red, si se cae el servidor o pasa cualquier otra cosa es la aplicación el origen de todo mal. Esto aunque injusto, es razonable, ya que los usuarios no tienen por qué conocer toda la infraestructura que tiene un sistema de información para que funcione y ellos lo que notan es que el sistema no funciona, que va lento o cualquier otra contingencia.

Cada vez que sucede una incidencia de esas características se traduce, en función del tiempo que se tarde en resolver, el momento en el que se haya producido y el número de usuarios implicados, en trabajo, ya que habrá que volver hacia atrás tareas que no se han ejecutado correctamente y lo que es más importante, falta de confianza de los usuarios en la aplicación y en el equipo de personas que está detrás. Cuesta mucho ganarse el respeto y la confianza de los usuarios y sin embargo, perderlo, es mucho más sencillo.

También es cierto que la mayoría de los problemas que tienen las aplicaciones no son consecuencia del departamento de sistemas, sino porque las mismas tienen problemas funcionales y/o no funcionales que han llegado hasta la puesta en producción y esto es responsabilidad del departamento de desarrollo y/o de los usuarios si estos no han definido bien los requisitos o no han colaborado lo debido en todo el proceso.

Si la mayoría de los problemas que tienen las aplicaciones son resultado del proceso de desarrollo, ¿por qué nos fastidia/altera/mosquea tanto que de vez en cuando haya pérdidas de disponibilidad total o parcial de las mismas? Pues porque cuesta menos dar la cara cuando el problema es de tu responsabilidad que cuando es de otro y la cosa es que en la mayoría de los casos, independientemente de la naturaleza de la incidencia es el departamento de desarrollo el que recibe las “caricias” de los usuarios.

Otro problema que nos encontramos los desarrolladores con respecto al departamento de sistemas (o viceversa) es la existencia de prioridades distintas (en realidad son compatibles, pero nosotros mismos hacemos que cada una siga su propio camino) y esta circunstancia es la que favorece la creación del fenómeno de los dos mundos.

La prioridad de los desarrolladores es que los sistemas de información permitan el trabajo de los usuarios de la manera más eficientemente posible y, además, que el tiempo de respuesta ante las incidencias de las aplicaciones sea el menor posible. La prioridad de los departamentos de sistemas está en mantener la disponibilidad de los sistemas físicos, servidores y comunicaciones, así como establecer las medidas de seguridad apropiadas para evitar intrusiones o acciones no permitidas sobre cualquiera de los elementos anteriores.

Hasta ahí, todo bien, el problema está cuando los desarrolladores damos cabida a soluciones que no son compatibles con las políticas del departamento de sistemas o que requieren soluciones que muchas veces no están en su mano (los medios, memoria, procesador, etc… no son infinitos), de manera que pedimos la instalación de servidores nuevos, más memoria, más procesador, nuevas soluciones de bases de datos, etc… además de otros aspectos relacionados con las políticas de seguridad (apertura de determinados puertos, más capacidad de acceso a bases de datos, servidores, etc…,) generalmente, además, sin dar excesivo margen de maniobra en cuanto a buscar otras alternativas, ya que avisamos cuando ya se está trabajando en la solución o está terminada.

Como es lógico estas situaciones causan desgaste ya que por un lado los desarrolladores demandamos que se pongan a disposición de las aplicaciones las infraestructuras que creemos que se necesitan y pensamos, al no existir el tiempo de respuesta que nos gustaría, que los de sistemas viven en otro mundo, ajenos de los problemas del día a día de las aplicaciones y de los usuarios, y por otro los de sistemas piensan que no actuamos con perspectiva, que somos un desastre y que pretendemos resolver a base de fuerza bruta lo que no hemos sabido solucionar en el proceso de desarrollo.

En relación a este asunto, tengo que dar la razón a los de sistemas, ya que se suelen enterar demasiado tarde y eso es debido a que no se les consulta si una determina solución les parece adecuada con sus políticas e infraestructura. En el caso de que sea estrictamente necesario hacer una modificación en las mismas, además hay que darles tiempo para que puedan pensar en otras alternativas o a formarse o familiarizarse con lo que les hemos pedido que instalen y/o administren.

Otro problema que también ocurre con bastante frecuencia es el exceso de celo que a veces los del departamento de sistemas ponen respecto a determinadas políticas de seguridad, muchas veces desproporcionadas respecto a la realidad existente y basadas generalmente en apreciaciones personales más que en decisiones del propio colectivo del departamento.

Es necesario que desde sistemas establezcan las políticas, sería un error que desde desarrollo se impulsasen las mismas, pero es necesario que las mismas sean generales y conocidas y no se deje al criterio del personal su endurecimiento o reblandecimiento. Además es necesario que las normas que se dicten sean racionales con la realidad de la organización y sus capacidades, ya que a veces las mismas provocan un incremento de complejidad en el proceso de desarrollo o de gestión de los proyectos totalmente innecesario.

Muchos de estos problemas quedarían resueltos o, al menos, paliados si existiesen unas normas por escrito que rigiese el funcionamiento de los departamentos de desarrollo y de sistemas y si, además, los responsables de los mismos, siempre dentro de la profesionalidad y pensando en el interés general de la organización, llegasen a soluciones de consenso en aquellas excepciones, que seguro se producirán, que haya que estudiar por no cumplir parcial o totalmente las normas.

Además de todo lo anterior es necesario el respeto. Los desarrolladores tenemos que entender que los de sistemas conocen mejor la problemática del mantenimiento de las infraestructuras que nosotros y ellos deben entender que nosotros conocemos mejor la problemática del desarrollo y mantenimiento de los sistemas y las apreciaciones de los usuarios. También es necesario entender que ambos trabajos no son fáciles y que en muchas ocasiones, actuamos desde situaciones exigentes y con presión. Todos nos vamos a terminar equivocando, no una, sino cientos de veces y tenemos que intentar ser comprensivos.

Es difícil alcanzar la situación ideal en que los departamentos de sistemas y de desarrollo no sean dos mundos con objetivos dispares, sino uno solo que verifique el objetivo final de cualquier departamento de informática y que no es otro que dar el mejor servicio posible y eso solo se puede conseguir si todas las partes involucradas reman en la misma dirección.

Raymond Edward Ozzie es desde mediados de 2006 arquitecto jefe de software de Microsoft sustituyendo en ese puesto al mismísimo Bill Gates (que se ha declarado admirador de su trayectoria), antes trabajó en empresas importantes como Lotus Development e IBM, además de emprender aventuras empresariales de éxito (sus empresas terminaron siendo adquiridas por otras más fuertes). Dentro de su trayectoria profesional se especializó en el software de trabajo en grupo, formando parte del grupo de desarrollo de Lotus Notes, software con el que se comenzó a trabajar hace maś veinte años y que en la actualidad, con las sucesivas versiones que han ido apareciendo, sigue en la brecha con una gran cuota de mercado.

Además de la trayectoria profesional exitosa de Ray Ozzie, su nombramiento también ha sido resultado de su conocimiento y experiencia en la integración entre el trabajo en grupo e Internet y se haya visto en él la persona capaz de establecer un puente entre las soluciones de escritorio de Microsoft y el enfoque actual de usuarios y aplicaciones que no es otro que la red.

Una de las citas más conocidas de Ray Ozzie es que “la complejidad es destructiva. Chupa la sangre de los desarrolladores, hace que los productos sean difíciles de planificar, construir y probar, introduce problemas de seguridad y provoca la frustración de usuarios finales y administradores”.

No puedo estar más de acuerdo con él, cuanto más complejo es el software que se desarrolla más problemas tendrá en todas las fases de su ciclo de vida y por tanto, más esfuerzo y coste tendrá asociado. Es cierto que cada aplicación o sistema que se desarrolla tiene una complejidad inherente, pero también lo es el hecho de que los desarrolladores tendemos a añadir un plus de complejidad al producto. Esto es así porque en muchas ocasiones nos empeñamos en tirar de teoría a la hora de hacer los sistemas, en otras porque intentamos que el sistema esté integrado con todo lo integrable y en otras porque intentamos que la primera versión del producto sea la definitiva, en lugar de realizar desarrollos iterativos que reducen complejidad y permiten que los usuarios se vayan adaptando al sistema e ir moldeando con la experiencia los requisitos funcionales.

Hay que hacer convivir la simplificación con las necesidades en materia de organización de sistemas que esté implantada, es decir, lo más fácil por ejemplo es que la aplicación tenga su propio sistema de terceros, tenga en tablas propias información que se mantiene preferentemente en otras aplicaciones, que se rehúse a utilizar soluciones corporativas, etc…, pero si en todos los casos se aplicase esta filosofía de funcionamiento lo que tendríamos al final es una multitud de sistemas estanco con información redundante y con el paso del tiempo, incoherente. No es sencillo encontrar el justo medio en esto, como tampoco lo es determinar hasta dónde se llega en la primera versión del sistema ni qué soluciones aplicar a nivel funcional, de arquitectura, de codificación, etc…

En cualquier caso lo que hay que plantearse es que si hay dudas se vaya siempre por el camino más fácil (ya habrá tiempo de soluciones más elaboradas o complejas). Insisto, si hay dudas, si sistemáticamente vamos a por lo fácil resolveremos algunas cosas pero a la vez crearemos nuevos problemas.

Por otro lado, tal y como comenta Ray Ozzie, la complejidad es algo que al final sufrimos todos, cliente, proveedor, usuarios, departamento de sistemas, departamento de explotación y que provoca, al ser una fuente continua de problemas, un gran desgaste.

Según muchos expertos en marketing, la marca importa tanto en tiempos de crisis como en momentos más halagüeños, pero sobre todo en épocas donde la economía no está tan boyante y en donde no se quiere especular o arriesgar en los resultados.

El desarrollo de software no es ajeno a esto y muchas empresas, sobre todo aquellas que pueden permitírselo, acuden a empresas conocidas para realizar el mantenimiento y/o el desarrollo de sus sistemas de información. Prefieren pagar más, pero a cambio tener un cierto grado de seguridad de que el resultado de los trabajos será satisfactorio.

Las empresas más pequeñas podrán pensar: “bueno, de todas formas, esos contratos son tan grandes que no tenemos infraestructuras para abordarlos, por lo que me da igual que competencia con más nombre se haga con ellos, además, lo mismo hay suerte y hasta me subcontratan, en algún caso, parte del trabajo.”.

Lo anterior podría no ser un problema si no sucediera algo que se ha convertido ya en un hecho y es que muchas de esas empresas grandes o de renombre, han decidido también irse a por trozos de tarta más pequeños. Esto en cierto modo es razonable ya que los trozos de tarta grandes son menos (y de menor tamaño) por lo que para compensar no hay más remedio que irse a por contrataciones que en otros tiempos, tal vez hubieran descartado ya que para ese tipo de empresas el overhead que tienen muchos contratos pequeños no les termina de compensar. Seguramente para conseguir rentabilidad en este tipo de trabajos hayan tenido que hacer variaciones en sus procesos productivos y de gestión, cosa lógica si se quiere ser competitivo en estos otros mercados.

¿Es tan importante la marca en el desarrollo de software? yo lo respondería a esta pregunta con otras, para ti como persona, ¿es importante la marca?, ¿compras marca o producto?, ¿prefieres marca aunque te cueste algo más caro?, ¿asocias marca a calidad?, ¿confías más en una marca conocida que en otra que no lo sea tanto?, seguramente en la mayoría de los casos triunfaría la marca, pues también en la mayoría de los casos triunfará la marca cuando existan unas condiciones parecidas entre las diferentes empresas que luchen por hacerse con un contrato.

Mi opinión es que no hay una solución universal (no hay que cerrarse en la marca o en el nombre, porque ni uno ni otro hacen análisis funcionales, diseños técnicos y programan), es decir, habrá que estudiar exáctamente qué es lo que se quiere contratar, su impacto en la organización y el presupuesto del que se dispone (entre otros muchos factores) y a partir de ahí empezar a escuchar y a leer compromisos por escrito (entre lo que se dice y lo que se escribe hay muchos, muchísimos matices).