El origen de esta presentación fue la exposición, en 2004, a un grupo de empresarios vizcaínos, de diversas técnicas útiles en la contratación de proveedores tecnológicos y en la gestión de sus proyectos digitales asociados. Algunos aspectos han quedado ya obsoletos (9 años después), pero otros siguen perfectamente vigentes.
3. Antecedentes y Objetivos
En la Universidad de Deusto y en otros ámbitos
académicos y empresariales he intentado insuflar
criterios a los plausibles arquitectos y diseñadores de
estrategias de negocio electrónico.
...para que diriman sobre opciones tecnológicas adecuadas a
distintos negocios objetivos.
En esta presentación se trata de enseñarles a discriminar
sobre opciones de negociación y contratación de
ProTecs y proyectos informáticos… ¡con sentido para sus
empresas!
Se trata, pues, de aplicar e-lectrólisis para separar lo esencial
de lo accesorio o lo banal.
4. Agenda… ¡por Temas!
La intención es enseñar a los asistentes, que se
consideran insertos en el mundo empresarial, reglas
prácticas de “sentido común” en negocio electrónico,
para que puedan...
Lidiar con ProTecs (Proveedores Tecnológicos) y con su propia
idiosincrasia: encontrar el punto de e-quilibrio.
Contratar desarrollos tecnológicos en un entorno colaborador
entre ProTecs y respecto de la empresa misma.
Abordar proyectos tecnológicos mediante técnicas de
reducción del riesgo.
Apartarse de falacias, lugares comunes y simples equívocos
adscritos a las tecnologías.
6. Experiencias… ¿Malas?
En un reciente proyecto de e-Consultoría hemos tenido
la oportunidad de acercarnos a la casuística práctica y
muy concreta (problemas, problemas, problemas) que
marca las relaciones entre empresas y proveedores
tecnológicos (ProTecs).
El análisis aislado de cada una de estas relaciones nos
ha llevado a corroborar diversos síntomas que expresan
el desencuentro entre ambas partes
…y que trocan sobremanera difíciles sus relaciones
contractuales y de negocio.
7. ¿Contratos?
Usualmente no se firma contrato alguno, debido a que…
El ProTec no lo presenta (los abogados son caros)
La Empresa no lo solicita (pues no sabe qué pedir y teme
comprometerse… ¡aún más!)
El ProTec lo plantea y la Empresa lo rechaza…
…porque no lo entiende
…porque le parece abusivo
…porque no gana nada respecto de no tenerlo
La Empresa intenta imponérselo al ProTec
…y éste contraataca con un contrato igualmente exigente (en
sentido inverso, claro)
8. ¿Contratos? ¡Contritos!
El contrato tecnológico intenta paliar o mitigar el efecto de las
desviaciones contingentes respecto de…
…la empresa: por si acaso el ProTec no le entrega lo que quiere.
…el ProTec: por si la Empresa no establece claramente aquello por lo
que pagará.
El problema es que la empresa no suele saber lo que quiere (y rara
vez lo que de verdad necesita), y el ProTec no suele ser flexible en el
uso de sus recursos y esfuerzos (“si no querías que te amputara la
pierna haberlo dicho al principio, que ahora ya he preparado el
serrucho”).
…así que los contratos, cuando se dan, o bien pretenden que el
ProTec adivine el futuro, o bien colocan a la empresa en inferioridad
(tecnológica) para subyugarla.
9. ¿Contratos? ¡Sí! Pero…
¿cómo?
El objetivo de un contrato tecnológico es conseguir la
máxima independencia posible de la empresa respecto
de su ProTec y de la tecnología empleada.
Y éste no es el objetivo sólo de la empresa, sino que debería
serlo también del ProTec
El contrato debe, además, asegurar que las dos partes
están en cada momento conformes con lo que
construyen/entregan/pagan
…por lo que deben establecerse mecanismos para asegurar la
comprensión (por todas las partes) de ciertos hitos y, sobre
todo, para abortar proyectos indeseados.
10. ¡Ah! Pero… ¿No Hay
Recetas?
¡Claro que sí! He aquí algunas cláusulas que el ProTec debiera
asumir y garantizar:
Uso y posibilidad de extensión del producto vendido o arrendado
(personalizado o no)
Traspaso integral a la Empresa de la propiedad intelectual de todo lo
desarrollado (software y modelos) para un proyecto dado
…o reducción significativa del coste
APIs y/o modelos explicados de datos
Ofrecer, incluido o no en el precio del proyecto, el uso de un API (o
conjunto de servicios) para que otros ProTecs –o la empresa misma–
puedan extender el resultado del proyecto o producto.
…o, en defecto del API, el modelo de datos (las tablas relacionales,
usualmente) bien explicaditas.
Prototipos iniciales y Juegos de Pruebas finales
11. Recetas y Criterios
El problema de las recetas no es su uso, sino el control
de los criterios de su aplicación.
Y es que no existe un “modelo normado” de contrato
tecnológico (pese a lo que afirmen algunas empresas, sobre
todo las muy grandes) y que, por tanto, cualquier compromiso
queda únicamente supeditado al convenio entre las partes.
Se trata de que la empresa entienda tanto las necesidades y
carencias de sus ProTecs como las suyas propias, y así pueda
establecer un punto de equilibrio sobre el que “pivotarán” las
condiciones contractuales de su proyecto informático.
Así que… ¡Intentaremos enseñarles a pescar!
13. e-Pivoting
Pivot: “A person, thing, or factor having a major or
central role, function, or effect” (Merriam Webster, 10th
Edition)
e-Pivot: El rol y función de control en la concepción,
diseño, desarrollo y mantenimiento de iniciativas de
negocio electrónico
Pivotar: “Moverse o apoyarse sobre un pivote” (DRAE)
e-Pivoting: la acción de pivotar en el ámbito electrónico
14. Ni Tanto ni Tan Corto
No se trata de “cómo lidiar con ProTecs” desde el punto
de vista del cliente
…que debería cortar primero las múltiples capas de aquéllos y
luego mantenerlos en agua, vinagre y sal para mitigar su
acidez.
…ni de cómo vender tecnología a clientes
…instruyendo, por ejemplo, sobre cómo averiguar el máximo
importe que un cliente podría pagar, con independencia del
trabajo a realizar.
Se trata de encontrar el punto de equilibrio entre la
profesionalidad de los ProTecs y las Necesidades de la
empresa.
15. Comprehensión y Extensión
Lo verdaderamente difícil de la contratación electrónica
es ponerse en el lugar que corresponde
…para entender tanto al proveedor como al cliente
…pero también para entender tanto al ingeniero que lo proyecta,
diseña y construye como al usuario que finalmente lo utilizará,
normalmente de forma intensiva.
Y para eso es necesario ahondar en la comprensión de
cómo operan proveedores y clientes en sus relaciones
…y también analizar sus tácticas.
16. El Libro de las Simetrías
Designing from Both Sides of
the Screen: How Designers and
Engineers Can Collaborate to
Build Cooperative Technology,
por Ellen Isaacs & Alan
Walendowski, 2001, New
Riders Publishing, 0-67232151-3.
…o como situarse en el punto
medio, no del compromiso, sino
de la satisfacción tecnológica.
…y orientado a la usanza.
18. What, How, Why? Ya’Know?
Se supone que el cliente posee el “Know-What”
Es decir, que conoce qué es lo que quiere y, mejor, lo que
necesita
Se presume que el ProTec contará con el “Know-How”
O sea, que sabrá cómo implementar las soluciones requeridas
Pero… ¿Quién asume el “Know-Why”?
Esto es: ¿quién establece los criterios por los que se asegura
la idoneidad y validez del “qué”, del “cómo” y, sobre todo, de su
adecuación
Y es que resulta que… ¡Ni el cliente suele saber lo que necesita
ni el ProTec suele poder abordarlo!
19. Ejemplo de “Mejora” (I)
El Cliente quiere mejorar su sitio Web, porque le han
comentado y tal vez ha constatado, comparándolo con
otros, que “no da la talla”.
Pero mejorar significa pasar de un estado a otro mejor, y eso
implica que ambos estados han de ser conocidos.
El ProTec solicita información completa al cliente, lanza
una oferta y se pone a “mejorar” el sitio Web
Pero la única mejora que puede abordar es el remodelado del
sitio Web con arreglo a sus propios criterios y conocimientos
técnicos.
20. Ejemplo de “Mejora” (II)
El Cliente quiere adecuar su sitio Web al valor supuestamente emanado
por la imagen de su empresa
Se mueve en el eje de gestión empresarial
El ProTec ajustará el diseño Web a los supuestos estándares Web que
presuntamente conoce.
Se mueve en el eje técnico-tecnológico
Y el caso es que tales ejes no se encuentran en el mismo plano, así que
el resultado tenderá a satisfacer al ProTec (que es el que impone su
criterio en la construcción) y a defraudar al cliente.
Pero es que, además el supuesto movimiento en cualquiera de los ejes
mentados es… ¡Ilusorio!
Así que la decepción conjunta finalmente se impondrá.
21. Ejemplo de “Mejora” (III)
El Cliente cree que algo anda mal con su sitio Web, pero no sabe
exactamente qué, y además, siguiendo las Leyes de Weinberg,
asimila que al tratarse de un aspecto técnico, no tiene que
profundizar demasiado ni calificar la situación de problemática.
Así que, en realidad, no conoce el “qué” y, por tanto, no se mueve en
ninguna dirección ni eje.
El ProTec compara el sitio Web con otros del sector de la empresa y
con sus propias tendencias de diseño y no se cuestiona si usa o no
la tecnología adecuada, pues asume que la idónea es la que el
conoce, dado que en el fondo también es una empresa sujeta a las
Leyes de Weinberg.
Así que, en realidad, no sabe el “cómo-del-qué”, por lo que aplica “sucómo” a “cualquier-qué”.
22. What? How? Know-Why!
Lo ideal sería contar con varias versiones del “qué” y del
“cómo” para, mediante el “porqué”, discriminar sobre
ellas.
Pero la realidad, como hemos atisbado, es que no se suelen
conocer ni “qués” ni “cómos”.
Así que utilizaremos el “porqué” como técnica universal para
descubrirlos
Dado que Cliente y ProTec se suelen mover en universos
desafortunadamente disjuntos, no sólo no tienen
respuesta a los “why”, sino que ni siquiera se los han
formulado.
Hay que situarse en el punto intermedio (pivote) para poder
descubrir los requisitos buscados.
23. El Porqué de la Técnica
…o la Técnica del Porqué
…que consiste en preguntar(se) en voz alta sin cesar por el
porqué de cada frase:
No queremos mostrar los precios en la Web.
¿Por qué? Es posible que los vea la competencia y entonces…
¿qué? ¿Se van a molestar? ¿Por qué?
No queremos gastarnos mucho
¿Por qué? Tal vez por carencia de presupuesto, pero quizás porque
la importancia que se le da al proyecto es marginal, así que no puede
esperarse tampoco ningún cambio, de ningún tipo.
Muchas veces se trata de inquirir… ¿Por qué crees
que…? Y de no cejar hasta conseguir respuesta, mala o
rápida.
24. El Porqué de la Tecnología
“¿Qué prefiere que utilicemos: Flash o Shock?” –podría
preguntar un ProTec, como también “¿Lo quiere con
HTML ó con Bases de Datos?”–
¿Por qué me hace esta pregunta? Utilice lo que le dé la gana
siempre que cubra mis requisitos y expectativas. ¿Por qué debo
elegir? ¿Para eximirles de responsabilidad adoptando una
decisión sobre algo que no comprendo? ¿Para evitar que me dé
cuenta de que no han extraído ni redactado ningún requisito de
la empresa?
Le he puesto aquí un Tunel de Idioma y…
¿Por qué? ¿Qué le he hecho yo? ¿Cuáles han sido sus
criterios para ponerlo o no? ¿Dar más opciones? ¿Por qué no
quitarlo?
25. El Porqué de los Extraños
Lo más difícil de la técnica del porqué es aplicarla cuando
suponemos conocer la respuesta:
¿Por qué no hago X? Porque en el pasado ya lo decidí y no he
encontrado elementos de juicio nuevos
¿Por qué hago X? Porque nos va bien
Etc., etc.
El resultado es, normalmente, que al asumir que existe una
respuesta, el énfasis se pone en aquellas cuestiones que no parecen
tener respuesta todavía
…y así se ignora la principal fuente de problemas (las presunciones,
las asunciones históricas) y se intenta esconder la génesis y los
responsables de los problemas de la situación actual (2ª Ley de la
Consultoría).
26. Escenarios y Coreografías
Típicamente, el empresario evita la descripción razonable de
escenarios, e intenta ocultar esta carencia mediante la descripción
de su coreografía.
Yo hago, él hace, tú deberías hacer, etc.
Pero no sé por qué lo que tú deberías hacer está bien o mal o si me
interesa o no o si…
Un buen remedio es obligar al cliente a escribir los escenarios de los
que parte cualquier operación
…pero el empresario prefiere pagar para que los escriban otros
(coreografía pagada, de nuevo)
Una buena manera de identificar los síntomas es preguntar: ¿Por
qué tu empresa es diferente? ¿Y por qué yo lo habría de percibir,
que no soy del sector?
…y si suena a Misión, Valores, etc., es que… ¡se desconoce!
27. El Libro de los Exploradores
Exploring Requirements: Quality
Before Design, por Donald C.
Gause & Gerald M. Weinberg,
1989, Dorset House Publishing, 0932633-13-7.
Una mezcla prudente de psicología
informática (Weinberg),
pragmatismo didáctico (Gause) y
guía para alcanzar criterios de
decisión.
…y, además, orientado a los
proyectos tecnológicos.
…y nada de bla-bla-bla.
29. De la Presunción y la Realidad
El cliente se pone en contacto con una empresa de Diseño Web
recomendada por un tercero.
Le explica la situación y desea una solución (la que sea)
La empresa presenta un presupuesto
El presupuesto es… ¡Inocuo!
¡Pero también inicuo!
¿Otra Oferta? Humm, parece que ya hemos perdido demasiado tiempo
con la primera
¿Por qué no darles una oportunidad? Lo mismo no lo hacen tan mal. Y, la
verdad, no debe haber demasiada diferencia de calidad entre ProTecs
…porque si no… ¡la empresa la conocería!
El resultado es siempre como las antiguas croquetas: de las sobras
también se hace cocina
…sobre todo si uno está de antemano conforme.
30. InfoPools
Una piscina que no cubra… está bien… vamos, en el
fondo es una piscina… pero, bueno, cuanta más agua
pues… mejor
La cuestión es que el cliente puede ser más o menos
consciente de sus problemas o “mejoras-a-acometer”…
Pero… ¿quién asegura que no se estará perdiendo el tiempo
con este o aquel ProTec?
Cómo asegurarse de que no se ha perdido tanto tiempo
explicando el problema que ya no haya opción y haya que
contratar al ProTec
Pues… ¡Proponiendo el trabajo a muchos ProTecs!
¡Simultáneamente!
31. De las Presunciones Éticas
¿Por qué no puedo reunir a distintos ProTecs para evitar
perder tiempo en reconsideraciones y re-decisiones?
No se trata, con todo, de establecer un “Pliego de Bases
Técnicas” que los ProTecs habrían de contestar.
La reunión consistiría en exponerles in situ la situación de la
empresa y forzarles a que, también in situ, determinaran cuáles
son sus características diferenciales (las de cada ProTec) que
podrían colaborar a… ¡mejorar el proceso!
La reunión no es para conseguir la oferta más económica
…sino la oferta con talante más colaborador
32. Las Formas y Los Modos
Las reuniones corales de InfoPool son más fáciles de mantener que
las reuniones normales
…pues la norma básica es que el cliente (el organizador) no debe
moderar: simplemente expondrá su problema, se someterá a
preguntas y no tolerará desplantes.
Se trata, pues, de premiar el comportamiento más colaborador, evitando
a ultranza las reuniones en privado
Si un ProTec no se presta a una reunión de tal tipo “colaborador” es
que no interesa como proveedor
Además, no se mantendrán nuevas “primeras rondas” con ProTecs
particulares.
El primer criterio deberá ser tan sólo el “talante”
…y el segundo la “disminución del riesgo”
34. Tecnología = Electrodoméstico
La esencia de la tecnología útil es, precisamente, su
utilidad independiente de la tecnología utilizada.
No se compra un vídeo (a no ser por compulsión técnica, ajena
a esta ponencia) por su relés, rotores, lubricantes o sus circuitos
integrados, sino por su utilidad, y después por su “usabilidad”
En la negociación de compra Web debe primar, por
tanto, su “usabilidad”
...y las cuitas tecnológicas no son material vendible, sino que
deben someterse y supeditarse al uso del resultado final y a sus
proyecciones.
35. Tecnología Invisible
La Tecnología debiera ser, para los clientes y empresas,
como la electricidad en el hogar: ¡Invisible! (al menos
cuando funciona)
Sus beneficios han de ser tangibles y su presencia inadvertida.
Las aberturas Internet de las Empresas habrían de ser como
interruptores eléctricos
Pequeños artefactos que hacen “visible” y “útil” la electricidad de
forma estrictamente localizada.
...y su ubicación y utilidad dependen del usuario-cliente.
36. ¿Precios-por-Página? ¡No!
Las páginas no son anuncios, sino estructuras de longitud
variable cuyo contenido depende de su finalidad.
La disposición de páginas representa una estructura jerárquica en la
que cada página supone un diferencial inferior al 0,02%
Cuando se cuente con el presupuesto por página, plantéese
un escenario de cambio radical y evalúese de nuevo el precio
y la razón de su diferencia.
Debe pagarse tan sólo por la adecuación de la idea web a la
especificidad del negocio y a sus plausibles cambios.
¡Rechacen soluciones genéricas a sus problemas concretos! ¡Paguen
por la posibilidad de cambio!
37. ¿Diseño? ¡Sí, pero Después!
Un equipo de creativos suele ayudar a materializar de
forma atractiva un concepto de negocio o servicio
...pero la Web trata más de contenidos que de continentes.
Exijan que las propuestas de sitios web soporten páginas
de contenido variable
...porque el diseño periodístico-televisivo tiene poco que ver
con el diseño web.
Deben conseguir que el precio del diseño web esté
estrictamente separado del de la construcción de su
infraestructura tecnológica.
38. Pero... ¿Diseño, al fin?
Mmmm
La regla básica de la Web es...
Un buen diseño ha de ser habitable
...entendiendo que la belleza formal es adecuada al sitio web de
un museo, pero en un negocio ha de poseer simplicidad
práctica.
La presentación de la información debe residir en una
capa distinta de la información misma.
...y la tecnología usada no debe importarles
...siempre que puedan certificar su sujeción a estándares
tecnológicos
...pues “Diseño no implica automáticamente Diseño Web”.
39. ¿Publicidad? ¡No! ¡Ubicuidad!
ubicuo, cua. (Del lat. ubīque, en todas partes).
1. adj. Dicho principalmente de Dios: Que está presente a un
mismo tiempo en todas partes.
2. adj. Dicho de una persona: Que todo lo quiere presenciar y
vive en continuo movimiento.
La empresa Web necesita ser ubicua (estar disponible
para el e-negocio en todos los lugares)
pero usualmente tan sólo consigue ser conspicua y longincua
(ilustre y distante).
...debido a una publicidad usualmente equivocada.
40. Pero... ¿Publicidad? Mmmm
La publicidad de sitios Web funciona verdaderamente en
entornos tradicionales (prensa, televisión)
...pues la percepción de publicidad en la Web se asocia
(erróneamente) a gratuidad accesible por cualquiera y, por
tanto, desprovista de valor diferencial real.
En planes de viabilidad Web, los modelos de negocio
basados en publicidad deben ser, en todo
caso, marginales.
...pues la publicidad suele enmascararlos.
41. ¿Folletos? ¡Vade Retro!
Resistan la tentación del Brochureware (Folleto-ware)
...que consiste en la traslación a la web de los (posibles)
folletos en papel que ponderan tan benignamente a las
empresas.
No inunden de fotos o dibujos los sitios web
Pero incluyan una opción para examinar visualmente cada uno
de los productos que se incluyan en cualquier iniciativa B2B
No intenten superar el papel llenando la web de
animaciones, colores llamativos o funcionalidades
espectaculares.
Reserven el ingenio para el negocio.
42. ¿Hosting? ¡No! ¡Integración!
La explotación de aquello que se sitúa fuera del ámbito
operativo de la empresa...
...será aprovechado plenamente sólo por terceros
Pese a que parezca más práctico traspasar la gestión de
sus datos sobre productos y precios a una iniciativa
externa...
...lo más eficaz es forzar la comunicación continua de la
iniciativa B2B con la empresa, facilitando así el cambio hacia el
negocio electrónico de ésta.
La web es tan sólo la parte visible (opcional) de un
enfoque B2B, pero nunca la esencial.
43. Algunas Citas Comentadas
No manager ever got fired for buying IBM (IBM
advertising slogan)
...pero esto no se aplica, en ningún caso, cuando hayan de
participar en una iniciativa Web externa.
Science finds, industry applies, man conforms
(Anonymous)
No acepten, sin más, “Best Practices” ni “Métodos Sectoriales
Probados”. El Cliente son ustedes.
All you need in this life is ignorance and confidence; then
success is sure (Mark Twain)
Si no les gusta... ¡rechácenlo!
44. Las Leyes de la
Consultoría de
Gerald
M.Weinberg
Las Leyes Inmutables
Mejoras, Fantasías y Extensiones
Otras Leyes Básicas
45. Las Tres Leyes Básicas
Éstas son las normas que los consultores deben seguir a
rajatabla cuando se hacen cargo de una cuenta o
proyecto:
1ª Ley: Pese a lo que el cliente pueda decirte, siempre
hay un problema
2ª Ley: Independientemente de cómo se muestre al
principio, el problema siempre es de personas
3ª Ley: Nunca olvides que te están pagando por horas,
no por la solución
46. Siempre hay un Problema
Lo usual es que la empresa asuma que no tiene ningún
problema que finalmente no pueda abordar, de una
forma u otra
…pues la base de la cultura de gestión es que los problemas
asociados a la empresa deben poder controlarse desde la
empresa misma.
…así que las áreas para las que llaman a consultores se
asimilan como “áreas de mejora” o, simplemente, no esenciales
para el negocio, pero deseables para su proyección.
Así que, naturalmente… ¡Siempre hay un problema!
Y es por eso que se contrata a un consultor (u otro tipo
profesional similar)
47. ¿Problemas o Mejoras?
Si el cliente no se reconoce enfermo, ¿cómo se le puede tratar?
El enfoque “Alcohólicos Anónimos” suele resultar traumático y sólo se
debe aplicar en casos flagrantes de problemas asumidos por el cliente
En el resto de los casos, se presumirá que el cliente es competente
para tratar con las cuitas de sus negocio
…y se le ofrecerá una mejora (pues nadie rechaza una mejora, se
considere enfermo o no)
Se trata de atacar tangencialmente el problema dando armas al consultor. Es
un enfoque razonable.
Cuando es el cliente mismo el que requiere contratar a un consultor
para una “mejora”, esto nos indica que el cliente sabe a ciencia cierta
que tiene un problema.
48. La Mejora del 10%
La Promesa del 10%:
Nunca prometas más del 10% de mejora
Y es que un 10% se asimila psicológicamente como un “NoProblema”. El éxito en un porcentaje mayor de mejora implicaría
que la empresa ha tenido un problema que no ha sabido
abordar.
La Solución del 10%
Si consigues una mejora superior al 10%, asegúrate de que
nadie lo nota
…y la mejor forma de conseguirlo es darle al cliente todo el
crédito por ese diferencial.
49. Es un Problema de Personas
Una forma frecuente de que los gestores o empresarios eviten notar
que tienen un problema es simplemente etiquetarlo como un
“problema técnico (o tecnológico)”
…que se supone no es una responsabilidad directa del gestor.
Pero, claro, aunque se trate de un problema técnico, siempre se
podría notar que se debería haber actuado o no-actuado antes, lo
que implicaría de nuevo un problema organizativo.
Así que el objetivo del consultor no será “notar el problema humano”
tras el técnico, sino entrevistarse con las personas que han originado
(por acción o inacción) que el problema técnico apareciese.
50. El Problema de la Cercanía
Sea lo que sea que haga el cliente, recomienda algo más
(Ley de Marvin)
Los problemas de personas se suelen dividir en:
Problemas de Percepción
Problemas de Perspectiva
Las personas que están demasiado cerca de un problema
aplican una y otra vez esquemas que no funcionaron ni la
primera vez
…pues si hubieran funcionado no hubiesen llamado a un
consultor
Amigo del Campo que Viene a la Ciudad[explicar]
51. Te Pagan por Horas
Esto no significa que haya que cobrar lo máximo posible al cliente
[bueno, no sólo significa esto ]
Si se quiere que se pague por la solución, primero el cliente ha de
asumir que tiene un problema, y que éste es lo suficientemente
grande como para pagar a un caro consultor para que lo solucione.
Así que si el consultor lo soluciona evidenciará las carencias del
equipo de gestión
…y si no lo hace, las suyas propias
O sea: este camino (de la solución) no conduce a nada
La 3ª Ley recuerda al consultor, simplemente, que si el cliente
hubiera querido una solución, habría pagado por una solución,
expresamente.
52. La Regla del Crédito
Nunca conseguirás nada si te importa quién se adjudica
el crédito
Para que un consultor obtenga el crédito de un trabajo, el
cliente habría de admitir que se ha llegado a una solución, pero
eso supone asumir que existía un problema, lo que es
impensable.
A resultas de este razonamiento, los consultores que suelen
repetir en las empresas son aquellos que nunca parecen haber
conseguido nada (lo hagan o no).
La diferencia entre un buen consultor y otro ineficiente es
que cuando trabaja el primero, el cliente resuelve
problemas.
53. La Fantasía del Llanero
Solitario
Cuando los clientes no muestren su apreciación por tu
trabajo, piensa que tal vez estén anonadados por tu
eficiencia –pero nunca olvides que esa es tu fantasía, no
la de los clientes
La postura ideal de retirada de un cliente es la misma que la
del Llanero Solitario: una vez que has terminado un trabajo con
un cliente esperas que no te llame otra vez para abordar el
mismo problema, así que has de seguir sin volver la vista atrás.
…pues, de otra manera, lo que el consultor buscaría sería la
contratación perpetua precisamente por haber sido incapaz de
instruir.
54. La 4ª Ley de la Consultoría
Si no te contratan, no resuelvas su problema
Para un cliente, un consultor es “alguien que te ayuda a
resolver problemas que piensas que podrías haber resuelto tú
mismo” (si tuvieras más tiempo)
Así que la contratación de consultores suele suponer la admisión
de un fallo personal
Así que si el consultor falla, esto supondrá un éxito para el cliente,
que verá reforzada su posición.
Esta ley recuerda que la consultoría es el “arte de
influenciar a la gente a petición suya”.
55. Otras Leyes Básicas
La Ley de la Mermelada
Cuanto más la extiendes, más fina se vuelve
Influencia o Afluencia: Elige Sólo Una
La mayoría del tiempo, para la mayoría del mundo, no
importa cuán duro trabaje la gente en algo: nada
significante sucede
Una vez que eliminas el problema número 1, el número 2
se promociona
Una vez que el consultor elimina el problema número 1, es
culpable de promover el número 2
56. El Libro de los Secretos
The Secrets of Consulting: A Guide
to Giving & Getting Advice
Succesfully, por Gerald
M.Weinberg, 1985, Dorset House
Publishing, 0-932633-01-3.
Uno de los libros más sensatos
sobre como contratar servicios de
consultoría… por ambas partes.
…y, además, orientado a la
consultoría tecnológica.
…y escrito por un autor brillante y
no de bla-bla-bla.
57. Aplicaciones Prácticas (I)
Si un creativo sabe demasiado de su negocio y rediseña
la imagen corporativa, cambiándola totalmente, sitúa al
cliente en la esfera de la mala gestión (por no haberlo
previsto)
Se impone un cambio radical, pero sólo del 10% de la imagen
global de la empresa.
Si se garantiza como resultado un sitio Web de comercio
electrónico, en el fondo al cliente se le está garantizando
el comercio electrónico (así que el ProTec siempre
fracasará)
Se debería haber abordado una incursión electrónica, con el
consultor como sherpa.
58. Aplicaciones Prácticas (II)
Se contrata a un consultor para que dé una solución de
ERP, pero no se le participa el problema con precisión, o
no se le participa en absoluto (así que el consultor
implantará su propia solución a otros problemas
anteriores y alegará que en otras empresas funciona)
En lugar de pedir al cliente qué es lo que quiere y cómo opera
(que plantea problemas, porque en otro caso no hubieran
contratado al consultor) y luego pasarlo a limpio, hay que
inquirir por el proceso (y las personas implicadas) que ha
desembocado en la contratación del consultor.
60. COfimática vs. Informática
Un entorno ofimático de trabajo es aquel orientado a la
productividad, usualmente basado en la producción y
gestión de documentos, por un trabajador no
informático, basado en aplicaciones de propósito
general, que apoyan su trabajo técnico, permitiéndole
elaborar documentos, organizar la información y
comunicarse con su entorno organizativo.
Quedan excluidos (parcialmente, con todo), los sistemas
corporativos, estructurados, orientados a datos estratégicos y
operacionales, diseñados y supervisados por analistas
informáticos.
61. La Visión de Microsoft [¡Explicar!]
Correo Electrónico
Lista de Carpetas de MS Outlook
Contactos
Contactos de MS Outlook
Documentos [Word, Excel, Powerpoint, etc.]
Carpeta de “Mis documentos” (MS Windows)
Documentos Compartidos
MS Sharepoint
Notas
MS OneNote (o Notas de MS Outlook)
Papel
Archivo Tradicional
62. El Problema… ¿Ofimático!
Antes de abordar la compra de un paquete software
comercial o un proyecto de desarrollo informático, debe
examinarse si el problema a resolver pertenece (o no) al
área de extensión ofimática, pues en tal caso…
…si se cuenta con licencias software (de, por ejemplo, MS
Office), la solución típicamente pasará por el uso de las
herramientas ofimáticas (Excel, Outlook, etc.) o por su fácil
extensión [¡Explicar!]
…si no se cuenta con productos ofimáticos, será más fácil
plantearse su compra si su adquisición y uso están ligados a los
aspectos de gestión.
63. La Ofimática de los ProTecs
Es ciertamente sencillo extender la lista de tareas de MS
Outlook para que refleje las particularidades de un
negocio dado
…como también es sencillo utilizar los contactos como
repositorio categorizado de clientes; o crear una nota; o leer
desde un programa externo las citas de un día.
Claro que… es sencillo para los ProTecs que conocen
las áreas de extensión ofimática (y sus herramientas,
como MS Visual Studio for Office)
Cualquier oferta de un ProTec debe considerar, primero, la
extensión ofimática; y sólo si se rechaza (siquiera parcialmente)
abordar el resto.
65. Regla Básica
Cualquier sugerencia u oferta de un ProTec sobre
sistemas operativos o máquinas (PCs, impresoras) debe
pedirse argumentada por escrito.
¿Por qué Linux? ¿Por qué no MS Office? ¿Por qué ahora?
¿Cuál es el impacto en mi proyecto?
En ningún caso valdrá la experiencia (sin más) del
ProTec, como tampoco servirán las declaraciones del
tipo: “Porque es lo mejor, ya te lo digo yo”.
Reflexión sobre Opciones [¡Explicar!]
67. Resumen Postural (I)
Se advierte la difícil integración de la tecnología en
general (y de la nuevas tecnologías en particular) en el
entorno empresarial, debida sobre todo a la desconfianza
en las tecnologías, en su dirección, en sus postores y en
sus posibles resultados.
La ganancia de confianza puede conseguirse mediante
una metódica disección de escenarios y la aplicación de
heurísticos y reglas que, minimizando el riesgo y
maximizando el ROI, supongan la adquisición de criterios
fundados que impelan a la toma de decisiones.
68. Resumen Postural (II)
La asunción empresarial de la tecnología es necesaria,
pero... ¡no a toda costa!
Ni la tecnología es “simplemente utilitaria” ni es un “destino
obligatorio”
La tecnología no es una “asignatura pendiente”, sino que su
compra, uso y mantenimiento deben asimilarse a los de un
electrodoméstico o un dispositivo industrial.
El objetivo final de las estrategias X-net no son las
páginas web, sino la integración de procesos de
negocio/servicio en cadenas digitales largas.
69. ¿B2B? ¿Biz-to-Blitz?
No se trata aquí de avisarles de los riesgos del Businessto-Business, ni de hacerles dormitar con sus plausibles
ventajas.
Pues el interés se evidencia por su asistencia, y demasiados
postores ya les han contado de argumentos convincentes y de
apoyos suficientes.
Mi intención sólo es centrarme en (y enfocarles hacia) la
mayor traba en su tránsito razonable hacia esquemas
B2B: la desconfianza e-negocial y tecnológica.
...y dotarles de algunos criterios prudentes para ganar la
necesaria e-confianza.
70. Objetivo Presumible
A
Se trata de definir y habilitar el camino para pasar de la
situación operativa actual (A) a la situación electrónica
operativa deseable (D)
El problema es que
(A) no está definido de forma automatizable
De hecho, uno de los mayores problemas en la determinación del
camino hacia la conexión B2B entre empresas es la carencia de
información interna de cada una sobre sus posibilidades y carencias.
(D) no se conoce (tan sólo se adivina)
...por lo que determinar el camino no puede consistir
simplemente en trazar una línea recta.
D
71. Presunciones, no Asunciones
Pocas empresas se cuestionan el advenimiento de una
situación estable y provechosa de mercadeo electrónico.
...pero el plazo en que tal situación resulte de inevitable
adscripción se antoja lejano (5-10 años, en el mejor de los
casos, según una reciente diagnosis)
Así que recorrer el camino desde la situación A (Actual) hasta
la D (Deseable) se parece al que nos separa de la conquista de
Marte:
Se antoja cargado de peligros.
Y... ¡Tal vez pueda esperar!
72. De la Situación Deseable
(D)
X-Net y B2B suponen la
sincronización de procesos de
negocio y servicio interempresas, pero...
Las agrupaciones sectoriales
pueden representar trabas
respecto del avance B2B
...por la confluencia de objetivos y
competidores
Las PYMEs suelen abordar
posturas miméticas, para evitar
riesgos y no trocarse en dianaspivotes respecto de su
competencia.
(c) 2004-2013 Ricardo Devis
73. Del e-Camino y la Distancia
+ Distancia + Desconfianza
+ Riesgo de tomar un camino erróneo
+ Volatilidad de las asunciones básicas
Erratismo Bursátil e Informativo
Volubilidad Tecnológica
- Capacidad de evaluación del ROI
¿Puede disminuirse la distancia?
No, pero puede mitigarse la percepción de distancia
(aumentando la confianza)
...mediante hitos de muy corta duración:
Micro-Entregables
74. Micro versus Macro
La desconfianza en las operaciones de e-business viene por su
similitud con las operaciones quirúrgicas:
A no ser que su riesgo sea casi nulo, ¿por qué abordarlas antes de
que sea estrictamente necesario?
¿Por qué no empezar con tratamientos que generen resultados que
faciliten la decisión sobre el abordaje de las siguientes fases?
¿Debe la empresa transitar globalmente hacia el e-Business? ¿O
puede empezar con tratamientos pequeños de “enfoque B2B”,
fáciles baratos y que generen beneficios mensurables? (pregunta retórica)
Pero... ¿cuáles son tales pequeños entregables?
75. Micro-Entregables X-Net
Tras el relativo fracaso de las fases metódicas, las TIC han devenido
en el énfasis sobre pequeños hitos prácticos:
Componentware y Procesos Componibles
Agile Methods (eXtreme Programming, etc)
Web Services (Micro-Servicios Web)
Micro-Cadenas de Valor Digitales (e-Biz Links)
Se trata de fragmentar el ciclo de vida habitual en las TIC en fases
mínimas con final práctico
...de forma que no se trabaje en infraestructuras que luego darán
soporte a... ¿qué?
Cualquier esfuerzo, desde el principio, debe dar fruto inmediato.
...y además debe ser inmediatamente comprensible
76. Micro-Ejemplos
Intercambiar información de catálogos de productos o
servicios en una iniciativa X-net no puede esperar para
dar frutos a que se traspase primero todo el catálogo
Pues el sistema debiera funcionar desde el principio con sólo
una referencia (y no den crédito a infundios sobre carencia de
funcionalidad).
Rechacen los mapas como pre-condición para la
construcción de un sitio web
A la web no se tiene que salir “con todo”.
Es mejor poco contenido y muchas adiciones que mucha
parafernalia inicial y poca evolución.
78. Seguridad Digital
Las tecnologías digitales permiten mayores niveles de
seguridad que las aplicaciones analógicas o que las
comunicaciones humanas o empapeladas
Y, entonces, ¿cuál es el problema?
El mismo que habilita el e-business/e-commerce: cualquier
puede acceder (o intentar acceder) a nuestros sistemas
Se da, pues, un desorbitado número de potenciales atacantes.
Un agujero en nuestro sistema de información es como una
herida en un hemofílico o un túnel en una prisión: todo puede
salir (o entrar) por él.
79. Seguridad Diversa
Imaginen que aprenden Taekwondo para defenderse
(con patadas) de posibles maleantes camino de casa...
¡...y que le atacan en un ascensor!
No puede preverse todo
...pero la comunicación digital no puede ser peor que la
telefónica, la postal o la basada en la confianza personal.
Las estrategias de seguridad deben aplicarse no a una
generalidad, sino a hitos y micro-entregables concretos.
80. Reglas de Supervivencia
Evalúen qué información debe ser privada, cuál
protegida y cuál pública
...pero invirtiendo la premisa típica: Deben pensar que toda la
información debiera ser pública, e intentar encontrar razones en
contra.
Se llevarán una gran sorpresa
...y de paso realizarán un inventario necesario
No permitan que nada ni nadie acceda directamente a
sus sistemas de información
...lo que incluye a sus empleados y usuarios de sus Intranets.
81. Primeras Conclusiones
Seguras
Dado que el camino no está
trazado, las soluciones
mágicas no se van a dar.
Lo que no entiendan no es
razonable.
La Seguridad es materia
voluble (objetiva y
subjetivamente), así que debe
ser siempre un apósito, de
poner y quitar/tirar
…como un abrigo
Pregunten siempre Why?”
(c) 2004-2013 Ricardo Devis
83. Las Islas pre-XNet
Antes de la irrupción de X-Net en el mundo de los negocios en
cualquier empresa podían coexistir varias aplicaciones
informáticas independientes
Cada una de ellas estaba centrada en la automatización de algún aspecto
concreto de la empresa y no influía en las demás aplicaciones
Por tanto contaban con sus propias bases de datos e interfaces de
usuario que se desarrollaban independientemente por distintos
proveedores tecnológicos
…y usualmente sin entrar éstos en lo que otros habían hecho ya.
Incluso los enfoques basados en “un paquete bueno para todo”
(sistemas ERP, etc.) no llegaron a funcionar.
84. e-Ducación Integrada
Sin embargo con las nuevas posibilidades (o exigencias) que
Internet ofrece a la empresa ahora, se necesitan desarrollos
informáticos integrados e integrables
Por ejemplo, a la hora de recibir un pedido no se pueden hacer
desarrollos independientes para la versión de la Intranet, la versión Web y
la versión para dispositivos móviles
Cada uno de estos desarrollos debe convivir con los demás
compartiendo un núcleo común servicios y procedimientos
¿Cómo conseguir entonces que los proveedores tecnológicos nos
entreguen aplicaciones informáticas que puedan dialogar con otras
(hechas por otros) de forma e-ducada?
85. Esfuerzos y Pliegues
Los esfuerzos de integración informática requieren…
Atender a la estrategia concreta de la empresa por lo que
surgen distintas iniciativas relacionadas con Internet, Intranet
y Extranets
Plegarse a la naturaleza de los proveedores tecnológicos
que asistirán a la empresa en tal proceso de integración
Así que aparecen cuitas relacionadas con Diseño Web,
Identificación Corporativa Electrónica, Recolección y Procesado
de Información Heterogénea,
…y otras muchas
86. e-Plataforma Deseable
La combinación de todos estos factores genera un vasto conjunto de
posibilidades, así que su abordaje parcial suele causar una costosa
fragmentación del esfuerzo, pues impide su utilización en otros
segmentos
Esto ocurre, por ejemplo, cuando se desarrolla un repositorio
ofimático para la Intranet y luego se quiere acceso vía Internet
El resultado es, normalmente, que distintos e-proyectos, con distintos fines
y presupuestos, han de convivir a la vez
Pues se suele esperar un retorno de la inversión asociada a los mismos y
resulta difícil, financiera y emocionalmente, reconstruir los proyectos ya
terminados cada vez que se empieza uno nuevo.
Faltaría aquí una suerte de e-plataforma razonable que pudiera
soportar las combinaciones antedichas. Y su concepción es,
precisamente, lo que vamos a abordar.
87. Contexto de Aplicación
Empresas que quieren iniciarse en Internet y no tienen una idea
clara de cómo dirigir su estrategia digital
Es decir… ¡la inmensa mayoría!
Generalmente la forma mas adecuada de salir a Internet es
mediante la exploración (esto es, experimentando),
…sacando algo y reaccionando a medida que se obtienen resultados
y experiencia
¿Por qué se intentan predecir los resultados de una iniciativa si es más fácil
(y más barato) probar-y-tirar?
Nadie acierta con su estrategia Web completa a la primera
Por tanto el avance mediante adaptación progresiva requiere de un
sistema informático que permita realizar cambios de forma rápida y
económica.
88. La Forma Flexible o la Buena
Hay dos formas de realizar un proyecto Web
Una implementación tan sencilla que no suponga una gran pérdida el
tirarla y rehacerla cada vez, pero centrándose en el nuevo enfoque
(ver otras e-ideas)
Una implementación de tanta calidad que admita cambios sin que
haya que volver a empezar
El primero es el método más recomendable
Es difícil conseguir una arquitectura como la que requiere el segundo
método
Por lo que se invierte más tiempo y dinero para obtener el mismo resultado
que con el primero
Esta Matriz es para las empresas que eligen el 2º método
Porque ya han utilizado el primero anteriormente y por tanto cuentan
con un volumen razonable de funcionalidad que ya requiere cierta
estabilidad.
89. Primeras Dudas
Pero... ¿no será mejor abordar un único mega-proyecto monolítico
que contemple todo (la Intranet, dispositivos móviles, Web, etc.) y así
no tener que estar cambiando nada en el futuro?
Cuanto más grande es el proyecto más difícil es de definir y más
se relegará debido al coste y tiempo que supondrá
¿Habrá que esperar a que se implanten los dispositivos móviles para
hacer la versión Web […?]
[…que ya podría estar dando beneficios y experiencia?]
Siempre habrá una nueva tecnología que considerar
Por lo que el proyecto estará en una continua fase de redefinición para
intentar abarcarlo todo
90. Dudas Exclusivas
Dado que no se puede evitar la evolución ¿por qué no dejar que se
encargue de todo el mismo proveedor tecnológico y así eliminar lo
que se antoja una difícil cuestión de coordinación de proveedores?
Pero es que, por definición… ¡un proyecto que se pretende
ampliable no puede depender de un único proveedor tecnológico!
Pues éste no podrá ser sustituido por otro proveedor sin tener que
volver a comenzar desde el principio
Por tanto el ProTec, sabiendo su posición, puede abusar mediante un caro
mantenimiento
…o, simplemente, ocultando al cliente las características no flexibles de su
software
…y la característica de “extensibilidad” se basa en que haya sido
construido de la misma forma.
91. En la Variedad está el Gusto
A la hora de abordar un proyecto Web se deberá distribuir éste en
distintas empresas tecnológicas
Así que ninguna deberá percibir sensación alguna de dominio sobre
el cliente
Se elegirá para cada módulo una empresa que sea especialista en
ese tipo de desarrollos
Abriendo las posibilidades de contratación al no requerir un proveedor
que domine distintas disciplinas
Y por tanto al aumentar la oferta poder ejercer mayor presión sobre el precio
Al tener cada ProTec una parte mejor definida (y de ámbito más
reducido, y por tanto más manejable) será más fácil calibrar precios y
tiempos.
92. Módulos y Médulas
Los módulos en los que dividir un proyecto Web serán:
Identificación corporativa
Componentes asociados a la presencia de la empresa
Logotipo, lema, colores, tipo de letra, etc.
Diseño del Sitio Web
Identificación de los usuarios, necesidades, contenidos y
navegación
Servicios Web de Integración
Concepción, montaje y creación de una plataforma de Servicios
Web
Esto es…
accesible vía HTTP mediante paquetes semi-estructurados XML
(nota técnica)
93. e-Cirugía Reconstructiva (I)
¿Por qué separar esas tres partes?
Identificación corporativa
Se puede reutilizar en los distintos proyectos informáticos
además de en los canales tradicionales
Folletos, Web, Intranet, tarjetas de visita, etc
Diseño del sitio Web
Al ser realizado este módulo por un equipo independiente no
acoplará la presentación con los servicios Web
Será más fácil cambiar el sitio Web (al ser mucho más ligero)
La modificación o inclusión de nuevos servicios no afectan a la Web
94. e-Cirugía Reconstructiva (II)
../…
Servicios Web
No están acoplados a una aplicación Web y por tanto se puede
reutilizar la lógica independientemente del navegador
Por ejemplo para dar servicio a la Intranet o a un sistema ERP
Será más fácil añadir otros servicios Web ya que estarán en una
plataforma independiente de una aplicación concreta
Y por tanto no se dependerá de su implementador para añadir
nuevos servicios
Permiten ir abordando poco a poco la adición de nuevos
servicios y la modificación de los existentes.
95. Coordinación y e-Pivoting
En definitiva estos tres módulos se separan con el fin de romper
ataduras con los proveedores tecnológicos
…de tal manera que no se esté e-coaccionado a la hora de
embarcarse en nuevas iniciativas Web o de Intranet
Pero… un momento... ¿cómo se coordina todo esto?
Si ya es difícil lidiar con un ProTec...
...¡de esta manera se triplica la faena!
Hace falta una labor de coordinación...
.. que el empresario no sabe hacer ni tendría tiempo de hacerlo
Por tanto aparece un cuarto participante: el e-coordinador, el cual se
encargará de la Consultoría Tecnológica
…y de lidiar con las cuitas de integración.
96. Los Tantos del Pivotaje
La Consultoría Tecnológica comprende fundamentalmente las
siguientes labores
Concepción de la arquitectura IT de integración
Revisión de los hitos asociados a las fases de desarrollo
Validación de los entregables de los demás participantes
Idoneidad y adecuación de la identificación corporativa
Usanza Web del Diseño del sitio
Control del ajuste de servicios Web y montaje
Consultoría sobre aplicación de la tecnología a la mejora de las
relaciones con los clientes (fidelización, monitoring, etc.)
97. Ejemplo Integrable
La empresa Macronet decide embarcarse en llevar a cabo la e-idea
de las Partidas Vivas
Mostrar a cada cliente la situación de sus pedidos, pagos, etc. “enlínea” (on-line)
Para ello inicialmente contrata como Consultoría Tecnológica a
“Paul, Vintcent & Asociado”
…que determina la arquitectura y los lindes de cada módulo para el
proyecto en cuestión
…le asesora en la contratación de los otros tres componentes del
proyecto
…y le forma para que en el futuro pueda abordar el mismo tipo de
coordinación con menos ayuda o ya de forma independiente.
…siempre bajo la máxima de que “en vez de regalar peces hay que
enseñar a pescar”
98. Fragmentación del Deseo (I)
El trabajo a realizar se reparte de la siguiente manera:
Identificación Corporativa
Crean y eligen el logotipo, tipo de letra, colores, etc.
Que posteriormente se plantea aprovechar en sus nuevos catálogos y tarjetas
de visita además de en la Web
Diseño del Sitio Web
Utilizando la estética definida anteriormente se diseña la navegación
necesaria para la presentación de las Partidas Vivas de un cliente
El sitio Web no debe requerir ningún tipo de programación para el
acceso a los datos
Se les impone la tecnología de desarrollo Web denominada JST
Prohibiéndoles expresamente ASP, JSP o equivalentes
99. Fragmentación del Deseo (II)
../…
Servicios Web de Integración
Se implementan WebServices que ofrecen la situación actual de un
cliente en un formato neutro
Se aprovecha para establecer una base para el acceso exterior al monolítico
ERP
Se realiza una correspondencia entre usuarios Web y los usuarios del
plausible sistema ERP con que cuente la empresa.
Se solventan los accesos a bases de datos y demás repositorios
corporativos
Se crean perfiles de acceso a determinados servicios del catálogo
Etc., etc.
100. ¿Lego o Mecano?
Posteriormente, Macronet, a la vista de la experiencia conseguida
con este primer proyecto, decide modificar sus servicios informáticos
Decide cambiar el sitio Web para ofrecer más funcionalidad a sus
clientes
Elimina completamente la Web actual y contrata a un nuevo equipo de
diseño Web
El cual utiliza la imagen corporativa ya existente y los servicios Web de
información que no han desaparecido al quitar el sitio Web antiguo
Posteriormente decide reestructurar sus servicios Web para ofrecer
mayores posibilidades a su Intranet
El sitio Web no tiene que cambiarse ,por lo que se da soporte a nuevas
aplicaciones sin tener que rehacer las existentes
101. Pero… ¿En quién confiar?
Para que este enfoque pueda llevarse a cabo es necesario definir
completamente las interfaces entre los distintos módulos
¿Dónde empieza el trabajo de uno y acaba el del otro?
Hay que delimitar claramente qué parte del proyecto corresponde a
cada proveedor
Hay que determinar qué debe entregar y qué se le debe entregar a
cada ProTec para acometer su trabajo
Definir los interfaces entre los subproyectos es otra tarea del ecoordinador
No pueden dejarse a los ProTecs, ya que primarán las soluciones
rápidas para este proyecto, en vez de criterios que faciliten futuras
ampliaciones
…con la que les tocaría pelear a otros cuando ellos ya no estén.
102. Entregables Integrados
Entregables de cada módulo:
De la identificación corporativa
Entrega de un e-booklet para la empresa en el que se detallen
especificaciones (Pantones, formatos como JPEG, tipos de letra, etc.) y se
acompañen con los ficheros pertinentes y, además, con ejemplos de
adaptaciones
Del diseño del sitio Web
Contenidos del sitio Web (paginas HTML y recursos)
El diseño no contendrá programación software alguna (es decir, que no
traspasará los lindes de ECMAScript)
Descripción de los datos requeridos por cada página
El diseñador trabajará con datos de prueba y sin conexión a los repositorios
corporativos (mediante el uso de JST)
Del módulo de los servicios Web
Documentación de los servicios implementados
Con formatos de los parámetros y de los resultados
103. Flexibilidad a la Fuerza
La aplicación de la e-matriz no consiste únicamente en separar el
proyecto en distintos módulos
Hay que asignar cada uno a un ProTec distinto
En caso contrario se corre el riesgo de que las interfaces no se definan
adecuadamente para adaptarse a otros módulos posteriores
Si no simplemente para que funcione la aplicación en conjunto
Asignando cada parte a un ProTec distinto…
Se asegura un producto flexible ya que ya se está produciendo la
situación en la que lo que hace uno lo tenga que utilizar otro
Los propios ProTecs exigirán que los entregables del anterior sean correctos
105. Otros Libros Siempre Útiles
Usabilidad: Diseño de Sitios Web, por Jakob Nielsen,
2000, Prentice-Hall, 84-205-3008-5.
No Me Hagas Pensar, de Steve Krug, 2000, PrenticeHall, 84-205-3252-5.
Presos de la Tecnología: Por qué los productos
tecnológicos nos vuelven locos y cómo recuperar la
cordura, de Alan Cooper, 2001, Prentice-Hall, 968-444464-8.
El Ordenador Invisible, por Donald A. Norman, 2001,
Paidos Odin, 84-493-0923-9.