Categorías
Tecnologia

Management del siglo XX

managementEl otro día tuve una charla con un manager del siglo XX. Básicamente hablamos acerca las métricas en el desarrollo de software.

No había vuelto a pensar sobre ello hasta que esta mañana he visto un post en Atrapalo acerca del libro «The future of Management» de Gary Hamel en el que se explica bien claro que el paso del management del siglo XX al management del futuro es la adaptación de la empresa al trabajador.

Es evidente que en una industria se deben tener controlados todos los parámetros que intervienen en el proceso para poder así mejorarlos y optimizarlos con el objetivo de poder conseguir las tasas más altas de productividad posibles. Se cumple la máxima aquella que dice que «no puedes mejorar lo que no puedes medir» (o una de sus múltiples acepciones).

Pero eso se aplica a los procesos industriales y el software, como tal, no lo es. Se trata del viejo debate entre industria y arte. Hay quienes consideran que la producción de software es una industria y que deben aplicarse las reglas que rigen otros procesos industriales. Y hay quienes piensan que el software es un arte y que como toda actividad artística no está regido por las leyes de la razón, sino por la creatividad, la inspiración y la motivación.

Personalmente me sitúo en un término medio. El software ni es una industria ni es un arte, es una artesanía. Producir software se parece mucho más a lo que hace un ebanista que a partir de un trozo de madera consigue una bonita máscara que a lo que hace el peón de la cadena de montaje o el pintor en su buhardilla.

En ese sentido el verdadero programador (no el simple picateclas) está más cerca del artista que del peón de fábrica. El proceso de ingeniería del software en su globalidad trata precisamente de alejar al programador del artista añadiendo una capa entre él y su código (el producto del programador). Es algo necesario puesto que en el siglo XX se vio que las empresas y organizaciones no podían verse sacudidas ante la pérdida de un «trabajador clave».

Para darse cuenta de lo cerca que está un programador del artista sólo hay que pensar la diferencia que hay cuando en una empresa de empaquetado de conservas se marcha un empaquetador y lo qué pasa cuando un artista deja de pintar o esculpir (normalmente porque muere). Sin duda el golpe de que un buen programador abandone una empresa es mucho más parecido al segundo ejemplo.

Ahora bien, ¿qué tiene que ver todo esto con las métricas del software? Pues mucho. Las métricas pueden medir (y deben hacerlo) los procesos industriales, pero poco pueden hacer frente a los procesos artísticos y de creación. El manager del siglo XXI debe darse cuenta de una vez que no puede medir el rendimiento de sus programadores contando líneas de código (¿os acordáis de esa patraña que nos contaban?).

Un buen manager hoy en día debe crear una relación de confianza entre los programadores para que en vez de competir para ver quién escribe más líneas de código inútiles, cooperen para conseguir objetivos concretos (quizá los managers del siglo XX olvidaron o nunca aprendieron las enseñanzas de John Nash). Un buen manager debe conseguir modificar la estructura de la empresa para adaptarse a los empleados. No se puede consentir hoy por hoy que una empresa pierda a un programador genial (en el sentido de «genio») porque una de las métricas lo dicte. El manager debe conseguir que los buenos programadores se sientan a gusto, que no quieran cambiar a otro lugar, que estén alineados con los objetivos colectivos y, sobretodo, tiene que ser su mejor aliado frente a las exigencias externas o internas (tanto clientes externos como internos, la dictadura del cliente es otro tema que trataré en otra ocasión).

Ni que decir tiene que el paradigma de la empresa que aplica un buen management es Google. Por eso los mejores programadores (1, 2, 3…) se van de las grandes empresas tradicionales para ofrecer su creatividad y entusiasmo a Google.

Así que, futuros managers, aprended que podéis medir las líneas de código, el número de bugs solucionados, el número de horas que vuestros programadores pasan en la oficina… pero que eso no os va a servir para medir el rendimiento de un buen programador. Mediréis la mediocridad, mediréis quien tiene más capacidad (o estómago) para adaptarse a tus métricas y conseguiréis acabar con el espíritu crítico, la proactividad y la creatividad.

Pero claro, explicar todo esto es muy dificil cuando el futuro manager que tenemos delante nunca ha sido un verdadero programador.

62 respuestas a «Management del siglo XX»

Jajaja, genial!! Lo mejor de todo es ver cómo esos manager del siglo XX miran sus datos y no entienden por qué no cuadran con las personas que tienen delante y los resultados «reales».

¿Por qué cuando se habla de métricas siempre se citan las líneas de código y el número de bugs solucionados? Da la impresión que solo existen esas dos. Las métricas son IMPRESCINDIBLES para conocer la evolución de un desarrollo software y si este se adecua o no a los estándares de calidad de la empresa. ¿Por qué nadie habla del número de defectos encontrados (que no solucionados) por linea de código? ¿O del número de puntos de caso de uso desarrolado por iteración/proyecto? Ambas nos dicen mucho sobre la calidad de los desarrollos y la productividad de la empresa y son imprescindibles para mejorar.

