Presentaciones varias

En el sitio web de Parleys encuentro presentaciones interesantes como las de JavaPolis 2007. Entre ellas podemos ver:

- Project Anti-Patterns: How to make your project fail. Presentación que explica los secretos para hacer fracasar tu proyecto miserablemente, ya seas cliente, gerente de cuenta, jefe de proyecto, arquitecto, diseñador, desarrollador o "tester".
- Scrum in Practice for non-believers. No se puede decir que los presentadores sean muy amenos, la verdad, pero al menos explican su experiencia en el uso de Scrum.

¿Has aplicado alguna vez los "anti-patrones" explicados en la primera presentación? ¿Cuánta gente conoces en tu empresa que los aplique habitualmente?

Diez diapositivas para solicitar inversión en software

Hace ya unos días hablaba de un portal de vídeos de formación gratuitos que enlaza a diferentes sitios web. Uno de ellos es el de la Universidad de California Santa Barbara, donde podemos ver los vídeos de su programa de gestión de la tecnología.

En el vídeo adjunto (una hora) Ann Winblad, co-fundadora de Hummer Winblad Venture Partners, explica a los alumnos el tipo de empresas que financian, la diferencia entre disrupción e innovación, la necesidad de detectar esos elementos disruptores y, al final, explica las diez transparencias que esperan que se les presente cuando se les solicita financiación, especialmente en temas software. Sinceramente, muy entretenido.



Estas diez transparencias son:

1. Resumen ejecutivo. Debe explicar el problema que se intenta resolver y la ventaja diferenciadora. Ha de expresar cuál es la misión y muchas veces sirve para capturar la atención de los inversores.
   
2. Equipo. Quiénes forman el proyecto, su pasado y capacidades. No se financia un producto, financian a la gente que compone el equipo, el proyecto.
   
3. Análisis del mercado. Tamaño, posición y competidores. Explicar por qué tienen que invertir, que el mercado es grande, no sólo un nicho.
   
4. Ventaja competitiva principal. ¿Por qué se tiene dicha ventaja y por qué ahora es el momento de llevarla adelante?
   
5. Supuestos clave (<5 ó 6) que se han tomado en cuanta para asumir que el mercado es grande y el proyecto viable
6. Clientes (potenciales y referencias). Asumir el rol del cliente, si es posible haber hablado antes con ellos. ¿Cómo usarían los clientes el producto? Si se tienen ya clientes, entonces es para lucirte.
   
7. Plan de producto
   
8. Plan de ingeniería. Información técnica de cómo se llevará a cabo el desarrollo del mismo.
   
9. Modelo de ventas y resumen de márketing. ¿Cuánto pagarían los clientes? ¿Cómo se va a llevar al mercado? ¿Qué tipo de promoción se va a usar?
   
10. Modelo de negocio/Financias/flujo de caja. Desarrollar el plan de operaciones. Explicar por qué merece la pena invertir, el margen bruto, beneficio, revenue... Si no eres capaz de hacer esto, nunca recibirás financiación.
    

¿Has solicitado alguna vez inversión? ¿Contemplaste todos estos puntos? ¿La conseguiste?

Ideas e innovación abierta

El otro día descubría una iniciativa llamada Ideas4all, una especie de portal donde pretenden reunir un millón de ideas, que proporcione gente de todo el mundo. El tipo de ideas es de lo más variopinto y parece más la típica tormenta de ideas llevada a escala multinacional, pero sin centrarse en un problema concreto. Eso sí, puedes definir también problemas para que la gente sugiera soluciones, lo cual es interesante porque en algunos casos el problema o la solución puede mostrar nichos de mercado como la de encontrar un despertador individual para dormitorios compartidos.

Lo que más me ha llamado la atención es el tema de lo que puedes recibir a cambio. En principio, básicamente reconocimiento. Se pueden licenciar las ideas como Creative Commons Attribution o con una licencia en la que "teóricamente" puedes retener la propiedad intelectual, aunque te aclaran el las FAQ que no evita que alguien pueda copiarla y te dan consejos al respecto.

