Me han pedido que complete un proyecto sin especificaciones concretas

Primero: Bienvenidos a esta cosita que me gusta llamar "vida real".

Los desarrolladores de software siempre dicen que antes de comenzar un proyecto, todos los requisitos deben estar completamente definidos, desde descripciones detalladas de algoritmos hasta maquetas de pantalla, y una vez que comienza el trabajo de desarrollo, no se deben permitir cambios. Cuando se entregue el producto, por supuesto corregiremos cualquier desviación de los requisitos escritos, pero no se permiten cambios que impliquen un cambio en los requisitos.

Sí, esto facilitaría mucho la vida del desarrollador de software. Y es una demanda absurda.

Imagina que quisieras comprar un auto. Así que vas al concesionario de autos y descubres que es solo una oficina con un tipo detrás de un escritorio. Te entrega una hoja de papel en blanco y dice: "Escribe aquí exactamente lo que quieres en un auto. Luego encontraremos un auto que cumpla con esos requisitos y te lo entregaremos. Una vez que firmes el papel, comenzaremos a buscar". para un automóvil, por lo que en ese momento no se permiten cambios". "Pero", dices, "tengo una idea general de lo que quiero, pero ciertamente me gustaría probar algunos autos diferentes, llevarlos a dar una prueba de manejo..." "No, lo siento", dijo él. dice: "Eso no es posible. Solo escribe lo que quieres y te conseguiremos un auto que cumpla con esos requisitos".

Ahora suponga que, además de eso, nunca antes ha conducido un automóvil. ¿Cómo sabrías lo que quieres antes de probarlo? Las cosas que parecen una buena idea en el papel pueden no funcionar tan bien en la práctica, etc.

No me preocuparían los requisitos vagos, SIEMPRE que todos los involucrados entiendan que los requisitos son vagos, que tendrá que llenar los vacíos y que cuando vean las decisiones que ha tomado, habrá algunas decisiones. que no les gusta y las cosas tendrán que ser reelaboradas.

Si este es un ambiente relajado y cooperativo, no debería haber problema. Produces algo, lo llevas a revisión, te dicen lo que les gusta y lo que no, haces cambios, tal vez vas en muchos ciclos. He hecho muchos, muchos proyectos como ese en mi vida. A menudo, el usuario tiene que probar el software para ver qué funciona en la práctica y qué no.

Si el jefe o el cliente están haciendo demandas irrazonables, o si usted no sabe cómo es el ambiente, entonces necesita obtener las cosas por escrito para protegerse. He hecho algunos proyectos en mi vida en los que el jefe o el cliente dice: "No sé cuáles son todos los requisitos, solo inventa algo". Luego me invento algo y cuando lo traigo de vuelta gritan: "¡Qué! ¡Eso no es lo que yo quería! ¿Qué clase de imbécil eres? Seguramente era obvio que..." y luego proceden a dar un montón de requisitos que nunca lo mencionaron antes y eso no era obvio para mí en absoluto. En ese tipo de entorno, incluso si no son gritos y amenazas de despedirte o cancelar el contrato, tal vez solo sean expresiones de gran decepción y frustración, en ese tipo de entorno, escribe un documento que describa lo que te propones hacer y devuélvelo para su aprobación. Si tiene suerte, esto conducirá a una discusión sobre cuáles son los requisitos reales. En el peor de los casos, dicen "sí, sí, lo que sea" y lo ignoran. Pero al menos en este punto, cuando regrese con el software, si dicen: "Eso no es lo que queríamos", puede devolver el documento y decir: "Oh, lo siento, esto es lo que acordamos". Debería hacerlo. Mira, está escrito aquí mismo, y tú lo aprobaste". En un ambiente amigable, dices esto de manera amistosa; en un entorno hostil puede que tenga que ser más contundente. De cualquier manera, entonces dice: "Está bien, entonces, ¿qué cambios en los requisitos desea hacer?" Luego póngalos por escrito y comience otro ciclo.

