Vista de un desarrollador de la Gestion de Proyectos

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:



  1. No siempre lo que pensamos, son los requerimientos del cliente.

  2. Escoger bien a los miembros de nuestro equipo de trabajo.

  3. Usar la persuasión, en lugar de la imposición.

  4. Calcular el riesgo en los proyectos que participemos.

  5. Si vamos a trabajar en un proyecto, pues trabajemos.

  6. No todos los trabajos son buenos.

  7. Si vamos hacer algo, hagámoslo bien.

  8. 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

7 comentarios sobre “Vista de un desarrollador de la Gestion de Proyectos”

  1. Sergio, muy interesante el contenido y el punto de vista desde donde esta encarado el curso.
    Yo soy Gerente de Proyectos de una empresa de desarrollo de Software y muchas veces me topo con problemas durante la gestion de los proyectos, surgidos de las diferentes percepciones de los desarrolladores y los encargados de liderar (no es simple ponerse en el lugar del otro y tratar de entender cuales son las cosas que para cada uno son realmente importantes en el marco de su trabajo).

    Felicitaciones y mucha suerte.

    Ing. Pablo Abian.-

  2. Excelente Sergio!!!!

    Me parece una muy buena idea, hablar de gestión de proyectos en un curso de desarrollo de aplicaciones. Muchas veces nos tendemos a centrar solo en los aspectos técnicos del desarrollo.

    Los temas elegidos y la presentación me parecen buenos. En todos se podría ahondar mucho más pero me parece una muy buena primera visita a la gestión de proyectos.

    Yo siempre hago mucho hincapié en la colaboración con el cliente, la importancia de la calidad y en que lo impotante son las técnicas que funcionan más que las metodologías. Tu también vas en esa linea y me gusta la orientación que le has dado.

    Decir que nunca se llega a ser un Jefe de Proyecto, un buen Jefe de Proyecto siempre está en el camino en mi opinión; aprendiendo continuamente y tratando de mejorar continuamente. Pero esto se aplica a cualquier desarrollador…

  3. Creo que lo más difícil es que un desarrollador tenga la mente abierta.. es decir que acepte los cambios.

    A mi me costo también adoptar esta visión, pero cuando estas preparado para el cambio y le agarras la onda, esperas cualquier cosa, y te es más fácil adecuarte a un nuevo ambiente.

    Muchas veces pasa, que los desarrolladores cuando ingresan a un proyecto, no ven la hora de cuando terminan la fase de analisis para ponerse a programar. Claro también hay personas especialistas en programación, y esa pasión se respeta. Pero creo que las organizaciones de hoy, necesitan profesionales más involucrados en todas las fases de un proyecto, por lo menos en cuanto a soluciones de organizaciones creo que es así.

    Saludos,

  4. Tras decirte que tu artículo es bueno, teóricamente hablando, voy a ser malo, Sergio.

    Yo he gestionado varios proyectos y siempre tienes un problema sea como sea que abordes la dirección del mismo: el tiempo. Y, con el tiempo, los recursos.

    Una cosa es la teoría y otra es la práctica. En proyectos ideales sueles tener recursos y tiempo suficiente, por lo que si no eres muy bruto el proyecto salga probablemente bien.

    Pero muchos proyectos requieren que se termine lo antes posible, por necesidad, estrategia o cualquier otra razón. En esos proyectos, donde tu jefe y el jefe de tu jefe sólo quieren ver resultados, la teoría no es válida. Te guías por tu experiencia y tratas de sacar el proyecto lo antes posible, eliminando muchos factores que harán que el proyecto no sea “bueno”. La documentación puede esperar. No es todo de color de rosa, pero se hace lo qu se puede.

    Saludos.

  5. Holas Ricardo!, gracias por los comentarios.

    Con respecto al tiempo es muy cierto, es un problema crítico, muchas veces los proyectos se quedan corto de tiempo y la forma rápida de solucinar eso, en algunos casos, es contratando más recursos. Pero algunas veces no es sólo por falta de recursos, también depende del cliente y del usuario, el alargamiento del tiempo.

    Y la decisión depende en ese momento del Jefe del proyecto. Y yo lo veo así: si te contratán para acabar con un muertito, proyecto dejado a medias, debes hacer eso, acabar con el muertito, aunque algunas cosas presenten no sean las mejores, te contrarón para acabar el sistema. Ya una vez terminado se puede presentar una actualización, o hacer una mejora del sistema. Pero esa decisión depende del Jefe de proyecto. Una vez entre a un proyecto ya iniciado, que se debía cerrar, y como dices ya esta armado todo, no tienes mucho que pensar sobre lo ya hecho, tienes que cumplir con las tareas para las cuales te han contratado. Es lo comunmente se le llama “trabajar orientado al objetivo”, es decir a cerrar el proyecto.

    Y respecto a la Documentación es válida siempre y cuando te sea útil. Otro caso que tu jefe de proyecto te diga has la documentación, en ese caso ya no depende de ti. Ojo tampoco es que te sublebes a todo lo que diga el jefe de proyecto, pero por algo es el “jefe del proyecto”.

    P.D.: Nuevamente gracias por tus comentarios, un gusto.

    Saludos,

  6. Hola sergio lei tu articulo y es muy cierto lo que comentas.

    yo estoy en una certificacion sobre ese tema y precisamente me piden desarrollar un tema sobre lenguajes de desarrollo rapido (LDR) pero no encuentro mucha informacion de eso de casualidad tu tendras algo de esa informacion, te lo agradeceria bastante.

  7. Hey amigo exelente material, en verdad siempre es bueno leer o saber conocimientos q han sido adquiridos en el campo de batalla como algunos dicen….. En general bastante completa y acertada la informacion. Saludos ha sido de gran ayuda…

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *