Cita:También es impresionante lo inverso,muchos desarrolladores parece que se olvidan que atrás de clases, objetos y compiladores esta toda la lógica de negocio.
Cita:De todas formas siempre está el que frutea desde cualquiera de los dos lugares... Siempre está el analista que te hace una definición en prosa, enuncia un requerimiento en el primer párrafo y en el segundo te hace el mismo pero negado y/o el desarrollador que después de explicarle y definirle hasta el último detalle del requerimiento sobre X te termina entregando todo el abecedario menos X.
Entonces el problema, definitivamente, está en el funcional, en el lider de equipo, o en..... pero no, la culpa no la pueden tener los desarrolladores, si estas en una estructura rigida.
Ahora, si me hablas de un equipo de trabajo que hace todo, en donde no hay roles definidos, en donde el programador no es solo un codemonkey, sino que su funcion es pensar y brindar una solución (lo ideal en Agile), entonces si, la culpa la tiene el programador (o mas bien, el equipo de desarrolladores).
Mientras haya una persona con el rol de analista funcional, un cliente sordo que quiere hacer las cosas como se le canta, y un desarrollador que no es escuchado, entonces lo unico que te queda es ponerte los auriculares, olvidarte de la lógica de negocio, y tirar lineas.
A la larga, el cliente se calienta, el analista funcional sufre presión, el programador busca otro laburo en mejores condiciones... Laburé un tiempo asi (6-7 meses) al estar con gente que no escuchaba, hasta que se dieron cuenta que ningun programador sabia de la logica de negocios (ni les importaba), y empezaron a cambiar... Y ahi empezaron a ver que los devs no fruteaban tanto, si no que te tiraban un documento de 300 paginas y a partir de ahi tenias que hacer un sistema.
Y como solucionar que los devs entreguen cualquier verdura? Bueno, ahi tenes cosas como reuniones diarias, entregas pequeñas y en corto plazo, pilas de soporte, y un laaaaargo etcétera...
Como te enseñan en mejora continua: No hay que preguntarse quien tuvo la culpa, si no, como dejamos que el problema suceda.
Cita:Es como que uno se tiene que poner en el lugar que ellos
Y ellos, noooooooo, cómo se van a poner en nuestro lugar
Hay algunos que sinceramente no les da la cara y deberían ser más humildes
Creo que si uno fuese tan inutil no existiría el puesto
Laburé dos meses como analista funcional part-time (la otra mitad, desarrollaba). Suerte que me vine a capital...
Me pareció un laburo jodidisimo e inutil, que puede cambiarse tranquilamente con un equipo de devs proactivos, y un cliente que sea un poco flexible.
En dos meses me di cuenta que:
- Si la logica de negocio es facil, hacer un documento no es mas que consumir tiempo al pedo.
- Si la logica de negocio es dificil, tenes que hacer un documento kilometrico.
- El documento es facilmente reemplazable por tests programados, y diagramitas para la logica interna. Talvez algun que otro documento para una parte en particular.... pero para eso, prefiero hablar con alguien idoneo del sector para el que estoy haciendo el sistema, que con un funcional que sabe las cosas a la mitad ...
Para el tema de las ERS.... cualquier grupo de devs con ganas de volar le rompe el tuje al funcional promedio: Piensan como va a ser la solucion, les hacen un prototipo de las pantallitas (incluso, hasta lo venden mejor) y despues con el tema de la logica de negocios, hablan cada dos por tres con el cliente/product owner/lo que sea. Es mas copado eso que un documento de 100 carillas creado por un funcional.
Y si me dicen "no todos los devs quieren volar, la mayoria se tiran a chantas", mi respuesta sería: Motivalos para que lo sean. Y si son chantas posta, echalos `prqie no quieren laburar, y si no lo haces, el dia de mañana probablemente crezcan, y se conviertan en funcionales chantas.
.
.gif "=)")