Programación orientada a objetos en WordPress: comprensión de las expectativas del cliente
A medida que avanzamos en la discusión sobre la programación orientada a objetos en WordPress, es importante que nos aseguremos de no adelantarnos cuando se trata de crear un producto para otra persona.
Muy a menudo, es fácil:
- escuchar lo que dice un cliente,
- construir algo basado en lo que hemos escuchado,
- entregarlo a dicho cliente.
Pero hay mucho más que eso. Lo he bailado un poco en publicaciones anteriores de esta serie; sin embargo, quiero comenzar a profundizar en lo que significa escuchar:
- Lo que dice un cliente,
- Desarrollar un conjunto de requisitos,
- Y luego crea bucles de retroalimentación en torno a eso.
En última instancia, queremos asegurarnos de que las personas para las que trabajamos y las soluciones que construimos sean realmente soluciones y no obstáculos u obstáculos que tengan que sortear.
Además, no creo que sea suficiente que un cliente simplemente disfrute de la experiencia de su producto final, sino también trabajar con el (o los) que construyen la solución.
Dicho esto, echemos un vistazo a lo que significa escuchar lo que dicen y partir de ahí.
Comprender las expectativas del cliente
Cada vez que lee libros u otro material sobre este tipo de cosas, a menudo convierte a una de las dos partes en el "chico malo". No siempre, pero a veces hace:
- el cliente parece ignorante de lo que está hablando,
- o hace que el desarrollador parezca un imbécil por actuar como alguien que sabe más sobre el tema en cuestión.
¿Qué pasa con una tercera opción donde el cliente tiene una idea clara de lo que quiere, los desarrolladores están dispuestos a escuchar y trabajar en conjunto con el cliente para construir algo?
Claro, habrá aclaraciones en el camino, y habrá términos que deben definirse, e incluso puede ser parte de algo de "recalibración" del calendario de desarrollo.
Pero la conclusión es esta: ninguna de las partes debe trabajar en contra de la otra. En cambio, se trata de trabajar juntos para encontrar la solución. Claro, requiere comunicación (en lo que los desarrolladores no siempre son buenos, según mi experiencia, pero no hay razón por la que no pueda ser mejor).
¿Qué dice un cliente? (¿Qué dice el desarrollador?)
Cada vez que se encuentran, es probable que piensen lo mismo porque cada uno habla un idioma diferente y cada uno piensa que lo que dice el otro es una jerga.
Y eso no está mal.
Los clientes tienen una forma de hablar sobre lo que quieren, y los desarrolladores tienen una forma de hablar sobre cómo lo entregarán.
Los términos que usamos
Pero puede haber un objetivo común.
Apunta a una descripción del problema que está tratando de resolverse. Trate de hacerlo en términos sencillos para que el diseño se alinee con el objetivo y la funcionalidad de la solución.
No creo que esto funcione para todos, pero es lo primero que recomiendo hacer cada vez que se sienta con su cliente.
Como verá más adelante en estas publicaciones, es útil desarrollar algunas oraciones que puede usar al comienzo de su declaración de trabajo a las que puede consultar cada vez que tenga que tomar una decisión.
En otras palabras, usted (y ellos) pueden preguntar:
¿En lo que estoy trabajando contribuye al objetivo común?
Y aquí es donde puede determinar el conjunto básico de requisitos.
«Necesita…"
Cuando se trata de comprar algo, construir algo, solicitar algo, querer algo o lo que sea, es bastante fácil comenzar la oración diciendo "Quiero que…".
Pero hay una gran diferencia entre "Quiero que haga [hacer algo]" y "Lo necesito [para hacer algo]", y cuando trabajas en software, generalmente es seguro decir que las cosas que se necesitan son básicas. a la aplicación Y lo que se quiere es lo que viene después de que se haya construido la base de la aplicación.
Es decir, es una conversación sobre "debe tener" y "quiero tener". Y es importante tener conversaciones para llegar a esa declaración final del objetivo común de la aplicación.
Una vez que esté en su lugar, puede comenzar a planificar su software en torno al problema del cliente. Y ahí es donde entra en juego la recopilación de requisitos.
Desarrollo de requisitos
Si usted y el cliente tienen una comprensión sólida de lo que se necesita construir, entonces es hora de reunir los requisitos.
Esta parte puede ser más divertida de lo que parece. Lo sé, lo sé: suena como tarea o alguna tarea, ¿verdad? Pero no lo es. En cambio, está tomando lo que quieren, lo que has entendido, traduciéndolo a un idioma común y luego redactando un documento que explica lo que hará el software.
Sin embargo, dependiendo de su experiencia, esto puede ser aburrido. Y por aburrido me refiero a una de las peores partes de tu trabajo. Además, los requisitos siempre cambian, ¿verdad?
No siempre.
Si se toma el tiempo para comprender lo que quieren desde el principio, entonces los requisitos no tienen que ser un documento de 50 páginas que describa cómo debe funcionar cada módulo.
Muchos libros lo documentan diciendo que así tiene que ser. Pero en casi una década de hacer esto, nunca he tenido algo que dure tanto y, en general, los clientes han estado increíblemente agradecidos de ver una lista breve que se puede modificar por correo electrónico o Google Docs, firmar y luego consultar a medida que avanza el proyecto. delantero.
Hablaré más sobre eso en el futuro, pero cualquiera que sea la mala experiencia que tengas, el miedo o la inquietud que tengas, no tienes por qué sentarte. Y continuaremos hablando de eso a través de esta serie.