En este año, por ejemplo, Google Chrome comenzó el año con la versión 10.0, y a día de hoy ya van por la 16.0. Es decir, que van a un ritmo mayor de 2 liberaciones por mes.

Esto parece que le ha sentado como un jarrón de agua fría a la comunidad de Firefox, que se ha comenzado a poner las pilas y, han anunciado un plan rápido de liberaciones, teniendo en cuenta de que Firefox salió en febrero de 2004 (ya como Firefox), ha tenido un ritmo de liberación mayor cada dos años… siendo las últimas liberaciones (3.5 y 3.6) menores y distanciadas en el tiempo por un año. A partir de la versión 4.0, comenzó la carrera siendo el ritmo de liberación cada dos meses. Por lo que hemos pasado de tener en marzo la versión 4.0, a estar ahora en octubre y recibir la versión 7.0.

Podríamos decir que esto es inmejorable para los usuarios de ambos navegadores, ya que esta carrera hace que las características de los navegadores, así como sus mejoras de rendimiento y demás, crezcan de forma que navegadores mantenidos por empresas como Internet Explorer, Safari u Opera, se queden fuera de juego. Pero también plantea un problema para los desarrolladores, que es mantener los desarrollos web para todas las versiones en uso de esos navegadores.

En mi opinión, Google Chrome ha mejorado en este sentido obligando al usuario a actualizar el navegador, incluso haciendo una descarga de la nueva versión en background y realizando la auto-instalación en el siguiente inicio del navegador, por lo que asegura que el navegador se mantiene siempre en la última versión y evita problemas para los desarrolladores de tener que mantener versiones antiguas de Chrome.

Firefox en cambio, avisa únicamente al usuario (al menos de momento) de que hay disponible una nueva versión del navegador, y que si se quiere actualizar, se entre en un semi-asistente que lo descarga e instala. No obstante, este tiempo que se toma y el hecho de tener que reiniciar el navegador no creo que le guste a la mayoría de los usuarios, por lo que es normal que aún, en estadísticas de uso, Firefox se vea dividido en usuarios, según cuándo se bajaron e instalaron el navegador.

Esperemos que en un futuro esto se estandarice de alguna forma, para que tanto uno como otro navegador, permitan hacer las tan frecuentes actualizaciones que están teniendo, de forma fácil y transparente para el usuario.

Tras casi la mitad de lectura, en un solo día, puedo decir que, bueno, hay de todo un poco, Lorente da unas buenas clases de experiencia en algo que ha visto y vivido tanto como es la vida, y deja sus conclusiones, acerca de situaciones vividas que, ante los ojos de algunos pueden ser irrelevantes, y ante otros ojos, pueden ser la respuesta a muchas dudas que se planteaban. En mi caso, después de otras lecturas, encontré algunas ideas muy buenas, y otras, pues lo normal.

Se agradece el detalle de escribir el libro directo al grano, sin rodeos y contando las experiencias directamente, resumido al máximo posible para transmitir la idea base de forma clara, y sin perder significado.

¿De qué estábamos hablando? … ¡El triángulo!

Bueno, después de haber hecho un poco la publicidad … decir que una de las ideas que más me ha llamado la atención… se podría decir que vi la luz en el momento que la leí, es la del triángulo del éxito, y el triángulo del fracaso.

Imaginando nuestro cuerpo, y un triángulo, de modo que, en el caso del éxito, la cúspide coincide con la cabeza, y la base con la entrepierna. Mientras que en el caso del fracaso, la base corresponde a la cabeza y la cúspide a la entrepierna. El símil, nos viene a decir que, cuando queremos algo, cuando luchamos por montar una empresa, hacer un proyecto, encarar unos estudios… todo lo que nos proponemos, tiene un posible éxito y un posible fracaso.

El éxito es la mezcla de, una sola idea, un solo objetivo (la cúspide), un buen olfato y pasión (zona intermedia) y muuuuuchos huevos, dicho de forma coloquial y algo ordinaria. Esto es lo que hace que las ideas funcionen. Mientras que, lo contrario, muchas ideas (base), olfato y pasión (zona intermedia) y pocos huevos, es la receta del desastre.

Entonces, ¿¡¿cómo triunfo?!?

Pues eso, teniendo en mente que una idea, un objetivo es lo único que se tiene que tener en mente para poder consguirlo y no desviarse. Pasión y olfato para acercarse a las oportunidades. Mucho, pero que mucho coraje y valor.

Criticando su estilo

Es curioso que gente como Damien Katz (creador de CouchDB), o Toni Arcieri (creador de Reia) hayan sido de los primeros (o al menos los que he encontrado) que hayan arrojado una piedra en contra del lenguaje que eligieron para desarrollar elementos que han sido bastante respetados, apoyados y usados.

En este aspecto, otros como Yariv Sadan, han defendido y reconocido algunos de estos comentarios y, tras leer a unos y a otros, me queda la pregunta de, ¿realmente han entendido para qué sirve Erlang?, ¿qué hace y cuales son sus potencias?, ¿cómo sacarle el máximo provecho así como programar orientados a la concurrencia?

Crítica a la sintaxis

Lo primero que critican de Erlang es su sintaxis. Recuerdo la primera vez que vi el lenguaje C, después de haber programado en Basic, Pascal y Modula-2 que dije… ¡qué raro! y ya ni digamos de cuando unos años más tarde comencé a ver Perl…

La sintaxis C-like, como dicen muchos, es muy extendida, pero no es nada comprensible para una persona que comienza desde cero. Niklaus Wirth desarrollo por esto mismo lenguajes como Pascal, para que sirviesen de aprendizaje al modo pseudocódigo. Un código que nada más leerlo, se entienda.

Erlang, en cambio, sigue una metodología más como Prolog, está orientado al desarrollo de funciones matemáticas, por ello, la función tiene una conclusión (->) para su comienzo y termina con un punto final. Cada elemento dentro de la función o expresión matemática se separa por comas, y todo es funcional, es decir, todo elemento en Erlang hace algo y DEBE retornar algo, incluso las estructuras condicionales, por eso tiene la forma que tiene.

Tipos de datos: registros y cadenas de caracteres

Los registros, son a nivel de preprocesador: tuplas. Esto quiere decir que funciones del tipo record_info no existen realmente, por lo que no se pueden emplear variables para pasarle a esa macro y queda el espectro del uso de los registros algo limitado. No obstante, hay algunos trucos que se pueden emplear y existen para paliar esto, en caso de que se requiera/necesite.

Otro de los problemas, con los tipos de datos, son las cadenas de caracteres, las cuales son listas de enteros. Esto no debe de extrañarnos, ya que en todos los lenguajes son listas (o arrays, o vectores) de bytes. En lenguaje C, por ejemplo:

char c[] = "Esto es una cadena";
char d[] = { 'E', 's', 't', 'o', 32, 'e', 's', 32, ..., 0 };
 
printf("%s\n", strcmp(c, d)==0 ? "true" : "false");

Esto nos dará verdadero, ya que ambas son listas de bytes, al igual que en Erlang podemos ver algo parecido con las listas de enteros:

[100,111,103] == "dog".

Lo cual también retornará verdadero.

Rendimiento: Churras con Merinas

Realmente, al leer el artículo de Toni, cuando llego al punto que dice: Erlang sucks at managing memory; habla de una comparación entre Erlang y Azul Vega, un procesador de 54 cores optimizado para ejecutar la JVM.

Un programa con ese procesador y esa JVM, NO se ejecutaría de forma distribuida, realmente, ya que solo se distribuyen las tareas posibles e internas de la JVM entre los cores, en tanto y en cuanto se puedan distribuir estas tareas. No obstante, no está diseñado para conectarse con otros nodos, por lo que NO es escalable. Además, solo tiene cuatro canales para acceso a memoria, por lo que, 27 máquinas de Pentium IV con HyperThreading podrían hacer ese mismo trabajo con Erlang… y aún así aún podríamos poner más hierro a bajo coste para seguir escalando y mejorando el rendimiento del software desarrollado.

¿Es un lenguaje de propósito general?

Erlang fue creado para entornos en los que hubiese que desarrollar software con alto grado de concurrencia, esto lo hace ideal para entornos servidores de cualquier tipo, y actualmente, para los escritorios modernos, donde los programas se ejecutan de forma concurrente, claro.

¿Elrang puede desarrollar web? Sí, ejemplos como ChicagoBoss, o Erlyweb, o Nitrogen lo atestiguan. ¿Erlang puede desarrollar aplicaciones de escritorio? Sí, ejemplos como Wings3D dan crédito de ello. ¿Erlang sirve para desarrollar aplicaciones de servidor? ¡Claro!, para eso fue creado.

En mi opinión, si PHP tiene esa denominación y es un lenguaje de marcas, Erlang DEBE de tenerla

Asignación única… ¿por qué?

Para trazar mejor los códigos, claro, y porque bien pensado, un lenguaje funcional no requiere del uso de tantas variables, por ejemplo, tal y como decía Damien Katz en su artículo, tienes este código:

f(X) ->
  X1 = foo(X),
  X2 = bar(X1),
  baz(X2).

Este código, bien escrito, sería:

f(X) ->
  baz(bar(foo(X))).

¿Quieres agregar logs para que se vean en el cambio de funciones y no los quieres poner dentro de las propias funciones, sino entre las llamadas… pues puedes hacerlo con otras funciones:

log(Caller, X) -> io:format("~s: ~p~n", [Caller, X]), X.
f(X) ->
  log("BAZ: ", baz(log("BAR: ", bar(log("FOO: ", foo(X)))))).

Realmente no es complejo si se escribe y ordena el código de forma adecuada… en otros lenguajes, como por ejemplo C, se pueden escribir cosas como esta:

char *s = "Parsea la cadena";
int size;
for (int i=0, size; s[i]!='\0' && i<100; i++, size++)
  ;

Otros códigos en Perl dan incluso hasta más miedo… pero es como siempre se dice… depende del programador.

El desarrollo en sí

Lo que creo que no se entiende, es que el desarrollo en Erlang, como tal, no es ni escalable, ni redundante, ni aprovecha todos los núcleos y procesadores de las máquinas, así como el resto de núcleos que estén conectados. El hecho de que se pueda aprovechar la forma en la que Erlang fue diseñado, es desarrollar el software de forma concurrente. Con los patrones adecuados.

Por ejemplo, Erlang puede, en un solo nodo, ejecutar casi 2 millones de procesos concurrentes. Esto quiere decir que, cada tarea que haya que realizar, debería de correr en su propio proceso, y este proceso es el que se lanza en el núcleo, procesador y nodo que corresponda. Como cuando se desarrollaba en PVM o MPICH.

Emplear los patrones de OTP es esencial para sacar el máximo provecho de la arquitectura de Erlang, y el crear manejadores de eventos, máquinas de estos, memorias compartidas a través de servidores, etc. debe de realizarse, necesariamente a través de los mecanismos que aporta Erlang.

Si se emplease Erlang para hacer llamadas a Mnesia, desde cualquier parte del código con las llamadas dirty y generando un nuevo proceso por cada petición aislada, tendríamos un programa que puede tiene potenciales errores de concurrencia, y que no aprovecha los nodos que tenga configurados y conectados el sistema.

Conclusión

Me parece muy poco profesional escribir este tipo de artículos, tanto para Tony como para Damien, en los que ponen una serie de circunstancias poco contrastadas y debidas al bajo conocimiento del lenguaje y, precisamente ellos, que han desarrollado grandes herramientas en este lenguaje.

Java, igualmente, es un gran lenguaje, pero como el mismo Tony comenta, requiere de que la JVM cumpla la especificación RTSJ y, en las comparaciones, por ejemplo, hablan incluso de que habría que adquirir un hardware especial para poder desarrollar algo parecido a lo que Erlang hace en cualquier arquitectura, creo que son muy poco objetivos.

No obstante, hay personas que no pueden permitirse esas certificaciones o no han podido obtener ningún título concreto y, sin embargo, podrían tener el nivel de experiencia y conocimientos requeridos, es el ejemplo de los autodidactas. ¿Cómo podemos evaluar a unos y a otros en igualdad de condiciones?, ¿cuál es el más adecuado para el puesto?

Procesos de selección

Lo primero, es que, habiendo pasado por muchos procesos de selección durante los tiempos en los que he buscado trabajo, y haciendo igualmente esas entrevistas a personas que entran a trabajar bajo mi mando, me doy cuenta de que, entre las cosas que se buscan a la hora de realizar una entrevista de trabajo, además de una formación que cubra las necesidades de la empresa, es también la actitud de la persona y su coherencia con el resto del equipo.

Vale, ahora, además de comprobar si tiene los conocimientos concretos para el puesto, agregamos otra duda: ¿cómo sabemos si encajará con el equipo?, ¿cómo sabemos si se podrá crear un equipo que en trabaje en sinergía?

Más o menos como comentaba en el post Afinidad y Perfiles.

La excelencia

Recientemente recuperé unos emails del foro de agiles, donde me encontré un comentario que me dió mucho que pensar:

El último libro de los Poppendieck cita estudios que indican que la
diferencia entre un mal (lo que sea) y un (lo que sea) mejor del mundo, es
10000hs de práctica dirigida. (lo que sea) puede reemplazarse por pianista,
programador, etc. Esto es, alrededor de 10 años de 20 hs semanales.

– Juan Gabardini

Con esta información, podemos llegar a la conclusión de que, con un período de formación concreto, con una supervisión (o en caso de los autodidactas con motivación), es posible conseguir que cualquier persona consiga unos conocimientos concretos.

Una de las formas de comprobar que estos conocimientos que dice tener la persona son los adecuados para la empresa es a través de las pruebas que suelen realizar empresas de tipo head hunter para catalogar de forma adecuada, conforme a lo que se busca, a cada persona.

También hay certificaciones reales, las que guían al alumno a un conocimiento concreto de forma teórico-práctica y ofrecen una serie de prácticas para afianzar esos conocimientos. No obstante, si no se trabaja en ese campo o pasan más de seis meses al término de los estudios, se puede considerar que el aspirante tiene una base, más que un conocimiento concreto.

Conclusión

Por tanto, si buscamos a una persona para un puesto concreto, nos corresponde hacer las pruebas pertinentes o solicitar los títulos y/o certificaciones concretas, así como analizar que la persona tenga un perfil afín para el resto de trabajadores del grupo.

En cambio, si lo que buscamos es trabajo a través de ir a entrevistas de trabajo. Lo mejor será hacerse con títulos y/o certificaciones, así como solicitar que se haga una prueba para que se vea lo rápido que nos podemos integrar en el trabajo en sí. Las aptitudes y actitudes de trabajo en equipo también serán muy importantes.

Ejemplo de procrastinación: El Pintor

Pongamos como ejemplo que haya pintores que cobren por horas en lugar de por metros pintados o por trabajo completo a realizar. Si un pintor tiene que pintar una pared de 20 metros cuadrados, para la cual sabe que puede tardar unas 2 horas, puede que trabaje una hora, pare para tomar algo, prepare de forma calmada y lenta su equipo, y trabaje después la segunda hora, habiendo echado, finalmente unas 4 ó 5 horas… quizás incluso las 8 horas que son el día laboral normal de cualquier persona.

El pintor cobrará entonces por 8 horas, en lugar de 2 horas que ha sido su trabajo real. Es más, si el trabajo fuese de 200 metros cuadrados, sabiendo que son 20 horas, quizás en ese momento, por procrastinación, los primeros días no hace gran cosa, y cuando va viendo que quien lo contrató comienza a estar con la mosca detrás de la oreja, entonces trabaja bien las últimas 10 horas que le queden, habiendo hecho un trabajo de tres días (todos tenemos derecho a nuestros descansos) en cinco días.

Por ello, estos profesionales, por costumbre (que no de mala fe), acostumbrarán a posponer el trabajo en el tiempo (procrastinar) para llegar al punto de parecer, durante un tiempo al menos, malos profesionales, acelerando en el último punto, para que se vea que saben trabajar, y acabando el trabajo justo a tiempo para que no se les eche del trabajo.

En el mundo del software…

Hay muchas veces que, la estimación de un proyecto de software se hace por tiempo. En función del tiempo tardado, se paga a los programadores, y se estima el precio del proyecto. No obstante, esto tiene bastante puntos negativos para los desarrolladores, e incluso para los clientes:

1. La competencia: competir por el desarrollo de software es decir que tardas menos (y por lo tanto cobras menos)… pero si el tiempo se recorta y no los requisitos, o pagas menos a los trabajadores (programadores) o les presionas para que hagan más en menos tiempo.
2. Procrastinación: si se firma un proyecto de un año, se fija el alcance los requisitos, y se comienza a trabajar. Pasará, y eso se quiera o no es así, que los primeros meses la curva de implicación y desarrollo es muy baja, mientras que el último mes es incluso insana, echando más de ocho horas diarias. La presión no se tiene hasta que la fecha está próxima a cumplirse, y como a los desarrolladores/programadores se les paga por el tiempo que están ahí desarrollando la solución, no les motiva el terminar antes.
3. Recursos Humanos: aún usando metodologías ágiles, si la presión es variante en el tiempo y la motivación de hay que entregar se sucede con bastante frecuencia, sin que haya un premio por ello, y sin embargo habiendo broncas o castigos en caso de no llegar, eso hace que la gente se desmotive, comience a trabajar cada vez peor y termine viendo más las páginas de trabajo que el desarrollo en sí.
4. Retorno de Inversión: equivocarse en una fecha tras otra, puede ser un punto de pérdida de dinero si se tiene que invertir horas de personas en algo que se supone que debería de estar acabado. Supone no saber exactamente el precio de un desarrollo hasta que no se ha terminado completamente.

¿Otro modelo es posible?

Pudiera ser posible, sí. Pensemos en el modelo del pintor, ¿cómo le pagaríamos?… supongo que lo más óptimo sería por pintura gastada y por metros pintados, así como por manos que dé. Es decir, materiales y mano de obra calculando el trabajo realizado, y no las horas invertidas. Esto hace que el trabajador sea el más interesado en ser óptimo en su trabajo, ya que, tanto si tarda una hora, como si tarda tres, cobrará lo mismo.

En el mundo del desarrollo de software, ¿es posible hacer esto?… muchos dirán inmediatamente que no… que es complejo, sino imposible, determinar cuánto tiempo se demora en desarrollar un cierto sistema. La pregunta es clara:

Si es posible determinar el tiempo que se va a tardar en un desarrollo, ¿por qué no se puede determinar el precio de ese mismo desarrollo?

Esto es lo que vienen haciendo desde hace mucho tiempo otras doctrinas, como la abogacía, los registradores, los notarios, los arquitectos… todos los que tienen colegios. En el primer caso, por ejemplo, el Colegio de Abogados de cada provincia establece un precio por trabajo específico a realizar. En nuestro caso, el desarrollo de software, por ejemplo, podríamos determinar conceptos como:

• Desarrollo de una página web: HTML + CSS + JavaScript; precio mínimo: XXX euros
• Desarrollo de una página dinámica web (lenguaje de etiquetas: JSP, ASP, PHP, …); precio mínimo: XXX euros
• Desarrollo de un sistema de gestión de usuarios; precio mínimo: XXX euros
• …

Si se desglosa el desarrollo que se pide, hasta el nivel de análisis (e incluso diseño) más básico, toda petición se pueden englosar en uno de estos conceptos, quedando algunos otros como “as” en la manga, como la creación de conceptos de investigación, o incluso de riesgo, por tratarse de algo que se sale de la línea base en la que desarrolla la empresa en concreto.

Estableciendo precios

Al igual que se debe de realizar un modelo de negocio cuando se levanta una empresa, se deberían de plantear los precios por concepto de lo que la empresa realiza. Está claro que hay conceptos que seguirán quedándose en horas, como la hora de atención al cliente, o la hora de soporte, o la hora de formación.

No obstante, se pueden determinar ciertos desarrollos en los que la empresa se desenvuelve sin problemas, si es web, por ejemplo todo lo que se suele desarrollar de web y cosas que no se han hecho pero se saben hacer, así como si fuese de sistemas, todos los posibles montajes que se pueden realizar en base a tipologías de servidores que se quisieran montar, sistemas de seguridad, de redes, etc.

Buscando motivación en lugar de procrastinación

Si se tiene una empresa en la que los desarrollos son para la propia empresa, tipos como se han puesto de moda SaaS (Software as a Service), es decir, vender software como servicio y no como producto, entonces se podría hacer una evaluación de los tipos de desarrollos que se acometen, fijar un esquema de conceptos internos, y pagar a los desarrolladores por trabajo realizado. Tal y como se paga a los equipos comerciales.

En este caso, las empresas pagarían el mínimo fijo a los trabajadores, y una comisión, por trabajo realizado ese mes. Si se han realizado muchas labores imputables por conceptos acordados, el trabajador percibirá la cuantía según su hoja de servicio. Sin embargo, si ha realizado poco trabajo o ninguno, solo percibirá el mínimo.

Competencia interna e intereses contrapuestos

Desgraciadamente, no todo es bueno en este modelo. El hecho de ganar más dinero si se hace más, hace que también se busque la forma de hacer menos y seguir ganando más (naturaleza humana), por lo que nos podemos encontrar que haya gente que intente atribuirse el trabajo de otros, o incluso soliciten ayuda del compañero para que le acabe el trabajo.

Esto hace que el trabajador se mueva siempre en beneficio propio, y no en el de la empresa, ya que gana dinero si hace, no si ayuda. Esto puede forzar a que el trabajador genere más trabajo del que requiera la empresa en cierto punto (necesidad de ganar más) o incluso que haga más hora para conseguir más beneficio.

Todo es controlable y todo se puede mejorar. Estos puntos son salvables, ya que se pueden incluir conceptos de soporte entre trabajadores. Si el jefe estima que un trabajador está ayudando a sus compañeros, puede darle un incentivo por compañerismo, que esté reflejado en la tabla de conceptos, con lo que se potencia el trabajo en equipo.

Así mismo, se puede incentivar el que se trabaje a unas horas concretas, asistencia a reuniones o incluso tener un contra-incentivo si se permanece en la oficina pasada una hora concreta, para controlar que un trabajador no llegue a un punto insano de saturación por obsesión de intentar conseguir cada vez más.

Conclusión

Considero que, al igual que el incentivo es una buena forma de educar a un niño, es una buena forma de mantener la motivación de una persona en el trabajo, haciendo que la propia persona, con su experiencia y su creatividad, en las horas que determine dedicar al trabajo, consiga el mayor partido, ganando lo que quiera ganar, y con limitaciones para que la obsesión o avaricia se pueda presentar.

Los partes horarios son un ente arcaico que vienen bien en casos de trabajos concretos, que no se pueden medir por un trabajo realizado, sino más bien por un servicio prestado o por una atención dada. Pero este no es el caso del desarrollo de software.

Cuando se contrata a una persona, en principio, hay que pensar en el entorno donde se va a ubicar. No solo son sus aptitudes profesionales, que esas son muy importantes, sino también sus actitudes, ideologías, cultura, todo aquello que conforma a su persona. Esto también es importante porque puede decidir el nivel de trabajo en equipo que podemos llegar a alcanzar.

También es bueno tener perfiles afines en el equipo. Si tenemos equipos formados por francotiradores, el trabajo puede llegara convertirse en un infierno, aunque la calidad del trabajo sea bastante alta. No obstante, siempre viene bien tener algún que otro cohesionador de equipo, y otros perfiles necesarios para que todo funcione.

Jorge Jiménez los expone bastante bien en su presentación El francotirador, el vago, el líder y otros chicos del montón, siendo:

• Francotirador: es como House, suele ser bastante destructivo, pero un gurú en sí. El trabajo en equipo es prácticamente imposible con él y siempre critica de forma destructiva.
• Pitufo gruñón: considera que la empresa no lo quiere, intenta buscar almas afines y son promulgadores del apocalipsis (cuando llega a la empresa, claro).
• Líder clásico: intenta mojarse lo menos posible, es extremadamente conservador y realiza cada acción de la misma forma que se ha hecho durante años… si falla, no es su culpa, ese procedimiento era así y él lo sigue tal cual. Es el ideal a seguir por los programadores mediocres.
• Cheerleader: es lo que también se puede conocer en otros sitios como el cohesionador. Es un perfil que permite tener un buen rollo en el equipo de trabajo ya que tiene facilidad de confraternización, pero al mismo tiempo, elude el compromiso o la responsabilidad.
• Líder: motiva y enseña, toma la iniciativa, infunde confianza, es cercano y responsable.
• Vago: no quiere responsabilidades, simplemente, se diferencia del cheerleader en que no confraterniza ni agrega motivación al resto del equipo, simplemente puede aparentar que hace algún trabajo, siendo su rendimiento real muy inferior a su movimiento físico, y nunca es responsable de nada.
• Cowboy: es un trabajador muy bueno, entregado y deja el listón muy alto en todos los trabajos en los que participa. Es lo que se considera un gurú o élite.
• Pesimista: otro perfil muy similar al vago, solo que en este caso no se esfuerza en aparentar, simplemente no hace nada y se escuda en que todo está mal.
• El rey de la Pista: es un manipulador nato, trepa y, como no, gran orador. Aprovecha los recursos a su favor para conseguir lo que se plantea y no duda en echar culpas a diestro y siniestro para salir siempre airoso. Se mueve y redirige sus acciones basado en el miedo al fracaso, muy similar al líder clásico, solo que en este caso, la culpa no la tienen los procedimientos, sino los demás. No obstante, tiene buena mano negociadora y comercial.
• El soldado: bueno, alguien tiene que trabajar sin quejarse y acatando órdenes, ¿no? En este caso es el soldado, un perfil que se adapta bien a los líderes, ya sean clásicos o no, acatando las órdenes sin cuestionar la autoridad. Hacen pocas preguntas, solo lo que necesitan saber para conseguir terminar su trabajo. En general, suelen ser poco creativos.

Según cómo se lean, los perfiles pueden parecer buenos o malos, hay gente que muchos de estos perfiles, en su punto de vista los considerarán malos, y otros muy necesarios y valiosos, por lo que al final, en una situación u otra, todos son necesarios.

Construir un equipo

Haciendo un trabajo de sentido común y un poco guiado por la experiencia, puedo decir que, un equipo perfecto, para mi, en el entorno de desarrollo de software, sometido a ciertas presiones y que debe de funcionar sin fricciones, se requiere:

• Un líder, y solo uno. Esto más que nada es porque los líderes suelen ser autoritarios, por lo que introducir a más de uno, en un equipo reducido puede ser contraproducente.
• Pocos gruñones y líderes clásicos o ninguno, mejor. Si el equipo es pequeño, es mejor no tener ninguno. Estos perfiles son bastante peligrosos, en caso de detectar alguno, es mejor la poda.
• Pocos cheerleader. Vienen bien para construir equipo, pero no para el trabajo al pie del cañón.
• Tantos francotiradores como sea necesario. Sobretodo porque son profesionales solitarios y no les va mucho el trabajo en equipo… no obstante, en épocas de necesidad, producen mucho más que los demás, pero hacen crecer el nivel de stress al resto del equipo. En este caso los cheerleader deberían de crecer al mismo ritmo que los francotiradores.
• Vagos y pesimistas… bueno, hay trabajos en los que, no es que se requieran vagos, sino que el nivel de actividad no importa… salvo cuando hay crisis. La monitorización, atención telefónica, y las tareas rutinarias son bien llevadas por este colectivo.
• Tantos cowboys como encuentres. Es un perfil difícil y muchas veces caro de conseguir. El cowboy es aquél que puede realizar el trabajo imprimiéndole un nivel alto de calidad. Requiere de que se le deje tiempo para trabajar, por lo que, no suelen ser tan buenos como los francotiradores trabajando bajo presión.
• Tantos soldados como nivel de trabajo tengas que mantener. Entre las virtudes de trabajo bajo presión del francotirador y la creatividad del cowboy, está el soldado. Este puede realizar cualquier trabajo tal y como se le indique, ni más ni menos. Muy útil cuando hay que ampliar plantilla sin posibilidad de incrementar los mandos intermedios.
• Si se requieren de comerciales…. bueno, en ese caso, no está mal reyes de la pista, ya que son capaces de ganarse a cualquiera y realizar un buen trabajo de relaciones públicas en ese sentido. No obstante, si el nivel de negocio tiene sus caídas y problemática de estabilidad, en ese caso, puede ser un problema tener a este perfil de cara al público. Como trabajador interno, puede parecer como soldado, pero rinde bastante menos.

Realmente es mi opinión y muy discutible, por lo que, se aceptan comentarios para correcciones y ampliaciones.

Esta información, no solo constituye un modelo formal que define a la empresa, sino la mentalidad propia de la empresa a la hora de tomar decisiones, que la hagan acercarse aún más a sus objetivos. Por ello, un plan es importante, nos hace centrarnos en un objetivo concreto, conocido y alcanzable mediante una serie de pasos. Esos pasos se pueden complicar generando otros menores que necesiten ser abarcados antes de proseguir, pero el objetivo, en ese momento sigue siendo el mismo.

Un plan como un roadmap, fijado a un tiempo específico, o con una serie de hitos a cumplir (sin necesidad de estar fijados en un tiempo real, sino simplemente orientativo) pueden hacer que las personas que trabajan en esa empresa se sientan motivadas a conseguir ese objetivo y produzcan con más ahínco.

Un ejemplo, son las empresas de Internet, donde anuncian a todo su público (empleados, clientes, proveedores, …) el próximo hito a cumplir, como puede ser conseguir el cliente un millón, un número específico de visitas (ya sean físicas a un establecimiento o virtuales a la web de la empresa) o una cantidad de usuarios en el portal web.

En el desarrollo de productos, ya sean elementos físicos (zapatos, coches, ordenadores, ….) o lógicos (música, software, literatura, …), seguir un plan es importante, ya que sienta las bases de lo que se desea plasmar en ese producto, y su futura evolución, hacia donde irá orientada su evolución. Esto da una idea a sus consumidores, y puede motivar a que consumidores que no le dan mucho crédito al producto actual lo apoyen viendo esa proyección… o incluso lo desavalen, viendo que se aleja de lo que ellos desean. La ventaja en ambos casos, se sabrá mucho antes de que eso pase.

Los planes son como mapas

El diseño de un roadmap, que no es más que un mapa que nos ayuda llegar a nuestro destino/objetivo; es importante porque da unas líneas estratégicas a seguir para cumplir hitos, objetivos concretos, en un tiempo máximo marcado.

Las líneas estratégicas, se marcan a largo/medio plazo, siendo líneas muy abstractas o muy poco definidas, es decir, no llegan a un alto nivel de detalle ni de concreción. Estas líneas estratégicas nos marcan los hitos a conseguir durante toda la proyección de roadmap.

Las líneas tácticas, son una descomposición de las anteriores, de modo que entran en algo más de detalle, para afianzar a corto/medio plazo, lo que se debe de conseguir para avanzar hacia el hito, para cumplir la estrategia marcada. Son actos muy bien definidos que se deben de estudiar y definir por los especialistas de cada área implicada en la consecución de la propia línea táctica, y de la línea estratégica en particular.

Conclusiones

Con un plan elaborado en el que se sitúen hitos coherentes a lo que la misión de la empresa, y sus objetivos plantean, es normal ver cómo las empresas se afianzan, dan sensación de calidad y buen hacer y, lo mejor de todo, es que al no haber tenido tanto desajuste en el camino, también se consigue que esta percepción se ajuste a una estructura de costes asequible para conseguir dar al cliente un precio competitivo.

Hay muchos libros que hacen mención a la calidad de las reuniones, como comenté en otro artículo anterior (El problema de aprender), libros como el de Richard Templar (Las Reglas del Management) o de Joseph O’Connor y John Seymour (Introducción a la PNL), nos dan claves para organizar una reunión y que no termine siendo una charla entre amigos en la que no se obtienen los acuerdos o intercambios de información esperados.

¿Convocar o no convocar?

Lo primero que hay que pensar, antes de convocar una reunión, es en sí el motivo por el que se convoca la reunión. Pongámonos en el caso de que queremos saber si una venta se ha realizado con los acuerdos pertinentes y el cliente ha sido dado de alta de forma oportuna. En este supuesto, ¿podemos encontrar esta información en una sola fuente?, ¿es necesario un intercambio de información entre varias personas?, ¿se requiere de algún tipo de sincronización?, ¿se requiere de algún tipo de negociación?… si la respuesta a todas estas preguntas (y otras del estilo) es que no, quizás la reunión no sea necesaria.

Muchas de las reuniones que se convocan a lo largo de una semana en la mayoría de empresas tienden a ser meramente informativas. Los organizadores de dichas reuniones son personas que requieren de una información que, seguramente tengan, que seguramente puedan localizar en una sola fuente, pero que necesitan de ese punto de encuentro para mezclar distensión e intercambio de información, fuera del ámbito propio de la convocatoria inicial. Incluso muchas veces, para no pecar de estar fuera del ámbito, se convocan dichas reuniones de forma tan general, que cabe cualquier negociación o intercambio de información.

¿Es lícito convocar reuniones generales de larga extensión?, tiene su sentido si se hace cada cierto tiempo, de forma no muy frecuente. No obstante, cuando una reunión dura más de 30 minutos, es que no se está siguiendo una planificación, o quizás haga falta llevarla a otra fecha, obteniendo más datos, puesto que las negociaciones que se alargan son fruto, siempre, de la especulación.

Orden del día: define el motivo de la reunión

Es importante, una vez se tiene claro que hay que convocar una reunión, tener claros los puntos a tratar en la reunión. Llevarlos escritos, con documentación complementaria, e incluso dar esta información a los participantes unos días antes de mantener la reunión… o unas horas antes si la reunión es importante que se realice lo antes posible.

El objetivo a conseguir, es que todos, al entrar en la sala, sepan lo que se va a hablar y la información que se maneja para, lo antes posible, realizar el intercambio de información pertinente y finalizar lo antes posible la negociación o toma de decisiones.

Asistentes: selecciona a la gente necesaria

Al igual que el orden del día, es importante seleccionar bien a los asistentes que van a conformar el foro de la reunión. Serán susceptibles de ser invitados todos aquellos que puedan aportar, de una forma u otra, con su experiencia o su trabajo, a enriquecer la reunión y hacerla más efectiva.

Es importante también que, en caso de haber sido el que convoca la reunión, se tome el cargo de moderador y se lleva la reunión por los cauces definidos en el orden del día, para no salirse del mismo e intentar que la reunión sea lo más eficiente posible, llegando a las conclusiones en el menor tiempo posible.

Recursos: reparte información antes de comenzar

El intercambio de información puede producirse antes de la reunión a través de informes, documentos, o cualquier tipo de información que pueda ayudar a cada asistente a ser informado sobre la problemática a resolver o el orden de trabajo a realizar antes de entrar en la reunión y proceder a la organización, propiamente dicha, del trabajo.

Los recursos pueden ser documentos escritos de forma concisa, pero realmente, si se quiere ser efectivo en el intercambio de información, que las personas implicadas lo vean y lo entiendan fácilmente, deberá de hacerse de forma gráfica, muy visual. Por ello, mucha gente usa las presentaciones como documentos de apoyo o recursos para una reunión.

Controla el tiempo y las distensiones

En el momento que una reunión comienza, no se hace esperar que, una o dos personas, las que sean más abiertas, comiencen a hablar, durante largo tiempo, sobre experiencias personales, trifulcas con un compañero o cotilleos de pasillo que, espero, no están recogidos en el orden del día.

Este tipo de comportamiento debe de ser cortado y llevado, o minutos antes de comenzar, como momento de relax antes de comenzar a trabajar, o al final, cuando ya se hayan alcanzado los objetivos perseguidos.

No obstante, a lo largo de la reunión, este tipo de misceláneas (o distensiones) aparecerán cada vez que alguien, de forma espontánea, relacione un tema a tratar con otro que no tiene mucho sentido o queda fuera del ámbito de la reunión, no dando información relevante. En estos casos, habría que decir: ¿qué relevancia tiene eso con lo que estamos tratando?; y en caso de que no consiga una explicación válida, se puede decir algo como: ¿podemos tratar eso en otra reunión o al término de esta?

El tiempo debe de ser vigilado, puesto que, aunque no se haya salido del tema, si una explicación, discusión o exposición comienza a extenderse, será hora de decir, ¿podemos extender ese tema en otra reunión con más información al respecto?

Lo importante, es mantener centrada la atención en los temas a tratar, hacerlo de la forma más rápida y concisa, y comprobar que todos los asistentes se quedan con la información necesaria y oportuna, la que necesitaban tener, o la negociación tratada y conforme a todos los presentes.

Recapitula al final

Es importante llegar a una recapitulación donde se sintetice lo acordado y se obtenga un consentimiento de todos los asistentes ante lo dicho y acordado. Esto se puede realizar a modo de acta escrita enviándola al final de la reunión a cada persona… pero la experiencia me dice que, al final, poca gente lee estos actas, por lo que es mejor hacer el resumen de forma oral y que todos afirmen si lo dicho y recogido es lo que se ha hablado, negociado y acordado.

Como siempre, puede haber desacuerdos, gente que tiene una postura frente a un tema, y otros otra confrontada. Al final de la reunión puede que no se haya alcanzado un acuerdo en firme, sino uno que implique condicionantes. Es importante recoger estos condicionantes y enunciar el acuerdo, con los condicionantes a los que está sujeto, y obtener la confirmación de los asistentes de que eso es así. Ya que, incluso en el desacuerdo, puede haber acuerdo

Conclusiones

Realmente… al fin y al cabo… es trabajo. Las reuniones son puntos de encuentro entre personas. Las personas somos animales sociales y tendemos a tratar temas variados, tendemos a entablar conversación de afinidades entre unos y otros y, si las reuniones en el trabajo, se hacen entre amigos, es normal que surja la miscelánea, que surjan las risas y se pierda durante unos momentos el hilo de la conversación principal.

En el peor de los casos, será al revés, en lugar de amigos, habrá gente que guarda rencor a otras personas y, en el momento que se toque un tema en el que una opinión pueda surgir de una de las partes, lo que sería un intercambio de información puede tornarse en una discusión abierta sobre una temática que está fuera de la reunión en curso. Será labor del moderador el cortar el tema de discusión y volver a centrar el tema original… y labor de la jerarquía más alta el solucionar el tema en otra reunión que trate explícitamente de ese problema.

Finalizando, solo me queda decir que, en lo que las reuniones respecta, suerte con ellas

Aprender tiene fecha de caducidad

Esto es un mito que se transforma, muchas veces, en excusa. Cuando una persona, llegada a cierta edad (o incluso muchas veces antes, mucho antes) menciona la típica frase: es que ya soy muy mayor para aprender eso; solo está enunciando una excusa por la cual, no pretende esforzarse en conseguir un conocimiento nuevo.

Aprender, a nivel cerebral y neuronal, no se deja de hacer nunca. Es más, un cerebro maduro, con un conjunto de conocimientos base, es más fácil que aprenda algo, que un niño al que le está costando aprender a leer y escribir. Algo tan concreto como el funcionamiento de un microondas, puede ser comentado a un adulto que enlazará ese conocimiento a otros que ya tenga de su base académica (o del conocimiento del funcionamiento de otros electrodomésticos) y lo aprenderá mucho antes que un niño de 5 años, que puede pensar que todo lo que le cuentas está sacado de una película de ciencia-ficción

Los jóvenes de hoy en día…

La estructura social ha cambiado, ya no se ata a una silla a nadie, ni se les obliga a estudiar durante varias horas con posibilidad de un castigo físico si al terminar el estudio no se sabían la lección. Ese marco ha cambiado radicalmente. ¿Quiero decir que deberíamos volver a ese marco para que las cosas fueran mejor? … ¡Ni de coña! :-S

Las cosas han cambiado, en eso estamos de acuerdo, pero las formas de enseñanza… pues no. Seguimos teniendo profesores que se sientan tras una mesa y nos dan una sesión de telediario, explicando (eso sí) lo mejor que pueden, una lección de historia, lengua, literatura o similar. En el caso de asignaturas de matemáticas es peor aún, porque no se trata ya de que se transmita de forma oral, sino que el profesor de turno se levanta, rellena la pizarra con una forma de hacer un ejercicio y, si se entendió bien, y sino… es que son unos burros

Hoy en día se penaliza, tanto socialmente por los compañeros, como por muchos profesores, el tener curiosidad, el preguntar algo sobre una asignatura, o sobre algo que se está explicando:

• el profesor, lo toma como una pregunta fuera de contexto, cuando no quiere responder, o una posible broma, o un niñ@, es que si no prestas atención, esto no sirve de nada;
• los compañeros, agreden verbalmente (y a veces hasta físicamente) al compañero que realiza preguntas de forma frecuente… entre algunos calificativos, no se podrá negar, que se suele tildar a estas personas de empollones.

Termina no siendo un buen marco de enseñanza. ¿Realmente la culpa es de los jóvenes?

…y el cambio de marco

Ahora piensa, una clase de historia, nada más entrar, en una pizarra, o de forma visual, el profesor ha colocado 1400, en el extremo superior izquierdo, y 1500 en el extremo superior derecho. Entre medias pone, simplemente RENACIMIENTO.

Nada más comenzar la clase, el profesor nombra el marco geográfico, estamos en Italia. Para llevarlo gráficamente, sitúa las mesas y a las personas de forma que se vean las ciudades estado que formaban, en ese tiempo Italia, se puede formar, incluso, un teatro en el que cada alumno tiene un papel, que leer y hacer vivir a los demás, sobre el renacimiento y el lugar que ocupa, según donde esté sentado.

El hecho, es que la motivación se rige por acción, si por la mañana se levanta un niño, sea de la edad que sea, para ir a una charla sobre un tema teórico que, el máximo movimiento que tiene, es un profesor poniendo fechas y nombres sobre una pizarra… por muy bien que organice y clasifique los datos este profesor, y por muy diverso que sea su registro vocal (a menos que mezcle comedia con narrativa audiovisual), está abocado a ver bostezos, e incluso gente que se duerme.

Aprender es hacer

Como dice el viejo proverbio chino: Me lo contaron y lo olvidé. Lo vi y lo entendí. Lo hice y lo aprendí.

Cuando, en una clase, se realizan ejercicios tras el profesor haber realizado un ejemplo, como en clases de matemáticas, esto suele reforzar el que los alumnos se motiven a trabajar, hagan los ejercicios y progresen. No es una panacea, en eso estamos de acuerdo. Pero es un avance.

Para realzar más la motivación, hay que conseguir que los alumnos se sientan parte de la clase, por ello el ejemplo anterior de la clase de historia. Esto es aplicable a más tipos de clases, por ejemplo de lengua, donde un análisis de oración puede salir de nominar a partes de la clase como sujetos, predicados, complementos, etc.

… y el refuerzo positivo

Está claro que, entre el trabajo y los estudios, donde más absentismo hay, sin lugar a dudas, es en los estudios. Esto es porque, el beneficio para el estudiante no es claro, además, se entremezcla con la posibilidad de fracaso y, ante una posibilidad de fracasar, para muchos, lo mejor es no intentarlo.

¿Qué pasaría si cada día de asistencia se valorase en 2, 3 ó 5 euros? ¿Nos apostamos a que esto bajaría el absentismo escolar?, es muy parecido a ir a trabajar, ¿por qué la gente no falta al trabajo?, ¡por miedo a que le descuenten el día de las vacaciones o la nómina!

Pero pongámoslo mejor todavía, ¿qué tal si hacemos un examen semanal?, todos los avances de cada semana puestos a examen, y una vez al mes, todos los del mes, y una vez cada 3 meses, todos los del trimestre. ¿Qué pasaría si los contenidos fuesen asequibles (lo que ya se ha visto en clase) y el premio la nota?, ¿qué tal si potenciamos el hecho de que tener notas favorables sea bueno? … y ya si se premiase económicamente, ni te digo , ¿qué tal una beca para los que lo hagan sobresaliente?

Explicar a un joven que lo que estudie y lo que introduzca dentro de su cerebro será bueno en un futuro (para la universidad o más allá… cuando se licencie y busque trabajo… sobre los 25 años como poco), teniendo solamente 8, 12 ó 16 años incluso es algo un poco absurdo, porque en el primer caso le estás diciendo que, cuando pasen 17 años (¡más del doble de la edad que tiene!), eso le habrá ayudado mucho.

Es equivalente a decirle a un trabajador: trabaja duro y haz por subir de sueldo, buscar mejores trabajos y progresar, porque cuando cumplas la edad de jubilación, te quedará mayor pensión; ¿qué efecto tiene eso?… ninguno, ya que ninguna persona, o casi ninguna, invierte en futuro a largo plazo, prefieren vivir el día a día y que, si en uno o dos meses (o dos años como mucho) me suben el sueldo, perfecto, sino, me quejaré y diré que merezco algo mejor (sin hacer nada, realmente ).

Concluyendo… ¿qué nos queda?

Pues llegados a este punto, analizamos las típicas frases:

• La educación está muy mal en este país: y en muchos otros, realmente, pero eso es porque no se tiene en cuenta cómo enseñar mejor, sino lo que hay que enseñar. Si el medio no es el adecuado, da igual lo que se transporte, por lo que seguirá estando mal, mientras los profesores sean reactivos (en su gran mayoría) y se dediquen a enseñar como ellos creen que lo hacen mejor, sin escuchar un feedback de sus alumnos y la realidad del día a día, al igual que las estadísticas de aprobados frente a suspensos (y dados de baja)… y que conste que pasar la mano o hacer exámenes ridículos, es otra forma de no hacer nada.
• Los jóvenes de hoy en día no estudian, ni trabajan, no hacen nada: sí, ciertamente, ¿pero quién les ha inculcado esos valores?, si los jóvenes son así, no es porque no se les pueda pegar (como creen muchos), sino porque no se les motiva a tener éxito, sino que se les inculca el miedo al fracaso. Cuando una persona toma fobia al fracaso, no hace nada, porque ante intentarlo y fallar, mejor no intentarlo, ¿no?
• No sirvo ya para nada, a mi edad, ¿qué voy a hacer si me echan? cualquier persona de menos de 60 años, es capaz de encontrar un nuevo trabajo en el que ser útil y desempeñarse lo mejor posible (y digo menos de 60, porque ya la edad se va notando y porque falta poco para la jubilación, pero es gente la que contrata, y si se les convence, hasta con 64 años y medio se puede comenzar a trabajar… o 66 y medio, depende de la ley ). Una persona de entre 40 y 60 años es capaz de aprender en poco tiempo una nueva forma de trabajar, y sobretodo si se parece a la que haya estado desempeñando durante todos sus años laborales anteriores (que serán, de seguro, 20 ó más). Aprender no es un problema, sino un desafío. Hay que superar el miedo a fracasar y servir de ejemplo a la juventud que va llegando.

Todos tenemos capacidad para aprender, y todos podemos aprender de todo lo que nos motive de forma rápida. En caso de estudios reglados, que no son motivación propia, sino impuesta, la motivación debe de salir de profesores, que, al igual que los alumnos, tienen la imposición de estar ahí, con la diferencia de que, si el profesor no realiza su trabajo, estará incurriendo en dos faltas bastante graves: no cumplir con el objeto de su contrato, y tampoco con su deber moral y ético de enseñar… y hacerlo lo mejor posible, aprendiendo, si hace falta, cada día algo nuevo.

Hola,

conforme al tema de los proyectos/productos, los desarrollos que se deben de realizar, los que se solicitan, y los que terminan (o no) entrando, es labor de la empresa asegurar un flujo constante de proyectos/productos con mejoras sobre lo que se ofrece en el portfolio de productos ya realizados, pero, queremos que conste que:

1. Cada proyecto/producto que se solicita, tiene unas implicaciones en tiempo y dinero que debe de amortizarse con los beneficios del mismo, ya que los recursos son finitos, al igual que el tiempo y el dinero de que dispone la compañía para este tipo de peticiones.
2. Los productos/proyectos tienen un proceso de desarrollo dependiendo de su complejidad, así como de la necesidad de integración dentro de otros productos/proyectos que ya estén desarrollados, por lo que no solo es labor de I+D, sino también de Sistemas y Área de Negocio el desarrollo oportuno del proyecto/producto, su forma de facturación y estructura de costes y la correcta puesta en producción para su monitorización y mantenimiento.
3. El desarrollo tiene varias fases en las que se debe de realizar el proyecto codificando cada parte solicitada o modificando un código ya existente, lo cual puede significar un mal funcionamiento en caso de que se haga con tiempos muy cortos y sin posibilidad de pruebas. La estimación de tiempos deberá de hacerse conforme a lo que se tarde en cada área en realizar su trabajo, y no comenzar a contar el tiempo antes de un inicio real.
4. Cada cambio que se solicita, pasado el período dispuesto para ello, conlleva tirar el trabajo de los días anteriores para comenzar prácticamente de nuevo y con menos tiempo. Por lo que, cada cambio, cuesta tiempo y dinero.
5. Desarrollar rápido una aplicación y ponerla a disposición del cliente, aún habiendo avisado de que puede generar fallos, es algo que debe de asumir quien lo solicita y sus responsables directos, así como los responsables de la infraestructura a mantener, puesto que en caso de fallo puede que no se vea afectado solo el desarrollo y el cliente para el cual se ha realizado el desarrollo, sino también el resto de clientes.

Puesto en conocimiento estos datos, queremos hacer constar y solicitar de vuestra parte que:

1. Se nos tenga en cuenta en cada proyecto/producto que se defina, así como cualquier cambio o indecisión que se tenga, antes de comenzar el desarrollo.
2. No se introduzcan cambios de última hora en desarrollos que están comenzados y con una fecha de entrega pactada, a menos que se pueda renegociar esta fecha de entrega.
3. Se defina un modelo de negocio antes del comienzo del desarrollo, para que la integración con área de negocio pueda realizarse desde primera hora.
4. Se nos dé voz y voto en las decisiones a tomar, en negociaciones con el cliente, y la forma de realizar cada desarrollo, ya que podemos aportar algo de innovación y valor diferencial, así como podemos amoldar su petición para optimizar el desarrollo y que el ciclo pueda, realmente, ser más corto.
5. Se tenga en cuenta de que I+D es desarrollo, es decir, que las tareas de llevar un proyecto/producto a producción es tarea de un conjunto de personas y de un jefe de proyecto designado para asegurar el éxito del proyecto/producto, por lo que, la responsabilidad es compartida por todas las áreas de entregar cada uno su parte y de realizar cada uno su trabajo.

Con todo esto, espero que podamos hacer más comités de desarrollo de productos y se nos dé mayor visibilidad ante la llegada de cualquier proyecto.

Gracias.

Espero que ante esta rogativa, se consiga algo bueno y de calado, ya que es asignatura pendiente en el sector de la informática el poder tener voz y voto a la hora de participar en la definición de productos/proyectos dentro del seno de muchas compañías de toda índole.