Gustavo Bonansea: Project Management

Invitación al Seminario

Tue, 17 Jul 2007 17:57:46 GMT

Los invito al próximo technight donde junto con Matías presentaremos SQL Server 2005 Express y la metología de desarrollo de Microsoft: MSF.

Para registrarse aquí.

Nos vemos.

Un buen Post sobre el eterno dilema sobre las expectativas del usuario

Wed, 14 Mar 2007 13:16:52 GMT

Mi amigo Carmelo me ha enviado un mail con este post bastante ilustrativo de la situación en la que nos encontramos cuando un cliente nos está comentando los requerimientos y sus expectativas a la hora de que le construyamos un software, contado desde la perspectiva de si fuéramos Arquitectos en el área de Construcción, en vez de Arquitectos de Software.

http://geeks.ms/blogs/eecsaky/archive/2007/01/04/que-pasar-a-si-un-arquitecto-tuviera-que-trabajar-como-un-programador.aspx

¿Visual Studio o Excel & Word?

Mon, 26 Feb 2007 11:56:57 GMT

Ayer leía un post de Rodrigo del Corral “Qué he hecho de mi vida... aun pico código :( “ (gracias Carlos Zanini por mandarme la referencia), en el que hacía una reflexión sobre la carrera de un programador, porque había leído una publicidad en una revista en la que se hacía énfasis de que si ya te habías cansado de ser el palurdo que escribía código y querías tener una carrera profesional debías hacer caso al aviso: “¿cansado de picar código y no hacer carrera?, buscamos talento, te buscamos a ti”.

Obviamente lo que se puede deducir del anuncio es que si tienes talento no deberías desperdiciarlo escribiendo código. Cuando uno hace una reflexión sobre las posibilidades de crecimiento de su carrera profesional, a menudo se ve en la situación de que si quiere ampliar sus chances y crecer tiene que generar habilidades que se encuentran en el dominio de la administración y gestión, dejando un poco de lado la tarea de generar líneas de código. Dentro de los escalafones de la mayoría de las empresas los desarrolladores se encuentran debajo en la cadena alimenticia. Inclusive tareas que pueden ser comparables en lo que refiere a habilidades, profesionalismo y conocimientos como podrían ser la de analistas funcionales, los desarrolladores profesionales encuentran a estos últimos con desventajas a la hora de percibir remuneraciones y reconocimientos. Está claro que no todas las organizaciones son iguales, las más planas y flexibles otorgan más responsabilidad sobre sus desarrolladores y los valoran, pero de todas formas se exige del desarrollador un perfil mucho más amplio y que no cubra solamente capacidades técnicas de desarrollo, sino uno más integral. Aquí se aprecian mucho las capacidades de análisis, de diseño y arquitectura, la constante actualización y conocimientos de tecnología, como así también las habilidades para el trabajo en grupo, contacto y gestión del cliente y usuario, manejo de proyectos, etc. ... en fin, el Hombre Orquesta en resumen.

Hay una cosa muy clara y es que a medida que la empresa es mayor y por lo tanto los proyectos crecen, en volumen e importancia (valor de negocio), la estructura exige más niveles y la gestión se hace necesaria, porque es muy simple que un solo desarrollador pueda realizar de principio a fin una pequeña aplicación, pero es poco probable que un proyecto que requiere 3000 hs/hombre pueda llegar a buen puerto simplemente reuniendo a los mejores desarrolladores y que cada uno escriba código, sin ninguna figura de coordinador. Y aquí empieza la historia donde nacen los puestos de “gestión” y es indiscutible que los puestos más altos en las empresas requieren de personas con habilidades distintas a las técnicas (aunque estoy convencido que lo mejor para una empresa de tecnología es que sus directivos sean tecnólogos) y esto genera una carrera hacia una mejor posición que se encuentra por un carril distinto que la perfección escribiendo líneas en C#. Y aquí comienza la devaluación del desarrollador.

Esto está también relacionado con el debate entre las dos posturas de “Programar es un arte” y “Proceso industrial de producción de software”. Si vemos a la programación como un arte estamos poniendo al programador en una posición de privilegio donde debe ser mimado para que su proceso creativo produzca la magia. ¿Da Vinci seguía un Project cuándo creó la Mona Lisa?. Lo más probable es que no. En cambio si vemos la programación como un proceso industrial, está claro que el desarrollador es simplemente un medio para producir lo que dije anteriormente hs/hombre, es decir simple mano de obra que puede ser clasificada y agrupada por su perfil (junior, semisenior, senior) en un Project y ser distribuida entre las tareas del proyecto. Todos estaremos de acuerdo con que un desarrollador es mucho más que esto, pero si seguimos el modelo artístico de creación de software claramente dejaremos al soft en una posición de producto artesanal. Lo importante es encontrar un equilibro, en donde podamos aplicar metodologías que impriman al proceso de desarrollo de una calidad profesional y no ahoguen el proceso creativo que es necesario para la evolución de la industria.

Quién no ha querido bajar alguna demo de una aplicación desde Internet y ha mentido cuando pedía la posición en la empresa; inclusive en muchos casos se ve el típico combo:

· CEO / President / CIO / CXO

· VP / Director

· Manager / Supervisor

¿Dónde está la opción “Soy desarrollador y tengo curiosidad de su producto”? Un desarrollador no es lo suficientemente lúcido para decidir por sí mismo, si quiere o no ver una demo del producto, por lo tanto deberá pedirle a su supervisor o manager que se la baje por él si le parece bien.

Una vez he leído un artículo en una revista española de desarrolladores donde había alguien que estaba enojado porque lo habían ascendido y ahora tenía que realizar tareas de gestión en vez de divertirse escribiendo código, el traducía lo que le habían dicho a esto: “eres el mejor programador de tu área por eso ahora no programarás más y harás gestión de proyectos, presupuestos, control de calidad, etc.”. Por supuesto que no rechazó la oferta de ganar más dinero. A mí en particular las tareas de gestión me gustan y divierten tanto o más que escribir buenas líneas en C#, analizar el valor de negocio que produce una línea de código, la gestión del proyecto y del cliente. Pero hay muchas personas que no les place, que su perfil es altamente técnico y están felices de ello, los cuales no deberían tener que dejar lo que quieren para tomar otra ruta diferente es pos del crecimiento personal y profesional.

Viendo hace mucho (varios años) una revista de juegos leí un artículo sobre el Engine 3D del Quake, en la que se hacía referencia a uno de los desarrolladores que le había apostado a otro que podía agregar efectos de luz dinámicos en un par de horas al motor gráfico, se fue a la oficina de Id Software (empresa que hacía Quake) y lo hizo. Bueno, lo importante del artículo era una breve bio del sujeto este en donde hacía referencia a que tenía por hobbie coleccionar Ferraris. Hago referencia a esto porque los demás mortales no creo que lo logremos escribiendo código, desgraciadamente es así, el mercado es así. Pienso que todos aquellos que tenemos grandes aspiraciones debemos abrir un poco la mente hacia los temas de management, comercialización y demás etc, para crecer económicamente... lo que nos convertirá en el clásico Hombre Orquesta donde ya no tendremos a bien leer todos los newsletters de [.Net, C#, Asp.Net, Xml, Web Services, ADO.Net, SQL Server, etc, etc], estar subscriptos a todos los RSS de MSDN, ver los videos de Channel 9 – MSDN TV (por favor traducir todo esto a sus equivalentes en las tecnologías donde cada uno de los lectores se desarrolle), sino que además tendremos que leer cuánto libro de Management, Entrepreneurs, Administración de proyectos, Liderazgo etc, etc (que gracias a Dios suelen ser de pocas hojas) que anda dando vueltas por las librerías.

C’est la vie.

GB.

Templates para MSF

Fri, 26 Jan 2007 10:30:41 GMT

Para todos aquellos que utilicen MSF como metodología de desarrollo de software les paso el siguiente link que me pareció muy útil: http://www.microsoft.com/downloads/details.aspx?FamilyId=9D2016AD-6F8A-47F5-84FA-BEC389DB18C1&displaylang=en. Contiene templates para todos los documentos para cada etapa de MSF, es decir que los templates cubren todo el ciclo de vida del proyecto.

Les paso un detalle de los documentos contenidos:

Envisioning

Current State Infrastructure Assessment.doc
Feature proposal.doc
Milestone Review Report.doc
Project Structure.doc
Risk Template Tool.xls
Simple Risk Assessment Tool.xls
Team Lead Project Progress Report.doc
Team Member Project Progress Report.doc
Vision Scope.doc

Planning

Availability Plan.doc
Backup and Recovery Plan.doc
Budget Plan.doc
CapacityPlan.doc
Communications Plan.doc
Deployment Plan.doc
Development Plan.doc
End-User Support Plan.doc
Master Project Plan 0.2.doc
Microsoft Support Plan.doc
Migration Plan.doc
MonitoringPlan.doc
Operations Plan.doc
PerformancePlan.doc
Pilot Plan.doc
Purchasing and Facilities Plan.doc
SecurityPlan.doc
Support Plan.doc
Test Plan.doc
Training Plan.doc
Business Requirements.doc
Conceptual Design.doc
Functional Specification.doc
Logical Design.doc
Operations Requirements.doc
Physical Design.doc
System Requirements.doc
Usage Scenarios.doc
User Requirements.doc

Developing

Testing and Bug Reporting.doc
Traceability Audit.doc

Stabilizing

Pilot Review.doc
Release Signoff Form.doc
Test Specification.doc

Deploying

Post Project Analysis.doc
Project Close-out Report.doc

Esto puede servir de una muy buena guía a la hora de crear los documentos para cada etapa.

Reflection Workshop

Mon, 05 Jun 2006 13:04:47 GMT

Reflection Workshop es una técnica propuesta por Alistair Cockburn en la metodología de desarrollo de software Crystal Clear.

Dentro del ciclo de vida de un proyecto resulta muy interesante dado que permite un momento de reflección, autocrítica y evaluación, un momento donde todos los miembros del equipo pueden expresar su opinión, sus deseos e ideas. Es una técnica introspectiva que da pié a la mejora en lo que respecta a la metodología de trabajo y que permitirá mejorar la calidad del producto; pero posibilita también un espacio para exponer ideas que ajusten el ambiente laboral y la dinámica del equipo y lo hagan cada vez más cómodo y productivo.

Esta técnica simplemente consiste en graficar un cuadro con tres entradas:

Cosas que queremos mantener: aquí se deberían expresar todas las cosas que el equipo de trabajo está haciendo bien, todo aquello que la gente se siente confortable de realizar y que permiten lograr buenos resultados; lo que no queremos perder en el futuro.

Cosas que queremos evitar: en el original esta sección se denomina como "problemas", yo prefiero hacer incapié en "cosas que queremos evitar". Problemas da la sensación de algo malo y generalmente cuando nombramos un problema implícitamente puede asociarse con algún culpable, esto hace que muchas veces los miembros del equipo no quieran remarcar problemas porque estarían exponiendo a alguno de sus pares. El hablar de cosas que queremos evitar deja una sensación de alguna situación poco feliz; pero que ya está superada, hemos aprendido de ella y no deseamos repetirla. El Refelction Workshop debería ser un momento divertido de crecimiento no lLa Inquisición en búsqueda de herejes.

Cosas que queremos probar en el futuro: en esta sección se deja abierta la puerta para la innovación, aquí se expresan las ideas que pueden ser útiles para probar en el futuro. Esto no es un "debe hacerse" sino un "nos gustaría probar". Es muy importante luego destinar una serie de recursos para llevar a cabo algunos de los ítems dispuestos aquí sino nadie se molestará en el futuro en proponer ideas si todo queda en un hermoso cuadrito y nadie las ejecuta.

Esta técnica me pareció muy interesante y así fue como el viernes pasado la implementamos aquí en Raona. Los resultados fueron muy alentadores. Invertimos unos 40 minutos en el desarrollo del mismo y obtuvimos una lista muy interesante de puntos para cada categoría. Creo que la riqueza de esta técnica está en la participación de todos creando un clima de colaboración donde todos pueden influir en la definición de la forma en la cual van a trabajar, siendo parte importante en las decisiones. Esto crea un sentimiento de responsabilidad por llevar a la acción las tareas delineadas dado que son las ideas propias las que se deben poner en práctica.

Risk Management: Sólo para mayores de 18 años

Mon, 08 May 2006 13:17:44 GMT

Hace poco empecé a leer el libro Waltzing with Bears, libro recomendado por Ramón Bosch en su lista. Este libro trata sobre cómo manejar el riesgo en proyectos de software. Es un libro muy interesante y útil que todavía no he terminado de leer; pero del que quería rescatar un concepto muy interesante: "Risk Management is Project Management for adults".

Gestión de proyectos para adultos

El autor expresa que uno de los puntos más característicos de la infancia, es la inocencia sobre las cosas "feas" de la vida. Los adultos intentan proteger a los infantes de todos los problemas, inconvenientes y hechos desagradables haciendo su mundo lo más feliz y placentero posible. Nosotros como adultos debemos ser concientes sobre los riesgos y protegerlos de cualquier peligro. No es común (salvo casos excepcionales como nuestra querida Mafalda de Quino) que los niños se preocupen por los compromisos ambientales que provocaría la instalación de enormes papeleras, o si el gobierno Iraní sigue con el enriquecimiento de uranio para entrar en la lista de las naciones con armamento nuclear. Ésta es una de las grandes ventajas de la infancia. Madurar implica tener conciencia de todos estos temas, es decir lidiar con las cosas no tan placenteras de la vida.
Si gestionamos un proyecto de software sin realizar una gestión consciente de los riesgos inherentes estamos haciendo "cosas de chicos". De forma que si queremos portarnos como adultos en la industria del software debemos realizar una buena gestión de los riesgos. Administrar el riesgo no significa ser pesimista o alarmista e ir gritando por los pasillos que todo se va a acabar y que el apocalipsis está por llegar, sino estar conscientes de que no existe un proyecto libre de riesgo, que los peligros existen y que es muy importante tenerlos identificados, tomar acciones preventivas, estar alertas y actuar en consecuencia. No hay que escapar de los riesgos, porque probablemente los proyectos más riesgosos también serán los más provechosos si se llevan a cabo correctamente, sólo hay que actuar como adultos.