En cuanto a los programadores «artista», en todas las empresas en las que he estado he visto varios. Y en la mayoría de los casos (no en todos), o bien su código solo lo podían mantener ellos mismos, o su alta productividad estaba ligada de manera exponencial al número de bugs que generaban. No se me ocurre que una buena revisión de diseño dentro de un proceso definido (como solución al primer problema) o unas métricas orientadas a medir el número de defectos (para solucionar el segundo) puedan «acabar con el espíritu crítico, la proactividad y la creatividad».

Saludos!

eltator… nunca fue bueno generalizar… habrá de todo, digo yo. Se nota un poco de resentimiento en tu nota: yo por programador «artista» entiendo aquel no que pica más código, sino el que lo hace mejor -y eso incluye robustez-. De lo contrario estamos ante un programador con aires, que también los hay…

Por cierto, las métricas están bien, es cierto, pero ya te adelanto que a mi se me antoja absurdo usar líneas de código como métrica, por ejemplo, y todas las derivaciones. Hay programadores que un problema lo resuelven en 50 líneas y otros en 5… ahí está el arte: en romper ese tipo de métricas. Lógicamente, como antes dije, las 5 líneas no deben serlo a costa de un código menos robusto, pero es que hay veces que 5 hacen exactamente lo mismo que 50 y mejor, a veces incluso más claro, si bien hay ocasiones en que un programador novel no entenderá estas 5 líneas, por lo que requerirás programadores con experiencia para poder manejar ese código.

En todo caso la programación es un arte… más allá de que los programadores sean artistas o no.

Muy muy interesante el artículo. Realmente me has puesto en un aprieto. Yo soy de esas de Calidad que definimos e implantamos las métricas para todo el ciclo de desarrollo del software. Mi obligación es crearlas, el management me lo impone, pero realmente creo y pienso como tu y cada vez que monitorizo estas métricas me doy cuenta de que poco me sirven la mayoria, excepto algunas que son buenas para reaccionar y ver donde se hayan los problemas reales. Estas realmentes son muy muy útiles.

Yo dejaría en que existen buenas y malas métricas… habrá que plantear al management esta questión: ¿pq no quedarnos sólo con las buenas y necesarias?

Programar es un trabajo muy bonito y creativo. Trabajé en su día como programador durante año y medio.

Sin embargo, la analogía que haces para decir que es artístico, comparándolo con un peón de cadena de montaje, es mala y tendenciosa. Deberías compararlo con otro trabajo de alta cualificación, incluso hay quien diría (yo no) que con otros ingenieros.

La falta de un programador se podrá suplir con tanta o menor complicación que la de un ingeniero de cualquier rama. Entender un código es complejo, pero tanto o menos que el proyecto de otro, sea de estructuras, instalaciones, desarrollo de producto, etc.

Programar no es un arte, o al menos no más que muchas (puede que no todas) las ramas de la ingeniería.

Estoy de acuerdo con _K_, soy programador pero no creo que sea un arte, se programador requiere de astucia, inteligencia, atención y empeño, entre otras muchas cosas, pero eso no te hace en un artista, un artista es quien puede tomar un trozo de piedra y convertirlo en algo hermoso, son realmente muy pocos los programadores que pueden tomar una idea y convertirla en un sistema sin errores… Hoy el desarrollo de sistemas no es el trabajo de un «genio» que saca adelante una idea. Para poder desarrollar sistemas en serio, es necesario de todo un equipo, de programadores, analistas y especialmente de un arquitecto!, o tu crees que le puedes decir a quien construye las paredes de tu casa que las realice sin un arquitecto

Que gracia que te dio el consejo uno de atrapalo, si los de atrapalo son los peores jefes que hay, son del OPUS y mandan a sus empleados usando la técnica del miedo. Mejor que no comente más sobre estos.

Además de las líneas de código y los bug, yo añadiría muchos más factores, como el rendimiento del programa, los comentarios del código fuente, la documentación, el grado de conocimiento del lenguaje empleado, el grado de aceptación del cliente, la capacidad de autoformación y comunicación con los compañeros, etc.

Aunque destacaría sobretodo la capacidad (como decía el gran Fuckouscky) de hacer un porche en una noche a partir de los elementos de una bicicleta. Normalmente eso nos piden a todos los programadores, con un conocimiento y herramientas mínimas, realizar un proyecto en el mínimo de tiempo que sea perfecto.

En la mayoría de empresas, no sólo está un programador que se dedica a ello, sino que el mismo se dedica a todo el ciclo de vida del proyecto (recogida de requerimientos, análisis, diseño, programación, pruebas, mantenimiento y atención al usuario) y hágase un bucle infinito de ello o hasta que el programador se harte y cambia a otra empresa normalmente igual.

Con todo esto, no solo se pierde al buen programador, sino que se le exige más de lo que se debe y se le quema rápido, con lo que tenemos un programador-para-todo sin creatividad (más bien la tiene, pero no tiene ganas de sacarlo). No me meto en el tema de los cuasi-programadores (gente que no tenía otra salida laboral y con un curso de visual basic de 10 horas ya se cree todo un programador), ya que la única creatividad es cómo salir antes del trabajo, copiar-y-pegar el código del programador-para-todo y modificarlo o bien darle la tabarra para que le arregle su código o errores/tareas que le queden.

