Si bien suelo coincidir con buena parte de los comentarios de Enrique Dans, creo que esta vez se ha pasado un poco en la simplificación. Lo que dice suena muy "cool", encaja bien con un cierto tono provocador, pero creo que está bastante lejos de la realidad, aunque puede valer como punto de partida para la discusión (lo que por otra parte me parece más cercano a su intención final, aunque esto es asegurar algo sobre lo que no tengo ninguna base.
El argumento, simplificando mucho, es que, en estos tiempos de recorte, es mejro recortar gastos de TIC por la parte de arriba de la pirámide, despidiendo a los directores de Ti que no sean capaces de "escribir el código que genere un ‘Hello World’ en C, HTML y PHP, y extraer ‘Hello World’ de una base de datos MySQL usando un script en Perl".
Con un poco de demagogia, el párrafo de “su enfoque exclusivo a la estabilidad en lugar de a la innovación han llevado a muchos directores de departamentos tecnológicos a convertirse en fósiles que gestionan cementerios de elefantes, en los que toda innovación recibe la calificación automática de “extravagancia” o “pérdida de tiempo” y donde los perfiles más innovadores sales huyendo como de la peste” podría ser contestado con que seguro que esto no es lo que pasaba en Lehman Bro., donde un montón de "perfiles “menos viciados” y con nuevas visiones" se alejó de la estabilidad y califico a los banqueros comerciales de “fósiles gestores de cementerios de elefantes”. En todo caso, este párrafo es un ejercicio de humor que no pretendo que se tome en serio ni sirva para distraer la conversación.
Pero siendo un poco más serio, creo que hay dos ideas a comentar: el inmovilismo de las direcciones de TI y el conocimiento técnico (o de lo último, esto no está claro) del responsable del área.
Coincido en que en muchos casos se puede caer en un cierto inmovilismo en cualquier area de dirección, siendo especialmente problemático para áreas como TI o marketing o incluso producción y logística. En la dirección de TI somos muchos los que preferimos estar en la "penúltima versión" (la última lleva a historias como la de yuki). Y creo que ese inmovilismo no es justificado, pero hay que distinguirlo de la prudencia que debe acompañar el desempeño de la responsabilidad en una empresa. Si tienes el típico cojo-sistema de millones de líneas en, por ejemplo, VisualBasic 6, no tiene sentido ponerte a migrar todo ahora a Ruby. Otra cosa diferente es que aproveches los nuevos desarrollos para hacer ciertos experimentos en nuevos entornos o nuevas tecnologías.
En cuanto al perfil del responsable de área, no queda claro si se refiere a conocimientos técnicos más o menos generales o a estar "en lo último". Lo primero, sinceramente, creo que no es la regla general. La mayor parte de los directivos de áreas de TI que conozco han pasado por etapas más técnicas o de más detalle como programadores o analistas o jefes de proyecto. Otra cosa es que hace 10-15 años ellos programaran en Cobol, Clipper o VB3 y eso no es lo que se utiliza ahora. Pero la lógica de los sistemas es la misma. Para mi la diferencia entre entender los sistemas no entenderlos es el "saber como piensan", y eso no cambia con el lenguaje de programación. Y el que escribía Cobol puede leer C# o .net o Java cuando es jefe de equipo, aunque no creo que necesite hacerlo si es el director de sistemas. No veo al director financiero haciendo apuntes contables o al de operaciones cargando camiones o apretando tuercas en una cadena de montaje.
Puede que yo esté equivocado, pero los tiempos en que el analista dependía del director financiero o que el responsable de compras, como premio a la gestión de telefonía, era ascendido a director de informática, han pasado hace mucho (o yo he tenido mucha suerte en lo que he visto).
Por cerrar con otra nota menos seria, sé escribir una query de SQL razonablemente (sigue habiendo matices entre Oracle, SQL y mySQL que me obligarían a un par de intentos), no sé escribir C (aunque piqué unos miles de líneas en Clipper y revisé y probé otros miles de VB) y, en cuanto a web-dos-cerismo, tengo blog, twitter y la intranet corporativa basada en software libre, igual que la herramienta de gestión de proyectos. Es decir, que no me veo directamente implicado en el ERE que Enrique sugiere, por lo que este no debe ser considerado un post defensivo.
Por último, me encanta este comentario de Gorki:
Un gerente de sistemas, debe saber de informática, pero más aún saber de información Para que quiere los datos la empresa y que va a hacer con ellos es bastante mas complejo que saber como se guardan y recuperan esos datos en la BBDD. Lo primero te lleva media vida de trabajar en empresas, lo segundo te lo enseñan en cualquier academia en tres meses,

20 sep 2008 | 10:27 AM
De acuerdo contigo en que no es necesario que el director financiero haga apuntes contables, pero hay que reconocer que muchos directores se acomodan en su función de gestión y dejan de lado el aprendizaje o el gusto por mantenerse al día.
Me gusta la frase con la que acaba SJ su discurso en Stanford en 2005, "stay hungry, stay foolish", creo que resume perfectamente la actitud que debería tener cualquiera que se relacione con la técnica -un director debería ser el faro que guía, y no convertirse solo en un gestor de como recortar el presupuesto o en un experto en sortear los entresijos de un comité...
Por cierto, ¿qué software libre de gestión de proyectos utilizas?
20 sep 2008 | 11:08 AM
Esta conversación, es una buena excusa para plantearnos -dentro de la forma más aséptica posible, porque somos humanos, con nuestro corazoncito- dentro de nuestras fortalezas/debilidades ¿cuáles son las fundamentales para realizar un trabajo correcto como "gerentes de sistemas" (ojo: afino mucho, no digo "gerentes de compras" ni "gerentes de producción" y digo "realizar trabajo correcto" no digo "sobrevivir" ni "promocionarse"):
- ¿Qué cualidades técnicas?
- ¿Qué cualidades humanas?
Está claro que "el burro grande, ande o no ande" pero intento extraer la esencia del puesto, lo impresicindible, como objetivos para concentrarme.
Tú mismo nos contabas cómo gestionabas a un empleado que pedía una reducción de jornada por paternidad. Esa situación ¿supone una pérdida de rendimiento para tu departamento? ¿supone un desequilibrio en tu ecuación coste/valor?
¿De qué sirve ser un excelente técnico si tienes un departamento en pie de guerra?
¿Se puede ser gerente de sistemas sin excesivos conocimientos técnicos, pero con la cualidad de extraer lo mejor -profesionalmente hablando- de la gente (bien por los métodos estilo "Casa de la Pradera", bien por los métodos estilo "Glengarry Glen Rose")? (ojo, esta pregunta es retorcida: no digo cuál método "gusta más" sino cuál método "es más oportuno" y no "para que la gente sea feliz" sino "para extraer el máximo potencial profesional" (aunque ambos factores pueden estar correlacionados)
En fin, dejo de enrrollarme. Aunque siempre es un placer escuchar vuestras reflexiones.
21 sep 2008 | 11:03 AM
Ante todo, gracias por seleccionar un comentario mio y enlazar a mi blog.
Sigo diariamente a eDans, y son muchas cosas he aprendido de él. Dicho esto, debo informarte que tiene una vertiente "populista" que le lleva con frecuencia a tratar temas con una visión estereotipada y demagógica de la realidad. Los viejos están desfasados, la SGAE es una cueva de ladrones, los políticos no entienden de Internet, el código abierto supera al código propietario y cosas parecidas, que para el sob dogmas de fé que no se precisan confirmación científica. Son lo que yo he llamado las "fobias de Dans".
Desgraciadamente en estas "fobias" tiene una partida de ardientes y fieles seguidores, que generalizando quizá injustamente, que no pasan del nivel de becarios en su primer trabajo. Como cuando saca estos temas a colación, obtiene 30 comentarios elogiosos a su persona, le resulta difícil ver con ecuanimidad el asunto y al contrario cada vez, se radicaliza más en sus ideas,
No obstante eDans sigue siendo una de las mentes mejor amuebladas del país y basta saltarse sus post de “fobias”, para tener una actualizada y lúcida fuente de información sobre lo que ocurre en Internet.
22 sep 2008 | 10:03 AM
E. Dans es un populista tecnólogico, y la mitad (yo opino que bastantes mas) de las cosas que dice no se sostendrían bajo ningun analisis serio, siempre y cuando este no venga de gente que cree que solo existe la tecnología.
Es el mejor ejemplo de "el papel lo aguanta todo" (en su caso sería más bien "las webs lo aguantan todo") que se da en muchas presentaciones.
22 sep 2008 | 07:03 PM
Sacha, lo que cuentas de Jobs es la clave. Pero vale igual para el director de TI que para el financiero o para un programador. Cierto que es más fácil que se acomode alguien de 45 que alguien de 25, pero no sería el primer caso.
Gorki, soy lector fiel de Enrique desde, al menos, 2003. Fue profesor mío y sigo teniendo con él una cierta relación. Es el primer blog que recomiendo a quién quiere estar al tanto de "lo que pasa". En absoluto quiero descalificarle a él o a su blog, pero en este caso no puedo estar de acuerdo con lo que mantiene y me apetecía más contestar aqui que en su blog, donde es fácil que una opinión se pierda entre las docenas de comentarios (como dice Luis, muchas de ellas con poca base empresarial). De hecho, creo que él mismo ha lanzado el post con idea de provocar, pero no tiene mucho sentido que siendo profesor de un Máster en Dir. S. I. ponga en tela de juicio a sus alumnos.
Como dice patata, la evolución en las responsabilidades va añadiendo componente de relación/gestión a tu trabajo, llegando a superar en dedicación esta parte a los conocimientos técnicos necesarios.
23 sep 2008 | 12:38 PM
Por cierto, Sacha, lo de los proyectos es una intranet creada con tiki-wiki y como herramienta de seguimiento de proyectos utilizamos Projity OpenProject. No es Microsoft Project, pero no cuesta 600 euros por equipo.
23 sep 2008 | 10:15 PM
Hola Rafa, sigo tu blog desde hace tiempo y todo este hilo me ha movido a escribir, aunque sea con caracter reflexivo, respecto al enfoque de la industria de TI al menos en éste país (que es el que conozco en primera persona) y el de EEUU y otros vía internet, compañeros, etc.
El caso es que siempre me he preguntado porque en el sector de las TI se define, generalmente una carrera profesional que arranca en el ámbito técnico y termina o deriva hacia el de la gestión (en un % muy elevando de empresas). Es evidente que uno siempre quiere mejorar salarialmente y esa es la única forma de conseguirlo. Repito, en un % elevado y por mi experiencia en diferentes multinacionales, lo constato. Para mi, es un lamentable error, porque se dejan de lado muchas de las aptitudes que son muy importantes y que determinan en que perfiles un es mejor, rinde mas, está mas motivado, etc. En EEUU todos conocemos los casos de programadores muy bien pagados y bien considerados. En España, los programadores, con la responsabilidad que conlleva, son muchas veces los peores pagados y los menos experimentados.
¿Por que no seguir programando con 55 años? ¿Por que gestionar personas si odias gestionar personas? ¿Por que ser Account Manager si te cuesta relacionarte y hablar en público?
Creo que si todos marcaramos los cauces de nuestro perfil en base a un conjunto de competencias y, evidentemente revisaramos el concepto de perfil/salario estariamos mucho mejor. Indudablemente, aumentando la productividad y la motivación. Todo ello enlaza también en que un Director Técnico, por lo que hemos hablado tiene que tener unas competencias muy variadas sin dejar de lado el aspecto de innovación y técnico. Pero no creo que sea necesario que el Director de un equipo de F1 tenga que ponerse a cambiar ruedas.
24 sep 2008 | 09:56 AM
Gracias, Antoni, por pasarte por aquí y por comentar.
Yo también me he hecho muchas veces la pregunta "¿Por que no seguir programando con 55 años?". Recuerdo el caso de un excelente programador que trabajó conmigo. No sólo era fantástico generando código, sino que siempre estaba pendiente de nuevas tecnologías, investigando y probando cosas nuevas. Pero, claro, eso no era lo que se esperaba de él en su empresa según pasaba el tiempo. Llego el momento en que tenía que pasar de un excelente técnico a, seguramente, un mediocre comercial. La unica opción fue dejar la empresa en la que estaba por una en que podía seguir siendo técnico, creciendo en salario y aportando a su empresa en lo que sabía hacer mejor: solucionar problemas técnicos. Es increíble la capacidad y conocimiento que desaprovechó la empresa que tuvo que dejarlo marchar.
24 sep 2008 | 01:29 PM
Aparece aquí un hilo iniciado por Antoni Gimeno muy interesante la carrera de un TI normal- Se inicia de Programador, en un momento asa a Analista y más adelante a Consultor hasta acabar en director de TI
Cada uno de estos saltos son saltos en el vació. Un programador va adquiriendo experiencia, cada vez es mejor y asciende a Analista Orgánico. Primer salto en el vacío. Uno puede ser un perfecto programador que encuentra las formas óptimas de acceder a una BD de forma que no se interrumpan los procesos y no saber diseñar con corrección una pantalla de captura de datos pues son dos tareas que nada tiene que ver entre sí.
Sigue ascendiendo como Analista y llaga a Jefe de Proyecto, o Consultor. otro salto en el vacío, ahora tu trabajo es dirección de un equipo de técnicos a tus órdenes y vendedor y relaciones públicas de los ticónicos con el usuario, cliente, quien consuma los programas que hace el equipo. Nada que ver con ser capaz de diseñar unos flujos de información en un determinado departamento en una empresa y los inputs y outputs de datos desde/hacia otros departamentos de la empresa.
Por último llagas a TI tienes que manejar un presupuesto, controlar un amplio número de personas internas y externas, hacer compras y estudias tecnologías para adoptarlas emigrando lo que hay o descartarlas por no ser prácticas en tu caso. Nada que ver con lo anterior.
Este es un motivo por el que hay mucha gente incompetente en este área tiene cuatro ocasiones en su vida para llegar a su nivel de incompetencia, raro será que no caigas en alguno,
Pero esto está montado así y todos queremos ascender porque todos queremos ganar mas y tener mayor parcela de poder.
28 sep 2008 | 05:26 PM
Mi puesto de Director de Sistemas fue "descabezado" en Abril de este año cuando ya se olía el descalabro del sector de la construcción y subsiguientes.
Para hacer bulto en la estadística, diré que blog tengo y mantengo, y que cualquiera de los hola_mundos que pregona Dans pueden resolverse con unos minutillos de búsqueda en Google. Lo que es harina de otro costal es programar algo más complejo en esos lenguajes, algo útil. De cualquier modo, durante mi ejercicio profesional tampoco he tenido entre mis funciones la programación, que habitualmente se subcontrataba, si bien requerían ser capaz de efectuar revisiones ocasionales de código a fin de mantener el control de los proyectos y el SLA compliance.
Estoy de acuerdo en que a un director de operaciones no se le ve apretar tuercas, aunque sí he visto a algún director financiero haciendo apuntes contables.
Atte.: Su Seguro Lector,
28 sep 2008 | 06:34 PM
Creo que a todos nos queda claro. Seamos serios. los comentarios en el post de edans hacen referencia a programar un "Hello wordl" y acceder a una base de datos MySql. Evidentemente argumentos poco sólidos cuando detrás de un lenguaje de programación, que únicamnte es el medio, es la herramienta, está el análisis, están los patrones de diseño, la definición de una arquitectura software, arquitectura hardware, diseño de base de datos, tuning, test de rendimiento, etc.. que deben ser tenidos en cuenta y que no puede evidentemente acaparar una única persona sino diferentes especialistas bien coordinados por un jefe de proyecto y liderados en última instnacia por un Director de Sistemas, responsable de departamento o como se le quiera llamar.
Creo que lo que hay que valorar es a donde puede uno llegar, lo que está preparado para aprender y su motivación y no el lenguaje de programación que conoce. Es absurdo. Hoy puedes utilizar diferentes frameworks: Ruby on Rails, Grails, Seam de JBoss, GWT (Google Web Toolkit), Zend (PHP) incluso el ultimo de Google: Android. Todos tienen cosas en común: parten de una buena definición de la arquitectura software, y en la mayoría de casos hacen uso de patrones de diseño bien conocidos y con muy buenos resultados.
Entonces mi pregunta es: ¿Es realmente importante conocer un lenguaje de programación? En fin, no se trata de dejarlo en un simple "hello world".