Entonces recogí un otro libro sobre el desarrollo de software y comencé a leer. Yo no era capaz de terminarlo porque esto me da tal dolor de cabeza. Cada pocas páginas consigo el impulso irresistible de dar palmadas a mi frente. A este precio, voy a conseguir una conmoción cerebral por el capítulo tres. Every few pages I get the irresistible urge to slap my forehead. At this rate, I'm going to get a concussion by chapter three.

Anyways, este tipo continúa sobre requisitos: Como no tener requisitos apropiados causa proyectos de ser sobre el presupuesto y detrás del horario, como el pelota de rasgo lleva a horario de proyecto rebelde y reveladores desmoralizados, yadda, yadda, yadda. ¿No, realmente? No, really?

Y su prescripción es que alguien escribe los requisitos y consigue que todos los accionistas se despidan en ellos. ¡Por supuesto, no hay sólo una clase del requisito - noooooo! - hay muchos la clase de requisitos. Así como los requisitos de usuario, allí son requisitos comerciales y diseñan requisito y requisitos thingajig y.... No sé, pero muchos muchos requisitos funky y cielos, si el director de proyecto consigue todos los requisitos escritos y se despidiera por todos los accionistas, entonces aleluya, esto será UN proyecto que terminará a tiempo y en el presupuesto. ¡Si sólo aquellos directores de proyecto estúpidos pudieran escribir que un juego bueno de documentos de requisito.... golpea! - there are many kind of requirements. As well as user requirements, there are business requirements and design requirement and thingajig requirements and .... I don't know, but lots of lots of funky requirements and gosh, if the project manager gets all the requirements written up and signed off by all the stakeholders, then hallelujah, this will be the ONE project that will finish on-time and on-budget. If only those stupid project managers could write up a good set of requirement documents....thump!

Lamentable, que era mi cabeza que golpea el escritorio. Creo que perdí el conocimiento durante unos segundos.

Bien, vaya a tratar de refutar este punto de vista que parece ser la sabiduría convencional con una excepción donde los requisitos escritos acorazados son la regla: Sistemas integrados. Básicamente, es realmente difícil cambiar una viruta después de que ha sido diseñado. Duh. Basically, it's really hard to change a chip after it's been designed. Duh.

Para más o menos todo otro trabajo de desarrollo de software, es una idea buena de anotar un juego de requisitos preliminares. Y luego imprímalos. Pero imprímalos en el papel muy suave que puede ser usado en el cuarto más pequeño de la casa. Como en un período muy corto de tiempo, esto es el único cuarto donde aquel pedazo de papel va a ser útil. But print them out on very soft paper that can be used in the smallest room of the house. Because in a very short period of time, that's the only room where that piece of paper is going to be useful.

Hay dos causas principales por qué, una obvia & una sutil. Comenzaré con el obvio: Vaya a fingir que usted es el cliente. Usted ha firmado un contrato con una casa de desarrollo de software para construir un programa elegante que hace algo. Usted ha consentido en pagar el dinero. En mayoría de los casos, usted paga mucho dinero. Usted ha puesto su firma sobre un pedazo de papel para algo que no existe en el presente. Usted también es dolorosamente consciente que cuando esta pieza del software es creada, si es no encuentra las expectativas de sus accionistas, ellos van a avisarle sobre ello. ¿Y cómo encuentran los tiempos una liberación de software el 100 % de las expectativas del cliente? Let's pretend you are the customer. You have signed a contract with a software development house to build a nifty program that does something. You have agreed to pay money. In most cases, you are paying a lot of money. You have put your signature on a piece of paper for something that doesn't exist in the present. You are also painfully aware that when this piece of software is created, if it's does not meet the expectations of your stakeholders, they are going to let you know about it. And how times does a software release meet 100% of the customer's expectations?