Buenas. Me ha encantado el artículo. Realmente te hace pensar un rato. Yo he sido (y todavía me considero) programador; mi especialidad son lenguajes 4ºG de alto nivel RAD, y considero también que la programación es un arte.
Tengo amplia experiencia en una consultora no de primer nivel, pero sí bastante importante, así como en medianas y grandes cuentas; mi experiencia me dice q se puedo copiar y pegar todo lo q sea (parchear), pero eso sólo hace q el código sea bastante mediocre, aunque funcione (luego vienen las modificaciones y la hemos hecho buenas). Sin embargo, eso no es arte; para mi es parchear y cumplir plazos, a costa de tener un script caotico q sólo entiende el que lo ha hecho.
Quizá habría q distinguir entre «programar» (COPY-PASTE, no hay parametrización, no hay sobrecarga ni reutilización, no se siguen criterios de rapidez del producto, sólo lo entiende quien lo ha hecho) y «PROGRAMAR» (reutilización, parametrización, rapidez, fiabilidad, pensado para el futuro, fácil mantenimiento posterior, …).
Salu2

Olvidar lo de artista y fijaros bien en lo de artesano (es que ya lo habia pensado yo muuuucho antes,je,je).
Eso si, en la vida moderna, no hay muchos artesanos. 🙁
En el caso de programas que usan mucho «componente» prefabricado, diria que se necesita menos artesanales, sobre todo si estos programas son muy parecido a otros que ya hemos hecho.
Por otra parte, para el software, hay que indicar que la cadena de montaje es cuando el software esta listo para su distribucion, o sea, cuando se graba en el medio.
Lo que hace el equipo de desarrollo, es lo que hace el equipo de ingenieria de otras disciplinas hasta que define el producto para ser ensamblado, solo que muchas veces hay que encargar al artesano para hacer «componentes» que no existen. Pero como al artesano (programador) lo tenemos contratato en la empresa, no podra repetir mas ese trabajo para volver a beneficiarse economicamente o laboralmente de el, ya que el uso o duplicacion del «componente» es ilimitado y gratuito por parte de la empresa, para este desarrollo o para futuros. Llegados a este punto el «superior» solo ve al artesano como una fuente de recursos duplicables gratuitamente al que hay que estrujar, o sea, como a un «no artesano».
Quizas esto cambiara cuando los «componentes» sean estandares y solo se haga lo que se puede con estos componentes. Los que no existan, no se hacen en la empresa, que los diseñe un ingeniero y los haga un artesano, que cobre por pieza fabricada (licencia).
Mi conclusion, el artesano nunca ha sido productivo para las empresas, a lo sumo se le contrata para aprovecharse de el. Asi que nunca seas ingeniero y artesano por el sueldo de un montador de cadena de montaje.

Buenas, yo creo que toda ingeniería podría considerarse como un arte, por arriba leí el ejemplo de un programador que escribe un programa en 5 líneas y otro en 50. Pues en otras ingenierías (como la mecánica) un mecanismo nuevo con un cálculo adecuado podría redurcir y bastante los recursos utilizados en el proyecto. Y estoy seguro que ese ingeniero/diseñador se sentirá un artista.

Entonces como medir a quienes fabrican software?, en muchos casos me han comparado con gente que puede hacer un programa en 1 día cuando por lo menos requiere 3. Claro, que estos programas «bomba» como le llamamos por aquí no tienen funcionando ni 1 día en producción y se están cayendo, o no contemplan ni las condiciones de error más básicas que dicta la experiencia o el sentido común.

Creo que es mejor medir la efectividad de quien desarrolla, por la cantidad de casos de uso que contempla, por la robustez del código (se puede medir en cuantas veces viaja de desarrollo a QA y viceversa), la legibilidad del programa (podría ser por medio del pair programming), la cantidad de comentarios(o la documentación), y el mantenimiento que hay que darle.

Y por ahi tienen razón, el que mide todo esto debe haber programado antes.

SaluDos

Muy interesante tu artículo, Iván. Siempre es bueno meditar sobre esta problemática.

Por cierto, creo haber leído sobre el fracaso que hay cuando Google contrata empleados que provienen de Microsoft: el choque cultural es demasiado grande (insisto, es un recuerdo aunque no puedo citar la fuente). Si esto es así, el tema de la gestión es más sutil de lo que parece.

A riesgo, de ser lapidado, me permito un comentario políticamente incorrecto: mucho me temo que aquellos que defienden a ultranza la faceta «creativa» de la programación y que «necesitan mánagers que no coarten la libertad creativa» son también los mismos que exigen un Colegio regulador de la profesión. ¿Cómo aunar en un mismo modelo conceptual ambos pensamientos?: «los únicos artistas somos nosotros» 🙂

Excelente!

Me parecio muy bueno el artículo-post., especialmente la analogía del programador y el artista. Concuerdo con los demás en que es necesario medir ciertas cosas (o mejor dicho, llevar un histórico) pero tampoco nos debemos atener a ello como si fuera una panacea universal. Pero ciertas mediciones, como las de las líneas de código, si que son absurdas, y aun así, todavía se emplean.

