Conviértete en una Caja Negra
En los tiempos que corren, con una crisis galopante o desaceleración -según se mire-, quien más quien menos teme por su puesto de trabajo. Sin embargo, no hay porqué preocuparse. Si tienes miedo de que tu empresa te la juegue, si temes ser despedido, siempre puedes intentar convertirte en una ‘caja negra‘ y agarrarte a la silla como un halcón a su presa ¡Conviértete en una caja negra!
Pero ¿qué es eso de una ‘caja negra’? Citando a Ixchel Hernández, una caja negra o blackbox es “una unidad cuya estructura interna se desconoce, pero cuya función está documentada. La mecánica interna no es algo que interese al que utiliza una caja negra para obtener una función“.
Básicamente y hablando claro, una caja negra es algo que funciona aunque no sepamos cómo.
¿Y cómo puede alguien convertirse en una caja negra? Sencillo: dominando y gestionando algún conocimiento, proceso o tecnología que no conozca nadie más y que no esté documentado.
No conozco lo que ocurrirá en otros sectores, pero en informática tenemos muchas oportunidades para convertirnos en auténticas blackboxes, ‘agujeros negros’ de conocimiento. Os detallo algunas de las más importantes:
- Convertirse en ‘el chico de los servidores’. Ser el único que se atreva a meter mano en el fichero de configuración httpd.conf del Apache, o el que conoce cómo se hace virtual hosting con Tomcat, te proporciona un halo de sabiduría que para sí quisiera Gandalf el gris.
- Una solución – Un hombre. Conseguir ser el único que domine una tecnología -cuanta más crítica mejor- o un programa de uso intensivo te convierte automáticamente en una genuina caja negra. En este apartado podemos encontrar mucho intrusismo profesional, como por ejemplo, el del tipo que domina ‘bestias del averno‘ como el Nominaplus o Documentum. Aunque también nos podemos encontrar enormes blackboxes en el mundo del desarrollo, como el tío que sabe depurar todas las fases de JSF, el que sabe cómo hacer bloqueos pesimistas con JPA 1.0 o, aún mejor, el que configura BIEN log4j y te deja rezando para no tener que modificarlo nunca jamás.
- Gestionar el servidor de correo. Como ya escribí hace tiempo, “quien domine el correo electrónico, dominará la empresa”. Mejor cuanto más críptico sea el servidor de correo, por lo que recomiendo un sistema propietario, tipo Exchange de Microsoft o peor. Si encima podemos complicarlo aún más, integrándolo con LDAP o algo similar, mejor que mejor.
- Ser la Aduana. Ésta es, sin duda alguna, la oportunidad más poderosa. Ser el único que controle el firewall, el antivirus o lo que sea que haga que la gente no pueda visitar el Feisbuj, el Tuiter o páginas sobre física cuántica durante su jornada de trabajo, te convierte no en una caja, sino en un arca negra de proporciones bíblicas.
Con todos estos consejos, seguro que ya sabes cómo convertirte en una caja negra o puede incluso que ya lo seas. Pero ¿de verdad te sientes más seguro en el trabajo? ¿De verdad te gusta ser una caja negra?
Piénsalo durante un instante. Ser una caja negra no es nada bueno, sino todo lo contrario. Si has conseguido convertirte en una caja negra es porque tu empresa o tú estáis haciendo algo mal, rematadamente mal.
Si has hecho todo lo posible por convertirte en una caja negra y luchas por seguir siéndolo, párate un momento y reflexiona sobre porqué lo haces ¿De verdad necesitas serlo para sentirte seguro en tu puesto de trabajo? ¿No crees que sería mucho más productivo y beneficioso para ti y la empresa que utilizaras todos esos esfuerzos en convertirte en mejor profesional? ¿No preferirías aportar valor para demostrar lo rentable que es pagar tu nómina? ¿No te sentirías mejor compañero compartiendo tu conocimiento con tus compañeros y enriqueciéndote a su vez con sus aportaciones y conocimientos? Basar tu trabajo en ser o no ser una blackbox es reconocer que estás fuera de mercado. No eres competitivo, estás fuera.
Podrías empezar por documentar todo tu conocimiento en un wiki interno o en un blog corporativo. Si aún así, crees que dejar de ser una caja negra puede colocarte en una peor posición en tu empresa, te recomiendo que busques otro trabajo. Quizás no merezca la pena seguir trabajando en un sitio así.
Si como empresa, Jefe de Proyecto en particular o gestor de personas en general has permitido que una persona se convierta en una caja negra, revisa tus criterios de gestión. Estás haciendo algo mal. Nadie debería ser una caja negra. Todos los equipos de trabajo deben ser multidisciplinares y flexibles. Eso no quiere decir que no pueda existir especialización en las tareas -siempre te encontrarás a alguien a quien se le dé mejor maquetar una página web que programar algoritmos genéticos-, pero un buen gestor tiene que intentar que la rotación de personal, las vacaciones o las bajas no afecten de forma dramática a la producción de un equipo de desarrollo.
Algunos dirán que la teoría es muy bonita, pero que en la práctica no disponen de recursos o tiempo para implementarla. Todo son excusas. Como empleado debes hacer comprender a tus responsables la importancia de documentar y compartir el conocimiento o know-how que vayas adquiriendo. Como gestor, tu obligación es solicitar más recursos y advertir de los riesgos a tus superiores si el día a día del trabajo está comenzando a crear cajas negras.
El primer paso para intentar solucionar el problema es reconocerlo. Hola, soy David Bonilla y, sí, soy una caja negra y no estoy nada orgulloso de serlo. ¿Y tú? ¿Eres una caja negra?
Tags: blackbox, caja negra
Categorias: gestion de personal, tecnologías de la información | 22 comentarios
22 respuestas a “Conviértete en una Caja Negra”
Buenas David.
Al empezar a leer el artículo me estaba asustando, quieres ser una caja negra? no por Dios, si yo tengo más cosas dentro que la caja de Pandora…
Donde trabajo actualmente, somos 4 en el mismo departamento, para 3 sistemas, y ninguno sabemos hacer el trabajo de los demás, esto no son cajas negras, son cuatro ataudes bien negros.
Saludos.
Hola Oscar,
Celebro que no quieras ser una caja negra. Me temo que más de uno se va a llevar un buen susto hasta que lea el final del artículo y alguno probablemente ni llegue y salga de aquí pensando que soy un terrorista laboral
¿Tienes algo pensando para que dejéis de ser cajas negras en el trabajo? ¿alguna idea?
Un saludo,
David
El mayor problema es que el trabajo diario suele desbordar estas "cajas negras", con lo que siempre es "Si, eso estaría bien .. pero es que ahora me pillas un poco mal" y claro, luego llegan las bajas, las vacaciones, etc,etc y todos a echarse a temblar.En nuestro caso partiuclar los "superiores" tampoco tiene una gran visión al respecto.
En otros ocasiones he propuesto, y creo que ha funcionado bastante bien, algo de XP resolviendo alguna incidencia del sistema en concreto, puedes ir explicando como atacas los problemas, cómo funciona todo etc,etc,. No puedes pretender tener a dos resolviendo lo mismo, eso no se lo creen por estos lares, pero si es 1 o 2 horas al día, la cosa cambia y al finla se verán los resultados.
Pero lo dicho anteriormente, muchas veces es un problema de actitud, del currito, o de falta de visión del jefe.
Saludos.
¿Cuando hablas de XP te refieres a hacer algo de Pair Programming? ¡Muy buena idea!
Como bien dices, es difícil vender la idea a los superiores, pero… por experiencia propia se que "las cosas de palacio van despacio". Lo importante es que las ideas vayan calando.
En cualquier caso, te recomiendo que asistas cuando puedas a alguna de las charlas de "Agilismo de Guerrilla" de los amigos de http://agilismo.es
¿Cuando hablas de XP te refieres a hacer algo de Pair Programming? ¡Muy buena idea!
Como bien dices, es difícil vender la idea a los superiores, pero… por experiencia propia se que "las cosas de palacio van despacio". Lo importante es que las ideas vayan calando.
En cualquier caso, te recomiendo que asistas cuando puedas a alguna de las charlas de "Agilismo de Guerrilla" de los amigos de http://agilismo.es
Desde el pto vista del tecnico: hay diferencia entre convertirte en una caja negra ocultando informacion a posta (o peor aun intoxicando) para hacerte imprescindible o que te conviertan en una caja negra aunque tu no quieras porque al final es mas comodo para todos a corto plazo (incluido los jefes). Tu lo arreglas rapido y nadie te pregunta nada ni te pide que documentes y cuando lo haces notas esa cara de desconectar y "si,si cuentame lo que quieras que a la proxima te lo vuelvo a pedir". Creo que el segundo caso es el mas extendido y sintoma de la cortedad de miras de las empresas de este pais de las que no se salvan las del ramo tecnologico.
Hay una caja negra que nadie puede abrir del todo y que creo que debe ser la que te debe dar valor como tecnico: saber como solucionar los problemas en general rapidamente y no como solucionar un problema concreto. Tambien eso se puede enseñar pero depende del caracter y de tantos factores que es complicado transmitirlo en el trabajo (tal vez si en la universidad o en entornos formativos)
Claro. Por eso he dirigido el artículo tanto a técnicos como a gestores de técnicos.
La caja negra a la que te refieres tu… yo no la denominaría caja negra, sino 'pericia' o 'experiencia'. Es algo que no se puede aprender trasmitir tan fácilmente.
Un saludo y ¡gracias por la aportación!
[...] Conviértete en una Caja Negra [...]
Efectivamente. Por eso me he puesto filosófico en el artículo: "si eres una caja negra piensate muy mucho si trabajas donde quieres o deberías trabajar".
Evidentemente, los informáticos somos, hasta cierto punto, unos niños mimados que aún podemos llegar a escoger entre varios trabajos. A ver cuanto nos dura… :/
Hombre, la forma más clara de detectar a las cajas negras es porque visten de naranja y llevan un localizador que pita todo el rato… :X
Coñas aparte, aunque en parte es excusa, bien es cierto que a veces es complicado tener a todo el mundo al mismo nivel en todas las tareas del equipo, simplemente por una cuestión de eficiencia "inmediata" del equipo, aunque a largo plazo no sea lo más conveniente. Pero ya sabemos a que plazo miran algunos las cosas en este negocio.
Nosotros intentamos minimizarlo comentando procedimientos de emergencia y documentando donde está cada cosa brevemente, al menos para que cualquiera pueda salir de un apuro dado el caso. Aparte de eso, todas nuestras aplicaciones han de estar en el repositorio de código y ser construibles como mínimo con linea de comandos + Ant, así que en caso de emergencia cualquier miembro del equipo puede bajarse cualquier aplicación y montarla en su equipo en un tiempo mínimo. Desde que lo pasamos todo así, hace ya algunos años no creas, nos vamos de vacaciones más tranquilos
.
Como además nos toca la parte de gestionar los servidores de aplicaciones y el paso a producción, y cansado de ser el único "pringao" que se pega con ello, lo estoy automatizando a base de un "repositorio de producción" para que al menos quede constancia de lo que se ha hecho. etc. pero queda la parte de que todo el mundo sepa como se hace… y se acuerde y tenga voluntad.
En todo caso, requiere un esfuerzo que se ha de ver apoyado desde más arriba, y muchas veces ese apoyo no se da. No es sólo de palabra, por que si no te dan el "tiempo=recurso" necesario para mantener la situación, pues son palabras bonitas pero a la hora de la verdad te quedas con cara de tonto.
PD: Luego está el tema que después de tirarte un par de días documentando los procedimientos de comprobación y re-arranque de los servidores en caso de emergencia, el personal que está de guardia ni se los lea y reinicie todas las maquinas a nivel hardware… como nos pasó estas navidades… país.
Aunque hay un factor individual importante, el entorno puede favorecer muchísimo las cajas negras:
* Un entorno laboral de cajas negras favorece que el "nuevo" acabe siendo también una caja negra, porque se cansa de "compartir" a cambio de nada, el resultado no es tanto el afán de ocultar sino más bien el desinterés de compartir.
* Cuando desde el nivel de gestión se invita a compartir conocimientos y experiencia, no como un mecanismo de cohesión de equipo y de alineamiento de objetivos sino como parte de un proceso de substitución, yo no lo he vivido personalmente (de verdad) pero sí conozco algún caso tipo "enséñale al nuevo…" cuando lo que sigue y no se verbaliza es "…que es el que te va a substituir".
* Un entorno laboral esencialmente competitivo e individualista (favorecido o no desde arriba) favorece las cajas negras pues se valora el valor que das y que no dan los demás.
Conclusión: a veces la caja negra es un mecanismo de adaptación a un entorno "hostil", lo cual no es necesariamente "malo" en ese contexto, eso sí, es triste y aburrido y hasta cierto punto patético porque el afán de ser una caja negra puede ser un signo de mediocridad y de complejo de inferioridad.
A mi gusta la 'política de mínimos' que comentas. Por lo menos que todo el mundo sepa construir un proyecto y los procesos críticos para solucionar problemas grandes. ¿Cuanto tardasteis en implementar esos procedimientos? ¿os costó mucho? ¿tuvisteis que perseguir al 'management' hasta el cuarto de baño?
Pues la verdad es que teniendo en cuenta que nuestro "tema" son muchas aplicaciones pequeñas pero distintas, pasarlas todas al CVS me llevo "un ratejo", pero lo que ya llevaba haciendo era lo de ir basando los builds en una estructura más o menos común a base del Ant, pero vamos, la parte técnica no es "nada" (sobre todo ahora que hay mucha más documentación sobre el tema que cuando yo lo hice) y es más problemático el encontrar/que te dejen tiempo para "refactorizar" proyectos para dejarlos "igual" pero mas montables.
Mi caso es un poco especial por que como no estoy en la empresa privada, no estamos tan "fiscalizados", así que básicamente lo hice yo por mi cuenta sacando tiempo mientras cumpliese con mi trabajo. Tenía un jefe que me dejaba siempre la carga a sólo un 70-80% para que pudiera dedicar ese % extra a mejorar lo que ya hacíamos, investigar cosas nuevas para hacerlo mejor etc. etc. y eso se nota. Ahora ya no tengo permiso tan explicito, pero si no son cosas gordas, por mi cuenta y luego cuando el resultado es obvio, suelen aceptar. Aunque a veces no. Utilizar un wiki no me dejaron nunca (words en carpetas compartidas es suficiente, me dijeron) hasta que despues de que insistiera yo durante al menos 3 años, a otro miembro con "mejor posición" se le ocurrió i zas, era lo mejor desde el pan de molde!
En fin, que a veces es complicado meterlo y si no tienes una demostración palpable de beneficios… claro que a veces para demostrarlo tienes que hacerlo y eso es lo que no te dejan…
Ahora nos dejan unos días al mes, estilo Google, para hacer "innovacion" y proponer cosas para mejorar lo que hacemos, aunque esta bastante fiscalizado (hay que dar bastantes explicaciones) es mejor que nada.
PD: Uno de los problemas que me encontré es convencer al resto del equipo de que dejara de usar sus proyectos "a su modo" y pasará a usar el repositorio común etc. Cuesta pero si les haces ver que así se podrán ir más tranquilos de vacaciones, al final acaban aceptando
. Con otras cosas sin esos alicientes, es más dificil. La cultura del "me va bien así, para que cambiar"
Yo hace algo más de un par de años era caja negra respecto a un módulo concreto, que sólo yo sabía arreglar, que sólo yo sabía modificar etc,etc. Intente por activa y por pasiva dejar de serlo, insistiendo a mi jefe para que pusiera a otra persona conmigo a irle explicando poco a poco, más o menos estaba conseguido cuando esta persona por 3 duros más se fue a otra empresa y nadie le hizo una contraoferta, a pesar de lo que costaría formar a otro para que hiciera lo mismo y que sabes que esa persona respondía…
Además de dedicarme a otros temas me seguían llegando como un goteo todas las modificaciones/arreglos en ese módulo, la cosa es que me canse, busque opciones fuera de mi empresa y el planteamiento fue claro "o me quedo haciendo tal y tal y me liberáis de toda responsabilidad de ese modulo o me voy a otro sitio a trabajar en algo que me satisfaga", es muy radical, pero después de varios años intentadondolo por las buenas y recibiendo respuestas del tipo "cada uno tiene su cruz…" pues mira es lo que hay, son lentejas, si quieres las tomas y sino las dejas.
Ahora en nuestro equipo de trabajo seguimos la practica de "propiedad colectiva del código", cualquiera puede resolver cualquier incidencia, cualquiera puede implementar cualquier nueva característica. No recuerdo donde lo ley, básicamente esto es aumentar tu "factor camión", que consiste en saber a cuantas personas de tu equipo las tiene que atropellar un camión para que todo el proyecto se venga abajo.
¿Factor Camión? ¡Que grande Alfredo!
La caja negra aun cuando sus funciones sean limitadas es indispensable para un equipo. Si una caja negra falla, se produce un vacio en el equipo, en el que los sistemas auxiliares no van a poder realizar su accion, pero si van a poner todo de su parte para que vuelva a funcionar correctamente. Es mejor ser caja negra que no ser nada.
¿no será mejor trabajar en un sitio donde no tengas que ser una caja negra? ¿no será mejor trabajar en un sitio donde no consideren 'nada' a quienes no son cajas negras?
Hombre la máxima de la informática de 'si va bien, no lo toques' muchas veces se utiliza para enmascarar inmovilismo absoluto.
Me puedo imaginar que cuando redujiste el riesgo de a que la gente la llamaran en plenas vacaciones ganaste muuuchos aliados…
Es triste que tengas que plantear ultimatums para que te hagan casos… pero el que este libre de pecado, que tire la primera piedra. Muchas veces no eres conscientes de las situaciones hasta que te las plantan delante de la cara.
En cualquier caso, si hay alguien que no es una caja negra, y eso lo sabemos todos, eres tu Alfredo
Hola. Antes que nada me pone muy contento que haya gente como todos vosotros en la comunidad. Diariamente leos vuestros foros, y comparto muchísimas cosas.
Y en cuanto a esto, yo que pensaba que este problema se daba sólo en la empresa donde trabajo…
Y os digo que no es cualquier empresa, sino que es una multi que se jacta de sus procesos, de que es cmmi nivel 3, y varias otras cosillas… En estos tiempos en los que hay que exprimir cada centavo, no se puede tener redundancia de personas, con una que se encargue de cada sistema es suficiente… hasta que la persona se cansa que no se pueda tomar vacaciones tranquila que ya la andan llamando porque ha fallado algo en la aplicación que sólo ella conoce, que los fines de semana se rompe algo y lo tiene que resolver (y que hay penalidades si se pasa de tantas horas), y que el jefe diga que "no importa cómo, sólo necesito que esté funcionando a las mil maravillas para mañana", y que nadie te pueda hechar una mano porque sólo tú sabes cómo funciona esa cosa, y que no hay tiempo para documentar porque se disminuye la productividad, y que cada vez somos menos recursos pero hay que seguir realizando la misma cantidad de requisitos totales.
Finalmente, uno se cansa y se va a otros rumbos… y os cuento que en mi corta experiencia en el mundo del trabajo he visto dos reacciones bien distintas de una empresa: por un lado, en la anterior empresa donde he trabajado (pequeña, de 5 desarrolladores), durante meses hemos querido convencer al jefe que traiga más gente, y que nos dé tiempo para capacitarles, que necesitábamos ayuda para llevar adelante el desarrollo, porque cada uno era el único que conocía un par de módulos, pero no fue sino hasta que renuncié que me ha venido a llorar para que me quede, que nadie conocía cómo funcionaba lo que dejaba… ¿es necesario ese extremo para sacarse las vendas de los ojos? ¿Y uno debe renunciar a una oportunidad de trabajo porque ahí sí se dieron cuenta lo mal que procedían? Y por otro lado, he visto como compañeros míos en esta multi se han ido por el cansancio que producía esta situación… ¿y la empresa cómo reacciona? ¿Haciéndole una contraoferta o prometiéndole 'cambios'? Pues no, que los pobres desarrolladores se pasarán semanas durmiendo 3 hs diarias para tratar de entender lo antes posible esas cajas negras que ha dejado el que se ha ido, mientras los clientes se impacientan que fallan y fallan, y que todo se viene abajo, y que los euros desaparecen, total… la gerencia un par de meses después dice: "¿ven que no era el fin del mundo? Pedrito se fue y lo sacamos adelante"… SACAMOS!, en plural! Nosotros destruidos del esfuerzo hecho por sacar andando el muerto que nos ha dejado el que se fue, y los jefazos hechándonos en cara que su forma de trabajar funciona, que no se necesita más de una persona en un módulo, que es deperdicio de recursos. Y luego no entienden por qué se cansa uno. Es tan bonito compartir conocimientos y enriquecerse mutuamente. Pero bueno, eso no es rentable, así que no sirve, a trabajar y no perder tiempo.
En fin, que nos ven como fichas de ajedrez, aunque creo que nosotros somos los peones, porque eso de hechar mano en el código es lo que menos valor aporta a la empresa… Y que viva la optimización de recursos, y la rentabilidad de la corporación, que los engranajes son intercambiables.
Saludos a todos!! Ah, y disculpas por el texto lleno de ironías
¡Madre mía! ¡Que cacho comentario!
No gracias a ti por leernos a mi y a todos los locos por el desarrollo. Comentarios como los tuyos son los que animan a seguir.
La situación que describes es la habitual en muchos sitios. Hay cosas contra las que no se puede luchar… ¿o si? Lo importante es la intención, las ganas de compartir conocimiento y de hacer bien las cosas. Creo que tu eres de los míos…
A veces uno se convierte, sin querer, en una caja negra por el simple hecho de haber desarrollado una parte de una aplicación. Entonces, a partir de ese momento, cualquier mejora, tarea o incidencia relacionada con ese modulo te toca por el simple hecho de haberla hecho tu. Pero estas cajas negras son faciles de romper: en el fondo cualquier otra persona con nivel técnico parecido al tuyo que se ponga a mirar el código, puede acabar sacando como funciona aunque no estes, por lo que no eres imprescindible. El problema empeora cuando se trata de una tecnología que solo la "caja negra" conoce, porque ahí tenemos dos problemas: primero hay que empollarse la tecnología (por ejemplo, un lenguaje nuevo, Erlang, CCXML, Flex) y después empollarse lo que se ha desarrollado. Puede que el coste sea mayor, pero al final (puede que después de bastante tiempo) habra otra persona que se pueda acabar ocupando de la tarea de el "caja negra". En fin, mi opinión personal es que en desarrollo, el concepto de caja negra es muy subjetivo y, al fin y al cabo, todos somos prescindibles.
Otra cuestión distinta suece en sistemas: imagina que solo un tio conoce como está configurada una máquina con varias aplicaciones, o peor, un conjunto de máquinas, un cluster, toda la red, con cientos de procesos en background, servicios, crons. Ahí el problema es mucho mayor, y a veces se reduce que es mejor volverlo a montar todo, que intentar saber lo que tenía montado la "caja negra".
Sea como sea, en desarrollo todavía no he visto a nadie intentando proteger su trabajo convirtiéndose en una "caja negra". Pero en sistemas si lo he visto, y ha sido muy desagradable ver como ciertas personas escondían descaradamente información (y otras técnicas que es mejor no contar) para agarrarse al puesto como un halcón a su presa (iba a decir como una garrapata, pero la metáfora del halcón es mas poética).
Deja un comentario