Get best of the week

Desarrollo de contratos de electrónica. Cálculo del proyecto.




Cada mes, nos llegan decenas de aplicaciones para el desarrollo de la electrónica. Y cada cliente potencial quiere saber el costo de resolver su problema, independientemente de qué tan bien lo entienda. ¿Puede un desarrollador de contratos complacer a todos? ¿Cómo eliminar de antemano a los "desesperados"? ¿Cómo evaluar aquellos proyectos que tienen posibilidades de desarrollo? Este es nuestro nuevo artículo.

Qué proyectos no deben considerarse


Cuando comenzamos, cada solicitud por correo parecía un regalo del destino. Nos sentamos con todo nuestro pequeño equipo y se nos ocurrió lo genial que estamos implementando este proyecto. Parecía que era necesario dar a cada cliente potencial el máximo detalle. Es necesario elegir las principales soluciones técnicas, dividir el trabajo en etapas, en tareas individuales, dibujar un diagrama de Gantt, calcular el costo del producto y describir todo esto lo más detallado posible en una propuesta comercial (KP). Pasamos en cada CP hasta varios días, y los clientes tuvieron una consideración eterna. Con el tiempo, se llegó a la conclusión de que no se puede perder el tiempo ingenieros y descartar proyectos sin un futuro


incluso antes de sumergirse en detalles técnicos. En primer lugar, es necesario comprender la seriedad de las intenciones del futuro Cliente. Por desgracia, solicitudes como "Vi ayer en Internet un dispositivo por 50,000 rublos, háganmelo por 30,000 rublos" son más comunes de lo que nos gustaría.

¿Qué debemos preguntar para evaluar las posibilidades de que el proyecto tenga éxito?


  1. ¿Por qué una organización necesita un producto determinado (objetivos de creación de productos)? Necesitamos encontrar la formulación más precisa de la tarea comercial, por lo que filtramos a los soñadores con la próxima "idea brillante" de una alfombrilla de baño automatizada, con bluetooth y una aplicación móvil.
  2. ¿Quién es el iniciador del proyecto (DM)? Descubrimos quién es responsable de la tecnología y quién asigna el presupuesto. Por lo general, se trata de personas diferentes y requieren diferentes enfoques en términos de ventas.
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

    • — :
      1. (, )?
      2. ?
      3. (), ? -? ?
    • — : . , , . « », , .
    • ? ? ? — .
  9. ? — :
    • (, )?
    • (, )?
    • ?
    • , ?
    • ( )?
  10. () ( )? «», - . , 9 .
  11. ? , . , , .
  12. (, , , )? « , ». , -.
  13. ? : , .
  14. ? – .
  15. ? (, , , , ). . ?
  16. ? ?
  17. (, , )?
  18. ? .


-




Entonces, el cliente y el proyecto cumplen con todos los requisitos, comenzamos la evaluación. La evaluación es inexacta e inadecuada. Si aún no tenemos TK, obtenemos una evaluación inadecuada con una gran extensión. Escribió TK - recibió una evaluación inexacta. Sin TK, el puntaje tiene una tolerancia de ± 400% o más. Esto se llama el cono de incertidumbre: el gráfico sobre las interfaces, pero la esencia en los diferentes proyectos es la misma. Cuanto más sabemos, menos incertidumbre. No pierdas tiempo y esfuerzo en TK.




Nuestras reuniones de evaluación de proyectos tienen el nombre no oficial de "Vanga Club". Los participantes se familiarizan con los materiales del proyecto de antemano. A la hora señalada, el Club recibe: un hombre de negocios, un gerente de proyecto, un ingeniero de circuito líder, un programador líder. A veces se invita a especialistas adicionales con experiencia limitada, así como a representantes de contratistas. Se necesita mucha gente para una revisión exhaustiva del proyecto. El comerciante está contento con su suerte y se esfuerza por satisfacer al cliente simplificando los requisitos. El gerente del proyecto tendrá que darle vida al proyecto, será responsable del tiempo, el costo y la cantidad de trabajo. Su deseo es poner una reserva, tener en cuenta los riesgos. Los ingenieros quieren hacerlo mejor que ayer. Pueden rechazar fácilmente una opción simple, pero "poco interesante". Sin un gerente de proyecto, puede tomar una orden subestimada, porque un hombre de negocios es muy elocuente.Sin un comerciante, puede contar tanto que el cliente ni siquiera contesta la carta.



La reunión comienza con una discusión general del problema para formar una comprensión común de todos los participantes. Luego, se construye una estructura jerárquica de trabajo ( WBS ) para el proyecto .
Para un solo dispositivo, se asignan partes de software y hardware. Para el sistema, se agregan diferentes partes como software de prueba, simuladores, parte del servidor, etc. Las partes resultantes se dividen en partes más pequeñas, por ejemplo, ramas de hardware en dos revisiones de la PCB y el diseño. La siguiente etapa es dividir las partes en tareas separadas. Si todo está claro con la implementación, las tareas deben ser pequeñas. La tarea "Escribir firmware" categóricamente no encaja. Consideramos tareas específicas normales con clasificaciones pequeñas, por ejemplo: "Controlador MCU I2C", "Elevar un proyecto", "Esquema E3".
No debe evaluar la complejidad de las tareas con anticipación, porque su complejidad y sus relaciones se aclararán solo cuando todas estén escritas en la pizarra.

