De esto no hay mucha relación con .NET, pero es igual de importante para el trato con los clientes que no tienen mucho o nada que ver con las Tecnologías de la Información, es decir, no lo conocen, lo conocen muy poco o ellos creen que lo conocen.
Lo hago, por que la corta experiencia que tengo, me ha servido para no cometer 'errores' al platicar o proponer algun proyecto, y esto después después de leer libros como Ingeniería de Software, donde te proponen pláticas y entrevistas con los clientes de una cierta manera, pero en la vida real...., pues es otro asunto.
Cuando trates con un cliente, él te abordará diciendo algo como....
- "Necesito un sistema que...."
- "Quiero una página que maneje...."
- "Quiero imprimir directamente..."
- "Quiero tener un inventario de...."
- "Necesito controlar a...."
Primer error: en la misma platica nosotros estaremos pensando en una base de datos, en un lenguaje de programación, en una cierta tecnología, incluso hasta la vista de cómo quedará nuestra aplicación.
No pienses en nada de eso, sólo escúchalo y déjalo terminar, pon atención muy bien de los detalles que te menciona... es en los 'detalles' donde radica la verdadera lógica o problema que necesita resolver.
Después de todo el rollo del cliente, termina diciéndote algo como:
- "Y.. como cuánto me costará?..."
Segundo error: Cotizar de manera inmediata el proyecto, nosotros hacemos un cálculo mental de lo que nos llevaremos en hacer todo (la base de datos, la aplicación, etc.) y terminamos por dar un precio que asusta al cliente. (jaja, sí, a todos nos pasa eso al principio)
Para poder dar una cotización tienes que ANALIZAR detenida y detalladamente todas y cada una de las actividades que vas a hacer.... si tienes que hacer documentación, si tienes que modelar una base de datos, si tendrás que ponerle imágenes o inclusive un 'estilo de vista' a la aplicación (en páginas web, pues fijate si harás las hojas de estilo y diseñarás las capas de la página, o harás como muchos... tomar templates y modificarlos...). No des un precio final en menos de 5 minutos... ni si quiera lo has pensado bien!!!, aunque el cliente te presione para darle un precio, debes de ser profesional..., tienes que ver qué actividades vas a hacer y en qué tiempo las piensas realizar.
Tercer error: empezar a hablarle en términos técnicos que sólo los desarrolladores conocen, con términos como 'bases de datos' (en serio, pregúntale que entiende por base de datos, y en algunos casos te sorprenderán de lo que piensan), 'Aplicación distribuída', 'Software en capas', 'servicios', 'cloud computing', 'minería de datos', 'dominios, subdominios', mucho menos le digas 'HTTP', 'CSS', 'SOAP', 'XML', etc., etc.
Al platicar con el cliente sabrás por la manera en cómo describe los procesos y cómo cree que se pueden solicionar o 'automatizar' el nivel de conocimiento que tiene sobre las TI, y aunque se vea que sabe mucho, trata de hablar siempre en términos que hasta un niño pueda comprender... Dile que la página web se verá 'bonita', 'interactiva' y fácil de entrar y navegar, que la aplicación almacenará 'automáticamente' los datos, que sus datos estarán disponibles cuando lo necesite, que el procesamiento será muchísimo más rápido, dile que al usuario le facilitará la vida (aunque tu te la compliques).
Cuarto error: nunca utilices las palabras 'creo que no se puede' cuando analices un proceso que el cliente lo tiene en su cabeza (o inclusive por escrito).
Empezando por el 'creo' que se escucha como a qué no lo puedes hacer y con el 'no se puede' que describe lo ineficiente que te ves en ese momento. Al cliente no le importa si tienes que utilizar hasta 10 tecnologías al mismo tiempo, o si utilizas un proceso complejo de sincronización, análisis, entrega, comparación, etc. Lo que realmente le importa es que su trabajo se haga y se haga bien.
Quinto error: Hacerte el que todo lo sabe y dejar los pequeños detalles a un lado, como te decía, es ahí donde debes enfocarte. Comunmente en las entrevistas sólo haces las preguntas necesarias y listo.
En cuánto más información tengas del funcioamiento de 'todo' lo que se pueda y no computar, es mucho mejor, así tienes límites (en todas las aplicaciones hay límites) para saber lo que vas y lo que no vas a contemplar. Pregunta cómo quiere se imprima un reporte, en qué formato, cómo hacen para la captura de datos (con qué están mas familiarizados... Páginas o aplicaciones de escritorio), qué tipos de máquinas son con las que cuenta o piensan contar, hasta la edad y experiencia de los usuarios en sistemas de cómputo. Todas esas preguntas que tienen o no que ver con el sistema debes saber para establecer los límites.
Sexto error: Darle opiniones espontáneas para 'mejorar' los procesos o problemas que vas a resolver con tu desarrollo.
Si bien es cierto que es nuestra obligación informarle al cliente de las maravillas que las computadoras hacen por nosotros, y que pueden hacer con su negocio, trata de medir bien las palabras que dirás, porque o le pueden fascinar, o quizá te tache de un loco. Por mas que creas que tus ideas mejorarán (y aunque así lo sean) su negocio, no te desesperes, quizá hasta el mismo cliente te dé la respuesta que necesita (lo que sucede casi siempre) aunque no sea la mejor opción.
Espero y te haya servido de algo, y si tienes algunos otros errores que puedas comentar (que yo sé que hay muchísimos más) son bienvenidos.
No hay comentarios:
Publicar un comentario