Como arquitecto de software, ¿debo centrarme tanto en analizar los registros y corregir los errores de otros?

La mayoría de la gente generalmente está de acuerdo en que un Arquitecto de software debe participar principalmente en el diseño de alto nivel, establecer estándares, elegir herramientas o marcos, evaluar productos, implementar prototipos y pruebas de conceptos, y capacitar y asesorar a los desarrolladores

Sin embargo, la realidad es que el título a menudo puede ser un nombramiento político para un desarrollador, un título especial otorgado a los desarrolladores líderes de proyectos, o incluso algo tan simple como una solución de gestión de recursos humanos para contratar a un desarrollador muy necesitado con un salario o califique que HR o la gerencia superior consideren inaceptable el título de Desarrollador de software o Ingeniero de software.

En otras palabras, los títulos en su mayoría carecen de significado.

El artículo de Wikipedia define a arquitecto de software como:

  

un programador informático que toma decisiones de diseño de alto nivel y dicta estándares técnicos , incluidos estándares de codificación de software, herramientas o plataformas ...

Dado lo anterior, sus estimaciones "el 50% de mi tiempo dedicado ... analizando los registros del software ... el 30% solucionando los errores de otros" lo alejó lejos de lo que normalmente se espera que haga el arquitecto de software.

• Yo diría que arriba hace que el título que te dieron sobre 50+30=80% falso.

Tenga en cuenta que per se, actividades como analizar registros o corregir errores de otros pueden ocupar legítimamente parte del tiempo del arquitecto, siempre que estos tengan el propósito principal de este rol, es decir, hacer un diseño de alto nivel Elecciones y establecimiento de normas técnicas. En realidad, este es el caso de cualquier tipo de actividades de desarrollo / mantenimiento / prueba de software.

Por ejemplo, si analizar los registros lo condujo a una idea de cómo hacerlo más fácil, mejorando el diseño, las herramientas o los estándares de codificación, este sería un esfuerzo perfectamente justificable para un arquitecto. De manera similar, podría ser completamente correcto que los arquitectos se ensucien las manos al corregir errores en particular, siempre y cuando esto resulte en mejoras de diseño / proceso específicas que lleven a una menor tasa de errores, etc.

_{En una nota un poco más positiva, su pregunta demuestra al menos una habilidad que es bastante importante para el arquitecto: la capacidad de clasificar diferentes actividades de tipo y rastrear los esfuerzos dedicados a estas. Considere agregar a su "caja de herramientas" habilidades complementarias para resumir sus observaciones y estimaciones y comunicarlas claramente, especialmente en la escala de gestión. :)}

  

Como arquitecto de software, se supone que debo centrarme tanto en el análisis   ¿Los registros y la corrección de errores de otros?

Se supone que? si y no. Usted está a cargo de la totalidad de la calidad del producto y la trayectoria de la evolución: haga que funcione mañana, pero también que funcione el próximo año.
¿Eso significa dar una mano para resolver problemas difíciles? Absolutamente - al menos lo hago. No puedes hacer que el producto funcione mañana si tus clientes te dejan.
¿Eso significa que debes dedicar TODO tu tiempo a eso? Absolutamente no. Estás a cargo de la TOTALIDAD de la calidad y evolución. Dedicar tanto tiempo a la búsqueda de problemas es contraproducente.

Se supone que debes ser proactivo:

1. Inicie planes de educación para que otras personas (dev / support) puedan levantar la carga. "Enseña a un hombre a pescar" y todo ese jazz.
2. Invente formas y desarrolle herramientas para respaldar el análisis de defectos y el aislamiento de causas raíz de forma más rápida y sencilla. Si encuentra esto aburrido, otros desarrolladores, posiblemente menos talentosos o con experiencia, encontrarán esto no solo aburrido, sino también difícil e incluso desalentador. Ayúdalos a superar esto con la tecnología.
3. Comience un esfuerzo para mejorar la calidad del producto: simplifique, modularice, cree marcos de prueba, lidere con el ejemplo, no quejándose y amenazando con dejar de fumar.
4. Asegúrese de que los desarrolladores sepan lo que está haciendo, pero también sus administradores. Un rol de arquitecto es mucho más sobre las relaciones con otras personas que sobre la codificación y el análisis. Por mucho que puedas odiar esto, la política juega una clave aquí. Asegurarse de que sus compañeros vean sus logros hace que sea más fácil convencerlos más adelante de que tiene razón. Si aún no está allí, respalde sus reclamos por investigación y POC.
5. Si todo lo demás falla, y solo después de dedicar tiempo a mejorar las cosas, hable con su gerente. Diga que sus habilidades se utilizan mejor en las fases de planificación y diseño y vea qué se puede hacer para cambiar la situación actual. Su producto podría estar en un apuro y la respuesta de su gerente podría ser "lo necesitamos para esto aquí y ahora". Sin embargo, insistiría en un plan a largo plazo: ¿cómo vamos a cambiar la situación actual?

Veo el papel de un arquitecto un privilegio. Puede influir en el producto de una manera que no lo pueden hacer muchas otras personas; la única que, en teoría, es más influyente que usted es el gerente de R & D del producto (y, posiblemente, marketing), pero está muy ocupado en la gestión.

El rol de un Arquitecto de Software tradicionalmente no los tiene arreglando errores. Los arquitectos de software ayudan a solucionar los problemas de diseño en el software, de modo que si por error te refieres a la forma central en que se diseñó el software se presta a una mayor fragilidad o dificultad para expandir / mantener, entonces el trabajo de la SA será proponer o rediseñar aspectos de la arquitectura. software para resolver ese problema.

Dado lo que dijiste:

  

50% de mi tiempo dedicado a Notepad ++ analizando los registros del software e intentando averiguar qué fue lo que no funcionó. 30% corrigiendo los errores de otros y el resto (si alguno) revisando el código spaghetti de los desarrolladores.

Ese no es el rol de un verdadero SA y, en cambio, es más de lo que haría que nuestros programadores de nivel de desarrollador 1 y desarrollador 2 empiecen con un desarrollador senior. Lo digo en particular porque creo que realmente ayuda a los nuevos desarrolladores de nuestra empresa a ingresar al producto y al código trabajando en ese nivel en temas de calidad de código. ¿Eres un nuevo SA en tu empresa y te están haciendo hacer este trabajo para ingresar al sistema? Si es así, tal vez eso está bien por un corto tiempo. Si este es su trabajo diario y lo ha sido durante más de un año, entonces posiblemente sea hora de buscar otro rol.

Entiendo tu frustración, pero entiendo si escribiste el código o si fuiste el último en tocarlo, el tiempo es corto, y pueden contactarte, muchos gerentes van a acudir a ti para arreglarlo, independientemente de tu título.

Suponiendo que todavía tienes amigos en el grupo de desarrollo que está en la crisis, ayudarás. El problema es cuando ellos, y lo que es más importante, su administración se acostumbra a ayudarlo, siguen regresando. Como dice "ninguna buena acción queda impune". Si pueden contar con usted para solucionar los problemas, independientemente de su título, usted es solo otro desarrollador y otra persona que pueden usar.

Es un problema difícil de resolver, pero mi consejo es:

1. Pregunte por el número de cargo para el proyecto de este proyecto que no es arquitecto de software. Me parece que los gerentes de proyectos no están tan ansiosos por pedir su tiempo, si tienen que ser responsables por ello.

2. Hable con su gerente sobre cuánto tiempo se está perdiendo y a qué grupos o proyectos. Su gerente puede decirle que no los ayude y que se mantenga enfocado en sus proyectos. Si es así, entonces el otro grupo viene y le pide ayuda, usted les dice que su jefe también dijo que no.

3. Organice su trabajo, mantenga sus prioridades claras y no responda a los proyectos de arquitectura.

4. Actúa como un arquitecto, haz que tus compañeros te vean como un arquitecto, no como el mismo desarrollador que has sido durante todos estos años. Ha roto con el hábito de tratarlo como desarrollador.

Buena suerte.

No, estás aquí para administrar el panorama general.

Usted tiene un problema de administración: corregir errores y mejorar la calidad del código es tarea de los desarrolladores. Como arquitecto, debe emitir directrices y arquitectura real (UML o lo que sea que haga flotar su barco) y luego realizar revisiones periódicas del código para garantizar estas pautas. se siguen correctamente.

Sin embargo, puede implementar y corregir errores en la arquitectura central.

Ejemplo: trabajaría en PRISM, MEF, etc. en un proyecto WPF / C #, pero no trabajaría en el XAML para mostrar la pantalla de bienvenida.

Trabajaría en el diseño de DB pero no escribiría procedimientos almacenados para operaciones CRUD.

etc.

Parte de la respuesta sería encontrar un ingeniero que esté dispuesto a asumir esta carga.

Por supuesto, la razón por la que esto es un problema es que este trabajo no es deseable, lo que no envía el mensaje de que es atractivo para los otros ingenieros, por lo que tampoco están ansiosos por hacerlo.

Veo dos posibilidades.

1. Le dieron la posición de arquitecto para que pudiera trabajar en elementos de imagen más grandes.
   En este caso, debe mencionar a la administración que no puede trabajar en estos elementos de imagen más grandes porque nadie se ha ofrecido para asumir el rol de soporte de nivel inferior. Ese es entonces su problema para resolver.

2. El título es en gran parte ceremonial: un hueso que te arrojamos para mantenerte cerca.

En este caso, es posible que la administración no esté muy interesada en facilitar su carga de soporte.

-

Una cosa que definitivamente no será útil para su objetivo es adoptar una actitud de desprecio hacia los otros desarrolladores e ingenieros que veo que se filtran en su pregunta. Desea que estas personas se pongan en pie y manejen estos problemas con confianza para que no tenga que hacerlo (posiblemente cometer algunos errores en el camino). Si saben que simplemente hablarán mal de sus soluciones y las solucionarán después, es probable que nunca vayan a mejorar.

  

50% de mi tiempo dedicado a Notepad ++ analizando los registros del software e intentando averiguar qué fue lo que no funcionó. 30% corrigiendo los errores de otros y el resto (si alguno) revisando el código spaghetti de los desarrolladores.

Este es definitivamente un tipo de trabajo que NO debes hacer para este rol. De acuerdo con mi experiencia / observaciones, arquitecto debe participar en el diseño de aplicaciones, mejoras, aclaraciones de requisitos técnicos y posibles problemas de rendimiento (no revisar los registros a diario, sino analizar principalmente problemas / errores) que deben abordarse o evitarse.

En otras palabras, mi punto # 1 es: los arquitectos son los diseñadores de alto nivel y los integradores de sistemas con experiencia práctica en cómo funcionan / aplican y deben usarse los trabajos internos de la tecnología.

Si tiene la oportunidad de asignar y administrar la calidad del código, entonces deben mejorarse sus habilidades de gestión del trabajo. Por lo tanto, el trabajo de planificación debe ser su prioridad en el enfoque de "cómo hacer el trabajo".

Punto # 2 : si eres uno de los pocos desarrolladores en estas aplicaciones, entonces este título es solo otro glaseado de azúcar por parte de la administración de la compañía para mantenerte en el mismo rol de "arreglarlo" con un nuevo título de fantasía .

El rol de un arquitecto de software es mucho más que lo que está haciendo en su empresa actual. Es responsable de definir los estándares de diseño de software, realizar diseños de alto nivel, estándares de codificación, etc., y la solución de errores puede considerarse solo una pequeña parte de lo que en realidad pensamos que no es. Pero, como ha dicho, está trabajando en un producto, es decir, siendo un arquitecto de software, la expectativa de usted respecto a la confiabilidad del producto será bastante alta y, en tal caso, su participación en tales cosas no solo Ayude al producto, pero también a la empresa, ya que tiene mucha experiencia en eso. Pero también debe contar con cierta exposición al desarrollo de nuevas funciones y nuevas tareas, que inculcarán su interés en su organización actual.

  

Como arquitecto de software, ¿se supone que debo concentrarme tanto en analizar los registros y corregir los errores de otros?

En cuestión de palabras, 'Sí'.

Así es como calificaría mi respuesta:

1. De forma predeterminada, debe permitir que los desarrolladores de software analicen los registros y corrijan los errores.
2. Sin embargo, ... usted debe ser consciente de los defectos que ocasionaron la pérdida de datos, requerir un retroceso oneroso de la base de datos, demorar mucho tiempo para que los desarrolladores lo resuelvan o pedir disculpas al cliente .
   1. Como regla general, sus informes directos deben informarle sobre dichos defectos.
   2. Debería crear una cultura en la que sus informes directos se sientan habilitados para informarle sobre dichos defectos, pero no obligados a hablarle de triviales.

Más sobre el # 2:

1. Estos tipos de defectos generalmente implican una falla arquitectónica. Cuando lo hacen, debe comprender la naturaleza precisa del defecto y diseñar una solución.
   1. Entonces, por extensión, debe estar listo, dispuesto y ser capaz de examinar los registros y corregir los errores de otras personas (incluso si no confirma directamente el código en el repositorio de código fuente).

La respuesta es probablemente no. ¿Por qué dedicas tanto tiempo a la depuración y problemas de soporte? ¿Alguien te está asignando ese trabajo?

Parece que necesitas aclarar lo que deberías estar haciendo. Es posible que necesite corregir errores; probablemente no debería ser la mayor parte de su tiempo.