¿Debe un análisis ser independiente de la tecnología? [cerrado]


11

Ayer tuve una discusión con uno de mis colegas. Él (un analista de negocios, anteriormente un programador) cree que debe conocer la tecnología utilizada para implementar el sistema, de modo que pueda tomar mejores decisiones de diseño. En mi opinión (soy un programador), un análisis no debe combinarse de ninguna manera con la tecnología y creo que un buen analista puede hacer un gran diseño sin preocuparse por los detalles de implementación.

¿Tengo razón al pensar de esa manera? ¿Hay alguna razón por la cual un analista de negocios necesitaría conocer la tecnología utilizada para implementar el sistema?

EDITAR: Creo que usé el término incorrecto al decir business analyst. Quizás quise decir arquitecto o analista de sistemas. No estoy acostumbrado a estos términos. Me refería a algo como arquitecto o analista de sistemas si lo prefieres.

¡Gracias a todos por sus increíbles respuestas! Todavía no tengo mucha experiencia y me alegro de que me hayas abierto los ojos.


8
¿Le pidió un ejemplo de cuándo marcaría la diferencia?
Karl Bielefeldt

No me dio un ejemplo, pero estamos utilizando una amplia gama de tecnologías que van desde sistemas AS / 400 antiguos, algunos Delphi y luego .Net para cualquier cosa nueva. Aún así, yo creo que si se quiere diseñar algo que es para ser implementado en RPG, usted diseñará de la misma forma en C # utilizando la separación de preocupaciones, y una capa adecuada para la lógica de negocio, etc
marco-fiset

Necesitaría saber tanto como el usuario. AS / 400 vs una aplicación web es un detalle que necesitaría.
codificador

2
La diferencia estaría en la parte "entonces tienes que presentar algo al usuario". El analista de negocios necesitaría saber qué tipo de interfaz de usuario se está utilizando y qué opciones están disponibles. Existen herramientas que los analistas de negocios pueden usar y que esencialmente les permiten definir lo que debería suceder funcionalmente cuando un usuario hace x (como hacer clic en un botón). Si la plataforma no tiene un botón (pantalla verde), esa es una información útil.
codificador

1
@marcof: La interfaz de usuario ideal sería donde el usuario piensa un pensamiento, y lo que quiere que se haga simplemente se hace. Cualquier cosa menos que eso se ve mermada por las limitaciones de la tecnología que tenemos a nuestra disposición, así que por supuesto el BA tiene que entender qué contexto se pueden diseñar en el sistema.
gahooa

Respuestas:


18

Ciertamente, hay casos en los que tiene sentido que un analista de negocios comprenda la tecnología al menos lo suficientemente bien como para entender dónde tiene sentido interrogar a un usuario de negocios sobre la importancia de una característica en particular. Por ejemplo, si el negocio está acostumbrado al comportamiento de una aplicación de cliente pesado mientras la nueva aplicación va a estar basada en la web, es probable que haya muchos "requisitos" que serían triviales en un cliente gordo pero relativamente difícil con una aplicación basada en web. Si el analista de negocios entiende si una solicitud de la empresa será trivial para el equipo de desarrollo o si implicará 20 horas de desarrollo de AJAX,

Para cualquier proyecto dado, es probable que haya una gran cantidad de conjuntos de requisitos que en realidad satisfarían al negocio al hacer varios tipos de compensaciones. Mientras más comprenda el analista de negocios acerca de las compensaciones que está haciendo, es más probable que entregue un conjunto de requisitos que maximice el beneficio para el negocio y minimice el costo.


44
+1 para "maximiza el beneficio para el negocio y minimiza el costo". Eso no se puede hacer sin que el BA comprenda la tecnología. El trabajo del BA es comprender más tecnología que el programador, a un nivel superior.
mattnz