Si el jefe o el cliente esperan tiempos de respuesta imposibles y lo culpan cuando no se cumplen las demandas imposibles, entonces, francamente, es hora de comenzar a buscar otro trabajo u otro cliente. O si necesita este trabajo/cliente lo suficiente, lo aguanta y acepta el abuso. (Tengo gratos recuerdos de la vez que mi jefe me preguntó cuánto tiempo llevaría convertir un sistema grande y complejo que nuestra empresa había construido hace años de un antiguo lenguaje informático a un lenguaje más moderno. Empecé a intentar pensar en voz alta un poco , habíamos hecho una traducción de este tipo en otro producto, por lo que teníamos algo de experiencia, pero nadie en la empresa hoy estaba familiarizado con este producto, bla, bla, y luego dijo: "No necesito una respuesta exacta, solo aproximadamente : ¿dos días? ¿tres días?" Me quedé estupefacto, "Umm, no", dije, "La pregunta es cuántos meses".

Necesitas empujar hacia atrás. Obtener tiempo en sus calendarios. Hacer preguntas. Haz un montón de preguntas. Haz tantas preguntas que se cansen de ti y te darán el detalle que necesitas.

Si no lo saben, proponga requisitos específicos y obtenga la aprobación. Documente sus respuestas y envíeles las respuestas para su confirmación. Eso deja en claro que la causa del cambio y la demora es que ellos cambien de opinión, y no su desarrollo.

Cuando dicen "constrúyelo a tu manera", lo que realmente quieren decir es "haz algo que yo pueda ver y cambiar". Es mucho, mucho más fácil revisar y cambiar los requisitos antes de implementarlos.

Por lo general, cuando los requisitos del cliente son muy vagos, lo que debe hacer es anotar lo que va a hacer (es decir, especificaciones técnicas y funcionales) y que ellos validen el documento . De esta forma, si quieren cambiar algo durante el proyecto, puedes señalar que no es lo acordado y cobrarles por ello. Al menos igualmente importante es el hecho de que no pueden culparte por hacerlo "de la manera incorrecta".

Si su proyecto no está demasiado avanzado, aún así trataría de hacer que esto suceda. Puede parecer una pérdida de tiempo a corto plazo, pero le impedirá toda una vida de implementación de cambios.

Si ya casi ha terminado (obviamente descartando la interminable lista de cambios que vendrán pronto), bueno, eso es más complicado. Estás viendo el control de daños aquí. Haga que su gerente lo reconozca, preferiblemente por escrito. No querrás ser el chivo expiatorio si el proyecto se complica mucho.

Para decirlo sin rodeos, esto me parece una mala gestión de proyectos. Hablaría con el gerente para evitar esta situación en el futuro.

Marv, creo que la mayoría de estas respuestas son tonterías.

Esta no es la realidad del desarrollo de software. Es el efecto de no administrar una tienda de software lo suficientemente bien.

Los requisitos no son la respuesta, porque los requisitos cambian. Ya sea porque las personas que firmaron cambiaron de opinión o porque nunca tuvieron una idea de lo que querían en primer lugar, es irrelevante. Incluso el propio negocio puede cambiar las prioridades, obligando a cambiar los requisitos.

Solo una persona parece haber sugerido Agile. Ese es un buen comienzo, pero Agile requiere mucha aceptación por parte de muchas personas, personas que tienen que hacer la tarea. Claramente, no estás trabajando con personas que no quieren hacer su tarea.

Entonces, tome prestado de Agile. Haga que estas partes interesadas asistan a conversaciones en las que usted impulsa la creación de historias ( http://www.mountaingoatsoftware.com/agile/user-stories ). Mantenga estas definiciones en su idioma, para que no haya confusión sobre lo que acordaron cuando se revise 3 meses después. Espere rondas de creación de historias, manteniéndolas de alto nivel/amplias al principio, y dividiendo las historias en historias más pequeñas con el tiempo, según lo considere necesario. Las historias más pequeñas significan alcances de trabajo más finos y ayudan a crear problemas solucionables.

Armado con un conjunto de historias lo suficientemente pequeño como para brindar estimaciones cómodas, puede impulsar un cronograma y priorización para desarrollar su proyecto, independientemente de cuánto ayuden o no las partes interesadas. Asegúrate de que las historias se almacenen de forma transparente. Y cuando la gente quiera que dejes de "trabajar por historias", retrocede .

Mockups, propuestas, PoC, todo eso está bien, pero incluso ellos deben provenir de una comprensión de lo que vas a construir para ganarte la vida. De lo contrario, es solo disparar en la oscuridad, creyendo que un día tendrás un golpe de suerte. Tome el problema por los cuernos, haga un guión gráfico del proyecto para ellos si no lo hacen ellos mismos.

"Fallar temprano, fallar a menudo".

Cuando tenga requisitos mínimos, construya un sistema mínimo y luego muéstrelo. Demuéstrelo y sus características a lo largo del camino, y solicite y espere comentarios que alterarán su trayectoria.

Sí, muchos desarrolladores como usted quieren una especificación impecable, después de lo cual irán a la torre y, algún tiempo después, saldrán con la implementación correcta, listos para recibir el siguiente proyecto.

Sin embargo, se unió a una empresa y un equipo en el que se espera que corra con un aporte mínimo, trote un poco, regrese con preguntas y demostraciones, y trote un poco más.

Hay un elemento de ineficiencia en este proceso. Pero a menudo los requisitos y necesidades comerciales lo dictan. Si esperaran para crear la especificación perfecta, el proyecto no se terminaría a tiempo y, de todos modos, necesitaría modificaciones porque nadie puede predecir el futuro.

El desarrollo iterativo puede no ser su taza de té, pero como descubrirá, es mucho, mucho más común que el desarrollo de especificaciones perfectas.

La comunicación, las frecuentes pruebas y comentarios de usuarios/clientes/supervisores, y la voluntad de aceptar los golpes se convertirán en excelentes habilidades si las desarrolla.

En el momento en que comienzas un proyecto, sabes lo mínimo que sabrás sobre él. Los consumidores de su proyecto también saben lo mínimo que sabrán sobre él.

Pueden darle un pastel en el cielo "esto es lo que creo que debería hacer, y así es como quiero que lo haga", pero lo más probable es que se equivoquen, especialmente en los detalles.

Del mismo modo, si toma un diseño y hace un plan de desarrollo de más de 2 meses para implementarlo, luego sale y trabaja en él, es casi seguro que no seguirá ese plan. Las partes serán más difíciles o más fáciles de lo que piensas, otras partes serán inútiles cuando llegues a ellas y, a medida que trabajes en el proyecto, adquirirás experiencia en ese proyecto.

Una semana después, tendrá una mejor idea del plan y muchos ajustes. En un mes probablemente pensarás que tu plan fue estúpido.

Tus clientes/jefes tienen una idea de lo que quieren. No son expertos en lo que quieren hacer: en el mejor de los casos, son generalistas que saben cómo resolver problemas similares, pero la única forma de convertirse en un experto en la creación de una pieza de software es crear esa pieza de software. Si ya hubieran creado esa pieza de software, no te necesitarían.

Su trabajo es convertirse en un experto en la creación de la pieza de software. Lo que hace el software, inicialmente, será vago. Ellos realmente no lo saben, y tú realmente no lo sabes. Así que iteras: averiguas lo que crees que quieren, les preguntas si eso parece razonable, implementas y obtienes algo frente a ellos lo antes posible. Dependiendo de quiénes sean, pules diferentes partes y dejas otras partes sin terminar.

Entonces obtienes retroalimentación. Les gustarán algunas partes, pensarán que otras partes son basura y pensarán que otras partes son una pérdida de tiempo. Te vas y cambias tu software, tal vez incluso deseches el trabajo y comiences de nuevo (porque ahora tu experiencia en escribir esa primera parte ha mejorado mucho, simplemente lo hiciste, y probablemente aprendiste algo de eso) y obtienes al mismo punto más rápido, o tal vez simplemente lo modifica y agrega lo que les gusta, y cambia lo que quieren.

Cuando reciba sus comentarios, pídales que digan qué es lo más importante que quieren mejorar. Póngalo por escrito. Preguntar qué es más importante (obtenerlo en una lista ordenada). Digamos que se pondrá en contacto con ellos con estimaciones de prototipos en uno o dos días. Adivine cuánto tiempo tomará crear prototipos de las principales funciones que desean, pregúnteles si están de acuerdo con un prototipo (NO una versión terminada) que esté listo para mostrarles en X días (incluya un búfer para errores) de uno de los principales 2 cosas que quieren.

Luego muéstreles su prototipo, pregúnteles si quieren que esté terminado o eliminado de la solución. Dependiendo de quiénes sean, es posible que desee dejar en claro cómo se comporta la aplicación que es un prototipo. En este momento debería tener una buena idea de cuánto tiempo llevará pulir el prototipo. Pueden pedir más cambios antes de "terminarlo", o pueden pedir que se pula. Si te piden más cambios, vuelve a lo anterior de prioridades.

Esto es básicamente ágil impulsado por el desarrollador, en el que participa activamente en hacer tratos con sus consumidores/jefe. Reciben prototipos frecuentes y se les pide que den su opinión con frecuencia. Tienes que asegurarte de que cualquier prototipo pueda y sea eliminado si no te piden que lo pulas, y que sepan que tus prototipos no están tan cerca de las funciones completas.

Al hacer esto, su experiencia en la escritura de la aplicación crece y su comprensión de lo que realmente quieren crece a medida que desarrolla la aplicación.

Si solicita una especificación completa por adelantado, las decisiones se toman antes de saber qué funciona y qué no.

Un equipo de software necesita no solo desarrolladores, sino también ingenieros de requisitos, evaluadores y algunos otros roles. Es muy posible que en un equipo pequeño, la misma persona use muchos sombreros a la vez. Pero tenga en cuenta que el rol de un ingeniero de requisitos requiere un conjunto de habilidades diferente al de un desarrollador. Si intenta crear requisitos a ciegas, sin saber la forma correcta de hacerlo, será muy ineficiente, básicamente codificará la aplicación incorrecta en la mayor parte de su tiempo de desarrollo y luego se frustrará cuando tenga que eliminarla y comenzar de nuevo.

Le sugiero que adquiera algunas de las habilidades que necesita un ingeniero de requisitos. En su trabajo actual, mejorará en las tareas que le han encomendado. En trabajos futuros, donde la especificación de requisitos puede ser creada por un ingeniero de requisitos dedicado o por consenso dentro del equipo, o improvisada por un cliente, tener este conjunto de habilidades (que interactuará con su rol de desarrollador más puro) lo hará una persona más valiosa. miembro del equipo y permitirá que su equipo trabaje en conjunto de manera más eficiente debido a una mejor comunicación con usted.

La mejor manera de comenzar es con un libro de texto completo. Mi favorito personal es Descubrir los requisitos de Ian Alexander , un texto muy práctico que es fácil de seguir para los principiantes. La segunda lectura en su lista puede ser el diseño de interfaz de usuario de Lauesen para ingenieros . El título puede sonar antiguo, pero lo que aprenderá de él ahora se conoce bajo la palabra de moda UX, que es una ventaja para tener en su currículum hoy en día. Y no, no se trata solo de la interfaz, cubre todos los requisitos que son perceptibles para el usuario (incluyendo la pregunta de qué funcionalidad incluir).

Al mismo tiempo, eduque a sus gerentes que es un trabajo real. Esto significa que 1) si esperan que haga un trabajo que necesita 10 horas de análisis de requisitos, solo le quedan X-10 horas para codificar. Y 2) que, al igual que cualquier otro proceso, convierte la entrada en salida, y debe tener acceso a la entrada antes de poder producir una especificación: en este caso, cualquier información que pueda obtener sobre el uso futuro de la aplicación usted está trabajando con Incluso el mayor genio de las ER no puede crear un buen concepto si no tiene acceso a usuarios reales. Los libros le dirán a qué fuentes necesita acceder; intente cubrir la mayor cantidad de ellos posible.

