Que casualidad que cuando se empieza a programar, es donde empiezan a saltar todos los quilombos de diseño y analisis.

Me cruce con bocha de programadores grosos.

Pero con ningun Analista que pueda entragar una documentacion de requerimientos sin contradicciones, o situaciones no contempladas.

(19-01-2012 20:36)ebric escribió:  Que casualidad que cuando se empieza a programar, es donde empiezan a saltar todos los quilombos de diseño y análisis.
Me cruce con bocha de programadores grosos.
Pero con ningun Analista que pueda entragar una documentacion de requerimientos sin contradicciones, o situaciones no contempladas.

Son dos cosas bastante diferentes. No se puede comparar un desarrollo que tiene una salida en base a un input determinado contra una especificación funcional en la que no solo se debe hacer una gran abstracción para modelar lo que venga en las siguientes etapas (sin hablar del hecho que desde el requerimiento del usuario hasta la implementación hay mucho ruido en el medio: interlocutores que no interpretan correctamente las necesidades del usuario final, redefiniciones, etc).
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.
Al día de hoy creo que el único momento en que no tuve ningún quilombo de esta índole fue al desarrolar par a par con el cliente "al lado", lo cual esta copado para cosas puntuales pero cuando el volumen de requerimientos crece y se incorpora mas gente en el equipo de trabajo se torna inmanejable.

Puede que te cueste un toque amoldarte,yo sabía lo que sabia al salir de paradigmas y me tuve que fumar cosas sobre constructores,clases publicas y privadas en C# (que en smalltalk no existen),LINQ,DHTML,JAVASCRIPT,AJAX,JQUERY...todo eso las primeras dos semanas,que fueron un burnout.Me esta costando bastante acostumbrarme,pero creo que lo estoy logrando y no es nada imposible ni loco.Los primeros dias te van a llevar de la mano seguramente,hasta que remontes vuelo .