Además, no se deben cambiar los requisitos, sino las restricciones que afectan la implementación de esos requisitos. El hecho de que la empresa no pueda obtener lo que quiere no significa que deba dejar de desearlo, aunque sí los obliga a racionalizar lo que pueden tener ahora . Por ejemplo, tener un mal trabajo ahora no me impide querer uno mejor, simplemente no se puede lograr con las limitaciones actuales. Lo importante es que abre la oportunidad de que si se elimina una restricción, el requisito ahora puede cumplirse. Si cambia el requisito por ahora, lo pierde para siempre
BiGXERO

8

Después de haber trabajado en ambos lados de este problema, tengo que estar de acuerdo con el analista. He visto algunos diseños espectacularmente pobres como resultado de la falta de comprensión de las capacidades de la tecnología. En algunos casos, ha sido el resultado de tomar el marketing publicitario como verdad. En general, el problema ha sido generar especificaciones que no coinciden con las capacidades técnicas.

El analista debe especificar qué debe hacerse, cuándo y por quién. Deben saber por qué se está haciendo. La prioridad de desarrollo debería depender más del porqué que los otros factores. El equipo de diseño y desarrollo necesita manejar el Cómo. Para desarrollar sistemas rentables, los analistas deben especificar qué debe hacerse en términos que no superen los límites de la tecnología disponible.

Empujar los límites puede aumentar los costos de varias maneras, pero en algunos casos puede tener un retorno significativo. Algunos de los factores de costo son:

  • Puede ser necesario experimentar para desarrollar una solución de trabajo;
  • Puede ser necesario adquirir nuevos empleados o consultores con conocimiento especializado;
  • Se puede necesitar capacitación sobre la nueva tecnología;
  • El desarrollo tiende a ser más lento y las tasas de errores más altas; y
  • Los esfuerzos adicionales pueden retrasar soluciones más simples que tienen un valor más inmediato.

6

Si se conoce la tecnología que se utilizará, los analistas deben tenerla en cuenta al crear el diseño. Las diferentes tecnologías hacen las cosas de manera diferente y un diseño que no tenga en cuenta esas diferencias tendrá problemas.

Sin embargo, los analistas de negocios no deberían preocuparse por la tecnología utilizada, su trabajo es recopilar las reglas comerciales y hacerlas comprensibles para el equipo técnico. Los analistas de sistemas / arquitectos / diseñadores o cualquier otro nombre que se les pueda dar deben conocer las tecnologías que se utilizan y diseñar a su alrededor, ya que deberían ser ellos los que realicen el diseño real, no los analistas de negocios.


6

Creo que hay un punto entre las dos líneas de pensamiento que probablemente sea más realista. Si bien un diseño de alto nivel podría ser mejor cuando se mantiene la tecnología independiente, debe tenerse en cuenta las limitaciones y requisitos conocidos del mundo real que deben incorporarse al diseño. ¿De qué nivel es este diseño? ¿Tienes suficientes requisitos? ¿Qué tan flexible es el medio ambiente? ¿Se invierte la dirección en una dirección técnica específica?

¿No hay parámetros operativos que lo conduzcan en una dirección específica? ¿Tiene una amplia gama de recursos capaces de implementar una solución en cualquier pila de tecnología? ¿Existen problemas de interoperabilidad que requieren acceso a otros sistemas?

Se necesitan respuestas a estas preguntas antes de que pueda decir definitivamente si la tecnología debe ser parte de la ecuación o si el diseño debe impulsar la selección de la tecnología.

Dado que no hay restricciones y es un diseño de muy alto nivel, podría estar de acuerdo con su opinión de que el diseño sea verdaderamente agnóstico. Sin embargo, en mis más de 20 años de experiencia, rara vez he estado en una situación en la que no hubiera restricciones que limitaran mis opciones, y que impulsaran mi diseño hacia tecnologías específicas o familias tecnológicas.


3