Por otro lado, hablaba el otro día en un comentario sobre el Observatorio Tecnológico de TID que se basa en la idea de innovación abierta descrita por Chesbrough mediante dos actividades: facilitando la llegada de ideas del exterior y haciendo que las ideas que no se puedan aprovechar internamente en TID en la actualidad se encaminen hacia nuevos mercados. En ese entorno se encuentra el blog La Cofa sobre vigilancia tecnológica.

Encuentra las cinco diferencias...

... entre el perfil de la persona que buscan las empresas y los estudiantes que salen de las carreras técnicas ICT.

Leyendo un artículo de Businessweek al que llego a través del Blog Salmón sobre los estudiantes de negocios en Reino Unido, me acuerdo de una charla que escuché hace unos años en unas conferencias en las que hablaba de por qué se había reducido el número de estudiantes de informática en EEUU.

Una de las razones que daba era el incremento de seguridad en su país, que había provocado una reducción del número de estudiantes extranjeros que iban a estudiar. Sin embargo, lo que realmente quería comentar era las otra razones:

1. Decepción de la gente que trabaja en el sector, que se transmite a los futuros estudiantes. Una de las razones para esta decepción es la falsa sensación recibida por los estudiantes a lo largo de la carrera de cómo se trabaja en proyectos ICT.
   
   
   
   • Percepción de que se está presente en todas las fases del proyecto (muchas veces se da sólo soporte o se entra a medio proyecto).
     
   • Percepción de que el trabajo que uno completa no es necesario mantenerlo, ni nadie va a tener que leerlo, por lo que no tendrá que hacer mucho esfuerzo en ello (recomiendo leer Romario vs Makelele)
     
   • Percepción de que no se tendrá que utilizar el código de otros.
     
   
   
2. Falsa imagen del informático transmitida en los medios. Y además negativa. Porque si fuera tipo Urgencias o Scrubs con los médicos o CSI con los criminalistas probablemente se apuntarían muchos más. Pero las películas presentan a los informáticos como gente generalmente asocial, raros, empollones, rebeldes o "piratas" que no se relacionan con otros y que tienden a dedicarse todo el tiempo a sentarse en frente del ordenador. Esto atrae a gente con ese perfil.
   

Y continuaba diciendo, ¿qué es lo que las empresas buscan? Gente sociable, que sepa trabajar en equipo, que contribuyan y sepan escuchar y que no se salten las normas continuamente.

La verdad es que hay cosas en las que no coincido, pero me parecieron reflexiones interesantes.

¿Es cierto que el perfil de los informáticos y telecos que conocéis es el que presentan las películas? ¿Tiene la culpa el cine de la imagen de los informáticos? ¿Hay una diferencia real entre las cualidades de los estudiantes de informática y telecomunicaciones que salen de nuestras universidades y lo que esperan las empresas?

Sopa de Siglas

Preguntándome sobre las diferentes descripciones del puesto de CIO (lo traduciré como Director de Sistemas y Tecnologías de la Información, para intentar seguir un poco los consejos de Pedro respecto al uso del castellano) dependiendo de la empresa en la que se trabaje, rápidamente me encontré buscando en Google una imagen que representara responsabilidades (gestion de personas, proyectos, proveedores, definición de estrategia ...) y tecnologías/procedimientos.

Respecto a esto último, las tecnologías y procedimientos, una vez se pasa una primera clasificación más general, enseguida empiezan a aparecer siglas y más siglas: ERP, CRM, SRM, BI, CMI, BSC, EIS, DSS, SEO, SEM, PPM (PLM), SSO, A4C (AAA), ECM (CMS), SOA, BPM, EAI, ESB, B2B, B2C, DBMS, ASP, VoIP, QoS, KPI, ITIL, PMI ...

Y eso sin entrar en "frameworks" (lo siento, no me gustan las traducciones de esta palabra) de programación o protocolos porque si no: J2EE, JSF, PHP, SIP, SOAP, REST, LDAP, XML, WML, VXML, XSL, SQL, EAP, SMS, MMS, RADIUS, VPN, TCP ...

