Ir al contenido principal

Concursos Públicos: Una oferta ganadora

Últimamente me he encontrado bastante ocupado diseñando ofertas para concursos de la Administración Pública, más en concreto para un par de Consejerías de la Junta de Andalucía, para el Ministerio de Trabajo, y he ayudado a un compañero en algunas para Ayuntamientos.

He sacado algunas conclusiones al respecto. Quizás el título del post pueda resultar engañoso, porque no voy a dar las claves de una oferta ganadora. Más bien pretendo hablar de las claves que pueden hacer a tu oferta perdedora, si no las tienes en cuenta.

La primera criba para saber "si vamos o no vamos" es leer con atención el pliego, tanto en su parte administrativa-económica, como en la técnica. Se pueden descartar multitud de pliegos si exigen una certificación administrativa superior a la que tenemos, si exigen certificados de Calidad que no poseemos (en nuestro caso, con el AENOR ISO 9001, solemos tener bastante), o si por la redacción del pliego se puede detectar que este concurso ya está "cocinado". En nuestro argot, "cocinado" quiere decir que ya tiene ganador de antemano. ¿Cómo saber si un concurso ya está cocinado? este es un tema bastante complicado y que daría para escribir muchísimo, de momento lo dejaremos para otra ocasión. Solo destacaré que fijarse en los puntos valorables es una comprobación elemental aunque por supuesto, no es la única que hay que hacer.

De hecho, el estar "cocinado" es el primer motivo por el que no ir a un concurso. Hay otros motivos que si el concurso lo merece se pueden solventar formando UTE con otra empresa.

Uno de los apartados valorables que suelen tener los concursos de Informática es la metodología. Si el concurso es de sistemas o contiene lotes referentes a sistemas, debería aparecer metodología ITIL, si el concurso es de desarrollo, deberá aparecer Métrica v3. ¿Dónde encajan aquí las metodologías ágiles? pues creo que encajan de manera artificiosa, o directamente no encajan. Lamentablemente esta tendencia no ha llegado aun a las Administraciones Públicas. Así que:

- ITIL: Microinformática, Sistemas...
- Métrica v3: Desarrollo.

Hay que adecuar las metodologías a lo que ya hay en el Organismo (Consejería, Ministerios, Ayuntamiento...). Para esto evidentemente tienes que tener alguien "dentro" que te informe, o simplemente llamar, intentar convocar una reunión,... Este tipo de conocimientos se suelen valorar mucho.

Si el concurso es de desarrollo, hay que tener en cuenta las políticas de Software Libre (en el caso de la Junta de Andalucía, y muchos Ayuntamientos).

Un plan de calidad, una buena planificación, y afinar con las mejoras propuestas son detalles que no deben faltar en una buena oferta.

La elaboración de la oferta requiere mucha dedicación (casi 24x7), mucha concentración, y si hay alguien que te lleve todo el tema burocrático-administrativo, miel sobre hojuelas (es una barbaridad la cantidad de "papeleo" que te exigen, y por detalles absurdos te puedes quedar fuera, a no ser que sea subsanable). De un concurso a otro siempre hay puntos que mejorar, así que gracias a la experiencia adquirida cada vez las ofertas son mejores. Por otro lado, hay mucho de copia y pega en cuanto a clausulas de confidencialidad, presentación de la empresa...

También me gustaría hablar de la ley no escrita: "Por mucho tiempo que tengas, siempre habrá nervios y prisas de última hora". Esto es así. Es como en los exámenes de la Universidad, en los que tu estimas el tiempo que te queda para llevarlo bien preparado, por ejemplo una semana. Si te dieran una semana más, te seguiría faltando una semana para llevarlo perfecto. No te preocupes, no hay ofertas perfectas, pero es bueno que seas crítico con tu trabajo. La siguiente te saldrá mejor.

Podría dar muchos más detalles, pero creo que no procede que se hablen de ciertas cosas en un blog. Creo que con lo escrito os podéis hacer una idea sobre la licitación...

