0
Si hacen 50 sitios mensuales, deben haber muchas pegas repetitivas. ¿han invertido tiempo en automatizarlas? Así se capitalizaría la experiencia que van ganando.
Una pregunta adicional: ¿por qué crees tu que cada vez demoran más? (Yo tengo una idea, pero necesito saber tu opinión)
over 1 year ago
jorge vergara
said:
Entre otros factores: la falta de documentación (la tradición oral se impone), falta de visibilidad de las tareas en curso que hace perder el contexto (usamos Mantis BT como sistema de pedidos), continuos cambios de contexto, el mismo equipo para urgencias (cosas que se deben arreglar en el minuto) y para desarrollos calendarizados, diferencias de nivel de los diseñadores (competencias técnicas y motivacionales). Tengo curiosidad, ¿cuál es tu idea?.
Muchas gracias por la respuesta Agustín!
over 1 year ago
jorge vergara
said:
Hola Agustín, aún estoy a la espera de tu idea, me interesa saber qué impresión te dio el caso así a priori. Saludos!
Sumándome un poco a lo que dice Agustín. Yo igual tengo una hipótesis: creo que se demoran cada vez más porque están colapsando, y antes de solucionar un tema llegan nuevos. Entonces la presión aumenta, la pega también, y la productividad va cayendo cada vez más. Otro problema, si lo viésemos como un Kanban, es que como tienen mucha pega en estado To Do, es que estén tratando de meter lo que más puedan en Doing, pero sólo se saturan, queman al equipo y pasan poco a estado Done. Estas son eso sí hipótesis, y estoy haciendo unos cuántos supuestos.
.
Para medir la velocidad sería bueno que metieran un tablero y se comprometieran con un ciclo (podrían usar el trabajo “mensual”) y ver cuánto de lo que comprometieron hicieron. @agustin.villena es más seco para esto (yo estuvo ahí en el OpenSpace llenándolo con post-it :p )
Sería bueno también que hagas lo que hagas, nos digas cómo te fue. Compartamos el conocimiento y la experiencia! :).
over 1 year ago
jorge vergara
said:
Hola Estéban, gracias por tu respuesta. Claro que estamos colapsando, aparte como en el grupo hay distintas motivaciones y competencias (algo inevitable) se hace difícil cohesionarlos hacia un objetivo común. Estoy en proceso de establecer algunas mejoras y espero poder comentárselas luego.
Si tiene plantillas base a las cuales tienes que agregar cada modificación que sus clientes les modifique, mi visión es que tal vez deberían empezar a embedir peticiones repetitivas en las platillas más el uso de refactoring, pues tal vez, como dice Agustín, no están capitalizando el know how y desarrollo que han realizado, en la maduración de su producto.
Lo otro es que si crees que la falta de documentación dificulta es trabajado de mantención y desarrollo, el trabajar más en la documentación de código puede ser útil y usar herramientas de generación de documentación automática (la única tecnología que conozco es Sandcastle de Microsoft) les facilite la vida, con un costo más bajo que irse por documentación exhaustiva.
El continuo cambio de contexto también podría ser un problema pues el tomar el ritmo de una tarea que es muy diferente nueva merma la productividad, por lo tanto mi opinión es que si mantienes cada miembro de tu equipo en tareas similares los cambios de contexto no serán tan costosos y podrás tener un incremento de la especialización de tu equipo que también incremente un poco la productividad, siempre teniendo en cuenta que también tu gente necesita cierto grado de diferenciación entre tareas para que no vuelvan rutinarias.
Si te fijas mis ideas no van por el uso de kanban sino de otras prácticas pero espero que te sean de utilidad.
over 1 year ago
jorge vergara
said:
Aún no podemos hacer un refactoring estricto, pero si está planificado eliminar las diferencias entre plantillas (usamos como 4 distintas) para que todas tengan la misma maquetación HTML y usen los mismos CSS (disminuyendo la curva de aprendizaje, el cambio de contexto y la documentación). Estuve revisando la información sobre “Sandcastle” pero es más para desarrollo de software que para documentación de procesos.
El Know How lo estamos tratando de capitalizar a través de la implementación de un foro interno, donde las preguntas y respuestas de todos queden para la posteridad (yo lo veo como una documentación informal) y se elimine la tradición oral. Igual es un tema muy incipiente y tienes razón en que debemos abordarlo con más seriedad.
Muchas gracias por tu respuesta Rodrigo!
En mi experiencia he vivido situaciones similares, aunque con mucho menos volumen de pega.
Lo que hicimos, fue dedicar un equipo a mantenciones, dedicar un equipo a desarrollos e incluir un equipo de QA cuya tarea fuera liberar a los desarrolladores de hacer pruebas manuales.
Junto con lo anterior, incluimos pruebas automatizadas (unitarias) y un sistema de integracion continua.
Hoy incluso estamos pensando en separar el equipo de mantencion en dos, uno de soporte de usuario y uno de mantención debido a que la atención al usuario consume mucho tiempo de nuestros programadores dedicados a la mantención.
Un problema que viene con esto es que la cultura se dispersa un poco, asi que estamos tratando de invertir tiempo en que los equipos intercambien experiencias y opiniones en reuniones y actividades comunes del área.
Otra cosa que hay que tener en consideración, es que si bien los programadores de desarrollo quedan más liberados de atención al usuario y mantención, no significa que nos alejemos de los clientes o de nuestra responsabilidad con la calidad, de hecho nos sentimos más apoyados en nuestras tareas ya que sabemos que otros colegas nos complementan y hay más ojos, con distintos puntos de vista, sobre la aplicación.
over 1 year ago
jorge vergara
said:
¡Efectivamente!. Lo primero que hicimos fue tomar Mantis y exprimirle datos estadísticos: qué nos piden, qué es igual, qué es distinto, qué se demora más, qué es más urgente. Según eso dividimos el departamento en áreas por producto (resultaron 3 áreas) y definimos un jefe por cada uno. Así delego la organización de cada grupo en un sólo interlocutor y me entiendo con ellos para planificar y documentar mejoras o estándares. El producto “portales” ahora están en manos de un grupo específico que no recibe tantas solicitudes de urgencias como antes, por lo que los tiempos de entrega y la agenda se ha ordenado, aunque llevamos en esto una sóla semana, y no podemos decir cuánto más se avanzó.
Espero poder contar mi experiencia en otro post. Esta comunidad está muy interesante y, si bien no somos desarrolladores de software, creo que nuestra “aventura” podría servir a todos.
Muchas gracias por tu respuesta davidlaym!
over 1 year ago
ricardo74
said:
creo que la solucion va justamente por el lado de separar el equipo en grupos, con distintos tipos de tareas. hay gente que se siente mas comoda haciendo mantenciones, mientras otros prefieren los desafios nuevos.
en todo caso, en la descripcion del problema no indicas la cantidad de personas trabajando en tu area, pero segun las practicas agiles los (sub)grupos no deberian tener mas de 10 personas.
All Shapado.com content and data are available under the
Trabajo en una compañía desarrolladora de software, en el área de diseño web. Una de nuestras labores es configurar “portales” (sitios) que nos solicitan desde comercial basados nuestro software ya implementado (piensen en algo así como “plantillas” de Wordpress). Aproximadamente nos solicitan 50 sitios mensuales y en paralelo al rededor de 120 cambios/mejoras por mes. Esta situación se repite todos los meses. Últimemente hemos estado retrasandonos cada vez más con las entregas y aumentar la dotación del área no ha ayudado, es por eso que estamos estudiando adaptar algunas metodologías ágiles a nuestro proceso diario (copiando lo que vemos en el área de desarrollo), por ejemplo el uso de una pizarra Kanban para medir velocidad y mantener el flujo de entrega constante. ¿Algún consejo?, ¿alguien ha tenido una experiencia similar?.
Agradezco sus comentarios. Jorge.