Todas las tareas se asignan mano de obra en horas. El método es una evaluación experta . Un reloj puede tomar valores de varias potencias de dos: 2, 4, 8, 16, 32, 64, 128 ... Las tareas con una evaluación de 128 horas o más aparecen cuando la implementación no está clara. Esto significa que vale la pena realizar un trabajo para aclarar los requisitos, verificar la aplicabilidad de la tecnología y, a veces, incluso dispersar y fumar un google.
Según mis observaciones, es posible aumentar la precisión de la evaluación, en primer lugar, solicitando la opinión de los desarrolladores menos experimentados. Entonces aprenden a evaluar las tareas más rápido por su cuenta. Si un ingeniero de buena reputación ya se ha pronunciado, todos los demás tienden a simplemente estar de acuerdo con su opinión. Y cuando comience el trabajo en el proyecto, las tareas probablemente serán resueltas no por él, sino por aquellos que no dijeron nada. Todavía escucharemos su evaluación, pero no en el momento adecuado.
Cuando se evalúan todas las tareas, resumimos los resultados y agregamos un 30% al software para la depuración y otro 30% a las pruebas de software. Estas cifras están tomadas de estadísticas de proyectos terminados.
Como resultado, la siguiente imagen aparece en la pizarra:



La evaluación generalmente va acompañada de una discusión aguda de los detalles, porque puede haber muchas opciones para resolver el problema. Por lo tanto, toma no menos de una hora. Dado el tiempo de preparación, incluso una evaluación preliminar del proyecto puede costar entre 5 y 20 horas a los principales desarrolladores.

Todos queremos hacer productos exitosos, productos electrónicos que beneficien a las personas. Discutimos cómo los resultados de la evaluación (cronogramas, recursos) son consistentes con los objetivos del proyecto en su conjunto. Puede valer la pena ofrecer al cliente otras formas. Por ejemplo, para reducir la funcionalidad para MVP, o para tomar hardware más costoso en favor de un desarrollo más barato. Es útil calcular aproximadamente la economía general del proyecto para las etapas posteriores: producción, producción, apoyo. Estas cifras muestran el peso relativo de los recursos y el tiempo para las etapas del proyecto y pueden cambiar significativamente su percepción (tanto la nuestra como la del cliente).

Las calificaciones recibidas del Wang Club se registran en Redmine. EasyWBS es adecuado para agregar tareas rápidamente en forma visual:




Para determinar el momento del desarrollo, construimos tareas de hierro en cadenas (cascada). Obtenemos este Gantt: para el software, dividimos la intensidad del trabajo en la productividad del número de personas que pueden participar en el proyecto al mismo tiempo. Como saben, lo que hace un programador en un mes, dos programadores lo hacen en dos meses. Por lo tanto, no debe tener en cuenta todos sus recursos de personal al calcular. Además, no todos los programadores de proyectos pueden comenzar a trabajar desde el principio. Sucede que debe esperar al hierro, el suyo o el comprado. El mismo retraso puede ocurrir en la unión de etapas y revisiones de hierro. Para informar al cliente, no se pueden tomar las fechas recibidas. A menos que tenga el prefijo "pronóstico optimista". Es mejor dar un pequeño margen. Él será útil.






En el módulo de Cálculo, se agregan tarifas para especialistas y costos para contratistas, producción, materiales, dispositivos, etc. Una excelente oferta comercial para el cliente.pdf que creamos directamente desde aquí. Lea cómo nuestros colegas evalúan los proyectos de manera diferente utilizando el ejemplo de una sola solicitud. Pequeña analítica de doce KP . Entonces, el proyecto es aceptado, evaluado. Queda por firmar el contrato, y seguir adelante, reescribir tareas, cambiar soluciones técnicas, ampliar requisitos, cambiar el proyecto más allá del reconocimiento.









Para nosotros no hay duda de si evaluar proyectos o no, porque estamos haciendo proyectos para clientes, no funcionará obtener un contrato sin evaluación. Pero con proyectos internos en empresas, la situación es diferente. A menudo, los proyectos internos no son evaluados. Y muy en vano. La consecuencia de este enfoque es la subestimación del tiempo y los recursos. Ni el equipo ni la gerencia pueden evaluar el progreso actual del proyecto. De ahí el malentendido y la desmoralización del equipo.

Y ahora, ¡analicemos en los comentarios sus enfoques para la evaluación de proyectos!

More articles:


All Articles