Comentarios

  1. Hola Alejandro. Leo hace algun tiempo tu blog y debo decirte que la mayoría de tus artículos me parecen muy interesantes.
    Con respecto a los concursos concinados... me pica la curiosidad por saber cuáles son los síntomas que pueden indicar que nos encontramos ante un "cocinamiento". Espero que publiques pronto algo al respecto.
    Por cierto, al hilo de las certificaciones que comentabas en el post, ¿tú cuáles crees que pueden ser las más útiles o valoradas?.
    ¡Un saludo y sigue así!

    ResponderEliminar
  2. En cuanto a la "cocina", todo lo que se puede decir en un blog público, ya está dicho.

    En cuanto a las certificaciones, ¿te refieres a las certificaciones administrativas de las empresas, las de calidad, o las que certifican conocimientos del personal?

    ResponderEliminar
  3. Ok, dejando de lado la "cocina" española, me refiero a las certificaciones de calidad y demás a nivel de empresa (como la AENOR ISO 9001 que mencionabas). Aunque también son interesantes (a otros efectos) las certificaciones del personal. De este último tipo,
    ¿tú consideras alguna especialmente recomendable?. Porque yo lo que sí tengo claro es que algunas de ellas no son más que meros papelitos incapaces de acreditar con solvencia ningún conocimiento concreto. Por poner un ejemplo te diré que es posible encontrar por Internet exámenes resueltos de muchas certificaciones Microsoft que luego, para vergüenza de de esta empresa, se repiten calcados en las siguientes convocatorias.
    Salu2!

    ResponderEliminar
  4. Yo considero interesante estas:
    Calidad: ISO 9000, 9001, 9002
    Medioambiente: ISO 14001
    Seguridad de la información: ISO 27001
    CMMI (distintos niveles)

    ¿Tener la ISO 9001 significa que tu empresa haga las cosas con calidad? Pues no, para mí la calidad es otra cosa. Pero este tipo de certificaciones pueden abrir puertas.

    En cuanto las del personal, hay multitud de certificaciones interesantes. Ultimamente están de moda la de ITIL Foundations v3, las de Java (Sun), Liferay... en fin hay muchas, y muchas de ellas carísimas. La administración les da bastante importancia, aunque bien es verdad que a priori no sabemos el nivel de aprovechamiento que ha tenido cada uno... pero estar certificado ya es un indicador a tener en cuenta.

    Un saludo.

    ResponderEliminar
  5. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  6. Como esta? soy lector de su blog,digame como podria comunicarme con ud?
    Me gustaria tener su orientacion,soy estudiante y ya me he documentado sobre las tecnologias para mi proyecto j2ee ya tengo decidido eso y ya he hecho pequeñas pruebas(ids,framework etc ...)
    Pero ahora quiero saber como estructurar de la mejor manera (talvez hay un standard) mi proyecto web, ya sea carpetas(arquitectura)espero no haber dicho incoherencias. muchas gracias de antemano
    mi correo es ae0719@gmail.com

    ResponderEliminar
  7. Hola. Estaba leyendo tus posts y me ha surgido una duda: en el proyecto de Venta en Gradas comentas que usaste Sql Server CE 3.5 para la aplicación cliente, pero también cuentas (o yo lo entiendo así) que los datos de ésta los consumías y los enviabas desde/hacia el servidor usando un servicio web. Entonces, ¿es realmente necesario usar Sql Server CE?, ¿qué te aporta?. Quiero decir que si podías recoger XML's desde el servidor con todos los datos necesarios para la aplicación (artículos, precio, stock, ...) y guardarlos en un DataSet local realmente no veo necesario almacenar dichos datos de forma persistente, ya que la aplicación simplemente podría consumirlos cada vez que fuera iniciada y refrescarlos cada X tiempo.
    Si estuviésemos hablando de que esos datos son modificados en la aplicación cliente y luego hay que sincronizarlos con la BD del servidor o que se tratase de datos de gran volumen entonces tendría sentido, pero en el escenario que tú planteas no termino de ver la necesidad del Sql Server CE. ¿Tú qué piensas?.

    Salu2!

    ResponderEliminar
  8. Buenos días eccho, es bastante sencillo, se hizo así por varios motivos, pero el más importante sería este:

    - Tu me hablas de escenarios ideales, y créeme que un campo de fútbol con 40000 personas, dista mucho de serlo. Pueden darse periodos de falta de conectividad, y los pedidos no pueden irse al limbo. Es decir, en el momento de hacer el pedido, un hilo se encarga de enviarlo en segundo plano. Por tanto se puede seguir realizando otro pedido, y si el hilo envía el pedido con éxito, el pedido se guardará en la base de datos local como enviado, y se notificará el éxito de la operación por pantalla. Si por el contrario, no se ha podido enviar (falta de conectividad), el pedido se guardará como no enviado, y se notificará, de manera que el operario pueda recuperarlo y reenviarlo... hay más casuística, pero creo que con esto ya se entiende.

    Un saludo.

    ResponderEliminar
  9. Hola Alejandro. Es muy cierto que el escenario planteado para la aplicación no es precisamente ideal. Aún así, cuando hablaba de no persistir los datos de la aplicación me refería también a los propios pedidos generados por el usuario (el camarero). La posibilidad que yo planteo es guardar temporalmente dichos pedidos empleando colecciones de entidades de negocio en memoria. Cumplen la misma función que la base de datos con la salvedad de que, evidentemente, se pierden al finalizar la aplicación. Tienen la ventaja, sin embargo, de que evitamos, en este caso concreto, hacer el mapeo objeto-relacional. Ello unido al hecho de no tener que acceder a una base de datos puede redundar en un mayor rendimiento así como en una estructura más sencilla donde la capa de acceso a datos únicamente la constituyen los métodos de acceso al servicio web.
    El resultado del escenario así planteado es que si se produjese, por ejemplo, una falta de conectividad el hilo encargado del envío del pedido al servicio web encolaría (o almacenaría en un colección o cualquier otra estructura de datos oportuna) el pedido fallido en memoria y notificaría fallo. Pudiendo luego el usuario acceder al mismo y reintentar el envío.
    Cierto es que no almacenamos permanentemente en la pda una lista de los pedidos correctamente enviados, pero dichos pedidos ya se encarga de almacenarlos el servidor que aloja el servicio web, ¿por qué almacenar redundantemente estos datos tanto en el cliente como en el servidor?.
    Desde mi punto de vista simplificar la capa de acceso a datos es siempre deseable, dado que las bases de datos crecen y ven mermado su rendimiento con el paso del tiempo, incluso un base de datos como SQLSCe.
    Para finalizar yo sólo contemplo 3 escenarios donde este planteamiento no es apropiado:
    -1º Se produce un excepción en la aplicación de la que no se puede recuperar y ésta se cierra, o bien un fallo del sistema -> en este caso se perderán todos los pedidos no enviados correctamente.
    -2º Se agota la batería de la pda.
    -3º El usuario cierra accidentalmente la aplicación.

    Un saludo.

    ResponderEliminar
  10. Hola eccho,

    Coincido plenamente contigo en los escenarios para los que sería necesario persistir la información de pedidos. Bien es cierto, que el tercer escenario es bastante complicado que se dé, porque se eliminó de la interfaz la "x" que en Windows Mobile minimiza la aplicación, y para salir hay que hacerlo controladamente y por el elemento de menú.

    Durante el proceso de pedido, y por motivos de eficiencia, se trabaja con Hashtables, pero dado que el cliente abona su pedido tras realizarse, esta información debe quedar persistida en algún "sitio". No se puede perder si nos quedáramos sin batería, o se quedara colgado Windows Mobile. En el caso de que no haya conectividad, este "sitio" debe ser la base de datos local en el dispositivo. Además, en el caso de que no hubiera conectividad, esta información no sería redundante, puesto que solo se encontraría en el dispositivo.

    Es verdad que los pedidos enviados correctamente si son información redundante (en cliente y servidor). Podríamos eliminarlos automáticamente una vez recibimos confirmación del servidor, pero optamos por mantenerlos en base de datos (el gasto ya está hecho), y así proporcionarle al usuario el listado de pedidos (exitosos o no) que ha realizado durante el partido (aunque haya agotado la batería, se le haya quedado colgado Windows Mobile, o haya cerrado la aplicación).

    Por otro lado, la aplicación contempla la regeneración de la base de datos del dispositivo. Cosa que recomendamos que se haga antes de cada partido, ya que no tiene sentido tener almacenados pedidos de partidos anteriores. Podría haberse hecho de manera desasistida, pero optamos por darle la libertad al usuario de hacerlo cuando este desee. En este sentido no nos gusta ser demasiado intrusivos. De esta forma evitamos problemas de rendimiento como consecuencia del crecimiento de la base de datos del dispositivo.

    Por último comentarte que no se usa ningún ORM para el mapeo OO - relacional en el dispositivo (en el servidor se usa IBatis, que no es exactamente un ORM, aunque nos soluciona el problema). Así que el mapeo se realiza con métodos de forma "manual". Dado que solo se persisten los pedidos, y la configuración, no es demasiado trabajo.

    Un saludo.

    ResponderEliminar
  11. Menuda se está montando con el tema de ITIL y los exámenes de Service Manager versión 2 de EXIN y APMG, que llevan 2 años seguidos repitiendo el mismo examen,

    Examen de EXIN:


    1. http://exin-exams.es/~/media/Extranet%20Documents/Exams/Exam%20Program/it%20service%20management/it%20service%20management%20service%20delivery/Sample%20exam%20ITSD%20European%20Spanish%20incl%20%20case%20A589%201%200408%20pdf.ashx

    Examen de APMG:


    =Responsabilidades de un gestor de cambios
    =Dificultades de no contar con la G de cambios
    =Costes de no terner la G. de cambios
    =Beneficios del proceso de G. de la Configuracion
    =Como comprobar las quejas de los clientes del Centro de Servicios
    =Beneficios de consolidar los centros de servicios de Jedah y Yihad
    =Criterios para clasificar e investigar problemas
    =Dependencias entre la CMDB y G. de problemas
    =Pasos para implantar una suite informçatica
    =Alianzas necesarias para diseñar el plan de continuidad en la fase de planificaciçon inicial
    =Etapas de ITSC y las salidas que genera
    =Documentos que se enconttrarçian en una auditoria del proces de Gestiçon de niveles de servicio
    ´=Problemas de una organizaciçon sin SLA
    =Como introducir la ´G de la demanda
    =Dificultades de usar sçolo recursos monetarios para deshacerse de los problemas de capacidad
    =Como medir el ROI de una ONG
    =Elementos clave de un modelo de costes
    =Contenidos del plan de disponibilidad
    =A quien involucrar para analizar la interrupciçon del servicioo ¿SOA
    =Beneficios de diseñar para la disponibilidad.

    Dirección de correo donde te lo dan todo:

    Sapetcosmv2@gmail.com

    ResponderEliminar
  12. Muy sensatos los comentarios sobre Metodologias. Tambien estoy de acuerdo en que has dicho todo lo posible sobre "la cocina" de un pliego, pero no estaria mal hacer una sentada (o privado) y poder contar más en "petit comite"... Habria mucho que contar.

    Otra cosa: me gustaria, con toda humildad, comentarte la existencia de un nuevo sitio web para la relación entre profesionales del sector de las Tecnologías y las empresas con objeto de facilitar relaciones de negocio. www.softauction.es
    Si te hemos hecho perder el tiempo, nuestras disculpas por adelantado.

    ResponderEliminar
  13. Estoy intentando conseguir el examen del APMG pero la dirección de correo que proporcionan no contesta, podría obtenerlo de algún otro método.
    Gracias.

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas. Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla. Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que

Portales Colaborativos I

El concepto de portal convencional supone una plataforma donde se ofrecen contenidos, funcionalidad (búsquedas, inscripciones,...), publicidad... Un Portal Colaborativo está influenciado por la filosofía Web 2.0: - Los usuarios saben donde encontrar la información (está centralizada). Dependiendo del perfil se le mostrará una información u otra. - Aúna los procesos de negocio de las organizaciones. - Se fomenta el trabajo compartido Online. - En definitiva, los usuarios son lo más importante. En Soltel andamos enfrascados en el diseño y desarrollo de un Portal Colaborativo, que nos permita agilizar ciertos procesos y por supuesto, estamos trabajando para que "no se quede" en la empresa. Para ello, hacemos hincapié en la abstracción, modularización y en los servicios generales que debería tener para poder convertirlo en producto. ¿Qué debería tener un portal colaborativo? - Un repositorio centralizado de todo tipo de documentos. Punto de acceso único a la información. - Agend

¿Por qué Yii Framework?

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos. Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes. En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja. Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en