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).

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 ,

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.

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".

segun dilbert [unitedmedia.com]

"Asi que por muy hijo de que sea hay que joderse porque el marron que nos podiamos comer seria de ordago..."

Hay un viejo dicho del buen gestor: al primero que hay que echar, es al imprescindible.

Si ahora echar a tu jefe es un marrón, mañana todavía lo será más grande, por lo tanto, mejor despedirlo hoy que mañana.

Por supuesto, como en todos los puestos, los competentes no abundan, así que lo más probable es que tu jefe se quede, porque el suyo meterá la cabeza en un agujero como las avestruces, a ver si así no pasa nada.

Un relevo como administrador se puede hacer incluso sin ningún dato.
El primer día puede que te vuelvas loco, el segundo puede que se pierda algo de productividad, pero si conoces bien las plataformas que vas a usar no deberías tener mayor problema a partir del tercero (estuve ahí, lo hice).

No soy administrador, pero me imagino que habrá una cantidad de scripts para automatizar los procesos (backups, movimientos de ficheros, etc) personalizados para la empresa que requerirán que el nuevo administrador conozca su localización y uso.

Aunque como todo, depente de lo grande que sea la empresa...