Creo que esto se reduce a educar a los clientes y a la gerencia.

Los cambios se vuelven más costosos cuanto más avanzado está el proyecto.

Puede consultar casi cualquier libro de texto de ingeniería de software para obtener los "costos relativos de corregir errores en el gráfico del ciclo de vida del software". Básicamente dice que cuanto más avanzado esté en el proyecto, más le costará hacer un cambio. Entonces, ¿por qué no solucionaría los problemas en la etapa de planificación siempre que pueda?

Code Complete menciona que la mayor parte del costo de un proyecto está en la codificación, por lo que si necesita repetir eso varias veces, el costo de su proyecto puede salirse de control fácilmente.

Planifique lo justo para la complejidad del proyecto

Hay varias metáforas apropiadas para la ingeniería de software. Mi favorito personal es la construcción de edificios. A diferencia de la construcción, la cantidad de planificación no necesita ser exhaustiva, solo debe ser suficiente para la complejidad del producto.

• Si el proyecto es trivial (como una casa para perros), entonces puede pedirle al constructor que "simplemente lo construya, podemos cambiarlo más tarde", y está bien. Cambiarlo es fácil.

• Si está construyendo una casa, generalmente le pide a un arquitecto que primero dibuje los planos. El cliente y el arquitecto acuerdan un diseño antes de construir la casa. Cuando se aceptan los planos, el constructor puede comenzar. Todavía puedes pedirle al constructor que lo haga, pero tendrá que esbozar un plan aproximado antes de comenzar, y te costará mucho más cuando tenga que arreglarlo.

