Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




B

Me van a comer en una reunión el lunes. Estaré solo con el cliente, el cliente del cliente, y otro proveedor del cliente.

Se cuestionará todo lo que he desarrollado, la forma en que está hecho etc.

¿Alguna sugerencia?

2 respuestas
SupermaN_CK
#22171vago_21:

Se cuestionará todo lo que he desarrollado, la forma en que está hecho etc.

Imagino que sabes lo que has desarrollado, cómo lo has hecho, el porqué lo has hecho, etc. ¿Cuál es el problema? Hazte unos apuntes y repásalos de todo lo que has hecho y crees que te van a preguntar.

1 respuesta
B

#22172 Es un proyecto muy muy gordo que tuve que downgradear porque el cliente tiene una versión antigua, además tiene mogollón de personalizaciones de ese cliente. No hay nada documentado porque no me dan tiempo para eso

1 respuesta
Lolth

#22173 No hay algún doc funcional de lo que se pidió o algo por el estilo?

1 respuesta
B

#22174 sí, pero de lo que se pidió a lo que se hizo después, vamos, en el doc habrá una cuarta parte

2 respuestas
Lolth

#22175 No se como se hace en tu empresa pero normalmente entre el cliente y el programador suele haber una persona encargada de ese cliente que lleva los funcionales al dia.

Pero estaría bien que tengas algo de info de los cambios que han pedido y ese día estar abierto a cualquier modificación.

Con un poco de suerte el cliente no sera un hdp.

1 respuesta
desu

#22175 Pues eso es problema de tu manager. Esta bien ceder y tener una actitud positiva pero si luego te va a comer lo habeis hecho mal y ahora a joderos.

Un documento de requerimientos SIEMPRE se debe cumplir todo para no tener problemas legales. Luego si haceis cosas extras es otro tema...

Yo he llevado/me han llevado el ultimo a;o 2 proyectos a juicio por temas legales asique se de lo que hablo...

Mi recomendacion:

  • ten una actitud de llevar la reunion tu, se tu el que saque los temas y ve punto por punto, desde el minuto 0 ve directo al grano
  • si te hacen preguntas nunca respondas ni si/no, consultaras todo con el equipo
  • nunca afirmes o asegures deadlines de nada, todo para revisar con tu equipo

termina la reunion pronto, di al principio que quieres hacer una reunion rapida de seguimiento y la proxima ya le dedicareis mas tiempo cuando este X (el responsable/manager).

A mi si se me ponen tontos salgo de la reunion, correo al jefe y de ahi al departamento legal. a tomar por culo el proyecto XD

1
B

#22176 existe esa persona, pero su nivel se limita a repetirme lo que dice el cliente pero teniendo menos idea que el cliente. Y el cliente es uno de estos nazis que hace trabajar a latigazos, me da muchísima pereza esa reunión

1 respuesta
desu

#22178 No justifiques nada en la reunion del dise;o, no habeis hecho documetnacion de dise;o? ahi esta explicado todo, dile que se lo pasareis al terminar la reunion y en una futura reunion comentareis el documento.

si no hay docu como dices, apuntate las dudas que tengas y eso lo haceis en el docu que les entregareis y discutires a futuro.

2 1 respuesta
B

#22179 gracias por los consejos. Me han dicho que van a hacer pruebas en directo, pero poco puedo responder ahí, sin acceso al entorno y sin debugger poco puedo explicar de por qué el sistema se está comportando como lo hace en determinados casos ¿algo para salir del escollo en este caso?

1 respuesta
Lecherito

#22180 pues que lo investigaras, que no sabes por que esta pasando algo (si no lo sabes). No eres omnipresente, y spoiler, no lo vas a ser, pero que no te pillen inventandote tonterias.

1
Kaledros

1.- Di siempre la verdad.
2.- Nunca, NUNCA, eches la culpa a nadie, ni siquiera a ti mismo, de cualquier error, fallo o similar
3.- Si se encuentra un fallo o error di que lo resolveréis pero no abundes en detalles técnicos si no te los piden, vas a acabar poniéndote la soga al cuello.

¡Suerte!

