¿Qué hacer si el jefe siempre pospone decisiones importantes sobre los requisitos y el diseño general?

Al comenzar un nuevo proyecto, mi jefe siempre evita tomar decisiones fijas. Por lo general, dice: ok, solo comienza a escribir algo y sé lo más genérico posible. Cuando hayas terminado, miramos cómo continuamos. Su argumento es básicamente que nunca se sabe y "desarrollo ágil".

Para mantener la pregunta lo más genérica posible: ¿qué haces si a tu jefe no le gusta tomar decisiones?

¿Solo quédese y escriba código que pueda sufrir una refactorización pesada y una reescritura parcial algunas semanas después? ¿O seguir discutiendo hasta que el jefe tome al menos algunas decisiones? Esta es más o menos mi estrategia actual. Debido a que es como una ley de la física, en algún momento hay que entregar algo. Ya sea porque el jefe del jefe quiere ver resultados o porque las cosas se están volviendo ridículas en algún momento.

También observo que mi jefe está criticando casi todo. Incluso sugerencias que se basan en las suyas ...

Construir prototipos

Simplemente comience a dibujar pantallas que no hagan nada al principio (¿presumiblemente tiene suficiente para hacer eso?)

Debería poder hacerlo parcialmente funcional lentamente, y eventualmente refactorizar parte del código incorrecto cuando quede más claro lo que está tratando de hacer.

Es un problema común que no sepan lo que quieren hasta que vean algo y se den cuenta de que no es lo que quieren. Descubrí que cuando alguien quiere que comiences a construir 'un marco' o algo 'genérico' como lo que te está diciendo, te vas a meter en problemas si lo intentas. Los marcos ya están escritos, no necesita hacer eso.

Hay varios problemas que he reunido de su mensaje: 0-No es su trabajo administrar el proyecto y no es su trabajo reunir los requisitos del usuario final. 1-El jefe no conoce los requisitos exactos 2-El jefe no quiere hablar con los usuarios finales acerca de los requisitos 3-El jefe está lanzando una terminología que realmente no entiende ágil 4-Usted está buscando una solución que se recupere escrito varias veces y no estás contento con eso

En cuanto a 1,2 y 3, es poco lo que se puede hacer al respecto si no es una persona mayor. Sin embargo, se puede hacer lo siguiente:

A - Pídale que comparta con usted el plan del proyecto. Puede tener uno o creará uno que muestre las tareas y los plazos. Uno de estos debe ser sobre análisis y recopilación de requisitos. Si no lo sugiere.

B - Prepare algunas referencias sobre la importancia de los requisitos para el éxito del proyecto de software

C - Prepárele una página de lo que Agile es y no es.

D - Prepárele una lista de entradas típicas para la etapa de diseño y convencerlo del valor de cada uno.

E: sugiera la incorporación de un analista comercial y / o modelador de datos al equipo. Dichos roles tendrán que sentarse con el usuario final y le brindarán la información requerida o al menos buena parte de ella.

F - Mira cómo otros desarrolladores colaboraron con este chico.

En cuanto al n. ° 4, puede sugerirle que utilice un enfoque de creación de prototipos o un generador de código que lo ayude a usted, al usuario y a tomar una decisión sobre los aspectos funcionales de la aplicación. La mayoría de las herramientas no generan una GUI perfecta, pero al menos puedes capturar la funcionalidad requerida.

En todos los casos, asegúrese de documentar cada una de las iteraciones con claridad y enviarle un correo electrónico sobre la información que recibió, lo que hizo (con cierto detalle) y cuál es el resultado. Asegúrese de atribuir los resultados a la causa adecuada, como (falta de requisitos, etc.).

Lamentablemente, algunas personas no aceptan consejos. Así que ten cuidado de cómo te comunicas con él.

¡Esto no va bien!

Buena suerte.

Solía ​​tener un jefe así, de hecho, bromeaba diciendo que su lema era "la indecisión es la clave de la flexibilidad".