• Si está construyendo un bloque de oficinas, es mejor que contrate a un arquitecto, o se derrumbará. Si un constructor increíblemente hábil logra hacer un bloque de oficinas sin un plan, pedirle que agregue un subsótano porque se olvidó del estacionamiento es inmensamente costoso o completamente imposible.

No necesita una especificación exhaustiva y completa antes de comenzar. Solo necesitas lo suficiente para comprobar que lo que el cliente tiene en mente es lo que tú tienes en mente.

No puedes construir más rápido de lo que puedes planificar

Los clientes a veces objetan que la planificación llevaría demasiado tiempo. Mi respuesta a eso es "¿Quieres que construyamos esto más rápido de lo que podríamos planificarlo? La planificación es más rápida, más fácil y más económica que la construcción, así que si no crees que podamos planificar esto en tres meses, entonces definitivamente podemos". No lo construiré en tres meses".

Si planifica con anticipación, los conceptos erróneos son baratos y fáciles de corregir. Si no lo hace, entonces solucionar los problemas más adelante será más difícil.

La forma ágil

Agile adopta un enfoque muy diferente.

• En lugar de adoptar el enfoque de cascada una vez, divide el proyecto en iteraciones de una o dos semanas cada una.

• Todavía realiza la planificación y la aclaración de requisitos , pero menos, y lo hace una vez en cada iteración.