Lo peor es cuando te encuentras con siglas que significan varias cosas, como ASP. Me acuerdo a una persona de Telefónica hablando a un antiguo compañero mío sobre las posibilidades de utilizar un producto en un entorno ASP (Application Service Provider) y él, programador como era, pensando en qué tenía que ver ASP (Active Server Pages) en todo esto si el producto estaba programado en Java.

¿Habrá una profesión en la que se usen más siglas que en la nuestra? ¿Te has sentido alguna vez perdido en una conversación con temor a preguntar algo? ¿Tienes alguna anécdota relacionada con siglas?

Business Case I: Razones, Opciones, Beneficios

El otro día me sorprendía (en realidad no) al hablar con un compañero de carrera y observar la cantidad de proyectos que se desarrollan sin un Business Case en algunas empresas.
Algunos se preguntarán, ¿por qué es tan importante tener esta información? Voy a intentar dar algunas pistas al respecto.

Lo primero que hay que entender es que el Business Case es un instrumento vivo que evoluciona a lo largo del proyecto y que se ve afectado por circunstancias internas o extenas al mismo. Debido a su contenido, debería ser el punto fundamental que haga decidir en cada etapa del proyecto si es conveniente seguir con él o si es necesario abortarlo.


Para entender mejor estas afirmaciones voy a comentar parte de su contenido brevemente en esta entrada, para completarlo en otras entradas posteriores.

El primer elemento que no debe faltar dentro del BC es el conjunto de razones que llevan a realizar el proyecto. Por ejemplo, la necesidad de gestionar mejor a los clientes debido a un conjunto de quejas en aumento o a una previsión en el aumento del número de estos. Estas razones ofrecen una base para entender por qué se sugirió el proyecto en un principio.

En segundo lugar se encuentran las opciones. ¿Qué acciones podemos tomar para atender a esa razón, problema o deseo inicial? Prince2 sugiere que siempre se considere la opción de "No hacer nada" y utilizarla como la base con que comparar el resto de opciones. En el ejemplo, ¿qué pasaría si no hiciéramos nada? ¿Se resentiría la atención a los clientes? ¿Perderíamos clientes? Frente a esta opción se plantearán todas las que se hayan considerado, indicando la elegida y el porqué de la selección. En nuestro caso podríamos plantear hacer "reingeniería de procesos", instalar un CRM comercial mediante consultoría externa, desarrollar nuestra propia solución software o una combinación de éstos.

Otro aspecto fundamental es la definición del conjunto de beneficios que se esperan del proyecto. Estos beneficios han de ser expresados en términos medibles (cuánto y cuándo) estableciendo la situación actual para poder realizar la comparación cuando finalice el plazo establecido. En el proyecto que estamos comentando algunos beneficios (no necesariamente compatibles) podrían ser "mantener el 95% de los clientes actuales (frente a un 20% estimado de pérdida si no se hace nada) durante los próximos dos años", "reducir un 30% el número de quejas a finales de año con respecto a las actuales", "incrementar los clientes totales en 10.000 manteniendo el número de reclamaciones en el porcentaje actual". Estos valores medibles o procentajes pueden incluir un margen de variación o tolerancia en el beneficio.

Los riesgos que afronta el proyecto y que pueden afectar al BC se pueden incluir también en el mismo, dejando los detalles de su resolución a otros documentos del proyecto.

Evidentemente, los elementos económicos serán fundamentales dentro del BC y, por tanto, los trataré en otra entrada.

¿Realizas un BC de todos tus proyectos?

Marca 2.0

Llego a través de una entrada del blog de navegapolis.net a un libro electrónico que explica de una forma muy metafórica cómo establecer relaciones con tus clientes. El libro se llama 21 Posturas para hacer el amor con tus clientes. Guía para entender el branding en un mundo 2.0.

Y tú, ¿qué postura practicas más?

Más innovación corporativa

El otro día hablaba sobre la innovación corporativa mediante la generación de concursos o comunidades (algunos lo incluyen en el crowdsourcing). En relación a este tema, Businessweek publicaba en este artículo información sobre los premios de Innovación de Cisco con un total de 250000 dólares al equipo ganador y la oportunidad de crear una unidad de negocio. Es interesante leer las precauciones legales y de recursos humanos que se tienen que salvar en este tipo de acciones.

