ソフトウェアアーキテクトとチームメンバーの関係は何ですか
私は100人未満の小さな会社で働いています。数ヶ月前、この会社は私にSAのポジションを提供し、私は受け入れました。この会社には3つのチームがあり、そのうちの1つで働いています。私がSAとして働くのはこれが初めてです。 。
過去数か月の間、私には管理の力がなく、チームメンバーに正しくてより効率的な方法で（コーディング関連の）ことをさせることさえできませんでした。チームメンバーは非常に基本的な技術的な質問について私と議論し、私は彼らに何度も何度も説明しなければなりません。一部のメンバーは私のアドバイスを受け入れましたが、他のメンバーは頑固にプログラムを作成し、最終的にはしばしば間違っていることが判明しました。
最近少し疲れて戸惑いました。ソフトウェアアーキテクトとチームリーダーを含むチームメンバーとの正しい関係は何でしょうか。また、ソフトウェアアーキテクトもチームリーダーが率いていますか？
ソフトウェアアーキテクトには管理能力がありません。これは私がコメントで言及した質問で説明されています：
ソフトウェアアーキテクトとして何をテーブルに持っていくべきですか？
スタッフアーキテクトはトップアンサーで説明されています：
SAは、すべての設計、テクノロジー、コーディングスタイルの決定について最後の言葉を持っている必要があります...ほとんどの場合...開発者は、問題をどのように解決するかを自分のレベルで決定できます。 ... SAは、先のとがった髪のボスを開発者のキュービクルから遠ざけます。
彼らがどのように彼らの仕事をするかについての良い説明は別の答えで提供されます：
厚い肌。優れた交渉スキル。
私自身も建築家であり、答えが私の経験と一致していることを確認できます。
さて、あなたが問題だと感じていること、チームメンバーとの意見の相違、そしてチームリーダーに従う必要性についてもう少し深く知りたいと思います。
注文する力がない人との意見の相違は、建築家の仕事の中で最も価値があり興味深い部分だと思います。あなたがそれについて絶えず気分が悪いならば、この仕事が本当にあなたのためであるかどうか真剣に考えてください。
頭の悪い「黙って私の命令に従う」ことでは解決できない意見の不一致は、建築家として進歩するためのユニークな機会を提供します。これらは、複雑な問題について話し合う方法、対立を交渉して解決する方法、物事を説明する方法、知識を伝え、新しいことを学ぶ方法を学ぶ方法です。これらは、チームメンバーを説得して影響を与えるスキルを練習する唯一の方法です。
特に運が良ければ、最初の理解が間違っているということについて意見の相違が生じることがあります。
思考を妨げる「私の命令に従う」エスケープハッチがないので、理解を深め、間違いを理解し、それを受け入れ、正しい方法を見つけ、共有し、導く方法を見つけることができます。
建築家の立場では、何がうまくいかなかったのか、何がうまくできたのか、そして獲得した経験を効率的に「再利用」する方法を分析することによって、そのような失敗から利益を得ようと努力したいと思います。 WP でのこの素晴らしい回答で説明されているように、これらの知識は正しく学べば非常に貴重なものになる可能性があります。
判断は成功からではなく、失敗から来ます。ほとんどの企業は、以前の企業によって失敗の代償を払われた人々を雇いたいと思っています...