Como todos sabemos, las empresas actuales tienden a buscar características que les distinga, integrar en la organización conceptos humanos, de ahí que los empleados hayan buscado y encontrado una fórmula para ser escuchados.
Y un ejemplo de esta búsqueda, es el concepto de: transparencia. ¿a que se refiere un empleado cuando pide transparencia?
En el entorno en el que me muevo, viene a significar que le demos la visión del contexto global que maneja un directivo para tomar la decisión que el empleado ha de asumir.
Hasta aquí todo parece adecuado, hasta que llegan los inconvenientes...¿donde está el límite de lo que se debe contar o no? ¿como marcar las pautas de esas transparencia?
Si un empleado pide cuentas de por que se ha despedido a un empleado, ¿se le dan? ¿donde queda la privacidad del desempleado? Si un empleado pide cuentas de cuanto ha sido la subida de sueldo de su compañero, ¿Se le da? Dificil solución.
Otro término complicado que las empresas empiezan a incoporar es la famosa "accesiibilidad" de los altos mandos.
Obviamente, el poder acceder a uno de los directivos de la empresa, es un hecho que agrada a los empleados, les da sensación de estar en un ambiente cordial y cercano.
Opinar es una tarea fácil de hacer para quien carece de criterio, y fácil de escuchar para quien puede imponer las decisiones.
La complicación es decidir que hacer con el resultado de esa conversación.
En mi opinión las empresas se equivocan cuando confunden "la accesibilidad de los directivos" con "el que sean ellos quiene ejecuten las soluciones" que los empleados demandan.
El que puedan solicitar cierta información, o el que accedan a los altos mandos para plantear sus preocupaciones no tiene que ver con en donde recaiga la acción consecuente.
En general, esto es un arma de doble filo. Estamos viendo que si el directivo no sabe ejercer su posición con un criterio "adecuado", o carece de habilidad para darse cuenta de la complicación y manejarla, caerá en el error obvio: los directivos acaban asumiendo tareas asignadas a mandos intermedios de sus equipos, para atender la demanda de quienes solamente tienen su visión particular.
Transparecia y accesibilidad, han de estar intimamente relacionados a delegación, trabajo en equipo y responsabilidad, de otro modo la consecuencia será frustración y ofuscación, y fomentará la “dirección de cortijos” en todos los niveles.
jueves, 17 de diciembre de 2009
viernes, 30 de octubre de 2009
En varias ocasiones nos hemos encontrado con el tener que abordar la tarea de definir un prototipo a la hora de definir un proyecto, y si el equipo que integra el proyecto, va a adoptar la metodología de Scrum para su gestión, la controversia está servida: ¿abordamos este primer análisis de la solución completa o lo dejamos para ir abordando en cada Sprint los análisis de las historias de usuario que habrá en él y por ende sus pantallas?
Partimos de la premisa de que para definir un prototipo tenemos que identificar y plasmar la idea global de la navegación del proyecto completo, así como la distribución de la funcionalidad en todas las pantallas de la aplicación, sin meternos aún en aspectos de diseño, pero afinando en la precisión del movimiento e interacción entre el usuario y los distintos elementos disponibles.
Al mismo tiempo, dado que queremos aplicar Scrum, partimos de la premisa de no abordar un análisis inicial que nos ocupe durante meses, quedándonos solamente en el momento del arranque del proyecto, en la idea general de cada una de las funcionalidades que ha de cumplir el proyecto.
El equipo ayudado por el Product Owner, seleccionará las historias de usuario que se abordarán en ese primer sprint, del cual tenemos una idea sin profundizar.
En ese momento, el Scrum Máster se hará una pregunta: tenemos que analizar la navegacion de toda la funcionalidad del Product Backlog a priori?
La respuesta, depende de quien responda.
Si responde él mismo, la respuesta seria no. No voy a dedicar tiempo ahora a definir tareas que puede que el cliente no quiera abordar, que puede que cambie el proceso de negocio que las nutre, que puede que cambie los requisitos del cliente. Si tengo que evaluar, dedicar este tiempo a un prototipo, es ir en contra de las ventajas de Scrum, y realizar un prototipo, lo considero un Riesgo que afectara a la planificación.
Si responde el arquitecto de información de ese proyecto, la respuesta será si. No podemos dejar cabos sin atar dado que la distribución de la información, la navegación entre pantallas, y la taxonomía de las mismas, puede provocar un cambio total en el interfaz, y por tanto en el desarrollo.
Si responde el equipo, dirán no. No quiero invertir todo ese tiempo ahora porque ese tiempo lo necesito para aportar calidad a mi código, realizar un buen cuaderno de pruebas exhaustivas y refactorizar en caso de que sea oportuno.
La conclusión final de todo este planteamiento es que sin prototipo no abordamos una tarea con orden, dado que el interfaz de usuario será la cara del proyecto, y para una optimización del tiempo, debemos abordar el análisis de cada historia de usuario cuando corresponda. Incluiremos la definición de cada parte del prototipo en cada sprint, como si fuera una tarea más del resto del sprint, y lo iremos revisando con el resto del producto, al igual que las demás tareas de integración.
Como comentan en el artículo, Dr. Charles Kreitzberg y Ambrose Little, es más simple que intentar abordarlo desde un principio como algo externo al proceso de desarrollo.
Os contaré el resultado del siguiente proyecto.
Partimos de la premisa de que para definir un prototipo tenemos que identificar y plasmar la idea global de la navegación del proyecto completo, así como la distribución de la funcionalidad en todas las pantallas de la aplicación, sin meternos aún en aspectos de diseño, pero afinando en la precisión del movimiento e interacción entre el usuario y los distintos elementos disponibles.
Al mismo tiempo, dado que queremos aplicar Scrum, partimos de la premisa de no abordar un análisis inicial que nos ocupe durante meses, quedándonos solamente en el momento del arranque del proyecto, en la idea general de cada una de las funcionalidades que ha de cumplir el proyecto.
El equipo ayudado por el Product Owner, seleccionará las historias de usuario que se abordarán en ese primer sprint, del cual tenemos una idea sin profundizar.
En ese momento, el Scrum Máster se hará una pregunta: tenemos que analizar la navegacion de toda la funcionalidad del Product Backlog a priori?
La respuesta, depende de quien responda.
Si responde él mismo, la respuesta seria no. No voy a dedicar tiempo ahora a definir tareas que puede que el cliente no quiera abordar, que puede que cambie el proceso de negocio que las nutre, que puede que cambie los requisitos del cliente. Si tengo que evaluar, dedicar este tiempo a un prototipo, es ir en contra de las ventajas de Scrum, y realizar un prototipo, lo considero un Riesgo que afectara a la planificación.
Si responde el arquitecto de información de ese proyecto, la respuesta será si. No podemos dejar cabos sin atar dado que la distribución de la información, la navegación entre pantallas, y la taxonomía de las mismas, puede provocar un cambio total en el interfaz, y por tanto en el desarrollo.
Si responde el equipo, dirán no. No quiero invertir todo ese tiempo ahora porque ese tiempo lo necesito para aportar calidad a mi código, realizar un buen cuaderno de pruebas exhaustivas y refactorizar en caso de que sea oportuno.
La conclusión final de todo este planteamiento es que sin prototipo no abordamos una tarea con orden, dado que el interfaz de usuario será la cara del proyecto, y para una optimización del tiempo, debemos abordar el análisis de cada historia de usuario cuando corresponda. Incluiremos la definición de cada parte del prototipo en cada sprint, como si fuera una tarea más del resto del sprint, y lo iremos revisando con el resto del producto, al igual que las demás tareas de integración.
Como comentan en el artículo, Dr. Charles Kreitzberg y Ambrose Little, es más simple que intentar abordarlo desde un principio como algo externo al proceso de desarrollo.
Os contaré el resultado del siguiente proyecto.
jueves, 2 de julio de 2009
CREATIVIDAD Y LA BUROCRACIA
¿cuando debemos de poner freno a la burocracia?
En general, debería ser siempre, pero donde es ineludible es en organizaciones pequeñas. Supongamos una tarea. Una tarea de definición asignada a un directivo concreto. Durante meses largos la actividad diaria de este director ha impedido que lleve a cabo esta tarea. Se va retrasando incluso pudiendo quedar en el olvido.
Entonces alguien detecta la carencia, evalúa las opciones que tiene de poder llevarla a cabo, e idea un plan de viabilidad: busca el objetivo, organiza los medios, evalúa alternativas y entonces, decide proponer algo a la dirección general.
Y este, es el punto clave de nuestro escenario: a quien le damos paso, ¿a la creatividad o a la jerarquía?
Por desgracia en la mayor parte de las organizaciones, se da paso a la jerarquía, en lugar de redireccionar la decisión. Se prefiere que una tarea no la haga nadie, antes que compartir el protagonismo de realizarla con alguien ajeno a ese área. Es preferible que no se cambie nada, si no es el que tenía la tarea asignada en primera instancia.
La tarea se queda perdida en la lista de TODO que nadie atiende.
Y lo peor, la creatividad y la iniciativa de las personas se difumina, se pierde en la burocracia, siendo el origen de un nuevo malestar empresarial.
Yo propongo algunas reflexiones para organizaciones pequeñas:
¿Qué ocurre si esa persona se cambia de empresa, nunca jamás nadie abordará esa tarea?.- Siempre tiene mejor resultado compartir las tareas, aunque solo sea para opinar. Pruébalo.
¿Qué ocurre si es otra persona quien lo realiza: es menos útil, menos creativo, menos original?.- Puede que le resulte un alivio quitarse de encima, puedeque todos salgan aprendiendo algo, y en último caso, la organización y el equipo siempre gana.
¿Que ocurre si la idea es de otra persona?.- Una idea sin nadie que la lleve a cabo, no es más que eso, con suerte una idea en un papel. En el equipo, el lema: "Tú lo piensas + yo lo hago = los dos lo terminamos", debería ser una máxima inolvidable que favorece el crecimiento en las empresas, la integración de las tareas de cada persona, y la colaboración en los equipos.
Quién sabe si unos segundos de reflexión pueden convertirse en fomentar la creatividad de cualquiera de tu empresa. Medítalo. :-)
En general, debería ser siempre, pero donde es ineludible es en organizaciones pequeñas. Supongamos una tarea. Una tarea de definición asignada a un directivo concreto. Durante meses largos la actividad diaria de este director ha impedido que lleve a cabo esta tarea. Se va retrasando incluso pudiendo quedar en el olvido.
Entonces alguien detecta la carencia, evalúa las opciones que tiene de poder llevarla a cabo, e idea un plan de viabilidad: busca el objetivo, organiza los medios, evalúa alternativas y entonces, decide proponer algo a la dirección general.
Y este, es el punto clave de nuestro escenario: a quien le damos paso, ¿a la creatividad o a la jerarquía?
Por desgracia en la mayor parte de las organizaciones, se da paso a la jerarquía, en lugar de redireccionar la decisión. Se prefiere que una tarea no la haga nadie, antes que compartir el protagonismo de realizarla con alguien ajeno a ese área. Es preferible que no se cambie nada, si no es el que tenía la tarea asignada en primera instancia.
La tarea se queda perdida en la lista de TODO que nadie atiende.
Y lo peor, la creatividad y la iniciativa de las personas se difumina, se pierde en la burocracia, siendo el origen de un nuevo malestar empresarial.
Yo propongo algunas reflexiones para organizaciones pequeñas:
¿Qué ocurre si esa persona se cambia de empresa, nunca jamás nadie abordará esa tarea?.- Siempre tiene mejor resultado compartir las tareas, aunque solo sea para opinar. Pruébalo.
¿Qué ocurre si es otra persona quien lo realiza: es menos útil, menos creativo, menos original?.- Puede que le resulte un alivio quitarse de encima, puedeque todos salgan aprendiendo algo, y en último caso, la organización y el equipo siempre gana.
¿Que ocurre si la idea es de otra persona?.- Una idea sin nadie que la lleve a cabo, no es más que eso, con suerte una idea en un papel. En el equipo, el lema: "Tú lo piensas + yo lo hago = los dos lo terminamos", debería ser una máxima inolvidable que favorece el crecimiento en las empresas, la integración de las tareas de cada persona, y la colaboración en los equipos.
Quién sabe si unos segundos de reflexión pueden convertirse en fomentar la creatividad de cualquiera de tu empresa. Medítalo. :-)
viernes, 19 de junio de 2009
INTEGRAR UN NUEVO COMPAÑERO
Recientemente hemos recibido un compañero nuevo en el equipo. Las reacciones en general han sido adversas, generando un sistema aislado en el desempeño del nuevo integrante.
Esto ha hecho que me pregunte: ¿como hubiera sido esto mejor?
El gran conflicto surge cuando los compañeros del equipo desconocen para que viene esa persona (que llamaré Mr. X), cuál será su tarea y cómo influirá en las tareas de los demás. En un sistema cerrado, como es un equipo de desarrollo, el sistema establecido se rompe y genera cierta incertidumbre.
Si pretendemos que Mr.X sea bienvenido y recibido con agrado, deberemos de presentarlo de una manera formal, explicar porque la dirección considera que es importante su labor, cuál es el valor que va a aportar a la organización, y cuáles serán sus cometidos.
El siguiente paso será dotar a Mr.X de los recursos necesarios para realizar su desempeño. Explicarle si es oportuno, la metodología de la empresa, los valores que conforman la filosofía corporativa, así como los procedimientos en los que se verá implicado.
Por último, si dichos recursos incluyen personas, deberemos reunir al equipo para definir la forma en que deberán interactuar, de manera que todos entiendan que no es un "peligro" compartir espacio, información, medios, etc. con Mr.X, y que por el contrario, se pueden ver beneficiados por sus aportaciones.
En un entorno de conocimiento del contexto, será más fácil integrar cualquier cambio en la estructura de los equipos. ¿No estás de acuerdo?
Esto ha hecho que me pregunte: ¿como hubiera sido esto mejor?
El gran conflicto surge cuando los compañeros del equipo desconocen para que viene esa persona (que llamaré Mr. X), cuál será su tarea y cómo influirá en las tareas de los demás. En un sistema cerrado, como es un equipo de desarrollo, el sistema establecido se rompe y genera cierta incertidumbre.
Si pretendemos que Mr.X sea bienvenido y recibido con agrado, deberemos de presentarlo de una manera formal, explicar porque la dirección considera que es importante su labor, cuál es el valor que va a aportar a la organización, y cuáles serán sus cometidos.
El siguiente paso será dotar a Mr.X de los recursos necesarios para realizar su desempeño. Explicarle si es oportuno, la metodología de la empresa, los valores que conforman la filosofía corporativa, así como los procedimientos en los que se verá implicado.
Por último, si dichos recursos incluyen personas, deberemos reunir al equipo para definir la forma en que deberán interactuar, de manera que todos entiendan que no es un "peligro" compartir espacio, información, medios, etc. con Mr.X, y que por el contrario, se pueden ver beneficiados por sus aportaciones.
En un entorno de conocimiento del contexto, será más fácil integrar cualquier cambio en la estructura de los equipos. ¿No estás de acuerdo?
LA INTENCION
En este blog quiero compartir con personas que como yo, están evolucionando su carrera profesional desde los puestos de desarrollo puro, a puestos donde se intercala la gestión y la informática.
Siempre he defendido que los programadores no deberían verse obligados a tener que dejar el mundo del desarrollo para poder avanzar en su carrera. Un programador con una experiencia de 10 años no debería de tener que apartarse de su vocación para ser valorado, motivo por el cual, me gustaría colaborar en comenzar a promover un cambio en la mentalidad profesional en que vivimos, divulgando mediante este blog tales reflexiones.
Me gustará poder ir mostrando la evolución de mis preocupaciones como gestor de proyectos, y gestor de personas. Si quieres compartir tu experiencia, no dudes en abrir debate, estaré encantada de poder buscar de la mano otros y nuevos caminos.
Saludos
Siempre he defendido que los programadores no deberían verse obligados a tener que dejar el mundo del desarrollo para poder avanzar en su carrera. Un programador con una experiencia de 10 años no debería de tener que apartarse de su vocación para ser valorado, motivo por el cual, me gustaría colaborar en comenzar a promover un cambio en la mentalidad profesional en que vivimos, divulgando mediante este blog tales reflexiones.
Me gustará poder ir mostrando la evolución de mis preocupaciones como gestor de proyectos, y gestor de personas. Si quieres compartir tu experiencia, no dudes en abrir debate, estaré encantada de poder buscar de la mano otros y nuevos caminos.
Saludos
Suscribirse a:
Entradas (Atom)
Entradas
