9 Pasos para un buen y efectivo manejo de un proyecto de desarrollo de software

Con una detallada propuesta y un competente jefe de proyecto para guiar la iniciación del desarrollo del software, existe otro importante elemento dentro de una organización que puede ser muy útil cuando se comienza con un proyecto como estableciendo pasos específicos. Existe una colección de normas prácticas para aprovechar un proyecto de desarrollo de software, establecido por dos profesores universitarios y consultores de negocio con destreza especializada en computación, ingeniería, y ambientes generales de negocio. El Dr. Gordon Scott Gehrs y el Dr. Dorota Huizinga establecen nueve pasos claves para considerar llevar a cabo en un proyecto de desarrollo de software.

Paso1: Descubrir las necesidades de los stakeholders

Entrevistar a los stakeholders con el propósito de descubrir si sus necesidades específicas existen, identificar su necesidad exacta, y determinar si el proyecto propuesto puede factiblemente entregar el desarrollo del software esperado.

Paso2: Analizar y determinar los requerimientos

Un apropiado análisis debería consistir de las entrevistas con los usuarios finales y otras personas quienes estén asociados con el nuevo sistema. Un repaso minucioso y entendimiento de los documentos de los usuarios, roles del negocio, y procesos son claves para la determinación apropiada y necesaria de las características y funcionalidades.

Paso3: Considerar las mejores prácticas

En el momento de definir los procesos de desarrollo del software se debe considerar las mejores prácticas. El Dr. Huizinga recomienda los procesos ágiles con énfasis en la documentación en imágenes, ambos para la documentación técnica y de requerimientos. Es importante seguir plantillas estándares, utilizar una herramienta de gestión de requerimientos y del tiempo.

Paso4: Diseño

Durante la fase de diseño, el arquitecto del software y el desarrollador puede poner junto un documento de diseño detallado resumiendo exactamente como el software satisfacerá los requerimientos específicos. El Dr. Gehrs recomienda el uso de mock-ups para acompañar el documento de diseño como una opción de elementos ilustrativos de la interfaz del usuario.

Paso5: Medición y rastreo de los progresos

Sin la infraestructura de la tecnología apropiada en el lugar, es difícil coleccionar y medir los datos claves del proyecto. Los indicadores del proyecto pueden ayudar asegurar la identificación rápida de los potenciales problemas, que permite que sean reconocidos y corregidos a tiempo. Cuando son observados fuera del periodo, el Dr. Huizinga remarca que los indicadores pueden ser usados para determinar la calidad del producto y despliegue deseado.

Paso6: Desarrollo

La fase de desarrollo, donde el documento de diseño es trasladado a una pieza real de software. Cuando el planeamiento cuidadoso ha sido ejecutado, el software marcará los requerimientos del manejo del negocio que inició la necesidad para el proyecto. El Dr. Gehrs menciona que los ciclos de desarrollo pueden producir varias versiones del software:

-> Alpha: característica preliminar/solamente funcionalidad
-> Beta: usada para el testeo interno o testeo de usabilidad
-> Candidatos de Release: usualmente una construcción estable puede necesitar algunas correcciones.
-> Construcción de producción o Gold Master: listo para el release

Los jefes de proyecto necesitan retroalimentarse con la experiencia de los usuarios, tiempos para completar las tareas, facilidad de uso, y otra información relacionada a la interfaz del usuario y los elementos céntricos del usuario.

Paso7: Automatización

Otro paso clave es asegurar la automatización de tareas repetitivas:

-> Construcción de códigos
-> Escaneo del análisis del código estático
-> Test regresivos

Dr. Huizinga cree que tomar medidas reduce el error propenso de la influencia humana cuando el software es implementado. Esto también facilita el uso de las mejores prácticas y colección de los datos relacionados al proyecto. Ella menciona que “todas las tareas repetitivas y mundanas deberían ser automatizadas cuando sea posible en cualquier parte del ciclo de vida del software”.

Paso8: Testeo

Ahora el siguiente paso es el testeo, Dr. Gehrs menciona que el testeo también puede variar bastante dependiendo de los procedimientos de testeos individuales adoptados por la organización. El testeo puede consistir de varias sub-etapas, como el aseguramiento de la calidad y la realización de las pruebas. Una vez que el software está en uso general, cualquier error encontrado es direccionado a una escala crítica: arreglos urgentes son programados para ser llevados tanto pronto sea posible. Los cambios característicos pueden ser elegidos para futuras versiones de actualizaciones.

Paso9: Prácticas graduales de implementación

El Dr. Huizinga menciona que “la implementación incremental de las prácticas por encima es crítico para poder sobresalir. La aproximación gradualmente a la introducción al cambio grupo por grupo y la práctica por práctica es esencial para alcanzar el cambio de la cultura organizacional, como cambio no es deseado, y siempre hay resistencia al cambio”. Porque la naturaleza compleja de los proyectos del software y la tecnología involucrada, el desarrollo del nuevo software justifica la propuesta sistemática. Entender el rol del líder del proyecto y la importancia de tener planeado un camino efectivo al desarrollo de los procesos puede ser una ventaja competitiva de una compañía dentro de un mercado competitivo.

Herramientas para la integración de Gestión de Cambios y Release (II)

Paso4: El QAE realiza el testeo de actividades.

El Ingeniero de Aseguramiento de Calidad recibe un e-mail de notificación del Rational ClearQuest que el software se encuentra listo para el testeo. Entonces se procede a revisar la información del defecto en el Rational ClearQuest y el cambio asociado (los archivos que fueron cambiados para arreglar el defecto) para planificar las actividades de testeo. Para verificar la etiqueta correcta de construcción y entender el entorno específico requerido para el testeo, se tiene que hacer referencia al BOM del Rational Build Forge.

Después, usar las características de gestión de testeo del Rational ClearQuest para la planificación del testeo. Generar casos de testeo en el Rational ClearQuest para asegurar que la corrección del programador ha corregido el defecto y luego acceder a los archivos modificados dentro del Rational ClearCase para empezar el testeo. Basándonos en los resultados construidos exitosamente Rational Build Forge puede empezar adicionalmente actividades automatizadas de testeo.

Una vez que el testeo ha sido completado, verificar los resultados de la capacidad de gestión del testeo en el Rational ClearQuest. Los resultados expuestos muestran que todos los casos de testeo han pasado. El BOM del Rational Build Forge es actualizado con los últimos resultados de testeo relacionados a la construcción. Las características de gestión de testeo en el Rational ClearQuest unifica el defecto con las actividades de testeo. El registro de un defecto contiene información sobre el defecto, como ¿qué archivos fueron cambiados para arreglar el defecto?, la información construida, ¿qué casos de testeo fueron creados para verificar el arreglo? y los resultados del testeo de aseguramiento de calidad.

Con el testeo concluido exitosamente, Rational ClearQuest continúa para administrar el flujo de trabajo del desarrollo del software con actualizaciones automáticas para el siguiente y último paso, el cuál es la “entrega”.

Paso5: El Ingeniero de Desarrollo entrega el software.

Después del testeo, Rational ClearQuest notifica al Ingeniero de Desarrollo que el software está listo para la construcción final y entrega. A través del Rational Build Forge, se puede acceder a los registros de construcción en el Rational ClearQuest para identificar todos los cambios (defectos, mejora de calidad, etc.) direccionados para ésta construcción en particular y los archivos asociados fuente almacenados dentro del Rational ClearCase. Los tres archivos que fueron modificados para arreglar el defecto actual son incluidos en la construcción del software.

Usando los procesos construidos consistentes y repetibles en el Rational Build Forge, se puede completar exitosamente y rápidamente la construcción, y los resultados de la construcción son automáticamente generados. Rational Build Forge ejecutará procesos adicionales que el equipo ha especificado para la entrega final del software.

Rational ClearCase almacena las unidades de despliegue mientras que el Rational ClearQuest almacena los registros de despliegue. Rational Build Forge soporta una colección diversa de tareas de despliegue, incluyendo mover archivos a la localización deseada, restaurar servidores web, automatización de notificaciones, etc.

Finalmente, Rational ClearQuest completa su gestión de los flujos de trabajo del desarrollo del software con la automatización y actualización del flujo de trabajo hacia el cierre.

Conclusiones

