De qué sirve el trabajo conjunto de los desarrolladores y cómo se nos ocurrió esta cosa y que resultados nos dió.
Hola nos gustaría compartir nuestro enfoque en desarrollo. Si le interesa, vámonos! :)
En la primera parte del artículo le contamos el principio del intercambio de los desarrolladores en el equipo. La segunda parte será sobre la especialización y capacitación en el departamento de desarrollo, y en la tercera — sobre los lados positivos y negativos de nuestro principio.
Siga nuestras noticias en Facebook. ;)
Qué sentido tiene el principio de interoperabilidad
De que se trata
El principio de interoperabilidad de los desarrolladores hace referencia a reasignar cualquier tarea del proyecto a cualquier desarrollador de nuestro equipo. Cabe incluso hacerlo a lo largo de todo el proyecto.
Para conseguir el proyecto hay que evaluar el tiempo requerido para dedicarse al proyecto y al código, teniendo en cuenta los riesgos de demora y de cambio de los plazos externos.
Al compartir los gastos internos con los riesgos externo, encontramos un equilibrio basado en nuestra experiencia y sólo después tomamos la decisión de cómo y a quién asignar las tareas.
Cómo se crean nuestros equipos de proyectos
El principio de que los desarrolladores son intercambiables significa que varios desarrolladores participan en los proyectos diversos de manera diferente.
El equipo para cada proyecto se construye en modo dinámico y puede cambiarse. Podemos a nuestras necesidades incorporar los desarrolladores a un proyecto importante y urgente, lo que deja libre al especialista de otras tareas, pero no todas, es que el desarrollador nunca se dedica a una sola tarea.
A veces un equipo se cambia totalmente cuando se refiere a proyectos nuevos y por supuesto será imposible imaginar ese escenario en caso de proyectos largos. Pero le decimos con toda certeza, se puede hacer lo mismo en los proyectos con historial. Es que todo depende del equilibrio entre los gastos internos y los riesgos externos.
El desarrollador principal del proyecto
Nuestro enfoque no excluye el rol del desarrollador principal en el proyecto, la persona que toma decisiones cruciales en el proceso del diseño de programa. Dar una mirada atenta, siempre hay el desarrollador principal en cada proyecto, en nuestro caso las personas quienes ocupan este rol pueden cambiarse.
En la etapa activa dedicada a implementar el funcionamiento precisamente el desarrollador principal está al tanto de todo el proyecto para adoptar las decisiones en el proceso. Si la etapa de funcionamiento siguiente es muy distinto del último, probablemente para cumplir esta tarea será asignado otro desarrollador como principal.
Tomar las mejores decisiones arquitectónicas y diseñar el código en función de la tarea en cuestión es un derecho y deber importante de un desarrollador competente. No importa lo genial que haya sido el diseño, no se irá. Y eso es bueno.
Tomando una decisión intentamos reducir los riesgos, lo que acompañan las discusiones durante el analisis técnico.
Gestión de los equipos de proyecto
El gestor de los proyectos (en colaboración con el analista y el director técnico) controla la actividad del equipo. Normalmente entre todos los especialistas sólo el analyst designer está profundamente en los proyectos y los sabe en detalles. El gestor de los proyectos siempre sigue informando sobre el proyecto y mantiene la comunicación entre todos sus participantes.
La gestión controlada asegura la transferencia de los proyectos entre los desarrolladores, intercambio de los conocimientos y la asignación de las tareas.
Sin embargo, los desarrolladores están acostumbrados y listos a dar una mano a su compañero de trabajo, explicandole los detalles del proyecto. Ellos ya están programados para explicarse.
Razones por qué decidimos aplicar este principio y cómo se ha desarrollado
Proyectos pequeños, flexibilidad de los plazos y demoras
Al inicio empezamos a realizar proyectos pequeños. Antes las tareas se barajaban como las cartas. A veces pedíamos los detalles del proyecto y quedábamos en espera de sus respuestas o en seguida se actualizaba el estado, dando alta prioridad, o tal vez se demoraban los plazos de entrega. Era difícil para nosotros planificar la carga interna de los desarrolladores.
Buscamos una solución y la encontramos mejorando nuestra flexibilidad. Así se dió a la luz el principio de interoperabilidad de los desarrolladores.
Proyectos medianos y pequeños. Lo más importante es cumplir los plazos externos de entrega.
“Estuvimos desarrollando” lo que suele decir la gente. De hecho, en un momento reconocimos que estuvimos listos para realizar proyectos complicados y grandes. No diríamos que teníamos proyectos que proponían presupuestos grandes o implementar muchas innovaciones, pero debíamos hacer un buen y duro trabajo técnico.
Así tuvimos proyectos con varios horizontes de planificación. A la flexibilidad interna se agregó la necesidad de mantener los plazos estrictamente, aunque los términos eran muy diferentes. El modelo de interoperabilidad obtuvo la segunda limitación grave.
Conciliamos los proyectos medianos y pequeños con los grandes
Ya estamos en el 2019 y trabajamos con proyectos de varios niveles y la complejidad de los cuales ha aumentado. Todavía nos da placer asumir proyectos pequeños, especialmente si nos interesan las tareas y tendríamos grandes perspectivas de colaboración con el cliente en el futuro. Nos atrae colaborar a largo plazo con el cliente, es que el proceso de implementación de Bitrix24 siempre consume mucho tiempo.
Dentro de un año, usando la funcionalidad requerida, más o menos, podremos evaluar en serio si la implementación de Bitrix24 será realizada con éxito o no. En el caso que la funcionalidad se use por defecto, entonces el año se cuenta desde que el sistema se configura completamente. Tenga en cuenta que dentro del año después de la personalización de la funcionalidad, vale la pena evaluar el resultado empezando desde la implementación de la versión comercial con la funcionalidad personalizada. Mientras tanto, hay que asegurarse que la implementación haya sido finalizada con éxito, eso significa que todos los componentes de Bitrix24 han sido incorporados en los procesos de negocio y los empleados ya han obtenido las competencias adecuadas para trabajar en Bitrix24.
Horizonte de planificación a plazo medio y backlog largo
Cuando se planea en detalle un proyecto grande, desde el inicio se necesita conocer sus recursos para cumplir las tareas al menos a plazo medio. Para enterarse, hay que entender cuántos recursos se requieren para realizar un proyecto grande. Entonces la planificación de los recursos depende de la carga general de trabajo para los empleados, y así mismo la carga directamente depende de la planificación. Tenemos en cuenta que los datos necesarios para planificar y encargar siempre cambian.
En este modo nuestro esquema falló. Hubo que encontrar una clave para gestionar el sistema con los dependientes desconocidos.Hemos descubierto que nuestra clave es poner prioridades.
Seguimos así
Dar prioridad
Un parámetro básico para valorar nuestro trabajo ahora mismo son las prioridades en el sentido más amplio.
Podemos decir que nuestro esquema basado en el principio de la intercambiabilidad entre los desarrolladores y sus trabajos sobre las tareas se parecen al impulso de electricidad que pasa a través de los cables cerrados en un círculo. Las prioridades externas determinan el alcance de las tareas internas.
Por su parte, el negocio pone las prioridades, corrige la experiencia y procede nueva información externa. Todo eso se cambia sin parar y estamos listos para responder de manera óptima.
No estamos encerrados en circunstancias y tomamos los cambios como las cosas cotidianas, ya que gestionamos nuestras prioridades según toda la información obtenida.
Asignación de la tarea
El encargo principal para el analyst designer y los managers de los proyectos es acompañar al cliente desde la etapa “idea” hasta la entrega del proyecto, formulando y satisfaciendo las expectativas de cualquier persona que participe en el proceso. Lo importante es que los desarrolladores también estén satisfechos. El analyst designer y el manager del proyecto manejan los dos juntos la tarea desde su asignación, poniendo los detalles. Procuramos asignar la tarea lo más detalladamente posible, proporcionar al desarrollador toda la información importante, incluso el entendimiento de la tarea en general y en particular y el rol de la tarea en el proyecto. Además cuando sea posible evitamos ciertas tecnologías como son el lenguaje, el framework, la variedad de la realización, aprovechamos esto al máximo en el proceso de la asignación de la tarea.
Luego tenemos que dar las respuestas a todas preguntas del desarrollador — e introducir los cambios debido a la carencia de la información en el plan de realización a tiempo. Eso puede ocasionar retrasos en las respuestas por parte del cliente o demoras en los detalles de la tarea por parte del proveedor o el retardo de la evaluación de la tarea por las aclaraciones.
Por fin, en realidad desde el inicio proporcionamos los criterios ciertos de aceptación. Ahora aplicamos la aceptación basada en el historial del usuario como adición a las descripciones de funcionamiento, prototipos, esquemas y otros artefactos.
Resolver y probar los puzzle
El gerente de los proyectos en conjunto con el analyst designer garantizan la gestión del proyecto. Para poder garantizarlo se debe desglosar el proyecto, luego discutir con los ejecutores la descomposición y las evaluaciones finales.
Cuando el equipo se está formando de manera activa, debemos prever el tiempo para realizar el proyecto por el puzzle de las tareas asignadas y también tener en cuenta el cambio de las evaluaciones por parte de varios ejecutores. Hemos desarrollado y estamos incorporando el estándar para evaluar las tareas, lo que facilitará el trabajo con las evaluaciones de varios ejecutores.
Las características de la descomposición se notan en el trabajo del examinador quien tiene su supervisor (el manager de los proyectos). El principio del trabajo conjunto en forma de intercambio de los desarrolladores influye en la prueba parcialmente. Hay características precisas en la ejecución de la tarea, detalles en la escritura del código, también circunstancias que provocaron el cambio y reasignación de las tareas.
Preguntas al desarrollador
Prestamos mucha atención para que nuestros desarrolladores se profundicen en el proyecto desde cuando fue en etapa inicial, cuando tuvimos sólo el concepto, planificando las ramos del negocio y los esbozos de cómo realizar el proyecto. Lo ayuda a mejorar la participación y estimular la motivación de los desarrolladores. Pero aunque a ellos no les guste leer y discutir los documentos, al menos los cuales no les sirven para el desarrollo actual.
Para que los desarrolladores se sientan cómodos, nos hemos acostumbrado a poner la información que describe el proyecto en forma de documentos cortos. Los formatos de estos documentos pueden diferir considerablemente de un proyecto a otro, pero mantienen el objetivo único — es servir como el punto inicial para comprender y discutir sobre el proyecto incluyendo los desarrolladores.
Además la profundización previa en el proyecto permite en cualquier forma simplificar y reducir el desarrollo futuro. Y no es ningún secreto que incorporar los desarrolladores en la etapa antes del desarrollo acelera todo el proceso.
Extraordinario, ¿verdad? Pero aún así este tiempo se gastará en el proyecto no para tomar decisiones antes,sino para hacerlo en el proceso. Estas decisiones serán más difíciles. A lo largo del proceso activo del desarrollo nadie sabe cuantos gastos temporales entrañaría cualquier cambio.
Nosotros preferimos dedicar este tiempo para planificar de antemano y mantener la gestionabilidad de los proyectos.
Lo que conseguimos
Hemos practicado ya bastante tiempo este principio y vamos a seguirlo. El principio está repetido de interoperabilidad de los desarrolladores nos da las flexibilidades organizativa y tecnológica.
Flexibilidad organizativa
Flexibilidad organizativa significa que tenemos poco o ningún circunstancia interna que sea insuperable. Siempre o casi siempre se puede encontrar la solución. Lo más importante es aprovechar bien las posibilidades que proporciona la prioridad.
En vez de buscar las posibilidades externas tenemos las posibilidades internas y la motivación para aprovecharlas. También usamos las posibilidades externas pero sobre todo más en los casos precisos y de mucho cuidado.
Flexibilidad tecnológica
Flexibilidad tecnológica significa que podemos seleccionar individualmente los stacks y las metodologías para realizar el proyecto. Dependemos sólo en parte de la reserva de los proyectos que ya hemos desarrollado.
¿Alguien está listo para trabajar con Agile? Muy bien, eso nos atrae — puede dar en el resultado una buena previsibilidad a corto plazo de descarga y las respuestas rápidas por parte del cliente. Otro prefiere solamente el estándar de cascada o ¿puede ser sólo por la licitación? Está bien, vamos a preparar un esquema que permita combinar la evaluación del presupuesto con las etapas de realización, incluyendo la flexibilidad en sus límites aceptables. En la opción de los métodos para realizar nuestros proyectos internos estamos experimentando con más valentía.
En vez de ofrecer al cliente nuestro esquema de trabajo, estámos dispuestos a crear otro esquema que se compone individualmente para cada proyecto o para cada etapa del proyecto. En nuestra actividad en Bitrix24 garantizamos que no se entrañaría los riesgos y gastos adicionales.
Principio vival
Por supuesto que los cambios ocurren siempre. Intentamos de que ellos sean a constructivos: observamos la implementación de los cambios internos; quitamos lo que no funciona; inventamos nuevas soluciones a los problemas.
Nuestro objetivo: crear todas las condiciones adecuadas para que el trabajo del desarrollador sea productiva, las tareas sean comprendidas con sus criterios claros.
Es un objetivo muy real, en general, lo hemos conseguido :)
En la parte siguiente lea sobre cómo funciona nuestra especialidad, capacitación y ayuda mutua entre los desarrolladores.