• Obtiene muchos comentarios de los usuarios en cada iteración

• Usted realiza los cambios más simples en el software que pueden admitir los nuevos requisitos antes de presentarlos al usuario.

• Haces mucho TDD para asegurarte de no romper cosas con tu refactorización constante

Muerte por un millón de cambios

Hay un tipo de usuario al que le gusta hacer un montón de pequeños ajustes. "Esta fuente debería ser un poco más grande". "Esta fuente debería ser un poco más pequeña". "Haz esto de un color diferente". "En lugar de lo perfectamente bueno que tenemos aquí, ¿qué tal si lo cambiamos a algo ligeramente diferente?"

Si ese es el caso, mi sugerencia es que haga que el cliente se centre primero en la funcionalidad central, para que se centre primero en los cambios más importantes. También debe pedirles que articulen el requisito que satisface el pequeño cambio.

Bien puede ser que haya un requisito importante detrás de la solicitud que simplemente no conoce. Si ese es el caso, comprenda la necesidad y vea si puede sugerir algo que satisfaga el requisito de una mejor manera.

A menudo, el requisito es "facilidad de uso general". La respuesta a la "facilidad de uso general" es casi siempre la prueba del usuario. No son pruebas de clientes, claro, sino pruebas de usuarios realizadas por unas seis de las personas que realmente terminarán usando el sistema.

Cuando no obtiene los requisitos que necesita para comenzar un proyecto, lo que debe hacer es anotar todos los requisitos que necesita y especificarlos lo antes posible. Hágales saber los requisitos exactos que necesita y, lo que es más importante, cuáles le impedirán completar el proyecto.

Mientras hace esto, codifique todo lo que pueda con lo que le dieron al principio . No puedo enfatizar esto lo suficiente. Continúa trabajando en lo que te han dado hasta que ya no puedas más. Hágales saber cuando haya llegado a un punto que no pueda superar porque aún no se han establecido los requisitos.

Puede haber una razón legítima por la que su(s) jefe(s) no le hayan dado las especificaciones que necesita: es posible que primero necesiten hacer una maqueta para ver cómo funciona, es posible que aún no las tengan porque sus usuarios/analistas de negocios están arrastrando sus pies en las métricas exactas que debe seguir. Cualquiera que sea la razón que tengan, incluso si es una mala razón, aún debe realizar la mayor cantidad de trabajo posible.

A veces, los requisitos cambiarán y no hay nada que pueda hacer al respecto.