La gestión del cambio, configuración y despliegue son puntos críticos en los procesos de desarrollo y entrega de software de calidad. La integración del software Rational ClearCase, Rational ClearQuest y del Rational Build Forge provee un ambiente de desarrollo de alta integridad con la finalidad de mejorar la entrega del software y la trazabilidad del ciclo de vida de desarrollo del software.

Herramientas para la integración de Gestión de Cambios y Release (I)

El escenario de casos de uso descrito en el paper de IBM que he encontrado, trae la solución de un efecto hacia el desarrollo y entrega del ciclo de vida del proyecto usando la integración de la gestión de cambio y lanzamiento de IBM, cabe mencionar que está orientado a los proyectos de desarrollo de software.

El software IBM Rational ClearCase, IBM Rational ClearQuest e IBM Rational Build Forge pueden apoyar al equipo durante el flujo de trabajo del desarrollo del software y entrega del sistema mediante los siguientes pasos:

Paso1: El QAE identifica y agrega un defecto

Se puede expresar que durante el testeo del sistema, el Ingeniero de Aseguramiento de Calidad (QAE) identifica el defecto, dicho defecto es ingresado al IBM Rational ClearQuest, para que después el equipo del proyecto reciba una notificación del nuevo defecto y poder identificar la prioridad de arreglar éste. Rational ClearQuest permite una configuración flexible y estandarización de los procesos del flujo de trabajo de un proyecto. El líder del equipo después de asignar la actividad a un miembro del equipo de desarrollo, el estado del defecto se convierte en “asignado”; y después puede generar reportes y gráficos sobre la información del proyecto, como por ejemplo: una lista de los defectos con alta prioridad, un gráfico de distribución de defectos en cada estado y un gráfico de defectos a lo largo del tiempo.

Paso2: El programador trabaja en el defecto

Como se ha mencionado anteriormente, el defecto es asignado a cualquier programador del equipo y será notificado por el Rational ClearQuest. El programador necesitará la información sobre el defecto, el cual se encuentra almacenada en el Rational ClearQuest, después se tendrá que agregar notas y acceder al registro construido directamente desde tu IDE usando el Rational Build Forge IDE plug-in, ya que permitirá que se vea fácilmente los archivos log, el entorno de los datos y las versiones del código fuente que ha sido utilizada en la construcción para que se pueda rápidamente aislar la causa del error. Luego conectar el Rational ClearCase directamente de tu IDE para acceder a los archivos del sistema de tu proyecto, para arreglar el defecto en particular se necesita el cambio de tres archivos después de revisarlos se marca algunas actividades al Rational ClearQuest, ya que ayudará ha asegurar que conoces cual de los defectos se debe estar trabajando y su prioridad, luego seleccionar el defecto actual de la lista. Después de haber realizado los pasos, el defecto estará ahora asociado con los tres archivos y el Rational ClearQuest automáticamente actualizará el defecto en el estado “open”, que significa que todos los miembros del equipo conocen que estás trabajando en el defecto. Después se modifica el código para arreglar el defecto.

Paso3: El programador realiza una construcción para verificar la solución

Después de haber realizado los cambios en el código, se necesita saber si las modificaciones realizadas han corregido el error. Normalmente, se debería entregar al equipo de desarrollo y esperar los resultados, pero en el siguiente ejemplo se realizará la construcción porque el Rational ClearQuest y los procesos estandarizados de construcción del auto-servicio en Rational Build Forge están integrados, y se puede ejecutar el proceso de construcción estandarizado y obtener la retro-alimentación en tiempo real para confirmar que tus cambios han corregido el defecto. El Rational Build Forge incluye un adaptador del Rational ClearCase y del Rational ClearQuest para que se pueda automatizar acciones comunes relacionadas a los procesos de construcción. Por ejemplo, el Rational Build Forge puede realizar que las operaciones del Rational ClearCase “file check-out”, “file check-in” y “apply a label” pueda ingresar un registro de construcción en el Rational ClearQuest.

La parte final del paper lo mostraré en el siguiente post…. Hasta pronto!

La Gestión del Riesgo Innovadora