Saludos

Siguiendo con la analogía del arte, creo que en la generalidad del artículo se confunde lo que es la creatividad y el arte. Todo Ingeniero tiene que utilizar la creatividad para resonver problemas complejos donde no se puede controlar el entorno.
Quizá de esa forma relacionamos a un artista con un Ingeniero, por medio de la creatividad, pero si pensamos desde el otro lado, el artista es un ingeniero.
A que me refiero, al músico por ejemplo, el contrapunto las «reglas» para la armonía, la relación entre el ritmo, la melodía y la armonía. No soy conocedor del tema de la múscia, pero entiendo que una persona con 12 años de estudio en piano puede interpretar una gran obra, pero sólo alguien con «Creatividad» e incluso genialidad puede concebirla.

De la misma manera en que hay artistas creativos y otros tipo Salieri, hay Ingenieros que dentro de las buenas práticas de la Ingniería de Software, pueden aplicar su creatividad para llegar a una solución que es una pieza sin igual, una obra de arte.

Yo no creo en el numero de líneas de código, sin embargo es una métrica que tiendo a utilizar para por lo menos darme una idea del tamaño del módulo/sistema.

Sé que el utilizar la metrica anterior es como comparar el peso de un avión (¿entre más pesado es mas eficiente?), pero ¿cómo medir entonces el progreso, tamaño o alcances de un proyecto?.

Ya se que salen con la típica frase «por el numero de funcionalidades» pero ¿acaso no hay funcionalidades muchisimo más complejas que otras? ¿acaso toooodas las funcionalidades son del mismo tamaño o por lo menos de tamaños similares?

Definitivamente comparto la idea de que el desarrollo de SW es más similar a un proceso artesanal que industrial. Llevo ya 18 años de programador y creame, si no estoy «inspirado» por mas motivado ($) que este, sencillamente las cosas no me salen.

Pero eso no me gusta, me gustaria tener control de mis estimaciones, me gustaria tener parámetros que se pudieran medir confiablemente, me gustaria no desvelarme tanto y me gustaria conocer el verdadero tamaño de un proyecto A PRIORI.

Yo no creo que programar sea un arte, ni el programador un artesano.

Como ejemplo lo que dijo creo que Dijkstra hace ya unos años y que describe la diferencia entre un artesano y lo que debe ser un buen programador, él completaba este refrán:

«Quien hace un cesto, hace un ciento…» a lo que Dijkstra añadió: «Sí, pero no hace un millón de cestos».

El desarrollo software tiene que orientarse a lo más abstracto que se pueda, y para ello, el programador debe estar muy formado.

He trabajado en empresas con programadores «genios» y como decís por ahí alguno, los «genios» son aquellos que salen de las lámparas maravillosas y «parece que arreglan» problemas de codificación, pero luego, cuando el cliente se da cuenta de que la solución no hace lo que él quería, hay que volver a sacar al «genio» de su lámpara porque nadie más entiende su código, porque no aplicó las normas de codificación de la empresa (nomenclatura y demás)…

Por otra parte, los programadores «genio» suelen ser aquellos que programan por hobby, se iniciaron en la programación por hobby y no tienen las bases que un desarrollador debe tener… al menos conocer el ciclo de vida de un producto software. Además, estos «genios» tienden a querer reinventar la rueda. He visto a «genios» empleando una semana en programar una solución, en lugar de pararse una hora a buscar una solución que ya exista y resuelva el problema… Es una necesidad constante de «reinventar la rueda» la de los «genios».

Antes que nada muy bueno el articulo.

Creo que algunos Programadores somos artesanos otros no lo son, simplemente lo hacen como mecanicamente. Nose cuales somos mejores o si hay mejores o peores.

Lo que si creo es que el programador artesano no esta hecho para trabajar en una consultora o en ese tipo de empresas que quieren produccion rapida a costa de 6 meses arreglando bugs (pero el proyecto se pago casi en su totalidad, ahí esta el negocio). Los que somos artesanos queremos hacerlo bien y si un dia no estamos inspirados vamos a producir menos y metete tu metrica por el recto, por eso creo que estamos hechos para trabajar freelance o en empresas chicas donde las condiciones de tiempo las pongas y no te las impongan.

Ojalá un dia se reconosca la informática como un arte, y no se siga pensando que lo unico que implica es hacer codigo. Donde esta la arquitectura de un software? ojala no se pierda eso que para mi es lo mas lindo de este trabajo.

Ojalá un dia sea manager y pueda cambiar las cosas desde abajo y no tener que irme por estas desconforme.

Saludos colegas.

Creo que se necesita creatividad para ser programador, y un poco de artista. Osea creatividad para tener ideas, para ver las cosas desde otro angulo, pero lo de artista, depende cuanto de «uno» pone en el codigo quiero decir que el resultado del diseño (el que no esta impuesto) puede mostrar la personalidad de uno (y eso es el arte, porque el arte puedes hacer cosas bonitas y a la vez inutiles, o feas pero con significado pero que descubre o oculta lo que uno es), depende como se mire, Creo q hay que tener una pizca de todo.