1 1 respuesta
desu

Otra cagada. Esa reunion hace demasiadas cosas.

Comentar diseño y aparte testear?

Mal.

1 reunion => 1 cosa.

ADemas, volviendo a llevar la batuta. Los tests los haceis vosotros automaticos y los compartis, o les proporcionais un entonro para testear y ellos lo evaluan por su cuenta, al final os devuelven una lista de errores o csas que quieren comentar... nunca en una reunion probar cosas a lo random porque perderas el tiempo.

Una vez el cliente te pasa la lista de erroes sobe el test,seria vuestro trabajo valorar que tests se deben arreglar i cuales no. Porque hay cosas que puedne detectarse en un test que no son errores de los requerimientos sino nuevos features, algunos se hacen y otros no..

Si algo petas no digas que lo arreglaras, cagada de novato. se analizara o se sacara un informe de errores con propuestas.

la mayoria de errores que saco en un tests o fase de pruebas yo no los arreglo. esta fuera de requerimientos. :)

1 respuesta
Lolth

Algo que estaria bien, no se si iras tu solo de vuestra parte, es dejar todos los puntos que trateis anotados y su estado y de quien depende cada punto (seguramente todo dependerá de ti) para sacarlo en la siguiente reunion para ver el estado de esos puntos.
Todo lo que se tenga que tratar debería estar plasmado en algun doc, almenos con esto ya irás preparado para la siguiente reunion.

2 respuestas
B

#22182 Gracias, ya contaré
#22183 El tema es que se ha juntado marcha de gente etc, el otro proveedo metiendo mierda y decir a todo que sí sin pensar en las consecuencias, pero vamos, a ver cómo salgo de la reunión, igual acabo actualizando cv xddd

#22184 sí, lo haré aunque sea por mi cuenta, pero vamos, que me toca todo a mí fijo

r2d2rigo

#22171

  • Graba la reunion, por duplicado si puedes.
  • Llevate un guion preparado.
  • En cuanto haya una pregunta que tengas dudas de responder, declina y di que la responderas post-reunion cuando tengas mas informacion.
  • Pies de plomo.
  • Actualiza LinkedIn.
4 1 respuesta
desu

#22184 Yo con conflictivos he llegado a grabar reuniones.

No hablan ni una cuarta parte de lo que hablan cuando no queda grabado...

HAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH

1
isvidal

por que te inventas cosas desu?

Todos sabemos que no has grabado ninguna reunion

1 respuesta
Ranthas

Buena tarde se ha quedado

B

#22186

Actualiza LinkedIn.

jajajajaj hijo puta

1 respuesta
Kaledros

Lo de grabar la reunión es muy buena idea, diles que así te aseguras de transmitir todas sus dudas a compañeros/jefes/etc. Que lo haces por ellos, para que no haya dudas sobre lo que se ha dicho, etc.

1
desu

#22188 pues lo hacemos bastante.

sobretodo cuando quedas un cliente y quieres QUE EL TE EXPLIQUE ALGO.

piensa que para grabar tienes que pedir permiso.

y volviendo al tema, la de grabar es verdad que es muy buena, me la apunto. "como no esta mi compa;ero que sabe mas del tema, te parece si grabamos asi lo puede ver el despues?"
y asi te ahorraras lios...

normalmente solo hemos grabado a gente conflictiva y esto de explicacione.s pero si algun dia quieres ir rapido y sacarte el meeting de encima, dices lo de grabar con esta excusa y seguro que en 10 minutos ya estas HAHAHAHAHAHAHAH

vivora

A ver, que está muy bien grabar reuniones, pero al final lo que es vinculante es el contrato que te firmen. A mi me ha salvado el culo tener un buen contrato redactado, exponiendo exactamente las funcionalidades que cubre el producto entregado, cuando me han venido diciendo que en X reunión pidieron Y funcionalidad y que no la tienen y la exigen. Por mucho que lo pidieran, si en una posterior reunión no se volvió a sacar el tema, cuando se expuso el contrato públicamente antes de firmarlo nadie volvió a sacar el tema, me da igual lo que dijeras en al reunión, yo me limito a desarrollar lo que está por escrito y firmado.

