Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

Cambio evolutivo en organización de una empresa de servicios de TIC

editada por Mu el Martes, 03 Abril de 2012, 10:12h   Printer-friendly   Email story
desde el dept. metatrabajo
TeLoCuento nos lo cuenta: «Mi empresa trabaja en el sector de las TIC y se plantea modificar las categorías profesionales existentes. Actualmente la plantilla se clasifica en técnicos, operadores (antiguos preparadores de trabajo), programadores, analistas-programadores, analistas de aplicaciones, consultores, etc. Las retribuciones van en función del puesto. Pero no existe un catálogo de funciones por puesto, lo que permite que un empleado con categoría de analista-programador haga análisis funcionales y un analista de aplicaciones programe. Nos surge el problema de cómo establecer categorías que se ajusten a la marcos de trabajo actuales: orientados a proyectos, como SCRUM. También se pretende que la retribución no vaya asociada a la categoría, sino a la producción. ¿Podéis ofrecer algún ejemplo de este tipo de organización y de catálogo de funciones por puesto? ¿Alguna especificación que lo establezca? ¿Experiencias en este cambio evolutivo? Gracias por adelantado.»

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Lo que yo veo.

    (Puntos:2, Interesante)
    por sammael (16347) el Martes, 03 Abril de 2012, 11:07h (#1305794)
    ( http://barrapunto.com/ | Última bitácora: Jueves, 24 Noviembre de 2011, 14:18h )
    Te cuento lo que llevo viendo ya anios en empresas por todo el mundo:

    Para la parte de programacion la cosa suele ser, basicamente, programadores senior y programadores.

    Ambos grupos analizan, ambos grupos disenian y ambos grupos programan, solo que si son senior se encargaran, en general, de las tareas mas complicadas.

    En equipos grandes tambien puede haber un (o mas) desarrollador jefe (o lider), que aparte de sus tareas de analisis, disenio e implementacion (como senior) se encarga de dividir tareas en otras mas simples para el resto del equipo.

    A eso le puedes aniadir un arquitecto tecnico que se encargue de definir las directrices generales y buenas practicas para uno o mas proyectos y un arquitecto para hacer eso a nivel de la compania.

    Un jefe de proyecto que se encarga de las gestiones del equipo (vacaciones, herramientas, escribir todos esos informes que les encanta a la direccion...) y un jefe de producto que sea el que reciba las peticiones de clientes, mejoras, bugs y demas, se encargue de recoger toda la informacion posible y dar prioridad a las tareas y ya tienes un equipo de desarrollo estandar.

    Lo ideal es que ademas haya gente de testing, lo que estoy viendo ultimamente es un movimiento hacia departamentos de producto/QA donde se encarguen de ambas tareas (especificar los requisitos y probar que se cumplen).

    Los consultores son lo mismo, pero suelen estar en cliente.

    Esto es, mas o menos, lo que viene a ser un equipo completo para gente usando metodologias agiles (en general, luego cada una tiene sus puestos y roles especificos).

    Tengo muchisimo menos contacto con la parte de tecnicos, soporte y demas, lo que veo en general es a gente siguiendo las directrices de ITIL, con soporte en tres niveles (el tercero suelen ser programadores), pero como he dicho, ahi tengo muchisima menos experiencia.
    --

    Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
    [ Responder ]
  • Fallo de base

    (Puntos:1, Interesante)
    por pobrecito hablador el Martes, 03 Abril de 2012, 11:22h (#1305796)

    Las retribuciones van en función del puesto.
    Las retribuciones deben ir en funcion del empleado. Si un desarrollador es bueno programando, no deberia tener un tope salarial en su puesto que le obligue a pasar a hacer otras cosas, en las que quizas no es tan bueno, para ganar mas dinero.

    Uno de los grandes problemas de Espanya es precisamente eso, que un desarrollador esta infravalorado y, por categoria, no puede cobrar mas de X, cuando quizas es quien esta sacando a flote el proyecto, debido a que el director de proyecto es un programador que tuvo que pasarse a dirigir proyectos, tarea en la cual no da buen rendimiento porque lo que sabia hacer bien era programar, pero claro, el limite salarial se lo impedia.

    [ Responder ]
  • 3 roles

    (Puntos:2, Divertido)
    por pobrecito hablador el Martes, 03 Abril de 2012, 11:25h (#1305797)
    Es sencillo, tres roles:

    - Jefazo: Su función es comentar lo mal que está la cosa e ir a comer con otros jefazos y clientes VIP.
    - Jefe de proyecto: Repartir tareas entre los becarios y reunificar el código.
    - Becario: Que pueden desde picar código, administrar servidores de Bases de Datos, crimpar cables, limpiar de spyware el equipo del Jefeazo hasta cambiar bombillas.


    P.D: Se supone que es un post de coña, pero he vivido esa "jerarquización" en persona. :S
    [ Responder ]
  • por obreiro (37284) el Martes, 03 Abril de 2012, 11:38h (#1305799)
    ( http://www.galizalivre.org/ )
    puedes seguir la tónica general:

    - Jefe tocahuevos
    - 2 o 3 Supervisores tocahuevos y lameculos

    - Pringados que se coman Diseño, proyecto, administración e implementación.
    - Becarios que se coman lo mismo pero cobrando aún menos que los Pringados.

    Y todo regulado con la flamante con la última reforma laboral.
    --
    nem guerra entre povos, nem paz entre classes!
    [ Responder ]
  • Sobre la gente de sistemas

    (Puntos:3, Interesante)
    por a_ver_est (2437) el Martes, 03 Abril de 2012, 11:52h (#1305801)
    ( http://curiosidadesdelahistoria.es/ | Última bitácora: Lunes, 23 Enero de 2012, 15:23h )
    Después de pasar por varias empresas te puedo decir que hay de todo, pero en las más serias suelen adoptar parcialmente las recomendaciones de ITIL (como indicaba el comentario anterior).

    Hay que tener en cuenta que la recomendación ITIL gestiona los recursos informáticos como servicios y no como mera infraestructura, la gestión de dichos servicios lleva asociados varios procesos/subprocesos y estos a su vez varios roles, una misma persona puede ocupar más de un rol y estar involucrado en varios procesos. Aunque honestamente yo no he visto aun ninguna empresa que haya adoptado todos.

    Por ejemplo yo soy responsable del dpt de técnicos Unix pero también participo en la gestión del cambio, gestión de la seguridad y gestión de la capacidad. Hay que romper un poco con el concepto puetso/categoría tradicional en España y pensar que según la ocasión te pones una gorra distinta.

    Así que a groso modo la organización práctica de la empresa suele ser algo parecido a esto.

    A nivel de dpt. de tecnología normalmente suele haber un centro de soporte al usuario (callcenter), nivel 1 de soporte (micro informática), nivel 2 (técnicos especialistas) y nivel 3 (generalmente el soporte del distribuidor). A veces centro de soporte al usuario y micro informatica forman un solo grupo.

    En paralelo suele haber un departamento de servicio que hacen gestión de las distintas carteras e interactuan con el cliente.

    Finalmente en varios de mis trabajos he cobrado variables en función de productividad u objetivos, mi opinión generalmente suelen enrarecer el ambiente entre compañeros, muchas veces la gente se concentra en las tareas que le sirven para cumplir los objetivos y deja un poco de lado las demás, pero si es cierto que consiguen que el típico trepa se mueva un poco.
    --
    Curiosidades de la historia [curiosidad...istoria.es]
    [ Responder ]
  • Cuidado con lo de la producción

    (Puntos:3, Inspirado)
    por Pirx (15304) el Martes, 03 Abril de 2012, 13:12h (#1305814)
    ( http://barrapunto.com/ | Última bitácora: Jueves, 09 Febrero de 2012, 16:10h )
    Está muy bien que el sueldo dependa más de la persona que de una categoría.

    Pero cuidado con eso de la "producción". Está demostrado que, cuando se introducen baremos para medir la productividad en la producción de software, los resultados son contraproducentes.

    Es bastante fácil hacer trampas. Si te dan incentivos por líneas de código, escribirás más líneas de código, incluso cuando lo óptimo es escribir menos. Si te pagan por arreglar fallos, escribes código menos cuidadosamente y después cobras por arreglarlo. Y si te inventas otra cosa, el programador se inventará lo necesario para adaptarse al baremo, que no es lo mismo que el objetivo.

    No tengo una solución mágica, me temo. Y la "solución estándar" de fijarse en las horas de calentar la silla no es mejor.

    [ Responder ]
  • Re:Taylorismo

    (Puntos:2)
    No se si el modelo Taylorista estará muerto, pero está claro que no se puede ni debe aplicar un modelo de producción industrial (fabricar/replicar cosas físicas) a lo que esencialmente es un proceso de diseño (desarrollo de software). Es un error tan común que la gente lo acepta como normal y por eso mismo deberíamos corregirlo a la menor oportunidad.
    --

    El doble de diversión en: La Botella de Klein [blogspot.com]

  • 2 respuestas por debajo de tu umbral de lectura actual.