El término»stakeholder» es muy utilizado en la bibliografía del mundo del desarrollo, planeación y filosofía ágil. Este no es un término nativo del mundo de la programación, más bien es un término que se toma de la jerga organizacional. Un stakeholder se puede definir como una persona interesada o afectada por el trabajo del equipo de desarrollo, ya sea porque espera obtener un beneficio o porque el trabajo producido le afectara directa o indirectamente. Las personas interesadas se pueden clasificar en dos tipos.
Stakeholders internos y stakeholders externos.
Nuestro trabajo como programadores afecta positiva o negativamente a la gente a nuestro alrededor, los primeros en notar este impacto son los stakeholders internos, estos son todas las personas dentro de la organización a las que afecta nuestro trabajo. Las aplicaciones de software suelen afectar a casi toda la organización. En la actualidad las aplicaciones son un espejo del modelo de negocio de la empresa. Puede que estés desarrollando aplicaciones de backoffice en la empresa para facilitar el trabajo de otras áreas, cada área que use la aplicación o dependa de ella se vera afectada por tus buenas o malas decisiones. Supongamos que llevas el sistema de seguimiento de compras de la empresa, si una área de trabajo ocupa algún bien o servicio debe de registrar en el sistema la compra del insumo junto con su correspondiente factura. Si surge algún cambio en el flujo, por ejemplo, una regla que impida registrar compras 30 días después de la fecha de factura, el cambio producido afectara a todas las áreas y, por lo tanto, todos se volverán tus stakeholders.
Así como hay un impacto interno en la construcción de programas, también es posible que exista un impacto directo o tu te veas influenciado por personas externas a la empresa. Por ejemplo, los proveedores de bienes o servicios son tus stakeholders externos, tus acciones pueden afectarlos o las necesidades y deseos de estos pueden afectarte a ti. La relación con un stakeholder no es unidireccional, más bien es bidireccional, esto significa que las decisiones o acciones de otros pueden afectar o modificar tu trabajo. Si tu empresa está sujeta a una regulación gubernamental, todas las disposiciones que el gobierno envié para que sean cumplidas te afectan a ti. Entonces, el gobierno se convierte en un stakeholder externo, él está interesado en que sigas sus instrucciones y puede pedirte evidencias de que los sistemas cumplen las disposiciones que él te pide, claro, difícilmente tu podrás hacer que cambie de opinión, por ejemplo: si una regla a cumplir es inconsistente o carece de sentido.
Un stakeholder puede involucrarse en el desarrollo activamente.
Existen varios roles dependiendo del tipo de marco ágil de trabajo que manejes, a la gente directamente involucrada en el proyecto como product owners, analistas de negocios o administradores de proyectos no se les considera un stakeholder ya que son parte del equipo. En las planeaciones o reuniones pueden aparecer personas relacionadas internas o externas, del lado interno podríamos tener al director de área que puede estar interesado en el avance del proyecto, puesto que este es vital para la empresa. Él o ella por su posición de poder podría hacer pedidos o emitir opiniones al respecto que tendrían que ser evaluadas. Del lado externo podríamos tener al cliente, al usuario o la persona que está pagando por el proyecto, que también está en posición de hacer pedidos o pedir cambios. No voy a tocar el tema de sí, esto es correcto o no, es algo que sucede y hay que tenerlo en cuenta. El stakeholder puede tener un rol proactivo al momento de desarrollar una aplicación.
No puedes darle gusto a todo mundo, incluidos los stakeholders.
El que te haga mención de estas personas interesadas no quiere decir que se deba hacer caso a todo mundo y tener contentos a todos, esto es un sin sentido. Las opiniones de las personas interesadas son valiosas, algunas van a tener mucho peso, otro no. Si bien, vas a escuchar y empatizar con ellas, esto no quiere decir que vas a terminar diseñando por comité. En algún momento se tendrán que desechar ideas, propuestas y deseos para no perder el rumbo del proyecto. El rumbo siempre debe de estar en completar un proyecto que aporte valor, que soluciones, los problemas de los usuarios. El diseño de tu aplicación no es democrático, el equipo debe de decidir lo mejor, ya que este toma la responsabilidad de lo que se construye. Alguien va a ser responsable por entregar resultados, y ese alguien vas a ser tu. Tenlo en cuenta cuando construyas tus aplicaciones, es importante escuchar, pero también es importante decidir por tu cuenta.
Conclusiones.
Me animé a redactar este artículo para tener en claro que es un stakeholder, de verdad es un término que leo muy a menudo y no me había tomado el tiempo de entender exactamente que significa. Muchas veces tendemos a usar terminología que no entendemos completamente lo que da lugar a errores, espero te sirva esta auto explicación.
Referencia: ¿Qué son los stakeholders?.
Autor imagen: Tim Green
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
2 comments On Agile: ¿Que es un Stakeholder?
Pingback: #Agile Hazlo o no lo hagas, pero jamás lo intentes. – Happy Devops ()
Pingback: #Opinion del libro Clean Coder De Robert C. Martin. – Happy Devops ()
Comments are closed.