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.

Anuncios

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.