Barrapunto

Documentar el código es una buena práctica, pero claaaaro, ¿para que vas a documentar algo que has hecho tú? ¿para que otro lo entienda cuando tú no estés?

Y lo mejor son los comentarios del tipo "instanciamos los objetos" o "ejecuto una query" xD

Estas prácticas hay que exigirlas desde arriba, pero como los de arriba no tienen que pelearse con el código...

La manera de registrar por escrito los conocimientos pueden ser mediante procedimientos o instrucciones técnicas/de trabajo, típicas de Sistemas de Gestión como por ejemplo los de Calidad.

La metodología, etc. dependerá de cómo sea lo que te dedicas. Se puede hacer de manera bien sencilla en Word.

Cualquier método puede ser válido, por ejemplo:

- Durante x días apuntas en una lista las cosas que realizas durante tu día a día.
- Detallas al máximo cómo realizas esas tareas, frases concretas de cómo se hace, capturas de pantalla, documentos que se utilizan, fotografías..... incluso grabaciones en video; todo depende de cómo sea tu trabajo. Piensa también en excepciones y problemas que pudieran surgir y cómo actuar ante ellos.
- Si puedes, la próxima vez que realices el trabajo comprueba las instrucciones que todo lo que hayas escrito anteriormente, para mejorarlo (siempre se puede mejorar).

Supongo que no es lo mismo que un administrador de el relevo a otro que que lo haga un programador, por lo que la pregunta sigue siendo demasiado ambigua. En caso de que sea lo primero, con algunas IP y contraseñas deberia ser mas que suficiente. Yo sobrevivi.

Se llaman educación y ética profesional. Cuando una persona se marcha de un trabajo o de un cargo, por lo general las empresas contratan a otra que será formada por esa persona que está saliendo, para que la experiencia que tiene sea pasada de primera mano. Conozco casos en los que Fulano de Tal, que acabó hasta los mismísimos, no ense&ntidle;ó nada por los motivos que fueran y el que llegó después se comió el marrón. Deleznable.

Siempre he salido bien de los proyectos y empresas en las que he estado. Los problemas que pueda tener con tal o cual persona, con la empresa en conjunto o con ciertos grupos no son motivo para que el que llega con ganas, con ilusión y seguro que necesitado (no somos ONGs y el trabajo hoy no sobra) se lleve un jarro de agua fría en forma de malos modos, no enseñar, no ayudar...

Los buenos modales y el trátame como te gustaría que te tratase aquí tambié se aplican. Si se tiene rabia del jefe, del grupo de compañeros o de la empresa, las denuncias, las furias, frustaciones e inmadureces... deben ser dirigidas hacia quien causó el perjuicio. El resto son cobardías y chiquilladas.

Sí, es un tema complejo, donde pueden intervenir fuertes emociones. Pueden haber muchos motivos por los que uno deja la empresa, se me ocurren: 1) económicos, 2) agravios, 3) tensiones, 4) cansancio, ...

Si los motivos son méramente económicos o por cansacio, y no se da un ambiente enrarecido, no tiene por qué haber falta de cooperación; en mi caso he vivido dos "despedidas", estoy por la tercera empresa en 6 años (1+1+4). En la primera "despedida" fue todo muy cordial, pues no había dependencia alguna y no es lógico hacer la puñeta si te han tratado bien, todo flores de colores. En la segunda cumplí hasta el último día, los compañeros me hicieron un regalo y todo, gente cojonuda, todavía les hecho de menos... lo único raro de esa despedida fue que el "pagador" no consiguió que me quedara, ni con aumento de sueldo: incumplió un trato, por lo que me tuve que ir, no me gusta la gente que me engaña.

Donde trabajo actualmente se dan agravios salariales notables por el mismo trabajo, supongo que como en todos los ámbitos. Tengo claro que me interesa dejar el empleo, pues llevo cuatro años con el mismo salario y trabajando duro. Cuando me tenga que ir, me iré sin dar portazo, no porque quiera volver, sino por ética. Nadie es imprescindible, y tampoco ocultaré nada ni haré la puñeta a mala leche, en absoluto. Eso sí, en cuanto se termine la "relación laboral", san sacabó. Ni llamadas ni gaitas, que se gasten la pasta que no me han pagado a mí (normalmente es más caro rellenar un hueco especializado que subir el salario, pues el que llega nuevo necesita un periodo de aprendizaje, y cuando aprenda, querrá más dinero... resumiendo: que para mantener una productividad a buen nivel sale más económico pagar un salario decente).

