BI & Big Data

- Drucker: el recurso económico más importante en el día de hoy es el conocimiento. Se convirtió en el

recurso económico clave y la fuente competitiva dominante (quizás incluso la única).
- La inteligencia de negocios es como una estrategia empresarial que básicamente su objetivo es
incrementar el rendimiento, la eficiencia y la competitividad del negocio mediante la correcta
organización, correcta explotación, el correcto análisis de sus datos y esa información será actualizada o
datos históricos
- La clave del BI es emitir conocimiento, como ya venimos hablando, son un poquito más o un poco mejor
que tener simplemente información, sino que cuando yo tengo conocimiento logro entender qué está
pasando con la información.
- Lo que dije al principio es que el concepto de BI aparece cuando uno quiere ver cómo explotar
correctamente los datos como mostrarlos, como utilizar la información que yo tengo almacenada en la
base de datos. Yo la tengo suelta ahí en las bases bien almacenadas, todas muy bonitas, no me sirve para
nada. Lo que hace el BI es básicamente emitir conocimiento y mediante la correcta organización y
análisis de mis datos e información sean actuales o históricos. Poder tomar decisiones de manera
eficiente en el tiempo que necesito y de la forma más correcta posible. Cuando yo tomo decisiones y
tengo conocimiento (la clave del BI como dijimos emitir conocimiento) es mediante toda la información
que tengo almacenada que yo la voy a ir trabajando para alcanzar ese conocimiento y así facilitar la
toma de decisión.
- Como la información es compleja (ya habíamos hablado muchas veces de que la información es
compleja y el propio sistema muchas veces tiene su propio enfoque) necesitamos tener un foco integral.
Sabemos que cada uno de los sistemas un TPS, un MIS, tiene su enfoque particular, entonces, ¿qué
necesitamos para tomar decisiones? Que la información sea integrada. Bueno, esto es un poco lo que
viene a hacer el BI. Como dice ahí, provisiona de información correcta, en el momento adecuado (no
puedo esperar a pasado mañana a que se me informe). Y hacia las personas correctas para que éstas
puedan tomar decisiones más adecuadas. La palabra provisión de información, momento adecuado y
personas correctas son claves cuando estamos definiendo o hablando de Business Intelligence,
inteligencia de negocio.
- Bueno, como los conciliamos, ahí es donde entra la idea de la inteligencia de negocios, tengamos una
forma y un vocabulario común para que todos entendamos qué es lo que queremos saber adónde ir a
buscarlo. Esa es la esencia del Business Intelligence.
- Ahora, cuando nosotros estamos hablando de manejar información para toma de decisiones de alto
nivel, muchas veces los datos que nos interesan no son datos individuales, sino que son datos integrados
y con esto nos referimos a sumas regionales por oficina, cálculo por decir algo, si estamos hablando de
sistemas contables por área de costos, sí por centro de costos nos interesan tener datos macro, su más
completas, promedios, y además, y por sobre todo, nos interesa poder comparar con períodos
anteriores. Nos interesa la información histórica que esa información histórica, además pasamos por
alguna migración de datos, como vimos cuando implementamos un sistema nuevo. Esa información
tiene formatos diferentes, cómo hacemos para que no se pierda el hilo conductor entre lo que se hizo en
el pasado y lo que se hace, ahora sí de vuelta en inteligencia de negocios. Lo que tratamos de hacer es
entender cómo funciona la organización. Entonces, ver cómo funciona el pasado, a ver cómo funciona
ahora para ver tendencias también es importante. Es por eso que no podemos consultar directamente a
los sistemas transaccionales porque no están diseñados para operar bien frente a esa clase de consultas.
- Muchas veces lo que se hace es trabajar con dos data warehouse, uno que tiene todos los datos tal cual
como existieron en la base de producción, digamos, en el sistema transaccional, y después una
conversión que se hace para poder hacer cálculos más rápido. Lo que importa es que es una base
separada.
- No me interesa mantener la información tal cual, sí me interesa mantener y resaltar resaltar sobre todo
en el diseño, aquello que nos importa para tomar decisiones. Por otra parte, es integrada esto que
dijimos si tenemos varios sistemas y cada uno representa una faceta de un hecho de la organización,
poder hacer que todas esas facetas estén juntas.
- Una vez que la pusimos en el data warehouse esa información no debería volver a cambiar si la
cambiamos es porque hicimos algún cambio en los datos de fondo y si son transacciones históricas, en
principio no deberían cambiarse salvo que haya una corrección.
- Es un formato SQL, sí, pero podemos tener un montón de otros orígenes de datos. También archivos
XML, CSV o cualquier otro formato que haga falta. Podemos estar sacando datos de otras aplicaciones,
no lo sabemos, lo que importa es que son orígenes de datos, lugares de donde podemos sacar datos.
Todo eso se va a integrar, sí, mediante alguna forma de gestión de datos o de integración de datos se le
extrae los datos de las fuentes. Si los transforma para poder hacerlos integrables, completa la
información que falta y descarta que esté ruidosa. Sí hay información que no es confiable, se descarta o
se la transforma para así hacerla confiable. Y con eso se almacena en esa base de datos del medio que
vendría a ser nuestro data warehouse.
- Sí, por eso se extraen los datos de las fuentes. Se transforma este y se carga en la nueva base de datos.
La LL del Low OK. Una vez que tenemos los datos en esas fuentes, no alcanza con eso solo porque
porque están en una base de datos, pero a nosotros nos interesa que esta información les sirva a alguien
para poder tomar decisiones con la información lo más apropiada posible. Entonces hay que generar
alguna forma de salida de datos, esas salidas van hacer dashboard, tableros de reportes. Si van a hacer
reportes listados con mayor o menor nivel de detalle, según lo que haga falta y podrían exponerse a para
que algunas aplicaciones muestren esa información según la necesidad o sean consultadas por otras
herramientas.
- Tipos de data warehouses:Objetivo es tal como fue en la realidad. Vos tenés tus tablas y las vas a tratar
de replicar. Subjetivo es cuando las procesas para interpretarlas.
- No es la intención de las aplicaciones de Business Intelligence tener un minuto a minuto.Pues lo que te
interesa es devuelta es ver cuál es la tendencia de tu negocio. Cuáles son las áreas en las cuales te está
yendo bien, cuál está yendo mal que está pasando, entonces contener la información actualizada a ayer
suele ser suficiente, incluso en algunos casos en una semana. Se le dice que es como sacar una foto de la
empresa.
- Entonces hay cierta precisión que se sacrifica para poder hacer esta integración. Por ahí podrías tener el
dato exacto si haces toda la cuenta, pero no lo podrías relacionar con los otros sistemas, entonces, para
ganar esa integración y tener una visión unificada de la compañía uno está dispuesto a sacrificar cierto
nivel de precisión. ¿Cuánto es ese nivel? Nunca más que un 1, o un 2% como máximo. Es importante
tener eso en mente.
Cuando uno dice estas operaciones, si nuestros datos son esencialmente ruidosos, una app de BI va a
tener grandes problemas, primero hay que trabajar en los datos.
- Cuáles son aquellos valores que son relevantes para entender
- Datos planos o todo texto, todo, fotos todo audio. Estamos hablando de un montón de formas o de o de
datos, de distintas variedades diferentes, y eso es una de las claves que vamos a ver en big data. No son
la gran cantidad y volumen gigantesco de datos, que es una de las grandes diferencias con BI, sino que
estamos hablando de un abanico de tipo de datos y diferentes datos muy diferentes entre sí, no
solamente hablamos de datos común y corriente, vamos a hablar de un montón de datos que abarca y
que permite manejar el Big Data.
- Todos los sensores que están dentro de estas cosas generan constantemente información. Sin
preguntarnos la generan automáticamente y claramente la cantidad es enorme, por eso existe el Big
Data para poder manejar, trabajar y procesar este volumen enorme de datos que, por su complejidad, su
gran volumen y su variedad de formatos como dijimos antes, vídeos, fotos, audios, plata, etcétera no
 pueden ser manejados (guiño, guiño) por las herramientas comunes de Business Intelligence. No puedo
trabajar con una gran cantidad de datos y la gran variedad de datos que tengo en Big Data con
herramientas de BI porque no están preparadas y no las pueden soportar.
- El problema del Big Data, principalmente es la cantidad enorme de datos, si EH, cuando hablamos del
Business Intelligence, hablamos de también un gran volumen de datos, pero en general en referencia a
hechos que pasaron en el pasado y que tenemos que tratar de interpretar hoy. En cambio cuando
hablamos de Big Data, nos referimos a datos nuevos todo el tiempo que tenemos que procesar tan
rápido como sea posible si.
- 3 Vs de Big Data: Volumen (Miles de millones de dispositivos diversos, como tambien de estructura
diferente), Variedad (muchas fuentes de datos y muchos tipos de datos distintos), Velocidad (capturar
eventos y procesarlos lo más rápido que sea posible)
- Acá nos importa más la velocidad, acá nos importa que las cosas se procesen por poner un ejemplo, si yo
estoy tratando de subir una historia de Instagram, hago clic en subir la historia. Las estructuras de datos
que se manejan acá van a privilegiar manejar muchos datos, manejar datos variables y manejar los
rápidos que garantizar la consistencia de los datos. Si una persona está queriendo conectarse a alguna
aplicación y un dato puntual, no se puede mandar, se puede reprocesar.
- ¿O con información completamente no estructurada? Tenemos todo lo que es análisis de video, digamos
el análisis de video de forma posterior, no sabes realmente qué te vas a encontrar dentro de las
imágenes de un video, sin embargo cuando los procesamos puedes llegar a encontrar datos, eso es
información completamente no estructurada.
- En semi estructurado y con una velocidad de procesamiento relativamente rápida, tenemos el análisis de
sentimientos, que es el análisis de sentimiento, así como procesados los tweets para ver las relaciones
entre los tuiteros, podemos procesar para saber si están hablando bien o mal. Dentro determinado de
vuelta el texto no es estructurado, pero podemos llegar a inferir que un mensaje es positivo o es
negativo, si es que, por ejemplo, se usa este análisis de sentimiento para identificar el bullying en las
redes sociales, si son cosas que requieren cierta velocidad a la hora de procesar los no puedes esperar
un mes para procesarlo. Tenéis que hacerlo tan rápido como sea posible como con el discurso de odio
racial.
- En Big Data vamos a procesar información tanto estructurada como no estructurada, mientras que para
lo que se lo usa en warehousing tradicional en general vamos a necesitar que exista cierta estructura, sí,
y todas las herramientas de Big Data nos van a permitir hacer procesamiento en tiempo real.
- En lo que hace de tecnologías de reconocimiento de patrones. Obviamente, como decíamos, esto de
cómo hacer para identificar determinados patrones en los movimientos bancarios o cómo hacer para
determinar si un contenido en una imagen corresponde a un determinado tópico. Si corresponde a
alguien que esta tendencias suicida, se trata de identificar cuáles son los patrones correctos, muchas
veces por medio de esta clase de técnicas de Machine Learning para identificarlo, y de esa forma,
establecer cuáles son las propiedades, agregar tags en general. Y con esos tags, hacer una gestión
diferente sobre el dato, lo más rápido que sea posible. Finalmente, algunos otros ejemplos son
interfaces de usuarios naturales que tienen mucho más que ver con la forma en que uno utiliza los
dispositivos y que muchas de esas capturas de de movimientos o de interfaces naturales del usuario
también se envían rápidamente vía Internet y son procesadas en el instante para reconocer gestos,
movimientos.
- Otras de las herramientas que tenemos el mapreduce es una de las herramientas principales, es el
algoritmo que hizo famosa Google. Básicamente la capacidad de utilizar hardware distribuido
computación en malla utilizando grandes clusters de computadoras para clasificar volúmenes de datos
en su momento de páginas web y luego recopilarlos en pequeños grupos de respuestas fáciles de
consultar. De esta forma podían procesar todos los links de un segmento de Internet y transformarlo en
una base de datos fácil de consultar a partir de palabras clave. Eso es lo que daba lugar a poder leer
 rápidamente la información, procesarla y después, en cuanto a la tenía ya poder ser consultable. Tenía
por un lado esta inclusión de grandes volúmenes de datos y por el otro la respuesta casi automática.
- Las bases de datos, nosql que son bases de datos, que justamente es su característica es que no son
transaccionales en el sentido de mantener las características ACID. Buenos ejemplos de esto son todas
las bases de datos como MongoDB, Cassandra, BigTable, donde la estructura de los datos no está
definida de antemano, sino que los datos sencillamente se suben, están súper especializadas en ser de
rápida escritura y de rápida lectura. Después, si uno quiere tener características de persistencia, de
consistencia, de aislamiento, las tiene que programar uno. Pero en principio de las bases de datos, al no
tener esas características ACID son muchísimo más rápidas.
- otra de las herramientas que tenemos es el uso de algoritmos genéticos que tratan de reflejar la forma
en la cual EH se mueven ciertos elementos biológicos para hacer combinaciones entre las estructuras de
datos y generar nuevas salidas.
- Big Data utiliza enormes volúmenes de datos, tanto estructurados como semi estructurados como no
estructurados, utiliza fotos, vídeos, sonidos, registros comunes, de texto, etcétera. Y por el contrario, BI
utiliza solamente datos estructurados, lee registros de una base de datos y los agrupa los transforma de
diferentes formas, pero no deja de cambiarles el formato de texto a texto o numérico al alfanumérico, y
permite hacer análisis de esos datos y tomas de decisiones, pero no mucho más que eso. Gran diferencia
en los tipos de datos que utiliza, una herramienta que utiliza la otra.
- Big Data utiliza enormes volúmenes de datos, tanto estructurados como semi estructurados como no
estructurados, utiliza fotos, vídeos, sonidos, registros comunes, de texto, etcétera.
Y por el contrario, BI utiliza solamente datos estructurados, los registros de una base de datos y los
agrupa los transforma de diferentes formas, pero no deja de cambiarles el formato de texto a texto o
numérico numérico del médico alfanumérico, y permite ser análisis esos datos y tomar decisiones, pero
no mucho más que eso. Gran diferencia los tipos de datos que utiliza, una herramienta que utiliza la
otra.
- Por otro lado donde se almacenan los datos.
Como dijimos BI tiene una base de datos centralizada que se llama DW, propia del concepto y la rama de
BI. Y Big Data utiliza archivos centralizados y bueno, todo lo que vimos y un montonazo de tecnologías
que no tienen nada que ver con data warehouse que tienen que soportar como decíamos arriba,
grandes volúmenes de datos y distintos tipos diferentes de datos también.
- Como funciona la lectura de datos.
Tenemos que permitir que el Big Data traiga datos online, en cambio el BI como hemos dicho, solamente
permite a los históricos, es decir, datos que hasta cierta hora se recolectan, separa y se corre el proceso
de ETL se capturan y se muestran, pero no es online ya que es más batch.
- La rapidez o la agilidad de análisis como decíamos. Big Data puede analizar diferentes datos en paralelo
por la gran capacidad procesamiento por dos temas previos y todo lo que Germán explicaba de su forma
de Trabajo de como esta pensado. En cambio la tecnología de procesamiento de Big Data, en cambio, BI
no yo no puedo estar en paralelo analizando datos y haciendo el ETL y recolectando. Yo tomo un horario
particular los datos, los transformó y los dejó, y quedan ahí planos chatos, quietitos y los voy a consultar
luego. No estoy corriendo procesos de ETL en el horario más pico, que es que se consultan los datos y no
hago varios ETL en paralelo, lo corro en un horario fijo, lo tomo, lo transformó, lo dejo y punto ahí se
queda. Y por ende por este gran motivo de estas cuatro diferencias claves, el BI no está preparado y
puedes hacer un poco de vida.
Ingeniería del software
La ingeniería del software es el establecimiento y uso de principios fundamentales de la ingeniería, con el
objetivo de desarrollar en forma económica software que sea confiable y que trabaje con eficiencia en
máquinas reales.

- Es importante, sobre todo antes de lanzarse a desarrollar una aplicación, comprender el problema y
comprenderlo de la mejor forma posible. Por otra parte, mientras más actividades quedan involucradas
o son resueltas mediante soportadas mediante software. La complejidad de estos diseños va
aumentando, entonces, hacer un diseño de forma apropiada es cada vez más importante.
- cuando hacemos estas elecciones tenemos que entender qué es lo que estamos permitiendo, es qué es
lo que no estamos permitiendo en el diseño.
- Entonces que el software funcione bien es fundamental, pero también que cuando funciona mal
funciona y lo menos mal posible, que sea fácil recuperarlo, que no se pierdan datos, que no se apague
todo.
- Para poder hacer que el software sea de calidad no alcanza con el cual hay que cumplir con todas estas
cosas que requieren la ingeniería del Software. Es decir, si ponemos mucho esfuerzo en el QA, pero
habiendo hecho un diseño paupérrimo, no importa cuánto tenemos, la aplicación va a ser mala Quality
Assurance, aseguramiento de calidad.
- Un sistema que esté diseñado con un diseño defectuoso, por más testeado que este, no va a ser de
buena calidad. QA no agrega calidad en todo caso la certifica, la verifica, pero no agrega calidad, lo que
agrega calidad es hacer un desarrollo consciente, tratando de tener siempre en claro las necesidades y
los diseños.
- Entonces, es fundamental ese enfoque, si no existe el compromiso con la calidad. De ahí en adelante,
todo lo demás empieza a tener digamos, cimientos poco sólidos.
- Entonces, decía, los procesos van a ser eso: cuáles van a ser las tareas o los conjuntos de tareas que
tenemos que garantizar que vamos a desarrollar.
Los métodos, Por otra parte, van a ser como vamos a hacer ese conjunto de actividades, el paso a paso si
se quiere acá vamos a estar hablando de tareas de análisis, cuáles van a ser esas tareas de análisis las
formas de relevamientos, las formas de comunicación que modelos vamos a desarrollar cuando estemos
haciendo los modelados estamos dentro de la ingeniería de software.
- Lo importante es que definamos eso. ¿Cuáles van a ser los modelos que vamos a querer hacer para
garantizar que el diseño sea coherente una vez que lo hacemos? ¿Cómo vamos a construirlo? ¿Qué
técnicas vamos a usar para desarrollar?
¿Qué técnicas vamos a usar para las pruebas? ¿Qué tipo de pruebas vamos a realizar y cuáles van a ser
todas las actividades de apoyo relacionadas finalmente?
Vemos la necesidad de la selección de herramientas, las herramientas van a ser aquellas que nos ayuden
a automatizar estas actividades o darles un soporte.
- Sobre todo creo que es la parte más complicada es separar lo que es proceso de métodos, pero me
parece que queda claro, los procesos son de vuelta, algo más genérico, tareas que son como conjuntos
de tareas, cosas que tenemos que ejecutar sí o sí en algún punto, mientras que los métodos son la forma
en la cual vamos a ejecutar esas cosas.
- No importa que tan grande sea el proyecto siempre es fundamental tener en claro cuáles van a ser las
tareas de comunicación a realizar. No importa que tan grande sea el proyecto siempre es indispensable
hacer tareas de modelado. A eso nos referimos cuando hablamos de acciones, hablamos de cómo
hacemos esas actividades de forma que se tenga bien claro un producto, una salida, un output
esperable. Entonces, por ejemplo, podemos hablar de cómo dice ahí, una instancia en la cual estamos
 tratando de entender los requerimientos, un análisis de requerimientos que tiene que dar algo (por
ejémplo un documento, una lista de requerimientos de alto nivel o detallada, etc.)
- Esta entrada en el detalle, esta bajada a tierra de cada una de las actividades. E insisto, la gracia de los
procesos es que son genéricos y, por lo tanto, no importa cómo estamos organizando nuestro proyecto,
no importa el tamaño de nuestro proyecto, deberían existir siempre si queremos de vuelta, si queremos
hacer que nuestro software sea software de calidad que se ha producido de una forma relativamente
económica y que funcione en entornos reales
- Planificación, modelado, construcción y despliegue, sí que son las actividades de comunicación, todas las
actividades que tienen que ver con comunicar a los distintos participantes. Parte de las actividades de
comunicación van a ser, por ejemplo, los análisis de requerimientos, que no son otra cosa que una
comunicación entre usuario y desarrollador o equipo de desarrollo, si quieren generar las hacen
analistas. Parte de la comunicación es poder dejar en claro las expectativas, que es lo que el usuario va a
poder esperar hacia el final del proyecto hacia el final del desarrollo del software.
- Normalmente, actividades de planificación son de las primeras, pero se siguen ejecutando. Lo largo de
todo el proceso. Por eso insisto, acá lo vemos como una línea, pero esto no tiene por qué ser así. Lo que
sí estamos seguros que todos los procesos, proyectos, todos los desarrollos del software deben tener
estas actividades en algún punto, si no se tienen el riesgo. Que la calidad del software sea baja es muy
alto, actividades de modelado que tienen que ver con una vez que entendimos el problema, imaginar,
diseñar y bajar a papel posibilidades de resolver y elegir las mejores.
- La construcción, que es efectivamente el desarrollo en sí y las actividades relacionadas con verificar que
ese desarrollo está andando bien y finalmente actividades de despliegue. Las entidades que tienen que
ver con llegar de El entorno de desarrollo de nuestro ambiente interno donde estamos haciendo las
cosas a un ambiente real. Del usuario o un servidor o donde sea que esté en un ambiente real dejarlo
funcionando y listo para que alguien lo pueda utilizar. ¿OK? Sin todos estos pasos no hizo fue. Por eso les
decimos actividades estructurales.
- La construcción, que es efectivamente el desarrollo en sí y las actividades relacionadas con verificar que
ese desarrollo está andando bien y finalmente actividades de despliegue. Las entidades que tienen que
ver con llegar del entorno de desarrollo de nuestro ambiente interno donde estamos haciendo las cosas
a un ambiente real. Del usuario o un servidor o donde sea que esté en un ambiente real dejarlo
funcionando y listo para que alguien lo pueda utilizar. ¿OK? Sin todos estos pasos no hay software. Por
eso les decimos actividades estructurales.
- Respecto a las actividades de modelado, vamos a tener que tomar esas cosas que obtuvimos en los
análisis de requerimientos y empezar a pensar en estos modelos, diseñar los diagramas de datos si los
diagramas de entidad, relación diagramas funcionales como pueden ser los de Fede y habrá más de
flujos de datos o porque no diagramas de actividad, diagramas de secuencia, EH? Por qué no también
diagramas arquitecturales, no como diagramas de componentes.
- Entonces no solamente es una cuestión de género del Código, sino también de generar las interfaces de
usuario, por ejemplo, las pantallas, probar todo, verificar que todo esté funcionando, armar las
configuraciones, sí, y finalmente el despliegue que va a ser ponerlo funcionando dentro del cliente o
dentro de la nube donde haga falta. Hacer soporte a eso, sobre todo el primer tiempo y una vez que se
termina hacer una evaluación del proyecto, que es algo más si quiere funcionar lo de gestión creo que
no deja de ser bastante importante entender qué es lo que pasa una vez que desplegamos, OK
- Porque es resulta importante, porque si gestionamos los riesgos identificados evitamos retrasos,
evitamos retrabajo, mantenemos bajos los costos. Sí, lo que es el control de avance del proyecto,
garantizar que estamos bien, que estamos avanzando y que no está habiendo retrasos, todo el
seguimiento las actividades de aseguramiento de la calidad, hay un conjunto de tareas que son las
pruebas sobre el código.
- La capacidad de reutilización de distintas librerías. Cuando nosotros programamos muchas veces nos
encontramos con que resolvemos muchas veces los mismos problemas, bueno. Si se resuelven muchas
veces el mismo problema, lo ideal es resolverlo una sola vez y usar siempre lo mismo, tener alguien que
haga algo de gestión de la reutilización también es bastante importante para reducir tiempos y costos, y
finalmente todo lo que es la preparación y producción de los entregables de los productos del trabajo.
¿Seguimiento de cómo se mide? ¿Qué es lo que estamos haciendo? De vuelta estas actividades no nos
dan software funcionando, pero hacen que el software funcionando funcione mejor y que el trabajo del
equipo sea mejor y más fácil, como son actividades que se encargan de cubrir las actividades son
estructurales, es por eso que las demás entidades sombrilla
- Tenemos los distintos modelos que efectivamente van a ir implementando estos distintos flujos que
veíamos antes. El modelo en cascada, como se puede ver, es la implementación directa del modelo del
flujo lineal. Sí, ese es el ciclo de vida clásico, es el primero que se diseñó en cierta forma el que está en
este Paper que les comentaba de una persona que, como las ideas de ingeniería y dijo, Hagamos
exactamente lo mismo y es súper interesante porque el tipo cuando escribió ese pero ella en el 60 y pico
dijo, ojo, que si hacemos esto va a salir todo mal y la gente cuando llegue al pero se olvidaba de esa línea
y simplemente un montón cuando esta persona ya había entendido que el desarrollo de software no
puede ser tan lineal. Tiene sentido a veces si hay ciertos proyectos en los cuales tiene sentido la esencia
del modelo en cascada es que cada etapa se desarrolle una sola vez en el momento que corresponde y
que las etapas posteriores tengan que esperar.
Entonces, primero hacemos la etapa de inicio del proyecto y todo el análisis de los requerimientos y
cuando lo entendemos hacemos una estimación y una planificación, y programamos todo lo que vamos
a hacer una vez que tenemos esto listo, pasamos a hacer los modelos y cuando los modelos están
completamente cerrados, hacemos la construcción.
¿Cuándo tiene sentido un modelo de este estilo? Cuando las características del proyecto y del problema
son muy fáciles de comprender o se tiene mucho conocimiento de cuáles son y que la estabilidad de las
condiciones tiene sentido, por ejemplo, en el desarrollo de.
- Tenemos otro modelo, que es como una serie de mini cascadas que es el modelo incremental, donde lo
que tratamos de hacer es separar todo el conjunto de requerimientos que también tienen que estar
relativamente bien definidos en pequeños mini proyectos. Y cuando terminamos uno podemos empezar
el que sigue. Fíjense que hay una etapita y en el medio donde se empiezan a solapar, tiene que ver con
la liberación de los recursos para cuando los desarrolladores están cerrando el proyecto, ya los analistas
están medio libres y pueden pasar.
- Base a prototipos. ¿Cuál es la idea de los modelos de prototipos? Que uno rápidamente cuando está
haciendo la etapa de análisis de requerimientos y tratando de comprender el problema, genera un
prototipo. Este prototipo no es un sistema funcionando, no es código listo para ser utilizado, es apenas
una maqueta. Pero que alcance como para ir con quienes tienen las necesidades con nuestros clientes,
con los especialistas, con quien sea, que está en condiciones de decirnos si esa maqueta tiene sentido
mostrársela y que nos diga esto, si esto no cambia de estas cosas. Si esa es la idea de un modelo
evolutivo por prototipo, hacemos evolucionar el prototipo porque es algo barato de construir, y
después, cuando tenemos todo bien detallado, pasemos a ejecutar una especie de versión con los
requerimientos mucho más claros, pero más lineal, entonces se itera sobre el prototipo hasta definir
hasta refinar. Los requerimientos y después se puede construir tranquilo sabiendo que hay 1 que hay de
alguien no sería cómo armar demos por qué, porque vos, cuando armas demos estás hablando de un
modelo que ya está funcionando. La idea de los prototipos es que se tiren a la basura.
Es muy útil para cuando la definición inicial de los requerimientos es un poco laxa, digamos cuando el
cliente no está del todo seguro de cómo quiere resolver las cosas.
- La idea del modelo evolutivo en forma de espiral es hacer constantemente evaluaciones de riesgo y
entregas. Entonces lo que tenemos son las mismas etapas que en el anterior. Fíjense que cada 1 de los
 sectores de la espiral tienen los nombres de las de las actividades estructurales en la cual hacemos un
conjunto de análisis y actividades de comunicación, de entendimiento de los requerimientos, se planifica
algo corto, se modela, se resuelve. Se entrega y se frena la pelota y se hace una evaluación de si vale la
pena seguir o no. La idea del modelo en espiral es siempre la evaluación de riesgos, si vale la pena hacer
una integración adicional o no. Entonces acá lo que se entrega es un producto de calidad, a diferencia
del prototipo que era una porquería, pero porque estaba diseñado para ser una porquería. Acá se
entrega un producto de calidad y al entregar ese producto se evalúa si conviene o no seguir
construyendo encima de ese producto. Cada ciclo hace crecer el producto, por eso es la idea de una
espiral.
- De las que estamos hablando ahora de las primeras cosas, seguirán en un papel que se publicó en el 95.
Los primeros pasos formales, no donde había dos personas que poseen un marco de trabajo que sé que
vamos a enfocarnos capaz hoy nosotros, pero hay muchos más que se llama scrum y éste empuja las
nuevas metodologías se termina de cerrar el 2001 con el famoso manifiesto ágil, que el manifiesto ágil
básicamente lo que hace son, se juntan de 7 personas líderes en el planeta con el mundo de
metodologías y definieron 4.4 principios clave que cualquier metodología ágil no importa, el modelo o el
marco que estemos trabajando. Scrum Kanban XP a todos los que vamos a ver después tienen que
cumplir, lo primero es que las personas y las interacciones van primero en lugar de procesos y
herramientas, acá cuando decimos van primero, no es que por eso sí herramientas no sirven la
metodología hablando las iba a fomentar o va a priorizar y poner en primer lugar a las personas y a las
interacciones. En vez del proceso y las herramientas no es que no las tenga en cuenta, sino que las
priorice las pone en primer lugar lo mismo con el software. La metodología es ideal y generar software
funcionando.
- Y se tiene como importante, como prioritario, colaboración, ida y vuelta constante con el cliente
constantemente en contacto, hablando con el cliente mostrándoles nuestro avance en vez de darle
tanta importancia a un papel gigante con las horas que vamos.
A trabajar los costos, etcétera, no significa vuelva a repetir que ninguno de los puntos de la derecha
existan, sino que son menos prioritarios o se le dan menos enfoque o valor.
Y por último, obviamente, porque se crea la metodología es porque tenían algo que respondiera más
fácil al cambio entonces priorizamos responder al cambio en lugar de seguir un plan. No es que no
sigamos un plan pero las cosas pueden ocurrir.
Apunta decir que dice, personas interacciones en lugar de procesos sobre funcionando en lugar de
documentación. Todo lo que viene después del lugar de que son los que están más a la derecha no es
que no exista en la metodología ágil, sino que no se le da tanto valor tanto como a los puntos de la
izquierda, que es donde realmente pone foco este manifiesto ágil. Las metodologías ágiles cualquiera
sea de las que estemos hablando.
Y por último, espero responder al cambio en lugar de seguir un plan. Esta metodología se crearon,
fueron empujadas o, nacieron para este para responder rápido a un cambio, no esperar que haya un
cambio. Y yo planear, planificar, te hago un prototipo, entonces te lo entrego en 2 o 3 años. Si hay un
cambio, lo agarramos, salimos adelante, no deja de existir los planes, pero se le pone foco en la salida
rápida en cuanto a los cambios que pueden surgir.
- Personas interacciones en lugar de procesos y herramientas. Software funcionando en lugar de de
documentación.
- Desarrollo incremental y reducción de gastos, que es lo que veníamos dejándonos y que los acababa de
contar con un ejemplo que pasa con las metodologías más tradicionales de desarrollo de la ingeniería de
software, que desarrolló hasta que no estaba terminada.
- Redujo costos, así que eso es una característica clave de la metodología que hace entregas pequeñas y
todo el tiempo constante en un cierto periodo de tiempo que ya vamos a ver cómo se define y me
 permite reducir tiempo, idealmente costos. Porque tengo todo el tiempo del pasado ocupada, no tengo
que después cambiaron un montón de cosas. Cuando me entero que está todo mal al final.
- Constantemente hay un compromiso (ojo es muy importante la palabra compromiso en la metodología
ágil), donde yo me comprometo valga la redundancia, a entregar constantemente y frecuentemente
resultados. Yo me comprometo a hacer 10 cosas en el período de tiempo que definimos con la
metodología bueno, a fin de ese tiempo, estas 10 cosas yo me comprometo a entregarlos. Y
constantemente el equipo está entregando resultados, hasta a veces no se espera a 6 días y se van
entregando a medida que se van haciendo entonces la entrega frecuente y constante de resultados y de
cosas terminadas, para probar, testear y seguir. Como decía el compañero, el proceso hasta llegar a la
producción. Constantemente todo el tiempo estamos trabajando y entregando material, siempre en el
agile.
Simplicidad como yo agarro cosas chiquitas (se supone que agarro cosas chiquitas, o no tan gigantes) las
desmenuzo las voy entregando constantemente. La forma de trabajar de la metodología es simple, yo
me comprometí.
Las vas haciendo, tiene definido su alcance, tiene definido hacia dónde llega, tiene definido que entregar
entonces la manera de trabajar de agile es simple, no hay burocracia, un montón de documentos y cosas
para hacer.
No debería ser engorroso ni burocrático. Si se convierte en engorroso y burocrático no estamos
aplicando bien la metodología ágil, que es lo que suele pasar en muchos lados.
- El equipo es fuertemente a nivel técnico, motivado y coordinado. Todo es mente en los equipos que
trabajan.
- La característica y el objetivo de una metodología ágil cualquiera fuera su modelo es entregar algo que
funcione. La entrega, lo importante es que tengo software probalo y funciona. La documentación, el
análisis, va a estar. Pero un documento muy chiquito o muchas veces se considera al software en sí
mismo, al código, la documentación.
El código muchas veces, el software funcionando es también considerada la documentación, por eso
decimos que está en un segundo plano. No es que no exista, pero no van a ver a comparación de
metodología tradicional, como veíamos antes, documentos de documentos detallados, documento
técnico, documento analítico, Funcional. No, a lo sumo, acompaña un documento de pruebas muy
chiquito o algún guarde una o dos hojas o pdf con verificaciones muy técnicas y nada más. Se hace la
documentación justa y necesaria, no se pierde tiempo en grandes papeleos y burocracia.
- Rápida respuesta a entornos cambiantes. Como dijimos, uno de los grandes impulsores de estas
metodologías es esto que si venía un cambio lo pudiéramos trabajar enseguida, no tuvieramos que estar
analizando si podemos, si no estamos preparados, no. La metodología agil por el equipo que es porque
técnicamente por la forma en la que trabaja, que simple sin tanta burocracia o documentación, por las
entregas que tiene, como va definiendo el tiempo, ya vamos a ver cómo define y cómo organiza el
tiempo. Siempre se guarda un espacio para cosas que vengan de prepo o escenarios cambiantes o cosas
que haya de cambiar sin ningún tipo de antelación. Entonces siempre está preparado el equipo y la
metodología para recibir cambios que sean inesperados y poder hacerle frente y sacarlos enseguida
funcionando. El alcance y logros por etapas, pasa a ser entregas frecuentes e incrementales. Yo voy
alcanzando mis logros por etapas, y no espero hasta el final del desarrollo de una aplicación para
entregarla, voy entregando cada sprint o cada período una funcionalidad diferente que va sumando a la
anterior. Entonces, todo el tiempo voy alcanzando mis logros porque defino etapas más chicas para
poder alcanzarlos continuamente y hacer entregas que frecuentes después también facilitará el
reemplazo laboral si se supone que el equipo está fuerte a nivel técnico, que todos saben manejar todas
las herramientas y tecnologías que utilizan para desarrollar en la empresa en la que estén x cosas, no
importa cuál fuere. Si alguien se me va, los que están enseguida van a poder reemplazar sin que se note
ese hueco o esa falta de conocimiento, porque se supone que el equipo que trabaja en agile es un
 equipo fuerte a nivel técnico, que todos conocen al pie de letra las herramientas tecnológicas en las que
están trabajando. Por último, la participación activa del cliente, como dijimos en la primera filmina que
ellos priorizan y defienden el contacto y diálogo constante con el cliente.
- Acá enseguida todo se destraba porque el diálogo con el cliente es constante y activo, entonces es
mucho más sencillo que estén al tanto de todo y cualquier problema que tengamos como equipo de
desarrollo, enseguida podremos cazar un teléfono hacer un chat y lo podríamos solucionar.
- Rápida respuesta a entornos cambiantes. Como dijimos, uno de los grandes impulsores de que estas
metodologías existan es esto que si venía un cambio lo pudiéramos trabajar enseguida, no tuvieramos
que estar analizando si podemos, si no estamos preparados, no. La metodología agil por el equipo que es
fuerte técnicamente por la forma en la que trabaja, que es simple sin tanta burocracia o documentación,
por las entregas que tiene, por como va definiendo el tiempo, ya vamos a ver cómo define y cómo
organiza el tiempo. Siempre se guarda un espacio para cosas que vengan de prepo o escenarios
cambiantes o cosas que haya de cambiar sin ningún tipo de antelación. Entonces siempre está preparado
el equipo y la metodología para recibir cambios que sean inesperados y poder hacerle frente y sacarlos
enseguida funcionando. El alcance y logros por etapas, al hacer entregas frecuentes e incrementales yo
voy alcanzando mis logros por etapas, y no espero hasta el final del desarrollo de una aplicación para
entregarla, voy entregando cada sprint o cada período una funcionalidad diferente que va sumando a la
anterior. Entonces, todo el tiempo voy alcanzando mis logros porque defino etapas más chicas para
poder alcanzarlos continuamente y hacer entregas frecuentes después también facilitará el reemplazo
laboral. Si se supone que el equipo está fuerte a nivel técnico, que todos saben manejar todas las
herramientas y tecnologías que utilizan para desarrollar en la empresa en la que estén x cosas, no
importa cuál fuere. Si alguien se me va, los que están enseguida van a poder reemplazar sin que se note
ese hueco o esa falta de conocimiento, porque se supone que el equipo que trabaja en agile es un
equipo fuerte a nivel técnico, que todos conocen al pie de letra las herramientas tecnológicas en las que
están trabajando. Por último, la participación activa del cliente, como dijimos en la primera filmina que
ellos priorizan y defienden la el contacto y diálogo constante con el cliente.
- Acá enseguida todo se destraba porque el diálogo con el cliente es constante y activo, entonces es
mucho más sencillo que estén al tanto de todo y cualquier problema que tengamos como equipo de
desarrollo, enseguida podremos cazar un teléfono hacer un chat y lo podríamos solucionar.
- Y a cambio, ese compromiso que el equipo de desarrollo. Asume cuando el po le pide, por ejemplo,
hacer un nuevo ETL. El PO se va a comprometer a no cargar de trabajo en el período del sprint que se
definió al equipo de desarrollo con cosas nuevas, porque las palabras clave de la metodología es que ese
compromiso en ese periodo de tiempo que como decía Germán 15, 21, 28 días, el equipo se
compromete a entregar 10 cosas, entonces el equipo se compromete a hacer las 10 de forma completa y
correcta, pero el po se compromete a no ponerle 11 cosas a ponerle 10 y mantenerse con esas 10. Ese es
el rol del po. Generalmente está asumido por personas con habilidades y características como por
ejemplo la comprensión del negocio, habilidades muy fuerte de comunicación, etcétera, pues una
persona que tiene el conocimiento del negocio, se tiene que dar la vuelta y darlo a explicar de modo
técnico al equipo de desarrollo.
- Scrum máster o también conocido como facilitador de proyectos, es la figura que sabe de pe a pa la
metodología ágil es el que lidera los equipos en todo lo que es la gestión del proyecto ágil. La misión,
básicamente de scrum máster es que el equipo alcance el objetivo hasta llegar al final del período, que
se definió que se llama Sprint.
Y cualquier duda o dificultad que pueda encontrar en el camino el Scrum Master va a ser la persona que
lo tenga y que lo pueda solucionar, porque es el facilitador de las metodologías de que tiene
conocimiento, de que certifico en agile sea el modelo que sea y que sabe cómo se maneja la
metodología y cuáles son los pasos a seguir.
- Los team members o el equipo de desarrollo. Son básicamente quien tienen la responsabilidad de
entregar el producto. Es recomendable según la teoría, obviamente que esto puede cambiar y adaptarse
a cada empresa. Un pequeño equipo de entre 3 y 9 personas, no mucho más con las habilidades
transversales entre ellos. Necesarias para realizar el trabajo de forma completa, es decir, que todos
sepan cómo hacer un buen análisis, un diseño, un desarrollo, que puedan hacer las mismas pruebas que
se necesitan para pasar el producto a la parte de testing.
- User stories, las vamos subiendo a los periodos definidos para empezar a tomarlas y trabajarlas ese es el
concepto de backlog básicamente. Una lista de trabajo pendiente que lo carga generalmente el product
owner (o el scrum master)
- En la grooming se vota el grado de dificultad y tiempo que nos va a llevar realizar estas tareas. Cómo se
define estos puntos en consenso con el equipo es algo muy democrático, eso está bueno de la
metodología ágil con sesiones de grooming donde se dice acá se pone el número de historia, por decir se
cuenta que hay que hacer y todo el equipo vota en una pagina el puntaje que tiene. El punto que más
gana o que más votos saca ese es el puntaje que se le pone en esa story y que va a representar el tiempo
y la dificultad.
- No son o no deberían ser actividades personales, son actividades del equipo.
- Y ahí se define la planning que se sube y quién toma cada cosa. Previamente ya punteada en la
grumming exactamente.
- Después, la realidad es que son sesiones diarias, como dice la palabra Daily, reuniones diarias que no
deberían ser de más de 15 minutos donde se va diciendo cómo va el avance de cada user story.
- Como dice la palabra daily, reuniones diarias que no deberían ser de más de 15 minutos donde se va
diciendo cómo va el avance de cada user story.
No se discute ahí cómo resolverlo, no se discute ahí porque se trabó, no se buscan responsabilidades,
nada. Si hay un problema, después se agenda una reunión aparte con quien corresponda.
Donde el equipo toma un minuto y medio, dos cada uno y dice que hizo ayer y qué va a hacer hoy y si
hay algún bloqueante, es el momento de levantarlo porque en las dailis y en todas las reuniones de estas
ceremonias del agile, siempre está presente aquí el cliente, escuchando qué estamos haciendo, que
entregamos, que nos falta entregar, que avance tenemos, y si hay algún bloqueante es el momento de
levantarlo para que lo puedas solucionar y que podamos continuar el trabajo.
- Si yo no llego a terminar mis historias antes de fin de sprint, el equipo me tiene que ayudar y
comprometerse a entregarlo, porque compromisos general del equipo y no de cada 1 de las personas
que conforman el equipo en sí mismo exactamente.
- Después tenemos la retrospectiva rápidamente, la retro es una ceremonia, una reunión que se hace a fin
de sprint. Donde se revisa que estuvo bien, que estuvo mal si se llegó a entregar todo o no hay por qué y
se anotan puntos de mejora para el sprint o el período que sigue, son siempre ceremonias de mejora,
donde se analiza qué pasó, si hay un problema o no, si nos demoramos en una entrega o no, si está
justificado o no y se detecta que estuvo bueno, se felicita, que estuvo mal y se mejoró, es como una
sesión de terapia de fin de período de o de sprint, de entrega de trabajo.
- Las user stories tienen que ser historias pensadas en términos de negocio, es decir, tienen que explicar
qué es lo que se necesita, no detallando qué es lo que hay que hacer, sino explicando que necesita a
alguien para conseguir algo. Mi idea es que tiene que tener siempre las 3 características: quien lo pide,
qué es lo que pide y por qué lo pide. Entonces normalmente se estructuran: “como usuario quiero poder
ver el listado de las llamadas de los últimas de la última semana para poder obtener listados de
performance” tiene que quedar bien claro eso y no tiene que ser mucho más complicado que eso una
user story. Las tareas se usan para cuando entendemos cuáles son las implicancias de eso, agregar todos
los pasos que nos implica tener ese listado 1 de los pasos va a ser construir el reporte, otro de los pasos
va a ser actualizar la base de datos para mostrarnos qué cosas, otro de los pasos de hacer ejecutar la
 prueba. Cada tarea lo va a hacer alguien que puede ser el mismo o no, pero lo que importa es que la
user story debe quedar bien claro que beneficio le trae al negocio
- Las user stories se pueden dividir en subtareas. Por ende yo puedo aperturar la user story y decir hoy de
esta user story hice la tarea uno y dos, que es, por ejemplo, conectar la base de datos y crear una tabla
el día de mañana hice la tarea tres y cuatro.
- los puntos o los story points son básicamente, cada punto va a representar la estimación en tiempo y en
dificultad que me lleva a hacer esa tarea.
-
- Demo: para una vez que terminó el SPRINT hago una historia cualquiera y las muestro en vivo para que
se vea que lo que se hizo funciona y se entregó correctamente.
- El ciclo de liberación del agile. Como dijimos, seleccionan una historia de usuario para liberar,
seleccionan una historia del backlog, elijo una de esas stories, la subo al Sprint que arranca o al periodo
que arranca para hacerla. La desgloso, como decía Germán, en tareas más chicas. La estimo y la planifico
en la grooming. Arranca el sprint la empiezo a desarrollar la integro y hago las pruebas una vez que la
termine de desarrollar, integre, hice las pruebas básicas, libero el software a la gente de testing, el cual
lo evalúa, y si está todo OK, pasa a producción y así continúa de vuelta al ciclo.
- Como veis, un ciclo muy sencillo para nada burocrático, donde yo he visto una historia. Le definen las
tareas más chicas para hacer paso por pasito, la estimo y la punteo. Arranca el sprint la desarrolló la
pruebo, funciona bien, y lo liberó para producción y se vuelve. Sencillo, simplicidad. La clave de la
metodología.
- Es trabajo del Scrum Máster Garantizar que el product owner no se meta agregar nuevas cosas, si se
agregan, es evidente que no se va a llegar. Que pasa si se termina el sprint una semana antes, no debería
pasar, hicimos todo mal si se termina una semana antes.
- El equipo puede estar tentado a tomar el camino más corto para sumar puntos, en decir o hace todo
más o menos como sale entrega rapidito y dale que va y después el tester que lo pruebe. Si falla viene
por retest y no pasa nada. O el equipo si no está bien controlado y el product owner y el cliente no tiene
un buen conocimiento técnico, puntea todo muy alto para tener un tiempo. Ni siquiera te digo sabana
de descanso, sino un tiempo considerable donde 1 pueda tomar un café y respirar sin que esté pisando
los puntos atrás. Por qué sucede entonces, si puede pasar lo que dice junior, generalmente en los
equipos mejores que eso no pasa. Todos tienen unos minutos de todos, te controla mucho y el equipo
termina siendo la segunda.
- Las personas enfermaron que puede pasar en un equipo y no hay forma de que el resto del equipo los
cubra. Se tiene que poder discutir con el producto owner cuáles son las historias que quedan con más
prioridad y descartar las otras. Y pasan el siguiente sprint.
Administración de proyectos
- Emprendimiento temporario que tiene un principio y tiene un fin, es temporal no puede ser algo
sostenido al infinito. Por otra parte es un emprendimiento temporario para crear un único producto o
servicio. Tiene que tener una naturaleza única por sus características, por su forma de ser, tiene que ser
único el resultado. Puede ser un producto en el sentido físico puede ser un producto en el sentido más
etéreo como es el software. Puede ser una recomendación, o sea un proyecto puede ser hacer una
evaluación de algo y presentar un documento. Lo que importa es que por sus características, si dos
grupos diferentes hacen el mismo proyecto no deberían necesariamente llegar al mismo resultado, ya
que es único. Se hace y se termina, un comienzo y un fin. Sí es importante tener en cuenta que un
proyecto puede ser realizado de forma progresiva en etapas
- La apertura de un negocio bien porque es un proyecto abrir un negocio aquí en el marco temporal hay
un límite de tiempo, un inicio y un fin. Cuando estamos abriendo un negocio, desde que decidimos
hacerlo hasta que logramos la inauguración todo eso puede ser la ejecución del proyecto de apertura, y
si se quiere por ahí un par de meses hasta la consolidación. El resultado es único, es tener el negocio
abierto, es haber definido: negocio, modalidad de operación, marca, cómo va a ser la apertura. Cubierto
las operaciones y la idea de cómo va a funcionar, una vez que se termina esa parte, entonces empieza a
funcionar el negocio.
El proyecto de ahí en adelante (la gestión de ese negocio) son operaciones, no tienen una naturaleza
proyectual porque no tienen un fin. La idea es que no se terminen (las operaciones) y no van a ser
únicas, ya que cada vez van a ser exactamente igual a las anteriores al menos en su forma de hacerlas. Sí
podría volver a ser un proyecto si es que van a salir cosas nuevas, por ejemplo si van a desarrollar un
nuevo mercado y queremos dejar de vender solo panchos y empezar a vender empanadas. La manera de
como vamos a hacer esa comercialización de empanadas va a ser un nuevo proyecto hasta que logremos
estabilizar (esa diferencia es súper importante)
- Los recursos van a ser cuando personas como dispositivos como tecnología. Todos aquellos elementos
de los cuales podemos disponer para lograr los objetivos propuestos por el proyecto, tenemos separado
de esto a lo que son las erogaciones de dinero que las tenemos asociadas a los costos, que en principio
se supone que el dinero es un recurso más por una opción de los recursos. Principalmente en tecnología,
son casi siempre en su mayoría personas, pero hay un montón de otros recursos a disponibilidad,
después están los costos (gastos que vamos a tener que hacer). En cada etapa de un proyecto vamos a
tener gastos diferentes, al inicio de un proyecto vamos a tener gastos más en el lado de lo que son
investigaciones, ideas, discusiones.
En el medio del proyecto vamos a tener un montón que tiene que ver con el pago de proveedores, por
ejemplo, que al principio no están: de adquisición de materiales, de adquisición de tecnología,
dispositivos, los pagos propios del personal asociado al proyecto también. Hacia el final vamos a tener
otros como por ejemplo gastos para un producto que sale del mercado: gastos de publicidad, gastos de
verificación de calidad, de corrección de problemas (en caso de que los haya). Pero los costos, sino que
las tenemos ahí en general se consideran todos los movimientos de caja del flujo de caja donde
asociados a las tareas del proyecto.
Otro de los elementos más importantes es el de administrar el tiempo, dijimos que la idea de un
proyecto es que tiene un principio y un fin. Entonces tener una gestión apropiada de en qué momento
se hace cada tarea ayuda a mantener de forma clara la fecha de fin y que ésta no se extienda más allá de
las expectativas. La gestión de las expectativas es fundamental: ¿qué es lo que esperan quienes estamos
pagando el proyecto? Finalmente, quienes están bancando políticamente al proyecto (en el buen
sentido de la palabra política), ¿qué esperan como resultado y en cuánto tiempo? Bueno eso es
fundamental, la gestión del tiempo para mantener esas expectativas vigentes y que no sean
desmesuradas es fundamental. Cuando hablamos de alcance de un proyecto estamos hablando de qué
 es lo que vamos a incorporar, qué es lo que vamos a hacer, qué es lo que vamos a entregar. Tiene que
quedar clarísimo el acuerdo asociado a nuestro tiempo, mientras más amplio sea nuestro alcance más
tiempo nos va a llevar y más costosos para asumir. Entonces definir y gestionar de manera muy clara
cuál es el alcance del proyecto también es muy importante. La calidad, cuando estamos gestionando
proyectos también debemos tener en claro que es la calidad que esperamos y cómo vamos a hacer para
gestionarla. No significa necesariamente que tenemos que estar 100% comprometidos con la excelencia,
en la calidad, ya que muchas veces podemos estar dispuestos a aceptar una calidad menos que
excelente y hasta mediocre en tanto en cuanto sea claro para nosotros que es lo que queremos. Lo que
tenemos que hacer es tener definido lo que en realidad queremos y hacer todo lo necesario para
garantizar la calidad a la que nosotros nos comprometemos. Lo principal para esto es definir qué es la
calidad y definir qué tareas y que costo vamos a tener asociados a la gestión de la calidad.
- Los objetivos están dentro del alcance, los objetivos planteados deben ser cubiertos con todas las
actividades que se desarrollan en el proyecto. Si los objetivos cambian, cambia el alcance, y si el alcance
cambia los objetivos pueden verse afectados.
- Sobre administración de proyectos como dijimos son un montón de técnicas herramientas métodos que
tienen por principal objetivo tratar de entender estos puntos. Por un lado, teniendo en cuenta cuáles
son los objetivos del proyecto saber qué es lo que hay que hacer para cumplir con esos objetivos,
cuando hay que hacerlo garantizar la orquestación de todas las actividades y pasos, cómo con qué
técnicas, métodos, herramientas y recursos. Administrar los proyectos por empezar es tratar de
entender eso, qué hay que hacer, cómo y cuándo hay que hacerlo, y a la hora de hacerlo garantizar que
estén todas las condiciones dadas para que eso se haga de una forma sin fisuras, sin fricciones, sin que
haya resistencias. Después una vez que tenemos definido todo eso armar un plan una cronología o
imaginar alguna forma de cronología, y empezar a ejecutarlo y controlar que las tareas que creemos que
van a hacer en determinado momento se ejecuten. Garantizar que se hacen las cosas, que se hacen
cuando hay que hacerlas, y que se hacen bien bajo los costos que se estima que hay que hacerlas.
Recordemos que, en la mayor de las veces, armar un proyecto es hacer un poco de futurología, es
pensar como creemos que van a ser las cosas, y después cuando empecemos a ejecutar nos vamos a
encontrar con una realidad que no siempre es la que queremos (ahí entran todos los riesgos que se
materializan). Entonces parte de la primera etapa de la administración de proyectos es armar el plan.
Una vez que se arma el plan éste se ejecuta, y a medida que se va ejecutando se va controlando, viendo
que se cumple, que no y por qué. Por otra parte, todos los proyectos van a tener un equipo de trabajo,
algo que sea un proyecto completamente impersonal siempre hay que coordinar. Dentro de la
coordinación hay un elemento de organización que es garantizar que todas las partes saben lo que están
haciendo las otras, y que se conocen cuáles son las dependencias, pero también de supervisión.
Mantener un monitoreo para garantizar que quien tiene que hacer algo esté enterado y que lo haga
efectivamente porque el resto lo van a estar esperando. Por otra parte, esta cuestión de administrar los
recursos, es decir, si un proyecto tiene distintas etapas y en la tercera etapa se supone que vamos a
tener disponible un recurso crítico, garantizar que ese recurso este.
- “La optimización ocurre cuando uno hace muchas veces lo mismo y empieza a entender qué funciona y
qué no estamos hablando de proyectos muchas veces la naturaleza única de los proyectos hace que la
optimización sea un concepto por lo menos polémico.”
La idea es que los administradores de proyectos que tienen mucha experiencia (se supone) en gestionar
personas, recursos, y que entienden cómo funcionan las organizaciones, deberían poder optimizar los
recursos para garantizar que la productividad sea máxima, que los costos sean mínimos, reducir los
riesgos e incertidumbres.
En el caso de sistemas, por ejemplo, si nuestro proyecto requiere 3 desarrolladores, pero al principio es
uno solo porque hay que hacer toda la parte de back end, y después vamos a necesitar los 2 de front end,
no contratamos a todos desde el principio. Los contratamos recién cuando los necesitamos o buscamos
 algún área que los tenga medio ociosos, otro proyecto que está cerrando para no traer todos los recursos
de una a gastar, a generar costos al pedo. Los ponemos en el momento en que es necesario.
- Respecto a lo que tiene que ver con la gestión y coordinación de los cambios los proyectos como dijimos
de vuelta van a tener una misión final desde que se empieza el proyecto y tenemos una idea de cuáles
van a ser los objetivos hasta que llegamos a este fin pueden cambiar las opiniones, pueden cambiar las
necesidades pueden cambiar las tecnologías. Entonces en muchas oportunidades va a haber alguien que
quiere cambiar algo del proyecto. Si la idea por ejemplo, la plataforma estuviera 100% optimizada para
Android pero de golpe viene uno de los gerentes y nos dice che miren que un porcentaje super
importante de nuestros clientes que por ahí no son en cantidades grandes pero si son los que más
facturan tienen la necesidad de que esté en iPhone vamos a tener que hacer algo para dar soporte y pues
si no teníamos contemplado nuestro alcance vamos a tener que cambiar el alcance del proyecto y cómo
cambiar el alcance implica cambiar también las tareas los costos. Decidir si vale la pena hacer ese
cambio y una vez que decidimos por sí o por no cambiar las tareas y la asignación de recursos es parte
de administrar el proyecto sí coordinar cuáles son esos cambios que hay que hacer. A veces los cambios
son más gansos, por ejemplo nos dicen hay que cambiar el color de fondo porque a este cliente su paleta
de colores institucional no puede llevar ese azul por ejemplo, tiene que ser con un color más pasteloso, es
un cambio menor pero el ya no estarlo o con cambios mucho más grandes como decíamos hace un rato
no cosas como por ejemplo todo el soporte a una plataforma diferente lo que importa es si no lo
teníamos al principio del alcance y se identifica como necesidad o alguien lo plantea hay que evaluar si
vale la pena y si vale la pena con todos los cambios que hay que hacer para garantizar que se cumpla.
- Para el nivel de calidad, nosotros nos comprenden comprometemos a un cierto nivel de calidad y
tenemos que hacer todas las tareas necesarias para garantizar las ese nivel de calidad. Como vimos en
las clases de adm de metodología y de ingeniería de software, tiene que ver no solamente con el
producto sino también con todo el proceso. Garantizar que las tareas se cumplen en el orden que tienen
que cumplirse y que quienes las están haciendo las están haciendo con la calidad que corresponde.
También es tarea de la administración del proyecto. Decir si nosotros queremos que el código sea un
código legible, y cada tanto organizar alguna revisión técnica, cada tanto organizar alguna lectura del
código, garantizar que alguien dentro de la de los programadores arme algún chequeo de estilos de que,
por ejemplo, las funciones no tengan más de 30 líneas de código porque más de 30 líneas de código
implica que se podría fraccionar en funciones más chicas. Hay que tomarnos el trabajo de decir: “Estas
son las características que yo quiero de calidad y estas son las tareas que voy a hacer para controlarla.”
Eso es administrar la calidad. Controlar el grado de avance, sabemos que en ciertas fechas tiene que
estar algo terminado garantizar que este, y si no está para cuando va a estar. Si tiene que estar para
determinadas fechas porque otra tarea la necesita, entonces hacer todo lo necesario para que se cumpla
y si no se puede alertarlo.
- Finalmente esto de mantener informados a todos, si de repente una de las tareas demorada porque es
un proveedor nos tiene que entregar, por decir, una pieza específica de hardware que hace algo que
necesitamos para poder vender, y no la tiene, y no está respondiendo el proveedor, avisarle a aquellos
que están en las tareas de gestión de compras, o de gestión de proveedores para que presionen, para
que exijan, para que en caso de ser necesario cancelen el contrato y se lo asigna otro, para que les
cobren una multa, para lo que sea. Lo que importa es garantizar que si hay algo que otros tienen que
enterarse se enteren, no guardarse nada. Insisto esta probablemente sea una de las tareas más
importantes del administrador de proyecto eficaz, garantizar que quienes tienen que enterar de las
cosas se enteren. Muchísima, muchísima transparencia respecto al estado de los proyectos. Lo destaco
porque esto es más propio de la práctica. Por ahí el Project manager siquiera sabe, porque no consigue
que otros le den la información que necesita. Entonces para no quedar mal frente al cliente se decide
decir que las cosas están bien cuando no lo están, o tal vez solamente no se sabe. Eso es un error muy
grande, el administrador del proyecto tiene que ser muy transparente al respecto del Estado del
proyecto.
Planificación estratégica
- Único lo que produce un proyecto es algo único sí a diferencia de la operación tradicional de una
organización que tiene como resultado un producto más estandarizado si se quiere. Sí? por eso
habíamos dicho un proyecto puede tener como salida de una nueva definición de un proceso un nuevo
producto un objeto único una recomendación hay muchos resultados posibles pero lo que importa es
que siempre son únicos se hacen con un fin particular y el resultado cambiaría en caso de que cambie la
situación en la que se hace, no es que nosotros sabemos de entrada que vamos a conseguir algo sino
que tienen propiedades únicas sí emm bueno asi como habían comentado antes habíamos visto las
características que tiene la administración de un proyecto del ciclo de vida el inicio la planificación la
ejecución el control de forma digamos constante la evaluación del proyecto y finalmente el cierre y
habíamos visto las distintas áreas de conocimiento que un administrador de proyectos tiene que ser
capaz de dominar para poder hacer una administración eficiente todo proyecto está relacionado con
esas distintas áreas que si mal no me de acuerdo son 8 sí y nada es fundamental que un administrador
de procesos competente tenga algún conocimiento sobre todas esas áreas
 tiene la organización en sí misma cómo somos como queremos ser en el futuro y hacia dónde vamos
entonces estos 3 puntos tenemos en cuenta cuando hablamos de la estrategia a nivel organizacional
entonces dicho esto y repasando un poco rápido lo que nos va a interesar va a ser que intentar lograr
que la estrategia organización cómo se imagina a sí misma como quiera hacer negocio hacia dónde
quieren un futuro esté en línea o alineada con aquello que el área de sistemas puede hacer y acá viene
el primer guiño la estrategia de ti ahora vamos a hablar sobre ello tiene que hacer las cosas estando
alineada siempre con la estrategia organizacional no podemos ir por afuera o separado o por detrás de
la estrategia de la empresa u organización siempre vamos de la mano y siguiendo el mismo fin
acompañando y somos parte de la estrategia de la empresa ahora la estrategia de la empresa de ti hay
obviamente que van a apuntar a lograr explotar al máximo nuestras ventajas competitivas acá de vuelta
volvemos con el concepto de Portland competitiva haciendo uso siempre de la tecnología que va a ser 1
de los puntapié para que le agreguemos un valor real a la empresa este valor real del que estamos
hablando va a tener muchísimas formas de materializarse como vemos en pantalla uno va a ser la
reducción de costos porque podemos aprovechar la tecnología para reducir costos realización pagan
restaurante todas las empresas ecuación diferencial producto podemos diferenciarnos vas a la
redundancia en diferenciación en cuanto diferencias en cuanto a la calidad de los productos en cuanto al
tener estos productos en cuanto a los costos de nuestros productos en cuanto a la forma en que han
hecho el diseño o hacia dónde van apuntados vamos a tener un montón de formas mediante la
estrategia de organización y también la de tecnología para poder diferenciarnos y explotar nuestras
ventajas competitivas a partir de esto que vamos agregando valor y teniendo esta forma de materializar
este agregado de valor vamos a poder medir el valor de los dos sistemas porque porque vamos a medir
si tenemos estos beneficios cuánto valen o no nuestros sistemas cuando vamos a medir el valor de otros
temas de información vamos a medirlo con algunos de los beneficios que vemos ahí si nos permiten
tomar mejores decisiones así podemos ahorrar o mejorar el proceso hacerlos más eficientes si podemos
tener una rentabilidad más alta en la empresa y vamos logrando cada día un poquito más y si
obviamente tenemos diferenciamos del resto por ventaja competitiva vamos a poder decir en estos
sistemas de información tienen un gran valor porque nos van a ayudar a hacer cumplir todos estos
beneficios que ellos nos van a permitir
 tenemos que repetirnos constantemente hasta que nos entre en las venas porque en muchas
oportunidades vamos a encontrarnos ustedes lo van a notar si trabaja en dos pasos y resultan estar con
proveedores organizaciones que tienen las cuales las gerencias de sistemas son muy autónomas
justamente por las características propias de la tecnología en general pero la organización tiene un
objetivo un objeto social si este objeto social es resolver determinados problemas de la sociedad
 determinada situación proveer determinado conjunto de bienes es crear valor si todas las
organizaciones tienen
 eficiente posible por supuesto nosotros acá tenemos un problema grande a veces a la hora de pensar
esto muchas trabajamos en tecnología sí pero de vuelta tenemos que pensar en eso una forma separada
la organización tiene un objetivo si este objetivo en el caso de que sea por decir algo una empresa
automotriz va a ser producir autos determinada calidad para determinado público el área sistemas va a
estar encargada de proveer todos aquellos elementos de tecnología y de información particularmente
de información para que esta tarea se pueda hacer en ese sentido las áreas de sistemas van a ser áreas
de apoyo deben ser la forma en empresas cuyo objetivo es la comercialización la producción
 La mejora de las estrategias administrativas, los procesos de negocio más eficientes, la rentabilidad, las
ventajas competitivas, todos esos términos tiene que redundar de alguna forma en algún tipo de
medición de cuanto estamos aumentando el valor que producimos ya sea por la reducción de costos, o
por la capacidad de abarcar más mercado, o por la posibilidad de ocupar espacios en nichos más
rentables.
 este proceso esta estrategia va a ser obviamente planificada cuando queremos planificarla y hacerlas
cuando queremos planificar estábamos en cuenta para que se pueda influir en el armado de vacaciones
la misma primera estación actual del negocio tecnología es decir cuáles son los planes que tenemos
cuales son los sistemas que tenemos que infraestructuras con las que contamos evaluar hacia adentro
de la empresa la información respecto a la tecnología que tenemos en la misma. A partir de ese análisis y
del contexto actual la tecnología en el mercado vamos a definir que queremos tener en el futuro que nos
hace falta que estamos flojos que podemos mejorar que queremos innovar y queremos traer de nuevo
que tenemos que actualizar que tenemos que ir mejorando para no quedarnos atrasados y no perder
soporte, por ejemplo. Y así, cosas. Generalmente estos planes de sistemas son a largo plazo se hace del
presente a 5 años, va a haber planes más chicos (planes tácticos), pero el plan en total se suele hacer con
un periodo de duración de aproximadamente 5 años. Atravesando este proceso siempre vamos a tener
varias cosas en medio primero las necesidades de nuestros clientes que como dice ahí están en
constante cambio y siempre tengo que tenerlas en cuenta a la hora de diseñar no solo mi plan de
negocios sino también mi plan tecnologías de la información porque no podemos pensar en la tecnología
sin que acompañe planes de negocios sino no tiene sentido que mi tecnología no soporte planes de
negocio y que no pueda soportar o ayudar o resolver necesidades de los clientes. Lo mismo con las
acciones de la competencia que también el contexto es cambiante constantemente, la organización
como sabemos, todo está en constante cambio y no podemos dejar de contemplar dentro de esta
estrategia de tecnología de información a como se viene comportando nuestra competencia, en que es
más fuerte tecnología está invirtiendo hacia dónde va la cosa en cuanto al contexto. También tenemos
que mirar hacia fuera y ver cómo sus competidores están comportándose para intentar diseñar una
estrategia que pueda competirle y ni hablar de generar ventajas competitivas y generar una
diferenciación de la competencia. Y por último la oferta tecnológica para decir en qué situación esta hoy
el mercado tecnológico, hacia dónde van las alternativas que esta mas en una punta, que te conviene
más. Ahora va todo hacia cloud, bueno que opciones de cloud tengo, si quiero saberlo o no, que
empresas estan en juego, cuáles son los propositos. Tenemos que tener también en cuenta cuando
hablamos de estrategia de tecnológia de información la oferta tecnológica que no solamente está en
cambio sino en constante evolución, constantemente van surgiendo nuevas tecnologías, nuevas
aplicaciones, nuevas cosas que tenemos que ir investigando para tratar de utilizar o comprar o elegir la
mejor opción para nuestra empresa. A partir de los análisis la situación actual y todas las cosas que se
van cruzando vamos a crear un conjunto de supuestos que es como queremos que vamos a ir
evolucionando en el tiempo y a partir de esos supuestos es donde vamos a tener hecha o empezar a
mirar nuestra visión estratégica del sistema, nuestro plan táctico. Para hacerlo más tangible y bajarlo a
cosas así de corto plazo y las siguientes implementaciónes de las cosas.
 ¿Qué hay de fondo? ¿Vale la pena estar atento a eso? ¿Existe algún caso de uso que tengo que me
resuelva a mí? Que por ahí a futuro pueda implementar o que puedo creer que el resto van a intentar.
Esa es la clase de preguntas que tenemos que hacer para tecnologías más nuevas y para tecnologías más
viejas, es si yo quiero ahora hacer un desarrollo de determinadas plataformas, si quiero hacer que todas
mis aplicaciones están basadas por tirar a largo plazo. Las empresas están dejando de usarlas, ¿por qué?
De vuelta acá estamos pensando 5 años 6 años a veces incluso más entonces después el costo de los
cambios de decisiones importantes puede ser enorme ese es la tipo de información que necesitamos
 Los sistemas suelen ir por detrás de la estrategia general de la compañía, entonces nosotros vamos a
desarrollar los proyectos e implementar los sistemas que ayuden a sostener la estrategia general. Sin
embargo puede haber la existencia de casos que la nueva tecnología o sistema nos lleve a cambiar la
estrategia, lo que va a llevar a reevaluar toda la estrategia, y esos son los sistemas de tipo estratégico
que pueden apoyar o hacer cambiar por completo la organización (cambiar formas de comercialización,
cambiar la manera de producir, encarar otros o los mismos mercados). Esto tiene la capacidad de
acelerar o demorar estas estrategias: si una estrategia depende específicamente de tecnologías y los
proyectos se demoran, esa estrategia va a estar tecleando, es un problema. O acelerarlas en caso de ser
exitosa.
 Una parte del mantenimiento es proyectual y una parte del mantenimiento es de operaciones. Si el
mantenimiento se refiere a errores de datos o a errores menores, suele ser operaciones e incluso trabaja
un equipo diferente. Si en cambio son errores de entendimiento de una funcionalidad porque
sencillamente entendimos que el cliente quería tener en determinado lugar cierta información y en
realidad necesitaba en otro, o porque creímos que un dato tenía que ser determinado formato y en
realidad tenía que ser de otro eso suele entrar más como parte de una segunda etapa del proyecto.
 Es importante tener un colchón que vendría a ser parte de la gestión del riesgo. Es decir, bueno nosotros
creemos que esta puede ser la fecha, y esto es el tiempo que creemos apropiado por si hay algún
problema. Entonces lo importante una vez más es gestionar las expectativas. Si a nuestro cliente
nosotros le decimos que el 20 vamos a tener algo, pero decimos que creemos que hasta el 5 del mes
siguiente es más seguro porque nos garantizamos cierto tiempo por si hay algún imponderable, digamos
que va a estar para el 5, y en el mejor de los casos lo adelantamos un poco. O digamosle la verdad: mira
yo creo que va a estar para el 20 pero la realidad es que si pasa algo se estira al 5. Gestionar las
expectativas de vuelta. Igual si es una práctica común y es bastante aceptable que se mantengan ciertos
colchones.
 ¿Qué es el administrador de proyectos? La sigla PMP es Project Management Professional, es el máximo
responsable del proyecto en el sentido que es el que lo arma, el que dice todo aquello que está
involucrado en el proyecto, el que dice creo que este es un proyecto viable, y después tiene que ir
garantizando que cada una de las tareas dentro de ese proyecto se va ejecutando. Entonces si hace bien
las cosas en principio, el proyecto debería estar lo más cerca posible de ser exitoso. Por supuesto, ciertos
proyectos que no importa lo que hagamos van a salir mal, pero la idea es que si pasa algo así nos
enteremos lo antes posible. La idea de los responsables del proyecto, los administradores, es esto
garantizar que el equipo pueda hacer todas las tareas necesarias para cumplir con los objetivos. Su rol es
un rol estrictamente administrador en el sentido de coordinación y asignación de recursos. Como por
ejemplo si estamos hablando de un proyecto que surge a raíz de una una contratación nueva de una
venda participar en la propuesta en sí misma que hace el cliente y en la negociación del contrato. Es muy
frecuente sobre todo en nuestra en nuestro rubro (en otras áreas como por ejemplo ingeniería civil no
pasa tanto), en sistemas ocurre mucho que las ventas las hacen gente de áreas comerciales y los
administradores de proyecto se enteran cuando el proyecto está vendido, las fechas ya están
comprometidas, el contrato está cerrado, y le dicen toma acá tenés un contrato fíjate qué podés hacer.
Lo ideal es que, a la hora de armar las discusiones con los clientes y la negociación del contrato, el
administrador de proyectos participe. No quiere decir que va a ser el responsable de redactar todo, pero
 sí de decir: yo quiero que estén estos tiempos, estas condiciones. Una de las cosas que por ejemplo se
negocia mucho respecto de, cómo comentaba antes, del mantenimiento en caso de que haya un
incidente productivo, cuáles son los niveles de respuesta. Si la incidencia es de determinado tipo te puedo
responder en tantas horas y si es de otro tipo te respondo en otra. Es importante que, a la hora de
discutir esos términos y condiciones con los clientes, esté ahí quien va estar de encargado de administrar
todo. Porque si pasan todas esas cosas mientras estamos en una etapa del proyecto cerrada, y otra en
pleno desarrollo, y tengo que sacar a los desarrolladores para mantener, claramente se van a atrasar las
fechas. entonces es muy importante que participe. O que los comerciales le digan al cliente que
determinadas funcionalidades del sistema son suficiente para cubrir sus necesidades, cuando no lo son, e
implican un desarrollo nuevo. El administrador de proyectos tiene que estar ahí para decir: eso es un
desarrollo nuevo y que va a llevar este costo y este tiempo. De vuelta administrar expectativas,
fundamental. Una vez que está cerrado la propuesta, o que está avanzada por lo menos, armar el plan.
Decir bueno para poder conseguir todo esto necesitamos dedicar cierta cantidad de tiempo, atender
necesidades que llevan cierta cantidad de tiempo, hacer las negociaciones. Cierta cantidad de tiempo y
dinero, comprar los equipos, comprar las licencias, este tiempo instalar, para esta fecha tiene que estar
la instalación, para esta otra las primeras pruebas. Es importante que sea el administrador de proyecto
el que arme ese plan y también junto con este plan, el equipo que va a necesitar para hacerlo.
 A la hora de revisar el estatus del proyecto no solamente es responsable, sino que es su responsabilidad
principal saber en todo momento en qué estado del proyecto en qué estado está el proyecto y poder
coordinar con los responsables de que el proyecto avance, porque avanza o no avanza, y con aquellos
que necesitan saber si el proyecto está avanzando o no, mantenerlos comunicados. Y acá entra como
importante esta palabra stakeholders. En general van a ser todos los interesados en el proyecto, y con
interesados nos referimos a que tienen cualquier tipo de interés en el proyecto, tanto positivo como
negativo.
Muchas de las habilidades del Project Manager son lo que se conoce en la jerga como habilidades
blandas, no necesariamente manejo de muchas herramientas y mucha experiencia a la hora de usar
cálculos. La mayor parte de las herramientas están relacionadas con la comunicación. La capacidad de
comunicar, de negociar, entender cuál es el negocio que vamos a estar embarcando para el proyecto
entender cómo pensar y resolver problemas, sobre todo cuando esos problemas son problemas de
organización. Tener un buen manejo del equipo, tener una muy buena escucha activa sobre todo del
cliente, pero también del equipo de trabajo. El equipo de trabajo va a ser el primero que nos va a poder
mostrar cuáles son los problemas que está teniendo a la hora de avanzar. Si un administrador de
proyectos no es capaz de escuchar a su propio equipo, lo más probable es que esos problemas exploten
después. Bueno, cualidades como ser adaptable, ser flexible, diplomático, proactivo, orientado a la
gente. De vuelta, todo esto se resume en tener muy buenas habilidades personales, tanto para con el
cliente como para con la gestión, como para con el equipo de trabajo, y tiene que ser muy capaz de
resolver conflictos. Entender en qué momento las necesidades del equipo no están en línea con los
recursos disponibles, y por lo tanto hay que cambiar las necesidades, y con esto sacrificarse alcance, o
cambiar los recursos y comprometer más gastos. Cuando el cliente está teniendo expectativas
desmedidas, como hacer para bajar esas expectativas y alinearlas un poco más a una realidad que
aquello que el equipo es capaz de cumplir.
 3 patas de la triple restricción son: alcance, todo aquello que nos comprometimos a cumplir, costos,
aquello que estamos dispuestos a gastar para hacer el proyecto, y tiempo, en cuánto tiempo lo vamos
a hacer. Agreguemos la cuarta que es la calidad porque muchas veces, sobre todo a la hora de reducir
tiempos y costos, la calidad es un factor más a considerar, una variable más que podemos ajustar.
Podemos estar dispuestos a perder calidad para cumplir los tiempos o para achicar los costos.
Personalmente yo creo que, si estamos en línea con todo lo visto en la clase anterior gestión de
ingeniería del software y hay un compromiso fuerte con la calidad, la calidad no es negociable. En todo
 caso lo que se negocia son extensiones en el alcance, cambios en los costos, o extensiones en los
tiempos, y por eso muchos autores la calidad la incluyen dentro del alcance.
 Alcance es todo aquello que queremos cumplir, las necesidades que queremos satisfacer, los objetivos
que tenemos para encarar el proyecto, y aquello a lo que nos comprometemos. Eso es uno de los
puntos. El otro es el costo que el costo, en general tenemos dos valores (sobre todo cuando hablamos
de organizaciones comerciales), por un lado es cuál es el costo que nosotros tenemos y otro es cuál es
la ganancia. Por supuesto cambios en el costo van a terminar afectando la ganancia de alguna forma,
entonces hay un límite base que es el costo que queremos cumplir para tener determinada ganancia (y
deberíamos afferarnos a eso), pero también tenemos un límite de hasta cuanto nos podemos exceder
para que el proyecto aunque tenga menos ganancias, por lo menos no empiece a ser pérdida.
Finalmente, tenemos el tiempo que es cuando comprometemos un proyecto, comprometemos
determinado rango de fechas como límites de distintas entregas y de cierre del proyecto. También hay
cierta flexibilidad pero muchas veces estos tiempos no son tan flexibles. Como por ejemplo si vamos a
hablar de un software que tenemos que tener disponible para que los clientes puedan realizar ventas
previas a Navidad, no puede pasar de tenerlo listo a mitad de noviembre para diciembre ya tiene que
estar funcionando perfecto. Y si llega a ser 8 de diciembre, y el sistema no está, el cliente ya se debe
haber perdido una gran cantidad de ventas y nos va a estar odiando. Entonces ahí las fechas (el tiempo)
no es variable.
Entonces cuál es el problema de la triple restricción, que si vamos a cambiar alguna de estas cosas lo
más probable es que se afecte el resto. Si vamos a extender el alcance porque el cliente pidió cosas
nuevas lo más probable es que se extiendan el tiempo y el costo. Y si por alguna razón no podemos
cumplir con ese alcance, y el cliente dice no vos tenés que cumplir, lo más probable es que aumente el
costo o tiempos. También si nos dice que hay que achicar el costo o el tiempo, lo más probable es que
aumentemos los costos, porque necesitamos más mano de obra, porque necesitamos más tiempo
dedicado al testing, porque lo que sea, o que tengamos que achicar el alcance. En ese sentido jugamos
un poquito como que la superficie de ese triangulo se tiene que mantener siempre igual, y si achicamos
una punta o la alargamos, las otras van a cambiar. ¿Qué pasa cuando no hay margen para cambiar las
cosas en las 2 puntas, y la otra necesita moverse? Lo que hay que hacer es una renegociación del
proyecto. Entonces, si no podemos cambiar los costos o ya estamos en el límite de la ganancia y estamos
entrando en pérdidas, y no podemos cambiar los tiempos, pero el cliente quiere aumentar el alcance, va
a haber que renegociar el contrato y los costos van a tener que cambiar y van a tener que cambiar los
tiempos. Entre tanto y con esos 3 puntos, nosotros como administradores del proyecto, tenemos que ser
capaces de manejarnos aumentando, o achicando una u otra según las necesidades. Lo importante es
siempre tenerlas monitoreadas, garantizar que el alcance está claro para todos (tanto para nuestros
clientes como para nuestro equipo), tener claro en dónde estamos respecto de los costos y cómo vamos
respecto a los tiempos. Siempre en el ida y vuelta, la calidad está ahí como un factor más si se quiere
jugar con esa. Personalmente yo soy de los que creen que no se juega con la calidad del producto pero
es una variable más.