¿Cómo mostrar el enfoque del proyecto planificado al cliente?

Tiene dos métodos que necesita revelar a su cliente potencial: 1) PM, 2) Software, SDLC. Estos dos métodos están separados pero necesitan trabajar en colaboración.

Responderé al n. ° 1 y dejaré el n. ° 2 para las personas más técnicas en este intercambio.

Su cliente está buscando cómo evaluó el proyecto en términos de lo que entregará al final del proyecto, así como las entregas intermedias durante el proyecto. Esto se exhibe mejor como una declaración del alcance del proyecto, que a menudo se encuentra en un acta de constitución del proyecto, pero también dentro de su Plan de Gestión del Proyecto (PMP), así como una Estructura de Desglose del Trabajo inicial (WBS) y posiblemente un Diccionario WBS inicial. Este es el qué.

Tu cliente querrá ver cómo estás programando el trabajo, las fases que propones, el tiempo que necesitarás para realizar las entregas. Esto se muestra mejor como un cronograma de alto nivel con hitos, como un diagrama de Gantt, pero es posible que su cliente desee ver su cronograma preliminar que muestra su WBS cargado a lo largo del tiempo. Este es el cuando.

Su cliente querrá ver el costo del proyecto. Esto se entrega mejor como su propuesta de costo con precio, pero su cliente también puede querer ver cuánto cuestan los componentes del proyecto, que se exhibe como parte de la Línea base de medición del desempeño (PMB) y dentro de su Diccionario WBS. Esto depende, sin embargo, de su tipo de contrato con su cliente.

Finalmente, dentro de su PMP, su cliente estará interesado en su enfoque de gestión para administrar y controlar el proyecto, cubriendo temas como riesgo, calidad, comunicaciones a las partes interesadas, su enfoque de adquisición de materiales que necesitará, etc.

Esta es una gran cantidad de información que probablemente aún no haya resuelto del todo, ya que ni siquiera tiene el trabajo. Así que escale esta información en consecuencia, es decir, muestre lo que tiene en un nivel alto, una vista más estratégica. Es probable que no tenga planes y cronogramas básicos para mostrar en esta etapa, por lo que querrá entregar esta información más en un formato de presentación. El mensaje de comunicación es que usted sabe cómo organizar, ejecutar, administrar y controlar el trabajo para llegar al final de la manera más eficiente posible y poder comunicarse temprano y con frecuencia cuando las cosas van mal.

Una perspectiva técnica:

De la información que ha proporcionado, infiero que el cliente es técnicamente competente y comprende muy bien los riesgos de transferir una base de código a un programador diferente. Es un problema frecuente que los programadores subestimen el esfuerzo de sumergirse en un código base existente.

Desde mi punto de vista será importante demostrar que no .

Factores que influyen en el esfuerzo por hacerse cargo de una base de código existente

Según el tamaño del código base, será muy difícil proporcionar una estimación razonable, ya que los siguientes factores pueden influir en gran medida en el esfuerzo requerido:

• Tamaño: métricas aproximadas como archivos, líneas de código
• Base tecnológica: ¿Se basa en un marco bien conocido, uno que podría incluso ahora? En mi opinión, esto aumentaría enormemente la confianza en su capacidad.
• Documentación, comentarios en código: ¿Existen y se mantuvieron?
• Capacidad de los programadores anteriores y motivo por el cual abandonaron el proyecto.
• Edad del software: por experiencia, diría que cuanto más antigua es la base del código, más y más probable es que encuentre hacks y atajos, a menos que el desarrollo sea muy disciplinado y refactorice el código de vez en cuando.
• Dependencias externas (bibliotecas): ¿Son maduras y estables, manejables? ¿O se utilizaron algunas bibliotecas oscuras de prelanzamiento?
• Una gran cantidad de metaprogramación personalizada y "magia de rubí", como se ve con frecuencia en los proyectos de rieles, puede ser muy problemático cuando se trata de comprender las partes internas.
• Cobertura de prueba

Le aconsejaría que obtenga la mayor cantidad posible de metainformación de antemano para demostrar su competencia y planificar sus acciones.

Enfoques generales

Para entrar en el código, sería ideal si pudiera organizar al menos una revisión con uno de los programadores originales, para que pueda brindarle un diseño de alto nivel y explicar sus decisiones de diseño.

Otro enfoque común para familiarizarse con una base de código es elegir un caso de uso específico y depurarlo de arriba a abajo.

Según el tamaño de la base del código, puede considerar el uso de herramientas especializadas para visualizar las dependencias de los objetos, analizar la calidad del código y similares.