La industria informática está hecha un asco: salarios lamentables, explotadores sin escrúpulos, etc. Recuerdo la época del 2000/2001, por entonces los "empresarios" tenían mucho mejor talante, hoy en día te tiran a bocajaro: 1) si no te gusta, vete; 2) si te vas todavía me haces un favor; 3) no te van a pagar mejor que aquí, pues cobras demasiado.

En fin, ya vendrán tiempos mejores, y si no, pues a cambiar de profesión. Si lo llego a saber, en lugar de estar un montón de años en la facultad estudiando informática, habría estudiado mates o filosofía... aunque quizá habría acabado también como informático malpagado. Solución: contemplación y contentarse con que no es más rico el que más tiene si no el que menos necesita.

Un ejemplo de buena vida podría ser una vida inspirada por el amor y dirigida por el conocimiento (Bertrand Russell)

Soy partidario de que las empresas, independientemente del sector en el que operen, hagan uso de normativas procedimentales como la ISO 9001:2000 [bulltek.com]

Especialmente en el mundillo de las TI. Las veo particularmente útiles, no sólo por la mejora continua, sino también por la Gestión de la Calidad que obviamente llevan implícita. el control documental, los indicadores, la gestión por procesos ... todo son ventajas :)

Las copias controladas, y el visado documental en elaboración, revisión y aprobación podrían perfectamente solventar tu problemática de difusión de la información.

Un saludo ,

Pues mi jefe lo estuvieron a punto de echar, y por muy cabron que sea menos mal que no lo echaron, porque no sabemos ni el 1% de lo que sabe el, y no digo por falta de capacidad, sino porque casi todos los temas de relevancia los lleva el "in exclusive mode"... Asi que por muy hijo de que sea hay que joderse porque el marron que nos podiamos comer seria de ordago...

Si la empresa te ha tratado bien, pues me parece normal que hagas lo posible para transferir conocimientos sobre el proyecto en el cual estabas trabajando.

Si te han tratado mal, que les den y punto. Y no me vengan a decir que se va a comer el marron el pobre fulano que viene luego. El marron se lo van a comer todos.

En mi opinión es tarde. No se debe pensar en "ahora que me voy, ¿qué hago?" sino más bien en un "día a día".

La única manera que se me ocurre ahora, es dedicar un tiempo a enseñar todo lo que sabes a 2 ó 3 personas, aunque 1 ó 2 de ellas no vayan a hacerse cargo de tu puesto. De esta manera, lo que a una se le escape la otra lo pillará.

Para la proxima vez te recomiendo que trates de hacerte PSP 2 (al menos). Yo estoy en ello y es jodidamente difícil (aún no soy ni PSP 0.1). Si quieres más información busca algo de "Personal Software Process", "humphrey" o, incluso, CMM.

También te recomiendo el uso de herramientas varias, como un bugzilla o similar, un repositorio, herramientas de generación de código si fueran necesarias, ... Si eres administrador, estas herramientas también te valen: las incidencias te las ponen en el bugzilla y utilizas el repo para guardar los ficheros de configuración de todas las máquinas.

Suerte!!

Depende de como sea la salida. Si me están despidiendo, y encima me ponen a un pollo para que le enseñe (encima de puta, poniendo la cama) pues como que no estoy muy colaborador.

Si me voy a otra empresa a cobrar tropimillones, pues no me importa transmitir el conocimiento a las nuevas generaciones.

Como a todo el mundo.

Y podrá ser todo lo inmoral que se quiera, pero la realidad empresarial casi nunca es la moralidad, así que yo tampoco me veo en la obligación de poner el culo para que me den mejor la patadita.

Este es un tema, el de transferencia de know-how, que siempre me ha causado una cierta risa.

Yo, en los cambios de empresas que he hecho siempre me ido a buenas con el resto de compañeros y jefes, quizas porque me he ido voluntariamente siempre y no via algun otro medio menos amistoso.

En cualquier caso, aunque es cierto que hay ciertas cosas que son transmitibles a los que vengan detras, sobre todo cosas procedimentales, hay otras que simplemente no lo son.

Todavia me acuerdo en mis comienzos: estuve con una beca en un centro de investigacion en el extranjero durante un año, que se continuaba con otra estancia de unos meses en un centro de investigacion local. Despues de un par de años de periplos varios decidi cambiar de aires. Lo mejor fue cuando a dos dias de que me largase definitivamente, mientras daba los ultimos toques a proyectos y documentacion, llego un jefecillo mio y me dijo muy serio:

"Oye, antes de irte, por que no pones por escrito todo lo que has aprendido en este ultimo año y medio ?"