Bienvenido a la Industria del Software.

Es parte de tu trabajo manejar cosas como esta. Muchas de las respuestas le dan algunas ideas más específicas sobre cómo hacerlo.

Es parte de tu trabajo ser flexible. Para hacer un código que esté parcheado, sí, pero comprensible en primer lugar. Y reparable, sobre la marcha. tu trabajo

Es parte de su trabajo escuchar las solicitudes de pastel en el cielo, hacer un poco de codificación, hacer que alguien diga, esa no es la forma de codificar, codificar de la manera que ellos quieren, lo cual no funciona. Luego regresa y hazlo de la manera que funciona. parte de tu trabajo

Supongo que lo único complicado que no es realmente parte de tu trabajo es presentar una queja de que esto es ineficiente. Puede mencionarlo, supongo, o puede tratar de vincularlo, cuando las cosas se hacen cada vez más tarde, puede sugerir ciertas cosas, pero esto probablemente no va a funcionar realmente.

Nuevamente, será parte de su trabajo lidiar con el desorden. Y sé amable. Y diga, está bien, jefe, cuando todo se tire a la basura. Y diga, ok jefe, cuando todo tiene que ser sacado del contenedor de basura, cubierto con basura y reelaborado.

parte del trabajo Si realmente no le gusta, le sugiero que inicie su propia empresa, contrate a un grupo de programadores un poco arrogantes e intente vender sus servicios y productos y hacer la nómina mientras sus empleados lloriqueantes dicen, es jefe parcheado, no es bonito jefe de código asi que...

Supongo que otra cosa es que las personas que manejan negocios a menudo nunca tienen tiempo para muchas reuniones contigo. Si puede hacer su trabajo, podrá anticipar algunas cosas, podrá arreglar las cosas que no puede y hacerlo todo por su cuenta.

Como ya se indicó en otras respuestas, sus "clientes" (aquellos que han solicitado la solución que está creando) necesitan algo que puedan comparar con sus requisitos para explorar y comprender completamente esos requisitos (la analogía de compra de automóviles y patadas de neumáticos). Es por eso que no proporcionaron especificaciones completas y comenzaron a solicitar cambios después de que su solución comenzó a tomar forma.

Cuando el "cliente" es consciente de esto, puede pedirle o permitirle explícitamente que construya un prototipo y desarrolle una especificación más sólida basada en lo que reveló el prototipo. Sin embargo, puedes terminar yendo por este mismo camino sin que nadie (tú o el cliente) sea explícitamente consciente de ello. El problema surge cuando cotiza en el momento de la entrega de lo que resulta ser el prototipo, donde su cliente esperaba que su cotización se aplicara al producto terminado.

En "The Mythical Man-Month" se habla de un sistema "piloto". Esencialmente, construir un sistema una vez (que se desechará) para aprender todo lo necesario para construir el sistema de nuevo, de la manera correcta y con qué frecuencia sucede intencionalmente o no. Es posible que esté a punto de completar su sistema "piloto", con la solución "real" aún por comenzar.

Quizás lo mejor que puede hacer en este punto es documentar cada solicitud de cambio, exactamente cómo entiende el requisito y su cotización de lo que se necesitará para entregarlo, y ser honesto. No comience ningún trabajo que requiera más de un par de horas con un mero acuerdo verbal. Anótelo: incluso un correo electrónico informal es mejor que nada. Es posible que debas protegerte de "eso no es lo que pedí" y "no me dijiste que tomaría tanto tiempo". Simplemente decirle a su jefe que debe dejar de pedir cambios podría ser malo políticamente. Deje que el rastro creciente de descripciones de cambios citadas hable por usted acerca de cómo las cosas llegaron a donde están y cómo estaba haciendo su mejor esfuerzo honesto para cumplir con las solicitudes de sus "clientes".

Alternativamente, elabore un cuadro o esquema de lo que cree que quieren los clientes. Si quieren un programa que tenga solucionadores de ecuaciones, puede dibujar un esquema (interfaz de usuario y todo) de un programa en el que al usuario se le presente un menú y luego se le permita presionar un botón para seleccionar un solucionador de ecuaciones. Luego, la ecuación se ingresa en un cuadro de texto, luego el usuario presiona otro botón para decirle al programa que resuelva la ecuación.