Ahora, después de firmar un pedazo de papel para lo que muchos en su organización consideran una cantidad de dinero obscena, un cierto período de tiempo pasa y usted consigue que otro pedazo de papel lea, con un título declarando que es un diseño/usuario case/business/whatever documento de requisitos. Usted lee rapidamente el documento. Mira bien. Hay un espacio para su firma. Tal vez usted lo firma. Tal vez usted devuelve un correo electrónico diciendo que usted firmó un pedazo de papel por millones enésimos de dólares, y esto es el único pedazo de papel tiene que firmar, alguna vez. Pero vaya a fingir que usted se despide en el doctor de requisitos. ¿Significa esto que usted, el cliente, ha dejado el derecho de ponerse en contacto alguna vez, comunica o fastidia el equipo de desarrollo con nuevos rasgos y/o requisitos? It looks okay. There's a space for your signature. Maybe you sign it. Maybe you send back an e-mail saying you signed a piece of paper for umpteenth millions of dollars, and that's the only piece of paper need to sign, ever. But let's pretend you sign off on the requirements doc. Does this mean that you, the customer, have given up the right to ever contact, communicate or nag the development team with new features and/or requirements?

No. Nunca. Alguna vez. No hay ningún cliente que haya existido alguna vez desde el inicio de los tiempos que no molestará continuamente el desarrollo para nuevos rasgos directamente hasta el momento de liberación y después. Ponerse. Usado. A. Esto. Ever. There is no customer that has ever existed since the beginning of time that will not continually pester the development for new features right up to the moment of release and after. Get. Used. To. It.

Entonces la lección para cualquier director de proyecto no es pasan demasiado tiempo para reclutar a doctores de requisito. Seguramente tóquelos con mucho ruido rápidamente, y quiero decir los tocan con mucho ruido, pero si, los milagros de los milagros, el cliente devuelve un bien y un documento despedido, no crea hasta que su trabajo sea terminado. La diversión acaba de comenzar. The fun has just started.

Esto sube mi segundo punto sobre caer a la trampa de requisitos de la documentación: la adquisición de todos los requisitos es superdifícil. En mayoría de los casos, es imposible. No hasta el cliente, y el cliente del cliente, pueden darle el 100 % de los requisitos. In most cases, it's impossible. Not even the customer, and the customer of the customer, can give you 100% of the requirements.

Mire usted, esto parece yendo a club de fans de Julia Roberts y refrán: "Queremos hacer una historia de amor con Julia y Brad Pitt. Ellos se caen enamorados, ellos luchan & desintegración, y luego ellos arreglan y se caen enamorados otra vez. Al final de película, cada uno del auditorio porque la película era tan maravillosa. Aquí está la escritura de la película. ¿Puede usted asegurarnos que después de ver esta película, alcanzará su hankie?" They fall in love, they fight & break-up, and then they make up and fall in love again. At the end of the movie, everybody in the audience because the movie was so wonderful. Here is the script of the movie. Can you assure us that after seeing this movie, you'll reach for your hankie?"

Déjeme contar un ejemplo del mundo real (he cambiado algunos detalles para proteger al inocente): Uno del cliente de Creo tenía un poco de tecnología de imprenta que corría con una suite de software desarrollada a principios de los años 1990. Creo tiene algún software de preprensa desarrollado aproximadamente una década más tarde que es inmensamente superior. Sin embargo, había algunas peculiaridades que fueron necesarias para ser desarrolladas y añadidas a la suite de software de Creo. Creo has some pre-press software developed about a decade later that is vastly superior. However, there were some unique features that were needed to be developed and added to Creo's software suite.