Independientemente del trabajo de desarrollo que realice, probablemente esté en una mejor posición para resolver el problema del cliente que su jefe. Si no sabe cuál es el problema que el cliente está tratando de resolver (que no es lo mismo que una especificación), entonces alguien no está cumpliendo sus requisitos de manera adecuada.

Dibuje algunos diseños de página o cree un prototipo no funcional o semifuncional. Pero haz algo. No está claro en su publicación si está creando software de cliente completo o aplicaciones web, pero la belleza de este último es que puede lanzarlo temprano, lanzarlo con frecuencia. Comience con los huesos descubiertos y trabaje desde allí. Un comienzo falso no hace daño si fluye algo de diálogo y se toman algunas decisiones.

Tenemos un dicho sobre $ WORK (aplicaciones web internas) para nuestros clientes: "Te daré algo para que me digas lo que quieres". Prepárate para tirar el primer borrador, pero te sorprenderá cuán raramente tienes que hacerlo.

Indíquele que los libros de Agile sugieren posponer las decisiones todo el tiempo que pueda, pero no más que eso . Cada decisión tiene un punto en el que debe tomarse, y tal vez estés allí ahora mismo.

Por otro lado, también pregúntate a ti mismo. ¿Realmente necesitas decidir qué capa de persistencia vas a usar para esta aplicación? ¿O puede comenzar a escribirlo en un CSV y mantenerlo lo suficientemente abstracto como para tomar esa decisión más tarde?

Escriba su propio documento de especificaciones y mantenga una revisión donde lo explique y él lo firmará. Entonces se convertirá en jefe, y su jefe pasará a más problemas de gestión interpersonal en lugar de problemas técnicos.

Participe en una 'gestión ascendente', hable con su jefe y clientes, encuentre algunas soluciones, elija la mejor para que su equipo la implemente, encuentre fallas en las otras y 'administre' a su gerente para que tome la decisión 'correcta'.

Y, por supuesto, asegúrese de que él piense que fue idea suya. (¡especialmente cuando todo sale mal!)

Necesita diseñar e implementar algo. Como su jefe no tomará decisiones, tómelas usted mismo. Tómese un tiempo extra para documentar sus decisiones y suposiciones antes de implementarlas. Envíelo a quien le interese, incluido su jefe. Afortunadamente, esa lista incluye más que su jefe, ya que lo presionará un poco para que tome algunas decisiones, ya que él sabe que otros saben que usted está listo para continuar. Se sorprenderá de lo rápido que recibe comentarios cuando pone decisiones por escrito, especialmente si toma decisiones con las que otras personas no están de acuerdo. Mientras tanto, procedería con las decisiones que tomaste hasta que me digas lo contrario.

Si terminó de perder el tiempo implementando lo que su jefe no quería, entonces está en él y no en usted, ya que él era consciente del camino que iba a tomar.

Además, algunas personas tienen dificultades para comenzar, pero una vez que ven algo tangible, su mente interviene. Tal vez tu jefe sea así y si le dices lo que planeas hacer por escrito hará que su mente funcione.

Tome decisiones usted mismo y comience a codificar. Por supuesto, el desarrollo de una manera flexible ayudará (lea los patrones, principios y prácticas ágiles de Robert C Martin si aún no lo ha hecho), pero toda la flexibilidad del mundo no ayudará si nunca se toman decisiones. Es posible que tengas que desarrollar lo que piensases necesario, y luego modificarlo según sea necesario. A menudo, los clientes / jefes no saben lo que quieren hasta que lo ven, o hasta que ven algo que no quieren. Esto probablemente lo llevará fuera del alcance de ser un desarrollador, pero así es la vida. A menudo encuentro que yo y mis colegas estamos tomando decisiones empresariales de manera efectiva. A veces, estos no son cuestionados, y las decisiones que he tomado comienzan a impulsar el negocio, simplemente porque nadie más tomaría la decisión. Asegúrese de enumerar TODOS sus supuestos y decisiones (sin excepciones) y presentarlos a su jefe.