Por ahi alguien comento «Llevo ya 18 años de programador y creame, si no estoy “inspirado” por mas motivado ($) que este, sencillamente las cosas no me salen.» …. pues algo asi me paso todo el año pasado, entre a una empresa de software para hacer mantenimiento, no era dificil, pero no se porque empece a perder el toque, le deje de tener afecto a «programar» , cumpli con mi trabajo, pero renuncie luego, para un projecto freelance,el cual digamos recibio todas las consecuencias negativas d mi trbajao anterior. Me senti desmotivado, nada ni lo que iban a pagarme me hizo querer seguir. El año pasado ha sido muy duro creativamente hablnado, bloqueado.

Afortunadamente este año le estoy volviendo a agarrar el gusto a la programacion.

Buenas,

Aunque entiendo lo que quieres decir, creo que equivocas el símil con la industria.

El programador es como el ingeniero que diseña un poducto ( de hecho somos todos ingenieros, unos industriales y otros informaticos XD ) y no como el que operario que produce el diseño que un ingeniero desarrolló.

Ambos ( industrial e informático ) deben desarrollar un producto robusto, tolerante a fallos, fácil de reproducir, de usar, etc, etc…

La informática es una industria, pero un poco peculiar, pues el coste de producción de sus artículos ( o de las copias, como se prefiera ) tiende a cero.

El problema viene cuando, como directivo tienes que premiar a aquel que se esfuerza en que sus diseños sean buenos, aquel que termine en plazo los proyectos, etc. Yo aún no he encontrado la manera…

Interesante cuestíón … Nacho me parece muy cabal lo que dices. Es cierto que hay que aplicar de alguna manera un criterio y una norma para hacer el código legible, reutilizable y sobre todo no perder el tiempo reinventando ruedas que ya existen. Tambien es verdad que se pueden hacer muchos tipos de ruedas y de hecho hay toda una industria y tecnología dedicada a ello. Nacho evita caer tópicos de lo contrario das por supuesto cosas que quizá sean obviedades parciales. Efectivamente debe haber un equilibrio entre el dogma y la creatividad. Veo a diario a jovenes programadores brillantes estancarse con auténticas chorradas por falta de creatividad. Ni mucho menos todo esta inventado ( y menos disponible gratis ) y cuatro lineas de código bien hechas siguiendo una norma y un orden con un toque de creatividad son puro arte. Si luego viene un memo incapaz de entenderlas … se ha equivocado de profesión. La creatividad es el 50% de un informático, de lo contrario los programas se harían solos.

Hay programadores que solo valen para picar lo que se les manda pero no los denominaría informáticos. Luego están los analístas y directores técnicos; capaces de dar soluciones técnicas a problemas complejos o marcar el camino y las directrices para conseguir una solución. Por último los jefes de proyecto y gerentes … deben saber coordinar a todos. La creatividad es la diferencia y la única característica que nos distingue de las máquinas.

Directa o indirectamente estás hablando de una métrica más, más humana y más racional, más lógica, que no sólo usa google, también otras empresas de éxito de varios tamaños (pero todas rentables) como son 37Signals, FaceBook, Google, Nokia… se trata de las metodologías ágiles de desarrollo (aplicable tanto en el software como en otras industrias) más concretamente hablo de SCRUM y Extreme Programming.

¿ Artistas o elementos de una cadena de montaje ? Lo que salga más barato, ¡por supuesto!
Evidentemente, implantando un método industrial puedes permitirte sueldos más bajos y, en caso de querer ganar más, entrenar a una casta de monos tecleadores con las mentes limitadas genéticamente para sus oscuros fines (muy simpáticos, eso si).

Es curioso que hables de managers del s.XX usando tópicos sobre programación del siglo XX. Hablar a esta alturas de artesania o inspiración hablan a las claras de la escasa concienciación obtenida en el uso de procesos y modelos para crear software de manera previsible. No son ingenieros, son otro cosa

La programación es tan arte como la pintura de brocha gorda, al que le toca pintar de blanco una pared poco arte desprenderá, tendrá su experiencia y su savoir faire para dejarlo perfecto y encontrará soluciones brillantes para no cometer errores pero en ningún caso será arte.
Las metricas son otra tonteria, lo que pasa que como medimos software da la sensación de que con un ordenador se podrá contar, madre mia, es como si evaluas a una secretaria por el numero de palabras que ha escrito o el numero de llamadas contestadas.
Un programador es como cualquier otro trabajador y si en el siglo XXI los managers no se dan cuenta de esto es que no merecen ser managers.
Habeis odio decir a alguien que la medicina es como un arte? Verdad que acojonaria? pues lo mismo hombre, lo mismo.

De programadores hay como de todo lo demás, por cada mil mediocres uno bueno.

Una visión pedante de la vida diaria de un programador cualquiera. Y una manera perfecta de tachar al programador de vago sin la suficiente profesionalidad para hacer frente a una gráfica de tiempos.

Existen normas y son para cumplirlas, en mayor o menor modo pero para cumplirlas. Al igual que un lenguaje de programación es un conjunto de normas para que un programa realice sus funciones adecuadamente, un Jefe de Equipo debe saber para gestionar su trabajo cuánto tiempo aplicarán sus empleados en realizar sus tareas. Decir lo contrario es tirar piedras sobre el propio tejado.

¿Hablamos de métricas? No sé por qué la idea global que me ha quedado en la cabeza tras leer este artículo, es la simple gana de plasmar el idealismo que se da últimamente en las nuevas tendencias empresariales: Google.

Señores, dejemos de creernos diferentes, póngase a trabajar.

La verdad es que creo que todo el mundo tiene un poco de razón, pero pienso luego insisto … después de 20 años dedicandome a esto veo que hay dos caminos, los dos igual de válidos. El que no tiene creatividad no tiene que hacer otra cosa que picar lo que le digan y punto, seguir las normas y no salirse de ellas. El que demuestre entusiasmo y creatividad tiene derecho a ser considerado algo más; por lo menos a diseñar de cero aquello que los otros no pueden ni siquiera imaginar. Diseño de software = creatividad, programar tambien pero quizá no sea tan necesario.

En fin, no os quemés e intentad ver la vida con un poco de ilusión. 😉

Solo lo entiende quien lo ha echo ???….Pues eso ya es una buena metrica en general para saber si eres buen programador o no…ya que el mediocre generalmente realizara un código tan simple que cualquiera lo entiende (cursillo de x horas de VB y venga a hacer bucles en vez de una buena SQL) … si no lo entiendes,quiere decir basicamente que estas mirando algo que esta fuera de tu nivel. así de claro y así de simple. A parte quedan comentarios, convenciones de programacion (prefijos en variables,etc.), control de errores, robustez, rendimiento…que son diferentes factores y no estan reñidos con la complejidad del código.

Saludos.

Yo diría que hay que diferenciar entre los que se dedican a hacer aplicaciones a medida para empresas, que en general son aplicaciones de gestión en las que hay mucha problemática común a otros proyectos y los que desarrollan un software complejo a largo plazo.
No es lo mismo estar en Accenture haciendo portales web para empresas, que desarrollar el nucleo del linux. El primero estaría más cerca del peón y el segundo más cerca de Leonardo da Vinci.
Por otra parte , me siento identificado con la medida «patás». Creo que está bastante generalizada en todo el que da trabajo a un programador.

Muchas gracias por todos vuestros sabios comentarios.
Quizá muchos de los comentarios se refieren al tema del programador artista/artesano. Estuve tentado de no decir nada de este tema porque se que es muy polémico y que las posturas suelen estar muy encontradas, pero finalmente creí que era imprescindible dejar clara la base de partida para poder llegar a la conclusión final: las métricas minan a los buenos programadores.
Fijaos también en el adjetivo «buenos». Evitentemente no todos los programadores son iguales igual que no todos los artistas son iguales ni todos los carpinteros son iguales. Hay programadores que simplemente cubren el expediente y hacen lo mejor que pueden su trabajo. Pero esos programadores no le interesan a las empresas que buscan la excelencia (por eso ponía el ejemplo de Google). ¿Os imaginais a Linus Torvalds trabajando en Accenture? ¿Verdad que no? Pues al revés mucho menos, pq la necesidad te puede llevar a rebajar tu nivel de exigencia, pero esa necesidad nunca lo va a tener una gran empresa pq desapareceria. (Aquí uso gran empresa como empresa que busca la excelencia, no como empresa con mucho dinero o muchos trabajadores).
Todo esto da para otro post. Sobretodo falta en este post algo muy importante: ¿qué debe hacer un manager del siglo XXI para valorar a sus empleados? Por cierto, ahora que lo comento, ha habido también un poco de confusión con el tema de evaluar empleados y evaluar producción. Para evaluar la producción SI que pueden llegar a ser útiles las métricas (p.e. en una consultoria es necesario tener métricas para poder dar una estimación y un presupuesto al cliente). Pero mi tesis es que NO sirven para nada para evaluar a los programadores. Por ahí alguien decia que entonces el típico «vende-motos» saldría ganando y otro decía que el amigo del manager sería siempre el mejor recompensado. Mi respuesta a esto es simple y clara: entonces el manager no está haciendo bien su trabajo ya que o bien no es capaz de llegar a conocer a sus programadores (vende-motos) o tiene prejuicios frente a ellos (amiguismo). El manager ha de ser capaz de librarse de prejuicios y de mirar más allá de lo que los programadores le digan. Pero bueno, esto ya da para otro post…

Hola, interesante el punto de vista pero no estoy tan de acuerdo…. llevamos años y años mirando como producir un software de calidad…. creería que el verdadero artista sería el manager que es capaz de salirse de este esquema tan rigido de las metricas siempre y cuando el trabajo lo amerite. Quién es el artista, el obrero o el arquitecto? El programador por lo general no tiene idea del negocio y por esto interpreta cosas que llevan a errores muy costosos para las organizaciones… asi que estoy de acuerdo en que la programacion no es un proceso mas, no se debe ver ni medir como en la revolución industrial en donde se cuenta absolutamente todo para valorar a un trabajador…..el punto es que el manager o analista es el verdadero artista que logra orquestar la creatividad de su programador con el negocio…que opinan?

