Malas decisiones

Tan poco tiempo, tantas formas en que las decisiones tecnológicas pueden salir mal. Si desea tomar decisiones tecnológicas acertadas, no permita que estos anti-patrones de toma de decisiones se interpongan en su camino.

por Isaac Sacolick

Malas decisiones

Cuando observa las nuevas tecnologías, ¿es como un niño en una tienda de dulces emocionado por probar todas las últimas innovaciones? ¿Quizás un líder en su organización es un jugador de tecnología y está listo para seleccionar proveedores sin suficiente análisis y debida diligencia? ¿O quizás el gerente de adquisiciones, la oficina de gestión de proyectos o las partes interesadas del negocio someten las selecciones de tecnología a una investigación tan exhaustiva que su organización se queda en la estela de la innovación y se queda atrapada en el barro con las plataformas heredadas?

Estas personas compradoras de tecnología se encuentran en muchas organizaciones y pueden socavar la capacidad de los líderes tecnológicos para realizar selecciones tecnológicas acertadas y oportunas. La selección de tecnología al azar conduce a un esfuerzo inútil y una deuda técnica, mientras que los enfoques demasiado metódicos ralentizan el ritmo de la innovación y frustran la experimentación, la asunción de riesgos inteligente y las culturas ágiles.

Estas personas pueden descarrilar su proceso de decisión tecnológica de muchas formas, desde atascar el proceso de evaluación tecnológica de su organización hasta perjudicar la toma de decisiones sobre cuándo invertir en tecnologías y qué productos o servicios considerar. Aquí hay 12 anti-patrones a tener en cuenta. Si desea tomar una decisión tecnológica inteligente, no haga lo siguiente:

Aceptar la opinión de los ejecutivos como decisión final

Cuando el CEO u otro ejecutivo influyente le pide al equipo de tecnología que compre e implemente una solución tecnológica específica, es fundamental dar algunos pasos hacia atrás para comprender el fundamento. ¿Qué problema está tratando de resolver este líder y qué tan bien cumple la solución con las expectativas? Con demasiada frecuencia, escucho a los líderes tecnológicos aceptar la voz del ejecutivo como un edicto y no tomar medidas para racionalizar el enfoque o presentar alternativas. 

Una solución es crear la disciplina de redactar y presentar declaraciones de visión de una página que se centren en un problema, una oportunidad o una propuesta de valor. Las declaraciones de visión bien elaboradas definen metas pero no son prescriptivas en cuanto a soluciones o implementaciones. Incluso si el equipo técnico completa esto en nombre del ejecutivo, a menudo conduce a una discusión y debate sobre múltiples soluciones. 

No solicitar ni considerar la opinión del cliente

Como tecnólogos, a veces cometemos los mismos errores que cometen los ejecutivos cuando se lanzan a las implementaciones. Vemos el problema, conocemos una solución y un sentido de urgencia nos impulsa a implementar la solución. Desafortunadamente, al no incluir la voz del cliente en el proceso de toma de decisiones, o al no comprender los beneficios (o no) para el cliente, podemos ofrecer fácilmente capacidades que no dan en el blanco. A menudo, las organizaciones ni siquiera logran definir formalmente quién es el cliente para ciertos proyectos de tecnología.

Definir un cliente es más fácil cuando desarrolla aplicaciones de usuario final mediante la definición de roles y personas. Pero encontrar un rol de cliente puede ser más desafiante cuando se consideran las capacidades de back-end, incluida la infraestructura, las capacidades de seguridad, el middleware, las bibliotecas o los servicios web. Pero los tecnólogos también son parte del negocio. Los arquitectos, analistas de negocios o líderes tecnológicos pueden actuar como representantes del rol del cliente al implementar tecnologías de back-end. Pídales que proporcionen requisitos, identifiquen los criterios de aceptación, tomen decisiones sobre las compensaciones y califiquen su satisfacción con la solución implementada. 

Ignore los estándares y tecnologías existentes

Históricamente, los departamentos de tecnología han tenido problemas para crear y mantener documentación y para comunicar y administrar estándares. Por lo tanto, cuando surge una solicitud urgente o un requisito principal, es más probable que busquemos nuevas soluciones en lugar de investigar y reutilizar las capacidades existentes.

Este enfoque a menudo conduce a capacidades redundantes, soluciones a medio desarrollar y una deuda técnica creciente. Agregar un paso de “investigación de soluciones internas” antes o como parte de la investigación de nuevas soluciones es una disciplina simple que puede aumentar la reutilización. Cuando la gente recomiende nuevas tecnologías, cree un proceso para estimar actualizaciones a plataformas heredadas o consolidar tecnologías con capacidades similares.

Fomentar una cultura tecnológica de un solo proveedor y un enfoque

¿Alguna vez escuchó a alguien decir enfáticamente, “Somos una tienda x “, como una forma de restringir cualquier investigación, revisión y consideración de otros proveedores o tecnologías? Una cosa es tener estándares y proveedores preferidos. Otra es ignorar las capacidades de terceros y obstaculizar la discusión de alternativas.

Permitir que la voz de unos pocos defensores de plataformas fuertes ahogue cualquier exploración y experimentación puede conducir a errores costosos. Los líderes tecnológicos deben abordar abiertamente este anti-patrón cultural, especialmente si está impidiendo que las personas hagan preguntas o desafíen el pensamiento del status quo.  

Suponga que construir o comprar es la única opción

Existe una amplia zona gris entre la creación de soluciones con código personalizado y la compra de SaaS u otras tecnologías que brindan capacidades listas para usar. En el medio se encuentran plataformas de código bajo y sin código altamente configurables , asociaciones comerciales y oportunidades para aprovechar las tecnologías de código abierto.

Entonces, construir versus comprar es una simplificación excesiva. Un mejor conjunto de preguntas es si las capacidades necesarias ayudan a diferenciar el negocio y qué tipos de soluciones ofrecen más innovación y flexibilidad a largo plazo.

Suponga que las API satisfacen las necesidades de integración

La mayoría de los sistemas SaaS modernos e incluso muchos sistemas empresariales ofrecen API y otras opciones de integración. Pero catalogar los ganchos de integración debería ser solo el comienzo de la investigación de si satisfacen las necesidades comerciales. ¿Qué datos expone la API? ¿Se admiten las vistas y transacciones deseadas? ¿Puede conectar fácilmente las herramientas de visualización de datos y aprendizaje automático? ¿La API funciona lo suficiente y hay costos de uso subyacentes que deben considerarse?

Los enfoques para acelerar las revisiones de las capacidades de integración incluyen estas tres formas de validar las API y aprovechar las plataformas de integración de código bajo .

No realizar la debida diligencia social

Cuando nos enfrentamos a una larga lista de posibles soluciones, las fuentes de información confiables pueden ayudarnos a reducir el campo de juego. Leer blogs, informes técnicos, reseñas e informes de investigación, y ver seminarios web, conferencias magistrales y tutoriales en línea son todos pasos clave del aprendizaje. Pero una herramienta que a menudo se deja de lado es aprovechar las redes sociales para consultar con expertos. Dos lugares para comenzar incluyen IDGTechTalk y #CIOChat , donde muchos expertos brindarán consejos y compartirán soluciones alternativas. 

Omitir la prueba de concepto

El arte, el oficio y la ciencia de seleccionar tecnologías implican diseñar y ejecutar soluciones de prueba de concepto (PoC) que validan los supuestos y prueban los requisitos estratégicos clave. Las PoC son particularmente importantes al validar tecnologías emergentes o evaluar plataformas SaaS, pero incluso el uso de picos ágiles para revisar componentes de tecnología de terceros ayuda a acelerar la toma de decisiones y evitar errores costosos.

El mayor error puede ser omitir la PoC, ya sea porque cree en lo que ha leído, confía en el proveedor o se enfrenta a demasiada presión de tiempo. Incluso cuando un PoC da luz verde a una tecnología, lo que aprenda del PoC puede ayudarlo a dirigir las prioridades hacia implementaciones factibles.

Desarrollar matrices de decisión elaboradas

Cuando muchas personas están involucradas en la revisión y evaluación de nuevas herramientas y tecnologías, un enfoque común para ayudar a impulsar una decisión basada en datos es crear una hoja de cálculo de matriz de decisiones. Las características y capacidades se ponderan por importancia y luego las califica un comité de revisión. La hoja de cálculo calcula las puntuaciones totales.

Desafortunadamente, estas herramientas pueden salirse de control rápidamente cuando hay demasiadas personas involucradas, se eligen demasiadas funciones o se asignan ponderaciones arbitrarias. La hoja de cálculo termina priorizando las preferencias de su autor, y la gente pierde de vista lo que debe evaluarse estratégicamente al revisar todos los detalles. 

Antes de embarcarse en una matriz de decisiones, retroceda un paso. Considere resumir las características de las soluciones hasta la esencia del problema comercial, en lugar de requerir que demasiados revisores evalúen largas listas de características.

Ignore las consideraciones de arquitectura, ciclo de vida y soporte a largo plazo

Soy un gran defensor de la evaluación de tecnologías basadas en la facilidad de uso y el tiempo de creación de valor, pero eso no significa que las consideraciones de arquitectura, mantenimiento y soporte a largo plazo no sean importantes o no requieran evaluación.

La clave es decidir cuándo evaluarlos, cuáles son las consideraciones clave, quiénes participarán en la revisión y cuánto tiempo invertir en la evaluación. Una buena manera de hacer esto es separar las preocupaciones sobre las puertas que los equipos de tecnología deben considerar al comienzo de una evaluación de los factores a más largo plazo que deben ser insumos para el proceso de toma de decisiones.

Omitir revisiones de SLA, protección de datos y seguridad

La presión del tiempo o la fe (ciega) en la tecnología elegida son malas excusas para escatimar en las revisiones de los acuerdos de nivel de servicio (SLA) y las evaluaciones de las prácticas de seguridad y protección de datos de los proveedores. La clave para hacer bien estas revisiones es tener la experiencia, las habilidades de negociación y las herramientas necesarias, y un proceso de evaluación eficiente, para que los tecnólogos y los patrocinadores comerciales no perciban las revisiones como cuellos de botella.

Las organizaciones más grandes que realizan revisiones internas de SLA, protección de datos y seguridad deben ser eficientes en el tiempo y concentrar sus esfuerzos en alinear la evaluación con los principales riesgos. Las empresas más pequeñas con experiencia insuficiente deben buscar personas externas con experiencia en el dominio de las soluciones.

Retrasar las revisiones financieras y legales

Lo último en mi lista, pero ciertamente no menos importante, son las revisiones financieras y legales. El anti-patrón aquí está esperando demasiado para traer a los expertos necesarios para llevarlos a cabo.

Tenga en cuenta que muchas ofertas de SaaS, servicios de API y tecnologías nativas de la nube tienen modelos de precios basados ​​en el consumo, y es posible que los costos operativos no cumplan con las limitaciones presupuestarias o financieras. Las revisiones legales son particularmente importantes para las empresas de industrias reguladas o empresas que operan a nivel mundial, y la revisión de los factores de cumplimiento en ambos casos puede llevar mucho tiempo. Tanto para las revisiones financieras como legales, las demoras pueden ser costosas.

No espere hasta el final del proceso de revisión de tecnología para aportar experiencia financiera y legal. Mi consejo es traerlos al principio y pedirles que opinen sobre lo que será necesario revisar desde el principio, antes de tomar cualquier decisión de selección de tecnología. Además, no sobrecargue sus recursos financieros y legales al tener demasiadas evaluaciones en progreso a la vez.

Intentar hacer malabares con múltiples evaluaciones de tecnología no es realista para muchas empresas, y los líderes deben priorizar sus esfuerzos de compra. Si lo hacen, le prometo que es posible realizar revisiones de tecnología inteligentes, integrales y eficientes.

DOCUMENTOS TÉCNICOS RECOMENDADOS

Fuente: https://www.infoworld.com/article/3626456/12-ways-to-make-really-bad-technology-decisions.html

Deja una respuesta