(19-01-2012 16:03)Matt escribió:  [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.

Boring.
CAPITALISTAS,CAPITALISTAS EVERYWHERE.

(19-01-2012 16:03)Matt escribió:  

(19-01-2012 14:33)brunodiaz escribió:  

(19-01-2012 14:08)ebric escribió:  Analistas y QA, busquense un trabajo digno.

---

Como dice Imakuni, el que no paso por desarrollo en serio antes no tiene idea de lo que habla.
Es impresionante el cambio cuando te toca alguien que si estuvo antes.

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.

Off-topic:

Alguien que me entiennnnnnnnnnnde

Hola Leatex, por que se te fueron 2 empleados che? Gracias!

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.

El tema también es que a veces uno dice su profesión, y se te ríen, o te toman para chiste, como me han hecho acá
Al principio me importaba, hoy por mí muéranse que yo estoy en otra línea paralela.

Aparte porque no todos somos iguales, y no todos tenemos el mismo nivel de inferencia
No es lo mismo uno que está muy cerrado y sólo se limita a agarrar las necesidades del cliente sin pensar mucho en el otro lado, y está el que tiene una visión más global, porque el desarrollo le interesa. Uno tiene que armar las cosas de manera clara y buscando llegar a un mejor producto donde los desarrolladores no te quieran ahorcar y el cliente esté satisfecho

Existen las reuniones periódicas, donde todos forman parte y dan ideas, proponen cosas..

Aparte nosotros también le hacemos más énfasis a la documentación. En mi empresa además corrijo los documentos de desarrollo que no responden a la lógica de la documentación que está estipulada. Creo que está mal por parte de la empresa en no dar charlas a todo el que ingrese sobre determinados estándares.
Yo creo que la idea es que exista la documentación necesaria para que venga otra persona, la lea y entienda con qué sistema se encuentra, qué es lo que está implementado y qué no, etc.

No sé, soy consciente de que no todos podemos ponernos en el lugar del otro..

Cita:No sé, soy consciente de que no todos podemos ponernos en el lugar del otro..

El tema es que este laburo tiene mucho de eso....

... entonces, si no te podes poner en el lugar del otro, definitivamente tu perfil no va con el perfil idoneo para dicho puesto.

Cita:El tema también es que a veces uno dice su profesión, y se te ríen, o te toman para chiste, como me han hecho acá

Es un tema de como es la cultura informática (?). , ¿A quienes nos bancamos "publicamente" los devs? ¿De quien no nos reimos?Es asi, es como el funcional que piensa que todos sus devs son vagos, o los testers que piensan que los devs no laburan porque siempre rebotan....

Tomalo como de quien viene, como dijiste ahora .

Igual, hay metodologías que hasta pretenden suprimir el sector de Testing como tal.... y que sea una tarea de devs.

Como que se fueron de tema y son un bodrio.

(26-01-2012 10:40)Imakuni escribió:  

Cita:No sé, soy consciente de que no todos podemos ponernos en el lugar del otro..

El tema es que este laburo tiene mucho de eso....

... entonces, si no te podes poner en el lugar del otro, definitivamente tu perfil no va con el perfil idoneo para dicho puesto.

Cita:El tema también es que a veces uno dice su profesión, y se te ríen, o te toman para chiste, como me han hecho acá

Es un tema de como es la cultura informática (?). , ¿A quienes nos bancamos "publicamente" los devs? ¿De quien no nos reimos?Es asi, es como el funcional que piensa que todos sus devs son vagos, o los testers que piensan que los devs no laburan porque siempre rebotan....

Tomalo como de quien viene, como dijiste ahora .

Igual, hay metodologías que hasta pretenden suprimir el sector de Testing como tal.... y que sea una tarea de devs.

No conozco ningún dev que le guste testear
Y es más, el ambiente de desarrollo lo suelo controlar yo, para sacar las cosas gruesas
Con lo de ponerse en el lugar del otro me refería a reirse/burlarse del puesto del otro, en parte..

(26-01-2012 22:10)nanuiit escribió:  Y es más, el ambiente de desarrollo lo suelo controlar yo, para sacar las cosas gruesas

Tengo miedo de preguntar que cosas "testea" nanu

Si no te gusta NADA PERO NADA programar, apuntale a funcional. Es habitual entrar como trainee. Igual tene en cuenta que hoy en dia el 60% del mercado es programacion en Java/.NET/PHP, y que los proyectos chicos (menos de 10 personas) suelen estar compuestos en su gran mayoria por programadores y QAs. En el lugar que laburo yo hay dos funcionales entre 200 personas.

Yo arranque como "analista programador" (AKA developer) y segui esa linea. A mediano plazo (1 año) pienso orientarme hacia el project management que es lo que me gusta. Te tiro como para que tengas una idea.

(26-01-2012 22:10)nanuiit escribió:  

(26-01-2012 10:40)Imakuni escribió:  

Cita:No sé, soy consciente de que no todos podemos ponernos en el lugar del otro..

El tema es que este laburo tiene mucho de eso....

... entonces, si no te podes poner en el lugar del otro, definitivamente tu perfil no va con el perfil idoneo para dicho puesto.

Cita:El tema también es que a veces uno dice su profesión, y se te ríen, o te toman para chiste, como me han hecho acá

Es un tema de como es la cultura informática (?). , ¿A quienes nos bancamos "publicamente" los devs? ¿De quien no nos reimos?Es asi, es como el funcional que piensa que todos sus devs son vagos, o los testers que piensan que los devs no laburan porque siempre rebotan....

Tomalo como de quien viene, como dijiste ahora .

Igual, hay metodologías que hasta pretenden suprimir el sector de Testing como tal.... y que sea una tarea de devs.

No conozco ningún dev que le guste testear
Y es más, el ambiente de desarrollo lo suelo controlar yo, para sacar las cosas gruesas
Con lo de ponerse en el lugar del otro me refería a reirse/burlarse del puesto del otro, en parte..

Es que las burlas no salen de la nada, sino de las experiencias personales que se van teniendo hacia puestos laborales que en principio parecen poco serios.

Off-topic:

Tiene razón Re, dividan el topic

Prometo splitearlo, porque encima es un offtopic copado