Empezamos una aventura...

... parafraseando libremente a Ernest Shackleton:
Se buscan profesionales para peligroso viaje.
Amistades en huida. Frío penetrante.
Largos meses de completa soledad.
Constante peligro. Dudoso regreso a la vida sano y salvo.
En caso de éxito, honor y reconocimiento
.
¿Te atreves a cambiar el statu quo del sector de las Tecnologías de la Información?
Empieza comentando y opinando. Sin tí nosotros no tenemos sentido.


La tira diaria de Dilbert 20/09/2011

dilbert.com

Nuestra estrategia consiste en aumentar la cuota de mercado.

Estoy confundido. Pasé todo el año anterior tratando de disminuir la cuota de mercado. ¿Fue que un esfuerzo inútil?

No se preocupe. Wally me dijo que tiene un buen sentido del humor.

No estoy seguro.

domingo, 18 de abril de 2010

Paso 1 bis: ¿Vale cualquier especificación?

Obviemos la opción habitual: no vale decir que lo escrito sobre una servilleta de bar mientras tomamos un café son las especificaciones del usuario; ni tampoco vale decir que lo que quiere el usuario es lo que cualquiera sabe ya. Ni responder con que no nos pagan por plantear problemas sino por encontrar soluciones. 
Como hemos dicho anteriormente en este blog, existen muchos estándares de documentación (uno de los más reputados es el del IEEE Pierre Bourque and Robert Dupuis, ed (2004). Guide to the Software Engineering Body of Knowledge - 2004 Version. IEEE Computer Society. p. 2–1. ISBN 0-7695-2330-7. http://www.swebok.org). Como todo estándard, lo importante es interpretarlo correctamente; por ejemplo, no hay que tomarlo al pie de la letra sino interpretarlo. Esto no significa reducirlo a un documento vanal sino adecuarlo a nuestras necesidades.
En SoftAuction hemos incluido modelos de especificaciones; las hemos dividido en dos partes:
  • Documento Público: permite dar una visión general de las necesidades de la aplicación.  Este documento es visible para todos los usuarios con perfil Desarrollador de Software registrados en la plataforma, siendo la información disponible para realizar una primera puja a la baja sobre el proyecto. Incluye los siguientes apartados (obviando el capítulo 1, que es genérico):
  1. Perspectivas del proyecto: Es una descripción general del proyecto. Esta sección pone el proyecto en perspectiva con otros sistemas relacionados. Si el proyecto reemplaza un sistema existente este deberá ser referenciado y explicado.
  2. Capacidades generales: Esta sección describirá las principales capacidades y por qué son necesarias. Se explicará el proceso que realiza el software. 
  3. Limitaciones generales: Se describirán todos los elementos que puedan limitar las opciones de los programadores. 
  4. Características de los usuarios: Esta sección deberá describir las características generales de los usuarios afectados por los requerimientos específicos. 
  5. Entorno operativo: Se describirá el entorno real en el que operará el software.
  6. Hipótesis y dependencias: Se describirán las hipótesis  en las que están basados los requerimientos específicos. 
  • Documento Privado: permite dar una visión concreta de las necesidades de la aplicación.  Este documento es visible sólo para  tres usuarios ganadores de la primera puja; siendo la información disponible para realizar una segunda puja definitiva a la baja sobre el proyecto. Incluye los siguientes apartados (obviando el capítulo 1, que es genérico):
  1. Requisitos relativos a capacidades de la Aplicación: que tiene que hacer la aplicación.
  2. Requisitos relativos a limitaciones de la Aplicación: que limitaciones se imponen a la aplicación
Estos requisitos tienen una tipificación concreta y exhaustiva. Cuando finalice el proceso de desarrollo, serán la base para realizar las pruebas de usuario que permiten demostrar que se ha desarrollado lo que el usuario solicitaba. Lo que no esta especificado no puede exigirse
Es decir, sobre modelos más exhaustivos, en SoftAuction proponemos un modelo suficientemente detallado sin caer en el extremismo. Pueden utilizarse otros modelos (¿gato blanco o gato negro? ¡que más da! mientras cace ratones...) pero no se permite no especificar. Y se revisa que las especificaciones sean adecuadas.
De esta forma, podemos confiar en que se sabe lo que se quiere y que se puede exigir lo que se ha pedido. Gana la empresa que necesita una aplicación de negocio para optimizar sus procesos y gana el desarrollador que realize un trabajo profesional.  

viernes, 16 de abril de 2010

Paso 1: Especificar los requisitos del usuario


Iniciamos la serie que prometimos. Y empezamos por el principio... (aunque esto parezca obvio, seguramente, muchos profesionales del sector de las Tecnologías acaban de perfilar una sonrisa en su cara).
El primer paso es Especificar.  La idea es tan tonta que parece que nadie en su sano juicio podría obviarla; pero puedo asegurar que la mayoría de los  problemas (en cuanto a plazos, calidad de desarrollo, adecuación a las necesidades del cliente, etc...) se solucionarían si en los proyectos de desarrollo software existieran especificaciones. Si fueran detalladas y completas habría fiesta...
El proceso de construcción de una aplicación de negocio suele ser comparado (lo que denominamos metáfora) con el proceso de construcción (genérico, el que nos permite hacer una casa). Sus similitudes son muchas y, como la mayoría de las personas tiene una idea (aunque sea general) sobre cómo construir una casa, nos ayuda a explicar lo que denominamos ciclo de vida del desarrollo.
Las personas tenemos la necesidad de disponer de una vivienda; algunos van a vivir solos o en pareja y no prevén aumentar sus miembros. Otros, en cambio, son varios miembros de la unidad familiar. Unos tienen una importante capacidad económica mientras que otros disponen de pocos recursos. En cada caso existen unas necesidades determinadas que pueden cubrirse con unos medios concretos. Siempre puede existir el caso de una pareja que adquiera una vivienda de varios cientos de metros cuadrados con muchas habitaciones y sus asociados cuartos de baño; salvo en el caso de que tengan previsto la visita continuada de otras personas, nadie entendería esa adquisición como adecuada a sus necesidades. Las empresas pueden equiparse con estos grupos humanos buscando una vivienda; cada organización tiene sus necesidades y unos medios concretos para cubrirlas. Lo normal es adecuar las necesidades a la solución elegida teniendo los costes como limitación. 
Nadie en su sano juicio permitiría que su familia viviera en una vivienda que se haya realizado sin planos; ni estaría contento con disponer de un piso en un edificio de varias plantas cuando necesita criar gallinas… Es decir, lo normal es especificar las necesidades que se tienen y resolverlas adecuadamente bajo las limitaciones que se definan. En la construcción de viviendas se parte desde unos planos generales (que definen la estructura de la vivienda) hasta terminar el planos detallados que especifican por dónde se realizan las canalizaciones de agua o electricidad. Cuando queremos comprar una vivienda no tenemos que entender los planos detallados y nos vale con ajustar nuestras necesidades (normalmente número de habitaciones necesarias, altura del inmueble, gustos varios y, sobre todo, coste) a la información suministrada por el vendedor con un lenguaje entendible.
En el sector del desarrollo de aplicaciones nos encontramos normalmente con que las especificaciones (los requisitos del usuario) suelen ser documentos vacios sin ninguna o escasa concreción; a partir de estos documentos (si existen) generales difícilmente se puede continuar definiendo el detalle (los planos de canalizaciones de agua, por ejemplo). La consecuencia es que se pierde un alto porcentaje del tiempo en “marear la perdiz” hasta que un programador empieza a tomar decisiones de negocio que le llevan a “quitarse el muerto de encima”. Luego ya le venderemos al cliente que eso es lo que él necesita...

Entonces empecemos por hacer las cosas bien: especifiquemos los requisitos del usuario. Las ventajas son obvias: aclararemos dudas en papel (suele ser más barato que sobre código de ordenador) y sobre todo, sabremos lo que queremos y podremos exigirlo al final del proceso de construcción. Además, dentro de las buenas prácticas en el desarrollo de software existen multitud de estándares de documentos (los más genéricos son las normas IEEE) que nos permiten disponer de una plantilla de documento de requisitos con aclaraciones sobre su contenido. 
Si eres una empresa que necesita una aplicación de negocio para optimizar sus procesos y no eres capaz de plasmar en un documentos tus requisitos, tienes un problema; posiblemente que no sepas lo que quieres. Incluso que no necesitas nada o que no necesitas lo que crees. Si no te ves con fuerzas para documentarlo, solicita la ayuda de un profesional (los denominamos consultores de negocio) que tenga tanto la visión de tu negocio (podrá hablar contigo en tu “dialecto”) como los conocimientos técnicos necesarios para plasmarlo en un documento (en el dialecto de los técnicos de desarrollo).  
Si eres un desarrollador de software que tiene en sus manos un proyecto que no dispone de especificaciones (suele notarse por las muchas horas que pasas en la oficina sin saber qué hacer y por las preguntas del tipo ¿cómo vas? que te hace tu responsable) tienes un problema. La próxima vez, antes de empezarlo, di que no; estarás comportándote como un profesional.


miércoles, 14 de abril de 2010

Los 5 pasos al éxito

La medicina ha detallado los 5 pasos que seguimos todas las personas cuando se nos informa de un grave problema; normalmente (creo, no soy medico ni nada que se le parezca) se aplica cuando sabemos que vamos a morir. Estos pasos son negación, ira, negociación, depresión y aceptación. Si los miramos desde otro punto de vista, por ejemplo cuando iniciamos las pruebas de usuario de la aplicación de negocios que hemos contratado para mejorar nuestra empresa, veremos que se ajustan como un guante hecho a medida. Es irónico pero real.

Pero este el negocio (si, es un negocio, una profesión y, hasta para algunos, una vocación) no merece que nos conformemos. Desde SoftAuction proponemos 5 pasos compartiendo solamente el último: la aceptación. Expliquemonos:
  1. Afirmación: Cuando decidimos iniciar un proyecto de desarrollo de una aplicación de negocio implica ser claros. Si eres la Empresa Contratista, ten claras tus necesidades, lo que quieres; si tienes un problema de negocio y lo planteas de forma clara, un buen profesional podrá ayudarte a resolverlo; si no sabes lo que quieres dificilmente alguien externo a tu organización podrá hacer otra cosa que sacarte el dinero. Si eres un Profesional del Sector (Desarrollador de Software o Consultor de Negocio) plantea dudas y propuestas claras; si hablamos con siglas ininteligibles, además de quedar como un imbecil, nadie te entendera. Es decir, afirmemonos en nuestras opiniones, necesidades, descripciones. Empezar mintiendo (decir medias verdades o lo que se quiere oir no es mas que una forma rebuscada de mentir) no ayuda a nadie.
  2. Paciencia: Cualquier actividad lleva su tiempo. Si eres la Empresa tienes que ser capaz de diferenciar las necesidades temporales de tu negocio de las necesidades de realización de un proyecto. Si eres el Desarrollador o el Consultor no digas que si a la mayor tonteria que te propongan. Al final, la realidad se impone, quieras o no. Tiempo al tiempo.
  3. Desacuerdo: Durante el desarrollo del proyecto, tener opiniones contrapuestas es sano. Es normal que la Empresa cambie de opinión en algunos puntos (no es normal que no tenga opinión y la vaya modificando sobre la marcha); es normal que el Desarrollador no quiera tener cambios en sus especificaciones (no es normal que admita todo ni que no admita nada). Un buen profesional sabe definir el impacto de un cambio, ver su importancia y negociar con la cliente. Una buena empresa sabe entender las razones y diferenciar lo superfluo ("este fin de semana se me ha ocurrido una idea estupenda") de lo importante. Hay que saber decir que no y hay que saber admitir un no; de esta forma, cuando digamos que si tendrá doble valor.
  4. Euforia: Si hemos seguido los pasos anteriores, cuando lleguemos al final del proyecto estaremos euforicos; nos creeremos en el mejor de los mundos. Pensaremos que hemos dado un paso de gigantes. Que todo te funcione en una prueba de usuario no significa que todos los usuarios consideren lo mismo. Tendreis problemas pero si teneis las ideas claras sabreis solucionarlos. Iros a celebrarlo con unas cervezas y luego volver a pisar la tierra.
  5. Aceptación: Basicamente es ver la realidad: la aplicación hace lo que debe hacer. Es como un niño que empieza a andar; dale tiempo y date tiempo. Si ves las cosas con algo de perspectiva, seguro que habeis conseguido mucho. Y el negocio lo irá notando con el paso del tiempo.
En SoftAuction no nos resignamos; pensamos que el sector no debe ser como transitar por un camino doloroso sino que debe orientarse al éxito. El éxito de los profesionales y de los clientes en un contexto de respeto profesional.

lunes, 12 de abril de 2010

¿Como hacerlo bien?

Hoy estamos de lanzamiento. La semana del 12 de Abril de 2010 hemos empezado a publicitar SoftAuction como la plataforma dónde los profesionales del Sector de las Tecnologías de la Información interrelacionan con empresas para solucionar problemas de negocio. Y como estamos de lanzamiento, vamos a iniciar una serie de entradas en este blog que intenten comentar como se hacen las cosas bien; creemos (estamos seguros!) que en el sector existen muchos excelentes profesionales y tambien creemos que en el tejido empresarial existen muchas empresas serias con necesidades reales de mejoras en sus procesos de negocio. Lo único que hay que hacer es juntar las necesidades con la oferta. Y ser tan buenos profesionales como sabemos.

Entonces ¿por qué todo los ratios de proyectos son tan desastrosos? Intentaremos responder a esta pregunta al final de la serie. Por el camino, iremos contando, desde nuestra experiencia, como podemos hacer las cosas bien en este sector, como podemos recuperar el prestigio que hemos ido perdiendo en los últimos años pasando de ser un sector pujante que era tratado como una inversión a ser considerados un mal menor y ser etiquetados como un gasto a reducir y gestionar (palabra que ha perdido todo significado en castellano).

¿Nos sigues en esta aventura? Nosotros, sin vosotros, no tenemos sentido. Invierte unos minutos al día en comentar y que entre todos, aprendamos. SoftAuction es tu sitio de negocio.


¿Te atreves a cambiar el statu quo del sector de las Tecnologías?