La interfaz de usuario ideal sería donde el usuario piensa un pensamiento, y lo que quiere que se haga simplemente se hace. Cualquier cosa menos que eso está paralizada por las limitaciones tecnológicas que tenemos a nuestra disposición, por lo que, por supuesto, el BA necesita comprender en qué contexto pueden diseñar el sistema.


2

Las diferentes tecnologías pueden tener estructuras de costo y eficiencia muy diferentes para resolver un problema dado. Estos costos pueden incluir cosas como los costos de contratación en el área local, los costos de energía y enfriamiento para sistemas específicos, el código existente y las posibilidades de reutilización de equipos existentes, etc., etc. Entonces, sí, tal vez uno pueda ignorar estas restricciones y detalles de tecnologías específicas si se está trabajando en un proyecto donde el costo y la eficiencia no son tan importantes como otras consideraciones (como la seguridad de la aviación, el control de la planta nuclear, los implantes médicos, etc.). Pero para la mayoría de las situaciones comerciales, la administración podría preocuparse por la estructura de costos de las posibles soluciones frente a los beneficios de la implementación del sistema.


1

El analista de negocios debe saber qué tipo de aplicación estamos desarrollando como * Aplicación web / Aplicación de consola / Aplicación móvil / Aplicación de informes, etc. * para que pueda idear mejor un buen conjunto de características para la aplicación o hacer retroceder al usuario en expectativas imposibles como arrastrar y soltar anidadas de tercer nivel (por ejemplo).

Él / Ella no necesita saber qué tecnología como Java / C # / Python / SQL, etc.


1

El proceso de análisis en sí mismo debe ser completamente independiente de la tecnología. Cuando investiga al cliente y sus necesidades, debe hacerlo con una mente completamente abierta. Sin embargo, el otro lado de la moneda es que a menudo se le pide al analista que brinde recomendaciones y también se le puede solicitar que maneje la arquitectura del sistema. Esta es una faceta completamente diferente del rol en el que una comprensión más amplia de las tecnologías disponibles es crucial, ya que puede marcar una gran diferencia para el cliente no solo en términos de la capacidad de poner en marcha un proyecto, sino también en términos de las necesidades a largo plazo del cliente y la sostenibilidad del proyecto en sí.

Si bien es cierto que la mayor parte del diseño de software es esencialmente la misma, independientemente de la tecnología utilizada, siempre hay áreas en las que el diseño estará influenciado por la elección de la tecnología. Las opciones de plataforma pueden influir en las opciones de idioma y API, mientras que la disponibilidad de experiencia, soporte e incluso el costo también tendrán un impacto en las elecciones realizadas. Entonces, desde una perspectiva, parte de su posición se justifica porque el análisis real debe realizarse sin la influencia de ninguna tecnología específica, sin embargo, usar el análisis para determinar un diseño siempre requerirá un conocimiento tecnológico más amplio, de modo que el analista pueda hacer recomendaciones lo que permitirá la aplicación de diseños destinados a satisfacer las necesidades del cliente.


0

Cada tecnología tiene límites y restricciones, por lo tanto, tiene sentido que un analista considere esos límites. Por otro lado, un analista que conozca bien .net, pero que no haya visto Java desde finales de los años noventa, muy probablemente diseñará una solución .net, utilizando terminología .net y patrones de diseño, incluso si Java (o RoR, etc.) encajaría mejor con el problema. Es relativamente difícil implementar dicho diseño en otra tecnología más adelante.

Por lo tanto, creo que un analista debe ser agnóstico cuando la tecnología aún no se ha seleccionado, pero tiene experiencia en aquellos casos en los que la elección ya se ha hecho.


¿No son los patrones de diseño independientes del lenguaje?
marco-fiset

2
Por lo general, no están vinculados a un idioma específico, pero algunas pilas de tecnología pueden hacer que sean más fáciles de implementar que otras. Un diseño hecho con ASP.net MVC en mente podría ser engorroso de implementar en PHP o Oracle Application Express.
user281377
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.