A continuación hablaré sobre un tema muy importante en la actualidad, “la gestión de riesgos”. Una buena gestión de riesgos comprende la identificación de los riesgos, el análisis cualitativo y cuantitativo para saber cual es la probabilidad de ocurrencia y el impacto en nuestro proyecto, el plan de respuesta también llamado el plan de contingencia o mitigación para contrarrestar que el riesgo se convierta en problema, y la supervisión y control de los riesgos del proyecto, según el PMBOK, 2004.

Buscando algún artículo sobre la gestión de riesgos encontré uno sobre la Gestión de Riesgo Innovadora publicado por el Dr. David Hillson PMP FAPM que a continuación compartiré con ustedes.

Si Ud. piensa que “la gestión de proyectos tiene que ver con procesos y gestión de riesgos, y eso es todo el contrario de la innovación”…. Entonces Ud. está equivocado.

El propósito de la gestión del riesgo en proyectos y comercios es buscar incertidumbres significativas y abordarlas de manera proactiva. Es más eficaz cuando la gestión del riesgo considera tanto amenazas como oportunidades, como recomiendan las normas de mejor práctica.

¿Lograr este objetivo requiere mucha innovación?

1. El primer campo donde la creatividad es indispensable es la identificación de riesgos. Esto requiere que uno piense lo impensable, que uno se libere del “plan” y considere otras opciones y alternativas; realizar preguntas como “¿Y si… Por qué no… Si solo...?”

Para la identificación de problemas potenciales (amenazas) y beneficios inesperados (oportunidades) se requiere el uso de una gama de técnicas creativas tales como el brainstorming (la lluvia de ideas), assumptions-busting (poner suposiciones en duda), análisis causa raíz, visualización, análisis de escenarios, o pensar en el futuro.

De hecho probablemente no es posible identificar riesgos sin ser innovador y/o tener nuevos pensamientos.

2. Pero una segunda parte del proceso de riesgo también requiere una nueva manera de pensar, es decir el desarrollo de respuestas a riesgos eficaces.

Según Einstein, “No es posible solucionar un problema usando las mismas ideas que lo crearon.” No es suficiente simplemente identificar riesgos, si la acción apropiada no se toma, ya que luego uno quedará expuesto al riesgo hasta el mismo grado. Sin embargo decidir qué es apropiado para cada riesgo requiere cierta innovación, estar dispuesto a considerar y tomar acciones que antes uno no consideraba necesarias.

Einstein también definió la locura como “hacer lo mismo sin cesar y esperar resultados diferentes”, lo que se podría decir de otra manera así “‘¡Si sigues haciendo lo que siempre hiciste, siempre recibirás lo que siempre recibiste!”

Como dice el proverbio chino, “Si no cambiamos de dirección, es probable que llegamos adonde íbamos.”

Pero la gestión del riesgo moderna es muy diferente. Acoge y aprovecha del cambio activamente, reconociendo que algunos riesgos ofrecen la oportunidad de mejorar el plan original al trabajar “más eficaz, más rápido, más barato” – hay algo positivo tanto como negativo.

“La gestión del riesgo no creativa” es un oxímoron que no puede existir, y la gestión del riesgo sin la innovación sólo repite y documenta lo inevitable.

Conclusiones

Si el objetivo de la gestión del riesgo se percibe como impedir que uno diverja del plan a todo costo, agarrarse desesperadamente al método original y rechazar el cambio, pues es verdad que se ahogarán la creatividad y la innovación.

Para ser eficaz el proceso de riesgo debe abordar ideas innovadoras y creativas tanto en la identificación del riesgo como en el desarrollo de respuestas, buscando de manera proactiva incertidumbres con la potencialidad de ser significativas y abordándolas apropiadamente. Algo menos no merece el nombre de la gestión del riesgo.

Comparando las Metodologías Guiadas y Ágiles

A continuación hablaré sobre un extracto de un paper que he encontrado sobre las ventajas y desventajas en el uso de las metodologías guiadas y ágiles.

Algunas diferencias entre Metodologías

1. SDM vs. PMBOK

Conociendo que el SDM es la metodología de desarrollo de sistemas que ofrece procesos, herramientas y técnicas para el desarrollo de software basado en otros sistemas; mencionaré algunas diferencias con el PMBOK.