Por lo tanto, en resumen, si tu entregable cumple con todo lo que se ha firmado, no tienes que preocuparte por nada, si el cliente se cabrea por algo y no está por escrito, dos problemas tiene.

1 respuesta
B

Si el tema del contrato es lo que me salvaría de estos temas, pero no se hace, al final yo soy un puto programador, ni más ni menos, no deberían ser mis problemas, ni debería estar yo en esa reunión.

Y lo de grabar es una excelente idea, así se cuidarán más de meter hachazos

desu

#22193 A mi los de legal me pidieron justificacion de horas trabajadas, notas de meetings y demas.

Tienes razon que al final lo mas importante es el contrato y las clausulas exactamente que dicen. Y el documento de requerimientos funcionales.

La cosa es que normalmente hay clausulas de que si las dos partes estan de acuerdo se pueden hacer modificaciones.

Lo de tener la justificacion de tus horas y de tu trabajo, aunque sean commits te aseguro que puede servir para que no te metan algun pollo por algun hueco.

nosotros tenemos esto en nuestros contratos:

En el supuesto de que el Proyecto esté caracterizado por un fuerte componente de investigación
o innovación tecnológica, XXXXXXX se compromete exclusivamente a realizar el desarrollo de las
actividades según las especificaciones acordadas por ambas Partes en el Anexo nº 1. Las
obligaciones asumidas por XXXXXX, salvo que en el Anexo nº 1 se prevea lo contrario, son de
medios y no de resultados.

Ahora llega el fin del proyecto y no se ha alcanzo resultados. Como justificas en una disputa legal que de verdad has puesto el esfuerzo que te han pagado? por ejemplo eh. Incluso lo que firmamos en los requerimientos a veces va con lupa para dejar claro este tipo de clausula y que no quede invalidada.

Si en el requerimientos dices que vas a hacer un modelo predictivo para solucionar X y no lo haces que pasa? porque estas asegurando que conseguirás un resultado...

Es jodido. Yo ando siempre con cuidado porque mis proyectos son los conflictivos y te la pueden liar facil.

Kaledros

Si lo que se va a tratar es el contrato y su relación con el producto que se muestra no deberían lanzar a un dev a los caballos, para empezar. Debería ir con él un manager o alguien que tenga autoridad para (y cobre por) discutir esas cosas. Si mandan a un dev y quieren discutir condiciones de contrato, de entregable y tal están haciendo el tonto unos y otros y mareando al pobre @vago_21

1 respuesta
B
#22196Kaledros:

Debería ir con él un manager o alguien que tenga autoridad para (y cobre por) discutir esas cosas. Si mandan a un dev y quieren discutir condiciones de contrato, de entregable y tal están haciendo el tonto unos y otros y mareando al pobre @vago_21

Voy a llorar :upside_down: me consuela que pienses lo mismo que yo

desu

Los que trabajáis en carnicas como funcionan vuestros contratos y requerimientos?

Vais encadenando contratos y por cada contrato haceis requerimientos especificos? Por ejemplo si renovais contrato cada a;o, cada a;o ajustais el plan de trabajo esepcificio y sus objetvios.

No entiendo como se hace en empresas de consultoria estas cosas. Yo es que acabo contrato y adios, solo hago el toque, el poner botones y divs que lo haga cliente o carnica.

2 respuestas
frekaice

#22198 En consultoras pequeñas se suele firmar un contrato con el cliente, dónde se indican todos los cambios y luego se reservan unas horas para modificaciones/pruebas.

Una vez llega la fecha se entrega la aplicación, la aplicación debería cumplir todos los requerimientos acordados. Durante el desarrollo puede haber cambios en algunas funcionalidades y normalmente se indica con un anexo o simplemente más informal.

Una vez entregado y validado si se tienen que hacer nuevas modificaciones se llega algún tipo de acuerdo o se paga aparte

r2d2rigo

#22190 no lo digo porque te vayan a largar, yo es que ultimamente tengo 0 tolerancia a estas mierdas y soy el primero en largarme cuando veo que es una casa de putas.

2 1 respuesta