Además, hágase un favor y obtenga la respuesta del cliente por escrito. Piense en ello como una forma de cubrir su trasero si el cliente dice más tarde: "No quería eso".

La comunicación es la mejor manera de resolver su problema. Haz preguntas que se cansen de ti y te darán el detalle que necesitas. Si no lo saben, proponga usted mismo los requisitos. Documente las respuestas dadas y envíeles las respuestas para su confirmación. De esta manera, deja en claro que la causa de la demora o el cambio se debe a que cambiaron de opinión. Cuando Mgt. decir 'construirlo a tu manera' que significa 'haz algo que yo pueda ver y cambiar'. Teóricamente, el desarrollo de software sugiere que antes de comenzar un proyecto, todos los requisitos deben estar completamente claros, desde descripciones detalladas de algoritmos hasta maquetas de pantalla. Cuando se entregue el producto, por supuesto corregiremos cualquier desviación de los requisitos escritos, pero no se permiten cambios que impliquen un cambio en los requisitos. Sí, esto haría la vida mucho más fácil para el desarrollador de software. No me preocuparían los requisitos vagos, siempre que todos los involucrados entiendan que los requisitos son vagos, que tendrá que llenar los vacíos y que cuando vean las decisiones que ha tomado, habrá algunas decisiones. que no les gusta y las cosas tendrán que ser reelaboradas. Demandas que no son razonables y hechas por el jefe/gerencia o el cliente, entonces necesita obtener las cosas por escrito para protegerse. Si el jefe/administración o el cliente esperan tiempos de respuesta imposibles y lo culpan cuando no se cumplen las demandas imposibles, entonces, francamente, es hora de comenzar a buscar otro trabajo u otro cliente. siempre que todos los involucrados entiendan que los requisitos son vagos, que tendrá que llenar los vacíos y que cuando vean las decisiones que ha tomado, habrá algunas decisiones que no les gustarán y las cosas tendrán para ser reelaborado. Demandas que no son razonables y hechas por el jefe/gerencia o el cliente, entonces necesita obtener las cosas por escrito para protegerse. Si el jefe/administración o el cliente esperan tiempos de respuesta imposibles y lo culpan cuando no se cumplen las demandas imposibles, entonces, francamente, es hora de comenzar a buscar otro trabajo u otro cliente. siempre que todos los involucrados entiendan que los requisitos son vagos, que tendrá que llenar los vacíos y que cuando vean las decisiones que ha tomado, habrá algunas decisiones que no les gustarán y las cosas tendrán para ser reelaborado. Demandas que no son razonables y hechas por el jefe/gerencia o el cliente, entonces necesita obtener las cosas por escrito para protegerse. Si el jefe/administración o el cliente esperan tiempos de respuesta imposibles y lo culpan cuando no se cumplen las demandas imposibles, entonces, francamente, es hora de comenzar a buscar otro trabajo u otro cliente. Demandas que no son razonables y hechas por el jefe/gerencia o el cliente, entonces necesita obtener las cosas por escrito para protegerse. Si el jefe/administración o el cliente esperan tiempos de respuesta imposibles y lo culpan cuando no se cumplen las demandas imposibles, entonces, francamente, es hora de comenzar a buscar otro trabajo u otro cliente. Demandas que no son razonables y hechas por el jefe/gerencia o el cliente, entonces necesita obtener las cosas por escrito para protegerse. Si el jefe/administración o el cliente esperan tiempos de respuesta imposibles y lo culpan cuando no se cumplen las demandas imposibles, entonces, francamente, es hora de comenzar a buscar otro trabajo u otro cliente.

Dale a tu jefe la interpretación mínima y más rápida de los pequeños requisitos que te ha dado y preséntalo rápidamente como un trato hecho.

Cualquier solicitud futura de cambio que no esté clara debe ser cuestionada dejando en claro que el cambio salió de la nada donde se le pidió que escribiera su propio artículo y ahora se está cambiando arbitrariamente. Pregunte por razones más concretas para cualquier cambio para que pueda descubrir sus propios requisitos y dígale a su jefe que se está negando a permitirle hacer sus propias cosas y presentarlas como su fracaso.

Sin embargo, si tiene una buena relación con su jefe, es posible que le esté dando la oportunidad de brillar: ¡pídale los medios para descubrir sus propios requisitos, aplíquese y cumpla!