ソフトウェアアーキテクトとして、ログの分析と他の人のバグの修正にそれほど重点を置くべきですか？
卒業後（2005年後半）、c ++ソフトウェアエンジニアと同じ会社で働いていました。 1年前、私はソフトウェアアーキテクトとして昇進しましたが、認定とバグの修正、レベル2のサポートにますます関与するようになりました。
私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったかを解明しようと費やしました。 30％が他の人のバグを修正し、残りの（ある場合）開発者のスパゲッティコードをレビューします。
この製品が嫌いになり、この会社の出口戦略について考え始めました。
この状況で私は何ができると思いますか？他のソフトウェアアーキテクトはまだコードのバグを修正していますか？
ほとんどの人は、ソフトウェアアーキテクトが主に高レベルの設計、標準の設定、ツールまたはフレームワークの選択、製品の評価、プロトタイプと概念実証の実装、および開発者のトレーニングとメンタリングに関与することに同意します
ただし、実際には、タイトルはしばしば開発者への政治的任命、プロジェクトの開発者をリードするために与えられる特別なタイトル、または給与やレートでひどく必要な開発者を雇うための管理人事の回避策のような単純なものである場合があります人事部または上級管理職は、ソフトウェア開発者またはソフトウェアエンジニアの肩書きには受け入れられないでしょう。
つまり、タイトルはほとんど無意味です。
ウィキペディアの記事では ソフトウェアアーキテクト を次のように定義しています。
a コンピュータプログラマ whoは、高レベルの設計選択を行い、ソフトウェアコーディング標準、ツール、またはプラットフォームを含む技術標準を指示します。 ..
上記のように、あなたの見積もり「費やした私の時間の50％...ソフトウェアログの分析...他のバグを修正する30％」はあなたを遠くに連れて行きますfarソフトウェアアーキテクトが通常行うことを期待されていることから。
- 私は上記が彼らがあなたに与えたタイトルを作ると言います
50+30=80%偽物。
それ自体、ログの分析や他のバグの修正などのアクティビティは、アーキテクトの時間の一部を正当に占める可能性があることに注意してください-これらがこの役割の主な目的を提供する場合-つまり、高レベルの設計選択を行い、技術基準を確立します。実際には、これはあらゆる種類のソフトウェア開発/保守/テスト活動に当てはまります。
たとえば、ログを分析した結果、設計、ツール、またはコーディング標準を改善することで、ログをより簡単にする方法についての洞察が得られた場合、これは建築家にとって完全に正当な努力です。同様に、特定のバグを修正するために建築家が手を汚すことは完全に問題ありません-これがバグ率の低下につながる特定の設計/プロセスの改善につながる場合など。
もう少し肯定的なメモとして、あなたの質問は、建築家にとって非常に重要な少なくとも1つのスキルを示しています。さまざまな種類のアクティビティを分類し、これらに費やされた作業を追跡する能力です。 「ツールボックス」の補足スキルを追加して、観察結果と推定値を要約し、特に管理のはしごでこれらを明確に伝えることを検討してください。 :)
ソフトウェアアーキテクトとして、ログの分析と他の人のバグの修正にそれほど重点を置くべきですか？
だと思う？はいといいえ。あなたは製品の品質と進化の道の全体を担当します-明日それを機能させるだけでなく、来年も機能させます。
それは、困難な問題を解決するための支援の手を貸すことを意味しますか？絶対に-少なくとも私はします。あなたの顧客があなたを去ると、あなたはその製品を明日働かせることができません。
それはあなたがすべての時間をそれに費やすべきだという意味ですか？絶対違う。品質と進化のTOTALITYを担当します。問題を追跡するために多くの時間を費やすことは逆効果です。
あなたは積極的であるはずです：
- 他の人々（開発/サポート）が負荷を持ち上げられるように、教育計画を開始します。 「人に釣りを教える」など、すべてのジャズ。
- より迅速かつ容易な欠陥分析と根本原因の分離をサポートする方法を考案し、ツールを開発します。この退屈な作業を見つけたら、才能のない、または経験の浅い他の開発者は、これを退屈なだけでなく、困難で恐らく気が遠くなるかもしれません。彼らが技術によってこれを克服するのを助けてください。
- 製品の品質を高めるための取り組みを開始します-単純化、モジュール化、テストフレームワークの作成-愚痴や辞任の脅しではなく、模範を示してください。
- 開発者があなたが何をしているのか、そしてあなたのマネージャーも知っていることを確認してください。アーキテクトの役割は、他の人との関係よりも、コーディングと分析に関するものです。あなたがこれを嫌うかもしれないのと同じくらい、政治がここで鍵を握っています。同僚に自分の成果を確認することで、後で自分が正しいことを相手に納得させることが容易になります。まだそこにいない場合は、研究とPOCで主張を裏付けます。
- 他のすべてが失敗した場合、そして物事を改善するために時間を費やした後にのみ、マネージャーに相談してください。あなたのスキルが計画および設計段階でよりよく使用されていると言い、現在の状況を変えるために何ができるかを見てください。あなたの製品は危機に瀕しているかもしれず、あなたのマネージャーの答えは「私たちは今ここでこのことのためにあなたを必要としている」かもしれません。私は長期計画を主張しますが、現在の状況をどのように変えるのでしょうか。
建築家の役割は特権だと思います。あなたは他の多くの人ができない方法で製品に影響を与えるようになります-あなたより理論的に影響力のある唯一の人は彼の製品R＆Dマネージャー（そしておそらく、マーケティング）です-しかし彼は忙しく管理する方法です。
ソフトウェアアーキテクトの役割は、伝統的にバグを修正することではありません。ソフトウェアアーキテクトはソフトウェアの設計問題を修正する手助けをするので、もしバグによってソフトウェアが設計されたコアな方法が拡張性や保守の脆弱性や困難に向いているなら、それはSAの仕事ですその問題を解決するためにソフトウェアの側面を提案または再設計する。
あなたが言ったことを考えると：
私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったかを解明しようと費やしました。 30％が他の人のバグを修正し、残りの（ある場合）開発者のスパゲッティコードをレビューします。
それは本当のSAの役割ではなく、代わりに私が開発者1と開発者2レベルのプログラマーに上級開発者と共に始めてもらいたいことです。特に私がそれが私たちの会社の新しい開発者がコード品質の問題にそのレベルで取り組むことによって製品とコードに入るのを本当に助けるのを見つけるのでそれを言います。あなたはあなたの会社の新しいSAであり、システムに参加するためにこの作業を行わせていますか？もしそうなら、多分それはしばらくの間大丈夫です。これがあなたの毎日の仕事であり、1年以上経過している場合は、おそらく別の役割を探すときです。
ご不便をおかけして申し訳ございませんが、コードを書いたか、最後に触れた方がいいか、時間が短く、連絡が取れるかなど、役職に関係なく、多くのマネージャーが問題を解決するためにあなたのところに行きます。
危機に瀕している開発グループにまだ友達がいることを考えれば、助けになります。問題は、彼ら、そしてさらに重要なことに彼らの管理があなたを助けることに慣れてきたら、彼らは戻ってき続けることです。 「善行は罰せられない」と言うように。タイトルに関係なく、問題を修正するために彼らがあなたを頼りにすることができるなら、あなたはただの別の開発者であり、彼らが使用できる他の誰かです。
それは解決するのが難しい問題ですが、私のアドバイスは：
この非ソフトウェアアーキテクトプロジェクト時間のプロジェクトの請求番号を尋ねます。私は、プロジェクトマネージャーがあなたの時間について責任を負う必要がある場合、その時間を求めるのに熱心ではないことに気づきました。
どのくらいの時間が失われているか、どのグループまたはプロジェクトにいるかについてマネージャーに話します。あなたのマネージャーは彼らを助けないようにあなたに言って、彼のプロジェクトに集中し続けるかもしれません。もしそうなら、他のグループがやって来て助けを求めます、あなたは彼らの上司も言っていないことを彼らに伝えます。
優先順位を明確に保ちながら作業を整理し、アーキテクチャプロジェクトの外部にあまり反応しないようにします。
アーキテクトのように振る舞い、同僚にあなたをアーキテクトとして見てもらいましょう。これまでずっとそうであった同じ開発者ではありません。自分を開発者として扱う習慣を他の人が破ってしまった。
幸運を。
いいえ、あなたは全体像を管理するためにここにいます。
管理上の問題があります：バグの修正とコード品質の向上は開発者の仕事です。アーキテクトとして、ガイドラインと実際のアーキテクチャ（UMLまたはボートに浮かぶもの）を発行し、これらのガイドラインに正しく従うように定期的なコードレビューを行う必要があります。 。
ただし、コアアーキテクチャにバグを実装して修正することはできます。
例：WPF/C＃プロジェクトのPRISM、MEFなどで作業しますが、スプラッシュスクリーンを表示するためにXAMLで作業しません。
あなたはDB設計に取り組みますが、CRUD操作用のストアード・プロシージャーは作成しません。
等.
私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったかを解明しようと費やしました。 30％が他の人のバグを修正し、残りの（ある場合）開発者のスパゲッティコードをレビューします。
これは間違いなく、この役割のために行うべきではないタイプの作業です。私の経験/観察によれば、architectは、アプリケーションの設計、改善、技術要件の明確化、および潜在的なパフォーマンスの問題に関与する必要があります（毎日ログをチェックするのではなく、主に分析重大な問題/ errors）対処または回避する必要があります。
つまり、私のポイント＃1は-アーキテクトとは、テクノロジーの内部の仕組みがどのように機能/適用され、使用される必要があるかについての実践的な経験を持つ、高レベルの設計者およびシステムインテグレーターです。
コード品質を割り当てて管理する機会がある場合は、作業管理スキルを向上させる必要があります。したがって、計画作業は、「作業を行う方法」アプローチの優先事項です。
ポイント＃2：あなたがこれらのアプリケーションの数少ない開発者の1人である場合-このタイトルは、新しい「修正」ロールを維持するための、会社経営者による単なる別の魅力です。 ファンシーなタイトル。
答えの一部は、この負荷に喜んで取り組むエンジニアを見つけることです。
もちろん、これが問題である理由は、この作業が望ましくないと感じたためであり、他のエンジニアにとって魅力的であるというメッセージを送信しないため、彼らもそれを取り上げようとはしていません。
私には2つの可能性があります。
あなたは建築家のポジションを与えられたので、あなたはより大きな絵のアイテムに取り組むことができました。
この場合、下位レベルのサポートの役割を引き受けるためにステップアップした人がいないため、これらの大きな問題に取り組むことができないことを経営陣に伝える必要があります。それが解決すべき彼らの問題です。タイトルは主に儀式的です-あなたを周りに保つためにあなたに投げられる骨。
この場合、管理者はサポートの負荷を軽減することにあまり興味がないかもしれません。
-
間違いなくnotがあなたの目標に役立つ1つのことは、あなたの質問で漏れていると思う他の開発者やエンジニアを軽蔑する態度を採用することです。これらの人々にステップアップして自信を持ってこれらの問題を処理してもらい、そうする必要がないようにする必要があります（途中で間違いを犯す可能性があります）。彼らがあなたが彼らの解決策をただ悪口をつけ、後で彼らのためにそれを修正することを彼らが知っているなら、彼らはおそらくこれまでステップアップしないでしょう。
ソフトウェアアーキテクトの役割は、現在の会社で行っていることよりもはるかに重要です。彼はソフトウェア設計標準の定義、高レベルの設計、コーディングの標準化などを担当しており、バグの修正は実際にはそうではないと考えられたほんの一部に過ぎないと考えられます。しかし、あなたが言ったように、あなたは製品に取り組んでいます、それはつまり、ソフトウェアアーキテクトであることを意味し、製品の信頼性に対するあなたからの期待は非常に高くなり、そのような場合、そのようなことへのあなたの関与は、あなたはそれでかなり経験があるので、製品だけでなく会社も助けてください。ただし、現在の組織への関心を喚起する、新機能の開発や新しいタスクへの露出も提供する必要があります。