Buenos Días, esta es una interesante discusion bizantina, programar arte o ingenieria? y les cuento soy Ingeniero de Sistemas, para lo que estudie 6 años y aunque ahora soy director de proyectos, fui durante 10 años programador. y efectivamente creo que la programacion es un arte, sin embargo no esta excenta de metricas y mediciones para mejorar calidad y rendimiento, no debemos olvidar algo que no ha sido mencionado y es que esto es un negocio (industria que genera lucro a quien pone el dinero), no es lo mismo encerrar a un pintor durante un año en su estudio a ver con que genialidad sale, o con cuantos cuadros sale, a encerrar a un programador durante un año a ver con que producto sale.

El software se hace por encargo, y por el se paga, y para el empresario es necesario obtener la mayor rentabilidad de su negocio. y para eso esta PMI, CMMI, y todas las buenas practicas que te apetezcan.

Cada vez que teminas un programa, te gusta mas o menos que otro, y puedes sentirte orgullo de la genialidad que escribiste, sin embargo no lo puedes colocar en una galeria para que el publico lo aprecie, y por supuesto no podran poner tus programas e una subasta de artes.

Muchachos, programar es un arte pagada por la industria. y entre mayor sea tu rendimiento mejora para la industria.

Iván Gadea, creo que diste más en el clavo con tu comentario #40 que con todo el artículo. ¿Pero no está todo esto muy trillado?

Quiero recalcar ciertas líneas:

«Las métricas minan a los buenos programadores.»

«Pero esos programadores no le interesan a las empresas que buscan la excelencia.»

«¿Qué debe hacer un manager del siglo XXI para valorar a sus empleados?»

«Pero mi tesis es que NO sirven para nada para evaluar a los programadores.»

«Confusión con el tema de evaluar empleados y evaluar producción.»

«Mi respuesta a esto es simple y clara: entonces el manager no está haciendo bien su trabajo.»

En mi modesto conocimiento de economía y como trabajador no veo presente ningún cambio significativo del modo de negocio de las empresas, ni costumbres de sus empleados o directivos. ¿Entonces realmente qué tratamos? Claramente el concepto global del artículo es inconexo, más psicológico que contencioso.

Con aire desenfadado pero tratemos de exponer bien nuestras ideas. Voy a cerrar mi opinión de la forma más sencilla: todos tenemos razón. Bien, relean las anteriores líneas que indiqué y trabajen más lo obvio.

Opresión del programador, excelencia, evaluación, prejuicios. Cada uno es libre de elegir su trabajo, de aplicarse al máximo, de trabajar por ideales y con ilusión, todo esto es inherente a uno mismo. Las métricas son una herramienta de trabajo para la empresa, nada más. No hay cambios importantes en las conductas de los trabajadores frente al trabajo, siempre fueron las mismas. Cada uno marca sus prioridades, cada uno busca su lugar. Estás contento o no.

La cuestión es que creo que los gestores que aquí llama del siglo XX, generalmente juntan churras con merinas. Una cosa es la productividad real de un programador, y otra cosa son las métricas de software.

Las métricas, como dice eltator bien dicho están bien para medir ciertos aspectos relacionados con el proyecto; ahora bien, el problema básico es usar las métricas para todo:

Dado que como medida de productividad y de «mérito» entre programadores, realmente, las métricas (aún en el caso de los puntos de caso de uso) dudo que den una visión del avance real del proyecto, desde un punto de vista de funcionamiento del programa (incluso en las métricas llamadas «de puntos de función»). ¿Por qué? Básicamente, porque la funcionalidad es algo abstracto y, nos guste o no, no se puede medir. Y es que, si bien se puede medir el número de funciones ya desarrolladas sobre el número de funciones totales a desarrollar, la funcionalidad como adecuación entre el funcionamiento real del programa y el funcionamiento esperado, es algo inmedible.

Comprendo muy bien la necesidad de medir para mejorar la productividad. Me parece muy lógico que se pretenda medir para poder predecir resultados futuros.

Lo que no acabo de ver es que las medidas que se vayan tomando en un proyecto puedan servir para otro proyecto futuro.

Me parece que generalmente las empresas de software lo mismo hacen un programa de gestión para un vídeoclub que para una farmacia.

Y los programas, aunque conceptualmente son lo mismo, en realidad no se parecen en absoluto.

Creo que lo que complica la medición no es que existan distintos tipos de programador, que también, sino que los problemas a resolver son distintos.

No veo cómo las métricas de un programa para una farmacia pueden valer para un vídeoclub, y viceversa.

Por mi experiencia, entiendo que las métricas que tomé mientras desarrollaba el programa para la farmacia, me servirán en tanto mi siguiente desarrollo sea para otra farmacia que funcione más o menos igual.