-> El PMBOK se enfoca en la gestión de un proyecto cualquiera, mientras que el SDM se enfoca en la producción de un software.
-> El PMBOK responde a las preguntas de ¿Quién?, ¿Qué? y ¿Cuándo? para la gestión de un proyecto, mientras que el SDM ¿Qué producir? y ¿Cómo producir?.

2. Metodologías Guiadas vs. SDM

-> Ambos proveen procesos, herramientas y técnicas.
-> Ambos requieren un enfoque disciplinado al desarrollo del software.
-> Cada uno tiene fortalezas y debilidades.

3. Metodologías Guiadas vs Metodologías Ágiles

-> Las metodologías ágiles dirigen muchas situaciones cuando las metodologías dirigidas no están bien definidas.
-> Las metodologías guiadas enfatiza en las comunicaciones formales y en el control, con la finalidad de ser más predictivo, mientras que las metodologías ágiles enfatiza en las comunicaciones informales continuas y a la reacción en los cambios, con la finalidad de ser mas adaptivo.

Ejemplos de Metodologías Guiadas

-> RUP de IBM
-> Gestión de Proyectos Tradicionales

Ejemplos de Metodologías Ágiles

-> XP (eXtreme Programming)
-> SCRUM
-> FDD (Feature Driven Development)
-> LD (Lean Development)
-> Crystal

¿Cómo elegir la herramienta correcta?

Seleccionando una metodología dependiendo de la situación, ya que la metodología guiada trabaja mejor bajo algunas circunstancias, y la metodología ágil trabaja mejor bajo otras, o tomando componentes y/o técnicas de cada uno, para construir los procesos que trabajen mejor para la situación.

Pero en realidad eso no me define que herramientas escoger ¿?, por eso se debe tomar en cuenta los siguientes factores:

1. Experiencia

Cuando el equipo tiene experiencia con el dominio de problemas, usa la metodología ágil, pero si el equipo tiene poca experiencia, puede utilizar la metodología ágil junto a la metodología guiada. Se debe tener en consideración el uso de:

-> R&D
-> Desarrollo iterativo mientras se está ganando experiencia con factores de realización.
-> Uso de nuevas tecnologías que impacte al equipo, por ejemplo la aplicación de grupos pequeños de trabajo.

2. Madurez del equipo de trabajo

-> Los equipos con poca madurez requieren una estructura adicional de una metodología guiada.
-> Los equipos con alta madurez fácilmente pueden tomar una ventaja ágil.

3. Localización y Tamaño del Proyecto

Si el equipo de trabajo es grande y geográficamente disperso requieren una comunicación formal de la metodología guiada, pero si el equipo es pequeño y localizado debe utilizar una comunicación informal. Es recomendable que los equipos no excedan de 6 a 8 miembros.

4. Cultura Organizacional

Algunas culturas organizacionales y equipos de gestión pueden ser más receptivos de un enfoque de otro.

5. Escalabilidad y Portabilidad

Para la construcción de un robusto sistema para la extrema escalabilidad a lo largo de una variedad de arquitecturas e infraestructuras podrían ser mejor direccionado con los controles de una Metodología Guiada.

6. Producto Comercial

La creación de un producto comercial requiere coordinación con Marketing y Departamentos de Venta, para la preparación de guías de usuario, el desarrollo de programas, y el establecimiento de equipos de producción; el cuál puede ser muy beneficioso utilizando un enfoque de una Metodología Guiada.

7. Combinando Metodologías

Combinando prácticas de ambos tipos de metodologías podría ser beneficial en algunas situaciones. Algunos enfoques son los siguientes:

-> Usar la metodología guiada para un proyecto o programa complejo y después utilizar la metodología ágil para sub-proyectos o sub-componentes.
-> Usar la metodología guiada para cualquier proyecto en general pero usar las técnicas ágiles como la programación en pareja para el esfuerzo de desarrollo.

Conclusiones

Un proceso definido no necesariamente debe ser formal o documentado, solamente debería ser consistente y ajustado.

El término ágil es un enfoque disciplinado al desarrollo de software pero con un énfasis en diferentes aspectos de los procesos.

