Productos, proyectos y otros animales.

Producto o proyecto? Las disputas sobre la definición de estos conceptos no disminuyen, y este no es un debate inactivo. Los métodos de gestión dependen de las características de cada disciplina, y las expectativas de las partes interesadas dependen. Quiero presentar mis definiciones de los conceptos de "producto" y "proyecto". Quiero enfatizar de inmediato: estas serán exactamente mis definiciones basadas en muchos años de práctica. Es poco probable que encuentre su palabra por palabra en la literatura certificada, pero intentaré mostrar todos los cálculos que conducen precisamente a tales definiciones. Discutiré con gusto en los comentarios si su punto de vista difiere del mío.

Un proyecto es una actividad. Un producto también es una actividad. Una vez completado, puede aparecer un resultado tangible en forma de un producto de TI, pero el software nunca es un fin en sí mismo de un producto. A diferencia del proyecto, donde el simple hecho de crear una solución de TI funcional será un resultado significativo. El objetivo de la actividad de creación de productos es resolver un problema específico de un grupo específico de personas. La calidad de una solución a un problema puede medirse en dinero, me gusta, la cantidad de vidas salvadas, la cantidad de accidentes o simplemente el concepto subjetivo de "calidad de vida". Sí, dado que, después de todo, somos especialistas en TI, utilizamos herramientas de TI para resolver problemas. Sin embargo, el resultado del producto en su conjunto no puede evaluarse por la conformidad de los términos de referencia y el producto informático desarrollado. Pero en el proyecto, así es como evaluamos el resultado.

El objetivo de la actividad del proyecto es cumplir la tarea en un marco de tiempo y presupuesto claramente definidos, con una calidad dada. Incluso si la asignación del proyecto se escribe en la primera fase del proyecto, el proyecto siempre tiene un cliente en cuyos intereses se escribe esta asignación. El proyecto es el cliente, el producto es el problema.Esta es una diferencia muy importante! Incluso si el cliente del proyecto formula el objetivo como "resolver el problema para mí", no será equivalente al producto por una simple razón: responsabilidad. Tan pronto como el equipo del proyecto forma la tarea y la presenta al cliente para su firma, la responsabilidad del hecho de que el método propuesto resuelva el problema se transfiere al cliente. Sí, en algunos casos, puede reducir el riesgo de soluciones perdidas mediante el uso de enfoques ágiles (para no iniciar otro holivar, supongamos que en este contexto, Agile es "un enfoque que reduce el riesgo de errores como resultado de ciclos de desarrollo cortos, constantes análisis del resultado y la capacidad de cambiar la dirección del movimiento en cualquier iteración "). Pero un proyecto siempre tiene limitaciones. Al menos a tiempo. Entonces, la responsabilidad deque al final del proyecto, el resultado no se logrará, aún permanecerá con el cliente (especialmente, especialmente con el enfoque ágil, donde el cliente está muy involucrado en el trabajo).

El producto no tiene cliente. Hay usuarios cuyo producto resuelve el problema. Pero no son clientes en absoluto. A Henry Ford se le atribuye la frase "Si le preguntara a mis usuarios qué hacer, aun así adjuntaría la quinta pata al caballo". No es tan importante a quién se le ocurrió la frase, pero ilustra perfectamente la diferencia. Ford resolvió el problema del movimiento rápido e independiente de las personas de clase media. Yandex taxi resuelve el problema de la entrega rápida de automóviles, independientemente de pertenecer a una flota de taxis, y el uso de un teléfono inteligente y un sistema de TI en lugar de un único centro de despacho le permite superar a este último en precio y calidad. Delivery-club resuelve el problema de la diversidad alimentaria. Etc.