La gestión de proyectos para el cliente estaba siendo coordinada de la oficina central al mediados de EE.UU mientras que la tecnología de imprenta estaba basada en el sitio de fábrica cerca de la costa occidental. Volé abajo a la planta para lucir suite de software de Creo y requisitos de captura. Hizo la presentación, voló atrás a Vancouver. Un par de semanas más tarde, conseguimos el mensaje diplomático de la oficina central que quizás todos los requisitos no han sido capturados. Entonces vuelo abajo otra vez. También quedo en hacer cargar la suite de software de Creo en un servidor y transportado al sitio de planta como un acreedor. Esta vez, durante la presentación, ellos tienen su superusuario, su administrador de sistema a mano. Soy afortunado que el cliente es bastante elegante para sacar a sus usuarios a la presentación para criticar la suite. El superusuario va profundamente en mí. Esto significa que ella perfora abajo muchos niveles a unos realmente obscurecen (a mí), pero importante (para ellos) requisito comercial que no está en nuestra suite de software. Prometí perseguir aquellos rasgos con algunos SMEs de Creo (expertos de materia) cuando regreso a la oficina. Did the presentation, flew back to Vancouver. A couple of weeks later, we get the diplomatic message from head office that perhaps all the requirements have not been captured. So I fly down again. I also arrange to have Creo's software suite loaded on a server and shipped to the plant site as a loaner. This time, during the presentation, they have their super-user, their system administrator on hand. I am lucky that the customer is smart enough to get their users out to the presentation to critique the suite. The super-user goes deep on me. That means she drills down many levels to some really obscure (to me) but important (for them) business requirement that is not in our software suite. I promised to follow up on those features with some of Creo's SMEs (subject matter experts) when I get back to the office.

Mientras tanto, el servidor con el software de Creo llega local con un representante de campaña local para hacer instalan y formación preliminar. También pido que un entrenador siga una visita local al cliente una semana más tarde. Preinformo al entrenador para mirar & hacer un informe para cualquier nuevo requisito. Seis semanas más tarde, envío a otro entrenador. Aproximadamente cinco meses han pasado desde mi primera visita a la suite de cliente. Finalmente, el superusuario es capaz de articular los requisitos que la planta necesite al representante de Creo que también es un SME en aquel subtema particular. Entonces capturamos los requisitos y los pasamos al equipo de desarrollo y conseguimos el mensaje atrás que ninguno de los requisitos es imposible de realizar, se necesitarán aproximadamente tres meses para entrar en la siguiente mejora. Final de historia. I pre-brief the trainer to watch & report for any new requirements. Six weeks later, I send another trainer. About five months have passed since my first visit to the customer suite. Finally, the super-user is able to articulate the requirements that the plant needs to the Creo representative who is also a SME in that particular sub-topic. So we get the requirements captured and we pass them on to the development team and we get the message back that none of the requirements are impossible to fulfill, it will take about three months to roll into the next upgrade. End of story.

Ahora, note que en este estudio del caso:
1. El cliente era sofisticado, entendiendo que teníamos que hacer el superusuario pasar mucho tiempo jugando con nuestro software entonces ella podría descubrir lo que fallaba.
2. Teníamos mucho tiempo. La adquisición de los requisitos apropiados tomó cinco meses. La codificación de los requisitos tomó dos semanas (la carga administrativa de hacer rodar nuevas mejoras en la suite de software considerada durante los otros 2.5 meses). Coding the requirements took two weeks (the administrative load of rolling new upgrades into the software suite accounted for the other 2.5 months).
3. Esto era una modificación de una suite de software preexistente. No presentábamos al cliente un "pedazo de papel en blanco.""
4. El negocio valió bastante para enviar a un servidor de acreedor con el software a la planta Y tener un total de cinco visitas separadas a la planta (dos viajes por el director de proyecto, un por un representante local, y dos por entrenadores).

Para concluir, el punto de este ensayo es que la adquisición de requisitos en el mundo real no es tanto un punto de documentación, pero un proceso iterativo con el cliente que continúa por el ciclo vital del proceso de desarrollo (y más allá).
Voy a tratar de terminar el libro que leo, si sólo presentarme a futuros empleadores como la fuente de la sabiduría (convencional). Pero realmente, si los bosques están llenos de directores de proyecto que creen que ellos son sin casa una vez que ellos documentan las estipulaciones de un proyecto a principios del ciclo de desarrollo, entonces no es sorprendente que muchos de ellos son triturados después de unos años en los negocios.

Etiquetado como: 166, 186, 83