Los equipos de gestión que trabajan bien con un enfoque de la metodología guiada también tienden a trabajar bien con un enfoque ágil.

Integrando el PMBOK al Proceso Unificado de Desarrollo de Software en Proyectos de TI

El siguiente tema que tocaré a continuación ha sido una ponencia en el Congreso Nacional de Gerencia de Proyectos PMI 2007 dictado por el PMP Guillermo Villavicencio. Los principales tópicos fueron: el problema con los proyectos TI de desarrollo de software, el RUP, integración del PMBOK al RUP (Mapeo de los principales entregables y actividades entre el PMBOK y el RUP) y un caso de aplicación práctica en el sector financiero en Perú.

Según un reporte Chaos realizado por la Standish Group identificó las siguientes causas del problema con los proyectos TI de desarrollo de software son:

-> Falta de involucramiento del usuario.
-> Falta de apoyo de la alta gerencia.
-> Objetivo de negocios difusos.
-> Gerente de proyecto inexperto.
-> Hitos de larga duración.
-> Requerimientos no administrativos.
-> Personal inexperto.
-> Planeamiento insuficiente.

Los dos grandes factores de éxito que pueden ayudar en la mejora de los proyectos de desarrollo de software a un 100% en 10 años son: proceso iterativo y manejo de proyectos profesional.

RUP es un proceso de desarrollo de software cuyas características son: iterativo, conducido por casos de uso, centrado en la arquitectura y gestión temprana de riesgos. Es un proceso bidimensional eso quiere decir que está compuesta por fases y disciplinas. Como ya sabemos RUP tiene 4 fases: iniciación, elaboración, construcción y transición; y cada una de esas fases tiene sus objetivos principales y su periodo de ejecución. Las disciplinas de gestión permiten: balancear y cumplir los objetivos de negocio, administrar los riesgos involucrados en los proyectos y entregar con éxito un producto que satisfaga las necesidades del cliente y de los usuarios.

El PMBOK posee un framework para gestión de proyectos, posee procesos principales que son agrupados en nueve áreas de conocimientos y muestra el nivel de actividad de cada proceso basado en el tiempo.

Ahora con respecto a la Integración del PMBOK al RUP, cabe recalcar lo siguiente: El RUP no cubre por completo todos los procesos de gerenciamiento de proyectos descritos en el PMBOK, con respecto al gerenciamiento de costos, recursos humanos y adquisiciones. Por otro lado, el PMBOK no está orientado a Proyectos de Desarrollo de Software.

Principales Características:

Propuesta de Solución: “Buscar en el PMBOK las mejoras prácticas de gestión de proyectos e integrarlas al RUP”


Mapeo de Áreas de Conocimientos del PMBOK con disciplinas del RUP

Conclusiones

Podemos utilizar la metodología iterativa incremental de RUP con gestión de proyectos PMBOK para proyectos medianos y grandes, y proyectos exitosos.

Es importante que el cliente entienda las ventajas del proceso iterativo incremental y las ventajas de una metodología formal de gestión de proyectos, al igual que las personas que practican la gerencia de proyectos comprendan la importancia de utilizar una metodología iterativa incremental de gestión de proyectos.

Todavía el mapeo tiene algunos vacíos en la disciplina de la Gestión de Proyectos:

-> Gerenciamiento de Recursos Humanos.
-> Gerenciamiento de Costos.
-> Gerenciamiento de las Adquisiciones y contrataciones.
-> Gerenciamiento del Alcance del Proyecto (el RUP se enfoca más en el alcance del producto o del software).
-> Análisis cuantitativo de riesgos y el planeamiento e ubicación de recursos para su tratamiento.
-> Otras técnicas que si se abordan en el PMBOK.

Ocho Tendencias a combatir cuestiones claves en Proyectos CRM

Muchos proyectos de CRM no son exitosos debido a que el gran problema es tratado de resolver todas las necesidades a la vez. Otros no tienen éxito debido a la política entre la TI y los interesados del negocio. Sin embargo, existen proyectos de éxito de CRM que han demostrado afrontar términos de tiempo, dinero y recursos. Estos proyectos siguen 8 tendencias importantes para luchar contra las cuestiones claves que a menudo se encuentran en proyectos de CRM, incrementando así el éxito de la entrega de una sólida visión de CRM.

Entonces, ¿Cuáles son dichas tendencias?

1. La correcta solución es seleccionada para un uso razonable de tiempo de ejecución

Si la solución no encaja en el modelo de negocio o procesos de negocio revisados con la funcionalidad out-of-the-box, no debería ser considerada sino se puede implementar con un mínimo de personalizaciones o integraciones con sistemas externos. En lugar de depender únicamente de las aportaciones a largo plazo de los empleados, la dirección ejecutiva usualmente contrata un proveedor independiente comprometido para trabajar con negocios y la administración de TI para determinar la solución que mejor satisfaga las necesidades empresariales.

2. Selecciona el proveedor correcto para la implementación que haga la diferencia

Está bien elegir una de los cinco empresas de Consultorías de spin-off para la implementación de la solución CRM, los más exitosos proyectos de CRM optan por empresas reconocidas de consultoría basada en la retroalimentación “antes de” y en los clientes existentes. Pequeñas empresas de consultoría proporcionan resultados mas eficientes (por lo general tres veces más calidad de los productos proporcionados por las 5 mejores empresas de consultoría), desde el diseño de las fases de producción y meticulosamente la toma de la propiedad en el éxito de la implementación del CRM.

3. Las personas negativas nunca deben estar en el equipo

Siempre habrá personas con energía negativa con el afán de destruir los proyectos de CRM. Los empleados perezosos y descontentos estarán mejor servidos si son expulsados del proyecto o participando en la fase del testeo del sistema donde la negatividad les forzará a ellos a tratar de malograr el sistema, identificando potenciales errores y funcionalidad perdidas que pueden ser resueltas antes de la aceptación del usuario.

4. Equipos híbridos proporcionan mejores resultados

Siempre hay un equipo híbrido que siempre se está basando de un complemento en el lado del cliente al lado del líder desarrollador, líder del testeo, líder de la integración, y un líder del negocio que entiende los procesos del negocio para cada función del sistema. Si los equipos de desarrollo se encuentran en el lugar, dos empleados y/o consultores del cliente estarán disponibles para la explicación de la lógica del negocio que normalmente se pierde en la traducción - un administrador señor de proyecto que comprende el desarrollo de los análisis de control, tableros, y los planes de proyecto detallados y un jefe técnico (consultor con años de experiencia en la entrega de la solución CRM).

5. Malos procesos son eliminados como parte de la preparación de CRM

El éxito de proyectos CRM tienen stakeholders ejecutivos que entienden que los malos procesos implementados en una solución CRM no es más que un mal proceso de negocio automatizado que requiere una mayor personalización, en última instancia utilizando mas tiempo, recursos y presupuesto.

6. La calidad de los datos y la fiabilidad está planificada en fases tempranas

Reconociendo que la conversión de datos deben ser planificados y desarrollados en el mismo tiempo de desarrollo es clave para una visión CRM exitosa. La migración de datos e integración de datos son planificados con las iniciativas de calidad de datos en las etapas de diseño no después del desarrollo de la funcionalidad del sistema.

7. Presentación de informes no es al final

El éxito de los proyectos CRM es mantener el propósito de la gestión de la visibilidad en la planificación y diseño. Dado que ésta es siempre una prioridad y la razón superior para la implementación, la presentación de informes es planificado tempranamente en las etapas de diseño por la ODS y expertos del Data Warehousing.

8. El tiempo de prueba es por lo menos el doble del tiempo de desarrollo

La norma estándar de la asignación de dos veces el tiempo de desarrollo de la prueba exacta sigue siendo válida. El éxito de los proyectos CRM tiene 5 fases que involucra el testeo unitario y funcional, el testeo del sistema, el testeo de la aceptación del usuario, el testeo de prueba de errores del testeo que son resueltos por el equipo de desarrollo. En resumen, los proyectos CRM pueden ser exitosos si estas tendencias se cumplen desde el comienzo del proyecto. A raíz de estas tendencias comunes aumentará la probabilidad de éxito de una visión CRM puesta en acción.

Source: http://ezinearticles.com/?8-Trends-to-Combat-Key-Issues-of-CRM-Projects&id=1261220