Yo me quedo con esta frase del artículo: We got more ideas in two months from this mechanism than our internal site did in about a year and a half.

¿Creéis que empresas tecnológicas como Telefónica o Gamesa y otro tipo de empresas más tradicionales como bancos o constructoras se beneficiarían de este tipo de medidas? Lo más cercano que he visto en Telefónica es el intento de crear una comunidad open source (Morfeo) cuyo éxito o difusión no tengo muy claro o la iniciativa Tú marcas tendencias, de las que no he visto una gran promoción ni llego a ver qué tipo de gente intentan involucrar.

Combinando metodologías

Existen numerosos artículos en la red sobre cómo combinar metodologías de gestión de proyecto tradicionales más centradas en el control tipo Prince2 con metodos Agile. Hoy he encontrado un libro que habla sobre cómo trabajar con Prince2 y DSDM. DSDM es una metodología creada en Gran Bretaña a finales del siglo XX.

Lo cierto es que soy bastante escéptico en relación a este tipo de libros. ¿Habéis leído alguno de este estilo que creáis interesante recomendar? ¿Combináis técnicas de gestión tradicional con métodos Agile en vuestros proyectos?

Arquitectura empresarial y Zachman

John Zachman desarrolló un marco de trabajo para la arquitectura empresarial llamado Zachman framework que ha sabido explotar creando su propia empresa de consultoría - ZIFA.

Zachman framework se resume de forma clara en este PDF que se puede descargar de la web de ZIFA. Básicamente, se utiliza una representación bidimensional. En un lado se presentan las diferentes perspectivas del problema vistas por distintos actores que participan en la definición de la arquitectura empresarial:

• El planificador. Perspectiva contextual observando el ámbito de la empresa.
• El propietario. Perspectiva conceptual que se presenta en el modelo de negocio.
• El diseñador. Vista lógica ofrecida en el modelo del sistema.
• El constructor. Modelo tecnológico incorporando la vista física.
• El implementador. Con la representación detallada.
• El trabajador. Representa el funcionamiento de la empresa.

En el otro eje se representan el Qué (Datos), Cómo (Funciones), Dónde (Localizaciones y Red), Quién (Gente), Cuándo (Tiempo) y Por Qué (Motivación).

Esta visualización en forma de cuadro permite alinear la visión del propietario con el resto de visiones, modelos y acciones que se llevarán a cabo para construir la arquitectura de la empresa. No es necesario desarrollar todos los modelos o rellenar todas las celdas, dependerá de los objetivos buscados en cada caso.

Aparte de la sincronización de modelos, otra de las ventajas es poder localizar qué información es necesario presentar a cada actor dentro de la empresa y en qué formato.

Underachievers

Sí, lo sé, lo siento, pero no he podido evitar escribir una entrada sobre la selección española de fútbol. Aunque tenga que ver con la gestión de equipos.

Aquí en Reino Unido, cada vez que hablaban de la selección española comentaban que quizá éste era su momento y que eran una panda de "underachievers" (con menor rendimiento del que se espera de ellos) crónicos. Con la coletilla de que quizá podrían hacer algo ahora que algunos de sus jugadores participan en la Premier League.

La cuestión es que, analizando las razones por las que la selección de España ha podido ganar la Eurocopa, aparte de la posibilidad esgrimida por algunos comentaristas ingleses se podrían encontrar las siguientes (¿cuál crees que es la que más ha influido?):

- Una buena gestión de de las personas realizada por el Line Manager Luis Aragonés.
- Una buena selección del equipo buscando que las personas fueran las adecuadas para las labores a realizar y colocándolas en los lugares correctos.
- Un equipo entusiasmado por un proyecto y que se cree capaz de conseguirlo.
- Un buen ambiente de trabajo sin personas que provocaran enfrentamientos internos.
- Un jefe de proyecto que lleva adelante el proyecto y no se deja influir por terceros ajenos al mismo.
- Sugiere otros...

En los proyectos que hayáis gestionado con éxito, ¿qué razón principal creéis que fue la que más ayudó al resultado final? ¿Cómo generáis entusiasmo en los proyectos?