Casi me desdoblo de la risa. Eso si, aunque obviamente no le hice ni puñetero caso, fui amable y le deje unos veinte kilos de documentacion personal para que le sacaran fotocopias por si a alguien le daba algun dia por leersela.

El know-how real esta, normalmente, en la cabeza de las personas en su mayor parte, y es muy dificil ponerlo por escrito.

En cualquier caso, aquello que si se puede poner, tiene que ir haciendose en el dia a dia. Es imposible transmitir los conocimientos en los quince dias de margen que normalmente se usan para largarse de un sitio.

La gestion del conocimiento es un bien fundamental en una empresa de base tecnologica, quizas en una pizzeria no, pero en una ingenieria, del tipo que sea, hay que saber gestionarla bien en el dia a dia.

En mi caso (tecnico de microinformatica - administrador ocasional [guardias]), cuando llegue a mi actual trabajo, los compañeros se portaron muy bien y respondieron a todas mis preguntas, pero el problema era que la informacion se encuentra dispersa en fuentes diversas y, aunque los precedientos estaban -mas o menos- documentados, el problema era encontrarlos. Asi que aproveche que en agosto no habia demasiado trabajo, monte un MS sharepoint (de la msdn que tenian tirado en un armario) y colgue todos los documentos que encontre. Con el tiempo, mis compañeros se han acostumbrado a utilizar sharepoint como primer lugar de ayuda, nuestro google particular, de manera que la informacion fluye (ahora estamos ubicados en diferentes edificios). En cualquier caso, la actitud de la empresa para la que trabajamos es de indiferencia hacia esta gestion del conocimiento, y el 'servidor' se encuentra en un pc reciclado que 'escondimos' en el cpd. Ahora, casi al final del proyecto, es muy probable que si nos vamos, la documentacion alojada en sharepoint desaparezca misteriosamente. La mayor parte de la informacion esta duplicada en una estructura de carpetas acordada con el cliente, pero me consta que estos documentos se actualizan mucho menos porque es practicamente imposible encontrar el documento a actualizar. Y ya que estamos... Alguien conoce alguna alternativa glp'ed a MS Sharepoint Portal Server?

La responsabilidad de que el conocimiento de una empresa no se quede en los trabajadores es de la propia empresa. Si no proporciona los medios, y sobre todo el tiempo, para que los trabajadores pongan la información en el soporte que se decida, o si el soporte no es adecuado, es su problema y su responsabilidad.
No olvidemos que por ley un trabajador tiene que notificar su salida con un margen de 15 días, tiempo más que suficiente para transferir todo lo necesario.
Luego es muy fácil echar la culpa al que ya no está.
Saludosss

Como apuntan por ahi arriba, es un tema muy complicado

yo no he durado mas de 1 año en ninguna empresa en la que haya estado y me han despedido solo una vez (y fue por cancelacion del proyecto)

me he ido de sitios de mala manera (por ejemplo el ultimo, donde le dije a mi jefe un viernes que ese era mi ultimo dia) y sitios a los que he vuelto cuando ha surgido un problema aun cuando estaba en otro proyecto o en otra empresa

no se me ocurre ningun metodo "estatico", ninguna formula magica que solucione ese problema, depende mucho no solo del tipo de trabajo que se desempeñe sino tambien de como sea ese mismo trabajo...

hay veces que con dos semanas (como dice la ley) enseñando a un sustituto de primera mano son mas que suficientes, otras, por mucho tiempo que te pases explicando, siempre quedan cosas en el aire

como consejos que te puedo dar, lo primero es que priorizes la informacion... el metodo utilizado para resolver un problema no sirve de nada si el que lo tiene que solucionar no tiene los usuarios, permisos, contraseñas, loquesea que necesita

lo segundo es que dejes documentacion... no solo comentarios en el codigo (que son muy importantes) sino tambien documentos, capturas de pantalla, procedimientos

lo tercero es que confies en esa nueva persona... cuando me ha tocado a mi explicar y cuando me han explicado, he agradecido mas que me intentaran transmitir la filosofia (metodologia, procedimientos, como lo querais llamar) del nuevo trabajo a que me dijeran "aqui pones tal, aqui escribes cual, aqui pulsas click", quiza esa persona al estar solo la primera vez lo pasara mal, pero a la larga me parece mejor para todos.

Por supuesto, lo peor ya esta hecho, lo que no este documentado no lo va a estar en 2 días.

Creo que lo importante es poner buena voluntad y tener paciencia con el "relevo". Intentar hacer un paseo por todas las tareas del último mes y decirle que cosas hacen falta para resolverlas, passwords, telefonos, documentación, directorios, temas pendientes, etc, etc...

Y por supuesto darle tu e-mail, que por una palabra tuya se puede ahorrar 1000 horas de trabajo

Todas las empresas de cualquier sector reconocen la importancia de que los trabajadores documenten su trabajo, para lograr la "intercambiabilidad" de recursos, es decir, que cualquier persona pueda continuar el trabajo de otra sin que se produzca un impacto demasiado acusado en el proyecto o tarea que se esté desarrollando. Pero por contra, casi ninguna deja tiempo a los trabajadores para que documenten y transmitan adecuadamente los conocimientos adquiridos. Se emplea el 100% del tiempo (o más) en producir y no se quiere asumir el coste del trabajo que no es directamente productivo.

Ahora resulta que te marchas y les entran los agobios y las prisas. Que lo hubieran pensado antes.

Uno de los principios, digamos "tácitos", dentro de la ingenieria del software es echar a aquel empleado que se haga indispensable. Es decir, todo aquel que no documente su trabajo, que el tio sea un crack de la vida y sepa mucho y que el proyecto dependa de sus conocimientos.... No se puede permitr que alguien pueda tener en su mano que un proyecto funcione o deje de funcionar, por lo que hay que pensar que el codigo es de todos y todos tienen que saber de todos. No se si tu jefe sera de estos, pero bueno, mas vale prevenir que curar :)

Pienso que depende de como estes en tu empresa actual, en mi caso; la otra ,se fue de la mañana a la tarde y nunca mejor dicho porque textualmente fue así. Y vete a pregunatarle a las margaritas del campo tus dudas...... Y yo me he dedicado a crear una base de datos (con ayuda del mejor programador del mundo) para todo el personal de la empresa, que ni siquiera me ha supuesto un "gracias, es genial" (no te digo ya una remuneración económica, que va!!!), como para perder mi tiempo en enseñar a nadie que venga detras... No sé si borrarla si algún día decido irme y los demas ; " a chiflar a la via".

Que si documentar, que si enseñar a un reemplazo, que si bases de gestión de conocimiento .... me parto de risa con estos comentarios.

He tenido compañeros y compañeras trabajando un día hasta las doce de la noche para terminar un programa y al día siguiente enviarlos a la puta calle, (antes de llegar a mediodía) porque sencillamente en la empresa estaban haciendo reestructuración y les había tocado a ellos. ¿os creéis que alguien en esta circunstancia se va a poner a documentar y a enseñar a otros? Y una mierda !!!

Lo que teneis aquí es un sindrome de estocolmo como una casa. Si un empresario tira a la calle a una persona que ha estado metida en un proyecto y es la que más sabe y es la que más horas se ha tirado liando código, y ésta se va llevandose consigo todo el conocimiento que tenga, lo que toca es que el empresario (o empresa o lo que sea) se joda y pague las horas de formación en la aplicación del que le toque entrar de nuevas. Y si no que no se hubiera limpiado al empleado anterior, o que le hubiera puesto otra persona de apoyo mucho antes ...... lo que pasa que todo eso son $$$$$$$ y no vas a gastar en gente, que hay a patadas ..... y por cuatro perras.

Otra cosa, si mi empresa me embarca en un proyecto y por a o por b quiere que yo forme a otras personas en ese proyecto o esa tecnología, lo que debe hacer es primero gratificarme y motivarme de alguna manera para realizar eso y lo segundo gastar recursos para hacerlo, no me vale el hacer un informe y ya está, porque lo primero el informe lo haré rápido, para la entrega, para irte a casa o para lo que sea y acabar cuanto antes. Si quiere que aparte del proyecto salga una formación que la pague, o la gratifique de alguna manera, y que no sea a costa del sacrificio del trabajador como ocurre siempre.

Otra cosa es largarte a otro sitio que te paguen más, o lo que sea, y no querer dejar colgaos a los cuatro amigos, pero de eso siguo viendo como culpable a la empresa, que no te ha puesto medios para poder canalizar esa información antes.

En fin, que si posibilitais mucho el tema "movilidad y rotacionalidad" os veo en dos días en el paro y vuestro puesto ocupado por otros con un 99% menos de experiencia y un 50 % menos de sueldo. No olvideis quien está arriba y quienes abajo.

Si quieren que se documente que pagen las horas extra etc... ademas de pagar un sueldo decente y valorar nuestro trabajo.
Encima de que nos putean lamerles el *******.
Me parece que no.

segun dilbert [unitedmedia.com]