Usando un símil, no sé si un arquitecto que haya diseñado un polideportivo pueda predecir con poco margen cuánto le costará diseñar un edificio de apartamentos. Y digo diseñar, que no construir.
De hecho, no creo que pueda predecir cuanto tardará en diseñar el siguiente polideportivo, a menos que sea bastante parecido.
Y fijaos que la gran diferencia entre lo diseñado por un arquitecto y por un diseñador de software (o arquitecto, si lo preferís) es que lo que diseña el arquitecto de edificios, será prácticamente lo que finalmente se construirá. De hecho, en muchas ocasiones, el arquitecto podrá hasta realizar pruebas de su producto antes de construirlo.

No sé, no he tenido ocasión de preguntárselo a un arquitecto. Pero en la fase de diseño, no hay métrica que valga.
El arquitecto no sabe de antemano cómo será el edificio antes de tener entre sus manos los planos.
Con diseño en mano, la historia es otra.
Sabremos con bastante exactitud cuánto costará levantar una pared. Y sabremos cuántas paredes va haber que levantar.

Y creo que con el software pasa lo mismo. Lo complicado del software es diseñarlo.
Y lo malo del software es que no siempre sabemos de antemano lo que hay que construir. Muchas veces no lo sabe ni el cliente.
Lo malo, o lo bueno del software, es que cuesta prácticamente lo mismo diseñarlo que construirlo. Por eso, no solemos diseñarlo con todo el detalle que lo haría un arquitecto.
Lo malo del software es que no podemos probarlo antes de codificarlo.

Yo creo que las aplicaciones habría que codificarlas dos veces. Una vez para desglosar todas las características que va a tener. Y otra para aplicar unas buenas prácticas. Os aseguro que la segunda vez sabríamos con bastante exactitud cuánto vamos a tardar. Y podremos mejorar la productividad. Y la calidad.

Y la calidad? qué es la calidad? entiendo que la calidad es la medida de los requisitos satisfechos.

En cuántos proyectos habéis trabajado en los que los requisitos estaban completamente descritos? Los requisitos funcionales, los de seguridad, los de rendimiento, los de interfaz, complejidad, mantenibilidad, etc.

Cuando el arquitecto firma un proyecto, el cliente obtiene un contrato en el que se detalla casi de todo. Y allí donde tenga cabida la interpretación habrá una normativa legal que aplicar.

Y otro tema importante: El arquitecto tiene responsabilidad legal sobre el producto que va a construir. Si no se ajusta a los requisitos, si el edificio no se ajusta a la normativa legal, a la memoria de calidades, etc., tiene que responder por ello.
Eso es algo que no he oído que haya pasado en la historia de la informática. Ni tan siquiera cuando han habido accidentes causados por fallos que hayan derivado en pérdidas humanas.

Creo que la mejora en las métricas y en el aumento de la productividad vendrán determinadas por lo que progresemos en estandarizar, desarrollar metodologías, en crear componentes reutilizables, etc.

De hecho, creo que es algo que deberíamos aprender de las otras ingenierías. Creo que su éxito se basa en que rara vez se construye algo de cero. La mayoría de las veces, el trabajo de un ingeniero se trata de combinar adecuadamente elementos ya desarrollados.

(No lo sé con seguridad. ¿qué grado de fiabilidad hay las estimaciones de proyectos de IT? Un proyecto de IT consiste en combinar eficazmente componentes ya desarrollados)

Respecto al tema de la gestión de recursos, y a la manera en la que se distinguen a los programadores buenos de los malos, por mi corta experiencia en la gestión de equipos, diré que las personas que funcionan mejor en un proyecto no son las que más saben, ni las que tienen más experiencia. Para mí, las personas determinantes en un proyecto son las que se implican más, las más motivadas, las que tienen una gran conciencia de equipo y programan sabiendo que el producto es el resultado del trabajo de todos, y no de uno solo, por muy bueno que sea. Yo creo que todos tienen mucho que aportar. El que tiene más experiencia, el que tiene mucha capacidad de análisis, el creativo, cada uno puede encontrar su espacio.
Por supuesto hace falta gente preparada, con conocimientos, experiencia y cierta aptitud. Pero para mí, lo determinante es que la gente esté a gusto, y sienta que su trabajo merece la pena.

Me parece que los proyectos que carezcan de personas que motivadas, tiene todas las papeletas de fracasar.

Creo que este aspecto de la profesión es igual para todos los trabajos en los que se dependa de la gente.

Y un buen manager, uno del siglo XXI, debe saber gestionar estos recursos, y aportar motivación. Dar su espacio a cada uno, y hacer que se sienta valorado, para que pueda aportar lo mejor de sí mismo. Me parece que da igual las carencias que pueda tener una persona suficientemente motivada. Seguro que se esforzará por corregirlas.

Cristhian, has dado en el clavo en el último párrafo: «Y un buen manager, uno del siglo XXI, debe saber gestionar estos recursos, y aportar motivación. Dar su espacio a cada uno, y hacer que se sienta valorado, para que pueda aportar lo mejor de sí mismo. Me parece que da igual las carencias que pueda tener una persona suficientemente motivada. Seguro que se esforzará por corregirlas.»

Perfecto. Si haces eso en tu trabajo conseguiras que todo el mundo lo de todo. Y si combinas eso con buenos salarios conseguirás que nadie se quiera marchar nunca de la empresa.

Responder a Daniel V. Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *