tio gilito

Como tengo instalado en la mesa de al lado al nuevo director de proyectos,(1) estoy viendo la presentación que prepara para aleccionar mañana a su equipo de gestores a "facturar". 

El título de la primera diapositiva es "¿Para qué existen las empresas?", y a continuación presenta con letra de gran tamaño, como remarcando que  "¡Toodo el mundo lo debería sabeeer porque es evideeente!: "PARA GANAR DINERO". 

Resulta tan obvio que acompleja no entenderlo. ¿Obvio?

¿En todas las empresas, es esta la meta de su emprendedor? Seguro que en muchas sí, pero también es seguro que otras han nacido para dar vida a proyectos ilusionantes por sí mismos.

Desde luego, sin dinero la empresas no tienen oxígeno, pero la diferencia es que en las primeras es el objetivo, y para las segundas, la consecuencia.

Quizá sea porque no sé de "bisnes",  pero me gustan más las segundas, y me da la sensación de que las primeras confunden el medio con el fin.

Hace poco me aconsejaba el director de negocio de la software factory en la que trabajo:(1) "El cliente no sabe lo que quiere. Copia y pega este informe que hice yo hace unos peses para Fulanitez, cambia los datos y ya tenemos facturado el estudio"  ¡?!

No le entendía, y sin duda él no habría entendido por qué yo no le entendía a él. Seguramente las dos visiones tienen razón: la una, en una empresa cuyo fin es facturar, y la otra en una empresa cuyo fin es construir soluciones.

Se me ocurre hacer un paralelismo con  la finalidad por la que algunas personas deciden ser médicos. Seguro que las hay que quieren alcanzar un nivel social y económico alto, y ven en la medicina una profesión adecuada para su objetivo, y seguro que las hay también que sencillamente, quieren curar enfermos.

Los primeros tienen que curar pacientes para ganar dinero, los segundos ganan dinero porque curan enfermos. Puede parecer lo mismo, pero hay mucha diferencia.

----

(1) Nota: Este es uno de los post que por "entrañables" estoy trasladando aquí desde el anterior navegapolis.net donde fue publicado el 31 de marzo de 2005. Hace ya algunos años que dejé de trabajar en la empresa aludida ;-)

edadSe dice que son necesarias 10.000 horas de trabajo de programación para alcanzar el nivel de experto, pero una vez llegado a él, ¿cuál es la evolución? ¿Se mantiene? ¿Continúa mejorando? ¿Retrocede?

Aunque hay diversas opiniones, posiblemente la más habitual considera que la edad desgasta la capacidad para adoptar y absorber nuevos conocimientos, por lo que al avanzar va transvasando a puestos comerciales, de gestión, de asesoría, o incluso a otras actividades. 

Como la demanda de software continúa creciendo, y en el medio plazo no es probable un cambio de tendencia, se empieza a cuestionar si la preferencia de candidatos jóvenes, o la percepción del "demasiado mayor" tiene sentido o puede ser un comportamiento inducido por una falsa lógica.

Patrick Morrison y Emerson Murphy-Hill del departamento de Ingeniería del Software de la Universidad de Carolina del Norte, han realizado un estudio pionero en esta línea, basándose en el análisis de los datos de la comunidad de programadores de stackoverflow.com (edad, reputación en la comunidad, tecnologías tratadas).

El objetivo de su primer estudio en esta línea es identificar si se aprecia algún tipo de correlación entre edad y nivel de programación, antes de profundizar con posibles correlaciones entre la "inteligencia fluida" o capacidad para identificar relaciones complejas y sus inferencias, y la "inteligencia cristalizada" que refleja la amplitud de conocimiento, comprensión juicio y sabiduría adquirida por la experiencia".

La conclusión a la que llegan los autores es que sí que existe una correlación entre la edad y la reputación de los programadores en stackoverflow.com, que parece indicar que se puede mantener un nivel de programación alto en los 50 y los 60, y que los usuarios más veteranos de stackoverflow se encuentran al día y adquieren sin problemas los nuevos conocimientos en las tecnologías que ha examinado este estudio.

Este es el documento del estudio: Is Programming Knowledge Related to Age? que presentarán los autores el 18 de mayo en el eventop "10th Working Conference on Mining Software Repositories" en San Francisco.

satisfaccion thumb"Un problema de los equipos de programación con importante impacto económico es la alta rotación de personal. La relación entre insatisfacción y rotación es una evidencia contrastada. El estudio (Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams) investiga si existe una relación entre la satisfacción laboral y el método de desarrollo empleado, y encuentra una correlación positiva moderada entre el nivel de satisfacción y el uso de metodologías ágiles..." (1)

satisfaccion laboral en equipos ágiles y no ágiles

 "El análisis comparativo entre equipos ágiles y la media general de profesionales TIC, ha revelado tasas significativamente más altas de satisfacción en los miembros de equipos ágiles. Además no sólo en los trabajadores, sino también en los administradores se da mayor satisfacción con sus empleos. Este es un claro indicador de que los métodos ágiles no son un movimiento orientado sólo a los programadores".

El informe completo y todas tablas comparativas del estudio en:

(1) Melnik, G., & Marurer, F. (2006). Comparative Analysis of Job Satisfaction in Agile and Non-agile Software Development Teams. Extreme Programming and Agile Processes in Sotware Engineering, 32-42.

motivandoEn otras profesiones no sé, pero si se trata de programadores, de gente apasionada por la tecnología y por la programación de nuevas soluciones, no se preocupe por motivarles. Son profesionales motivados por su trabajo mucho más de lo que usted lo está por el suyo.

La cuestión no es motivar, sino no desmotivar con "programas de motivación", planes de desempeño, control de horas de trabajo, recompensas y castigos, etc.
Quieren programar, son gente inteligente y los modelos de motivación de manual de recursos humanos, les resultan pueriles y denigrantes y les quitan las ganas que traían con ellos cuando llegaron a su empresa el primer día.

Estamos hablando de programadores, "programadores": personas a las que les gusta su profesión. Son un porcentaje escaso. Gente que cuando deja el equipo de la oficina, continúa, investigando y "jugando", que disfruta con retos intelectuales y a la que gusta estar en continuamente descubriendo y aprendiendo.

Si los programadores de su empresa no son de este tipo, si desde que dejan la oficina hasta que vuelven a la mañana o el lunes siguiente, no echan de menos un teclado... seguramente el consejo de este post no es bueno para usted, y es posible que sí que necesite las prácticas de motivación del manual de RR.HH. También es posible que no consiga nunca productos brillantes.

 

check

Estas son las variables que condicionan el nivel de los resultados que se pueden esperar con gestión ágil de proyectos, y el nivel de riesgo general del proyecto.

 

 

 

test viabilidad proyectos agiles

 

Safe Creative #1301274440493

puzzle

 

 

 

 

puzle empresario software

(Si el producto es "facturar lo que sea" con el menor coste, y procesos o talento son pamplinas, sobra este puzle)

 

Safe Creative #1301134336669

cambio"Tras algunos momentos difíciles, paramos la implantación de CMMI y retomamos técnicas ágiles, más colaborativas. Aquí describimos esta experiencia en la implantación de un marco Scrum distribuido y en la creación de una cultura kaizen".

"... La opinión de diferentes expertos y la experiencia en empresas veteranas resaltaban la importancia de establecer procesos compartidos que pudieran ser empleados por todos. Expertos en consultoría nos aconsejaron la implantación de CMMI en ambas ciudades. Se realizó un estudio inicial de viabilidad para lanzar la nueva empresa en Bangladesh e implementar CMMI con la ayuda de una consultora externa. Aunque veíamos muchos desafíos, parecía muy prometedor."

"... Encontramos un partner competente con el que firmamos un contrato por el que nos ayudaría a alcanzar un nivel 3 de CMMI certificado en año y medio ... Uno de los directores más experimentados de la organización se trasladó a Bangladesh durante dos años como director general."

 

De CMMI a Scrum

 

"Todos los nuevos empleados de Bangladesh vinieron durante un mes a Dinamarca, en otoño de 2005 para conocer y trabajar junto con el equipo local, comprender bien el dominio del negocio y establecer un entendimiento cultural entre las dos empresas ... En ese momento no éramos conscientes del impacto de poner el objetivo en la certificación para integrar las dos ciudades. En lugar de que nuestro objetivo fuera crear valor para el negocio y ofrececer soluciones eficientes a nuestros clientes, teníamos por meta estratégica establecer un proceso marco y cumplir una serie de prácticas clave para las áreas de proceso de CMMI ... "