Recientemente inicie un curso de Desarrollo de Aplicaciones, en la Célula de mi Universidad. A comparación de cursos anteriores, ahora antes de entrar a ver conceptos de Smart Clients, Desarrollo en Capas, o manejo de Patrones, u otro tema. Primero hablo sobre la Gestión de Proyectos Informáticos, la idea es darle más valor al curso, y sobre todo que les sirva para que lo apliquen en la vida real, y no sólo sea el curso por dictar.
Muchas veces al ser estudiantes, de todas maneras siempre recibimos ofertas para realizar algún Sistema de Información, ya sea por un amigo, un familiar, o porque lo buscamos nosotros mismos. Claro que algunas empresas se aprovechan de que la condición de estudiantes para reducir costos, en fin ese es otro tema.
En esas ocasiones, a mi me paso, muy poco sabemos de los roles de un jefe de Proyecto, un tester, y hasta muchas veces un analista, lo que sí sabemos es programar o desarrollar. Aunque no conozcamos estos roles, tendremos que hacer propuestas, algunos por probar, otros por necesidad, y otros por pasión.
Y ese es el motivo por el cual incluyo este tema dentro del curso. Ojo, no me considero un jefe de proyectos, bueno aún no, hay expertos en ello como Rodrigo Corral, o mis jefes en 3Dev. Mi punto de vista es como desarrollador, y en base a algunas experiencias que he tenido: Cuando me iniciaba hace años y en en mis etapas de practicante me rechazaron una propuesta de proyecto que hice, participe en otro proyecto donde faltaban algunos roles y se termino a medias, y después migre de ciudad y participe en un proyecto basado en la una solución Information Worker para una corporación. Adicionalmente a la poca experiencia que tengo, aún, lo que mostraré también será fruto de algunas conversaciones con amigos con los cuales he trabajado, algunos webCast que he visto, y leyendo blogs. Espero la validación, críticas, comentarios de Rodrigo Corral, y los han vivido la Gestión de Proyectos :$.
Los temas en la presentación adjunta son:
- Conceptos previos
- Ciclo de Vida del Desarrollo de Software
- Gestión de Proyectos de Software
- Evolución de los Sistemas de Información
- Recomendaciones
- Q & A
Conceptos previos
Como temas básicos primero debemos conocer la definición de un programa, y lenguajes de programación, y de partir ahí definir que es un Sistema de Información, normalmente conocido sólo como Sistema. No sé como será en otros países, pero por acá, cuando se dice quiero que me hagas mi Sistema, lo que está pidiendo es la realización de un Sistema de Información.
Y en cuanto a Sistemas de Información, resaltar algunos de sus beneficios: obtiene, procesa, almacena y distribuye información para apoyar en la toma decisiones y control de procesos en una organización; contiene información de sus procesos y entornos, entre otros. Recordar que existen tres tipos, eso dice la teoría: Transaccionales, de Apoyo en la toma de decisiones, y Estratégicos.
Al iniciarnos, no en todos los casos, siempre empezaremos viendo Sistemas Transaccionales, que no son otra cosa que los Sistemas de Ventas, Compras, Contabilidad, Logística, y todos esos. Los sistemas transaccionales son el primer tipo de información a implantarse en una organización; automatizan tareas operativas de la organización; son fáciles de justificar ante la dirección general, ya que sus beneficios son visibles a corto plazo.
Ciclo de Vida del Desarrollo de Software
Que en la práctica es Análisis, Planeación o Diseño, Desarrollo, Pruebas e Implantación del Sistema. Y la gestión de proyectos que está en torno a todo esto. En muchos casos las propuestas que hagamos serán de dos o tres personas, y bueno hacer el reconocimiento de quién hace qué cosa, muchas veces no es tomado en cuenta. Pero lo que sí no debe faltar es un tester y lo que siempre digo, es que, el desarrollador no sea su mismo tester, sino como :S. En estos casos podríamos conversamos con nuestro amigo que siempre le gustaba bajar sistemas, siempre hay uno en cada promoción, y retarlo e invitarlo a vulnerar nuestro sistema. En cuanto a los demás roles, por ser el primer proyecto, tendremos que asumir ser analistas, desarrolladores, y arquitectos; que hace el arquitecto?, pues a groso modo es el que define la infraestructura de la solución, y el modelo lógico y físico de la aplicación, se usará Cliente/Servidor, o un Sistema en Capas, y si se usará algún framework para crear la aplicación.
Gestión de Proyectos de Software
Aquí viene lo bueno, empiezo mostrando un gráfico, sobre ¿por qué fallan los proyectos?. Según las estadísticas es por elaborar requerimientos incompletos. Y algo que siempre recalco, es que software no es sólo codificar.
En cuanto a la duración del proyecto, que no sea mayor a 4 o 5 meses, eso creo que fue una de las puntos por lo cual rechazaron mi primer proyecto :(. Los clientes no pueden esperar más de 2 o 3 meses para ver resultados, si un proyecto es muy grande hay que dividirlo por módulos. Y establecer entregables cada dos o 3 meses.
Debemos tratar de que nos queden claro los requerimientos del cliente, él puede pedir un Sistema de Contabilidad, y nosotros haremos un sistema de Contabilidad, pero lo que quería era un Sistema integrado, es decir ventas, compras, inventario, etc. Debemos de tener claro lo que quiere el cliente, y siempre estar preguntando, para que no pase, que cuando estemos haciendo la instalación, te diga, NO, eso no es, lo que yo quería.
Realizar un documento de requerimientos, y hacer que los usuarios lo validen y aprueben. Esto principalmente te servirá para dos cosas: la primera será saber qué hacer, que tareas tienes que hacer, y en general para planificar la solución. Ahora la segunda cosa importante para la cuál te servirá, es que sucede si estas en la etapa de pruebas y vienen los usuarios, y te dicen que se dan dado cuenta que en un requerimiento no es lo que quisieron decir, y hay que hacer cambios, y te dicen: «pero es un cambio chiquitito», pero no saben que eso de repente puede hacer que tomes unas semanas más, es ahí donde sacas tu documento de requerimientos y dices eso no estaba, y puedes justificar que el proyecto tome unas semanas más si es el cambio así lo requiera, y si quieren algo más de lo que se había pedido, y como diría un amigo: ese es otro precio :D.
Si bien en la presentación se ven los roles de Jefe de Proyecto, Arquitecto de la Solución, Arquitecto de Infraestructura, Analista, Desarrollador, y Tester. No es necesario tener un usuario por cada rol, muchas veces sólo presentan el proyecto tres amigos, y tendremos que completar entre nosotros los otros roles, pero eso sí, si eres desarrollador no debes ser tester, si alguien sólo hace de jefe de proyecto, puede ser el tester, pero si sólo son dos usuarios compartiendo los roles, como comente arriba podemos acudir a un amigo para el rol de tester. Hay un cuadro de Roles, donde te dice que roles se pueden combinar, no recuerdo donde lo vi, creo que fue en una presentación, cuando lo encuentre, lo adjunto en los comentarios.
Asignar tiempo exclusivo a los proyectos. Esto es importante sobre todo para los que aún son estudiantes y ya están dentro de un proyecto o están haciendo la propuesta. Si el horario de nuestros estudios es el ideal, ósea, estudiamos o bien en la mañana o bien en la tarde, o bien en la noche. Esto nos permitirá darle un horario aceptable al proyecto. Pero qué pasa si tienes cursos en la mañana y en la tarde, y muy variado. Para estos casos sólo le dedicamos el tiempo que podemos al proyecto, y muchas veces esto hace que sumemos a las estadísticas de porqué fallan los proyectos. También evitar desarrollador en nuestra casa, en lo posible, y si la organización lo permite, trabajar en la misma organización. Algunos directores, sólo te ven una vez a la semana, y no les entrega nada, causa suspicacias sobre tu trabajo, además que cuando tienes un problema, ellos no saben que te estás tomando tiempo resolviendo el problema, sólo saben que estas atrasado. Pero si estas en la misma organización verán todo el trabajo que estas realizando.
En cuanto a la metodología a usar, en el primer proyecto que hice, presente, y no se aprobó, no sabía que debía usar una metodología para el desarrollo del proyecto. En cuanto a recomendar una metodología todavía no lo puedo hacer, ya que no he aplicado muchas, y sólo sería recomendación en base a lecturas. Lo que sí puedo recomendar es que revisen las diversas metodologías que hay, con respecto a metodologías ágiles podemos encontrar mucha información en el blog de Rodrigo, sobre todo de Scrum, también puedes revisar XP como metodología ágil, imagino que algunos llevaron en algunos de sus cursos RUP, y si no también lean, y bueno también esta MSF. Ahora la recomendación es leer estas, y ver cuál puedes aplicar más, a tu proyecto, que combines y vayas viendo su utilidad, no se dejen llevar mucho por la teoría, por ejemplo si usas RUP, no hagas todos los diagramas UML, sólo por hacer, hazlo porque realmente lo necesitas, y te ayudan a entender mejor el modelo. Lo que si debes tener claro es que de todas maneras debes tener Documento de Requerimientos, y si sólo con esto entiendes el modelo de la organización no hay porque gastar el recurso tiempo, haciendo diagramas que no nos servirán. Si estás haciendo escenarios ya conocidos, Sistema de Contabilidad, Ventas, Compras, etc, revisa en los trabajos o tesis de tu Universidad, muchas veces estos modelos ya están resueltos, y no hay porque perder el tiempo tratando de volver a inventar la rueda. Si ellos ya resolvieron el modelo, aprovechémoslo.
Las herramientas no son el fin, son los medios. Que en un proyecto no dejes que te motive la idea de usar la herramienta o entorno X, ya que las herramientas con el tiempo cambian, lo que te debe motivar es aprender el modelo del negocio, ya que eso cambiará muy poco con el tiempo, y entre las diversas organizaciones. Pero ojo, esto no quiere decir que no sea importante escoger una buena herramienta de desarrollo, mientras más productivo te hace la herramienta, mucho mejor, que esta demás mencionar, que uno de los objetivos de VS2005, es incrementar tu productividad.
Asuman con compromiso cada proyecto en el que participen, si van estar en proyecto por probar, o porque no tienen otra cosa que hacer, y a medio proyecto lo vas a dejar, mejor no se metan. Desde el momento que presentaron el proyecto, su nombre está en juego, dependiendo si se termina o no el proyecto. A corto plazo no afecte mucho, pero cuando retomemos el hacer proyectos, y ahora si estemos motivados, será difícil volver a obtener la confianza de las organizaciones o personas. Recuerden que si hacen bien un proyecto será un referencia más, pero sino, puede ser mala fama sobre nuestra persona.
Ahora la pregunta del millón, cuánto tiempo durará el proyecto, y cuánto costará. Rodrigo ya nos hablo sobre las estimaciones. Yo les recomendaría en cuanto al costo y el tiempo, que en un primer proyecto se la jueguen, consulten con amigos o docentes, o mentores, sobre cuánto podría durar el proyecto. Y sobre el costo, negócienlo con la organización, y traten de que este primer proyecto salga de todas maneras, aunque no ganemos mucho. Y porque arriesgarnos tanto en nuestro primer proyecto, y es que a partir de este, formaremos nuestro sentido común, de estimar tiempo de duración, y costo del proyecto. Aunque no será «la experiencia», será nuestra propia experiencia y conoceremos como respondemos a un proyecto. Indudablemente que puede que trabajemos mucho y demás en este proyecto, pero el siguiente ya no nos volverá pasar.
Evolución de los Sistemas de Información
Esto es como parte complementaria y teórica. En muchas organizaciones grandes, lo que se desea es un sistema integrado, que al realizar una venta automáticamente, se descuenta el producto de abastecimiento, y se registre en contabilidad. En organizaciones grandes el desarrollo de estos sistemas puede durar mucho tiempo, y en ese tiempo perder dinero, y entre otras razones, es porque las organizaciones optan por un ERP. En la presentación encontrarán más detalles.
Recomendaciones
Y para finalizar, aunque cuando hago la presentación esto lo acompañe con algunos «videos», acá sólo dejo las recomendaciones, trataré de buscar «imágenes» que se presten para las recomendaciones :D:
- No siempre lo que pensamos, son los requerimientos del cliente.
- Escoger bien a los miembros de nuestro equipo de trabajo.
- Usar la persuasión, en lugar de la imposición.
- Calcular el riesgo en los proyectos que participemos.
- Si vamos a trabajar en un proyecto, pues trabajemos.
- No todos los trabajos son buenos.
- Si vamos hacer algo, hagámoslo bien.
- Vivan los proyectos, motívense.
Presentación Adjunta: starrillo_DesarrrolloSoftware.pdf – 2.50 MB.
P.D.: Y nada, espero que les sea útil, y se inicien en los proyectos :).
Saludos,
Post cruzado desde
starrillo blog
:
.