Un producto siempre tiene un inversor. Puede ser un fundador que invierte su tiempo y dinero acumulado, o una compañía separada que invierte dinero o conexiones. Un inversor difiere del cliente en que no acepta responsabilidad por el resultado del equipo. El equipo es responsable del resultado del producto. Para comprender si un producto se mueve en la dirección correcta, se generan métricas del producto. Con respecto a sus cambios, se evalúan estos o aquellos cambios realizados en el producto durante un período determinado. El proyecto también tiene métricas, pero se relacionan principalmente con el desarrollo del tiempo o el presupuesto. Para entender la diferencia, veamos un ejemplo simple: la métrica "ejecución presupuestaria" para el período mostró un exceso del hecho en relación con el plan. El análisis mostró que captamos el segmento en el que no esperábamos publicidad contextual.La conversión del segmento a la acción objetivo mostró que hay potencial. Si hacemos un producto, analizaremos y fortaleceremos las ventajas competitivas del producto en el nuevo segmento, aumentando el presupuesto. Si estamos haciendo un proyecto, este es un paso claro más allá de los límites del proyecto y debemos ajustar los anuncios para eliminar el tráfico innecesario.

Cada producto tiene al menos un competidor, una forma familiar de resolver un problema. Para Henry Ford, estos eran paseos a caballo o carruajes tirados por caballos. Para el taxi Yandex, llame a las compañías de taxi o llame a un servicio de despacho único. El Delivery Club lucha, en primer lugar, con "cocinarlo usted mismo". Y la efectividad de cada uno no es la conveniencia de las interfaces de sus aplicaciones, sino la calidad de la solución al problema original. Si Yandex-taxi siempre llegará mucho más rápido que a través del despachador, no importa cuán inconveniente sea la aplicación, la usarán. Pero en Tolyatti, por ejemplo, todavía un taxi, ordenado por teléfono de un solo servicio de despacho, llega más rápido y en más lugares. Por lo tanto, en Tolyatti Yandex taxi como producto no tiene éxito, a pesar de la aplicación súper genial.

Es posible que los proyectos no tengan competidores, ya que el objetivo del proyecto puede ser optimizar algún proceso o simplemente recopilar datos, reconocimiento en batalla. El proyecto termina tan pronto como se alcanza su objetivo o la fecha límite para su implementación. El producto está vivo mientras el problema está vivo. Los cambios de producto son una forma de sobrevivir en un entorno competitivo. En cada iteración, el equipo del producto debe responder las preguntas "¿qué podemos cambiar para que sea aún más fácil / rápido / más cómodo para nuestros usuarios resolver su problema". El equipo del proyecto resuelve el problema inverso: cómo evitar el crecimiento del volumen del proyecto.

Ahora, en base a las características anteriores, derivemos las definiciones del proyecto y el producto.

• — , , , . ( ) , .
• — , . , , , , — , . — — .

Antes de sacar conclusiones, quiero responder una pregunta silenciosa de los lectores: "¿Qué tiene la imagen en el título del tema en discusión"? El mas directo. Jacob Jordaens describió la segunda reunión de un sátiro con un campesino de la fábula de Esopo "El hombre y el sátiro". En la primera reunión, el sátiro le preguntó al campesino, que se soplaba las manos en invierno: "

¿Qué estás haciendo?" ¿Por qué estás soplando en tus manos?
"Los caliento con mi aliento".
En la segunda reunión, que está en la imagen, el sátiro le pregunta al campesino: "
¿Por qué estás soplando la sopa, tratando de calentarla?" ¿Está tan caliente?
"¡No, soplé la sopa para enfriarla!"

A partir de este diálogo, el sátiro concluye que los humanos son criaturas sospechosas de dos caras que es mejor evitar.

Se necesitan definiciones de los conceptos de "producto" y "proyecto" para no caer en la misma situación que un sátiro. Son necesarios para aplicar las herramientas adecuadas en el momento adecuado, eligiendo el sistema de control adecuado. Para no intentar evaluar las actividades del proyecto con métricas de productos o viceversa. Para no tratar de formular un presupuesto de producto sobre la base de especificaciones técnicas para un sistema de TI. Enfocar claramente al equipo en una estrategia de trabajo específica. Por ejemplo, al diseñar sistemas de TI en un proyecto, tiene sentido elegir las soluciones menos riesgosas. Y en el producto están aquellos que cumplen con el concepto de ganar-ganar. La elección de una cascada iterativa para el desarrollo del proyecto es un paso completamente natural, ya que le permite controlar con mayor precisión el presupuesto y el momento. El uso de enfoques flexibles en los productos es más conveniente, ya que son los que cometen errores con mayor frecuencia y más rápido.Use enfoques de acuerdo con la realidad, no se engañe, y habrá menos frustración en la vida.