フロントエンド開発者はどこに座っていますか？
こんにちは、ライター、トレーナー、UIアーキテクト、デザイナーのCXチームを管理しています。フロントエンドの開発者またはトランスレーターを介して開発者とより良い関係を築くことができるように、フロントエンドの開発者を追加することにより、能力を拡張するために取り組んでいます。フロントエンドがどこに座っているのかしら？彼らはUXと一緒に座っていますか、それともエンジニアリングに座っていますか？エンジニアリングではなくマーケティングまで報告しますが、これも標準とは少し異なります。
私が解決しようとしている問題のいくつかは次のとおりです。
- 将来使用するために再利用可能なコードとライブラリを構築する
- UI/UX設計の技術的な実現可能性を確保する
- 最大の速度とスケーラビリティのためにアプリケーションを最適化
- バックエンドに送信する前に、すべてのユーザー入力が検証されていることを確認します
- 開発者とUXの間のトランスレーターとしての役割を果たす
ご協力ありがとうございました！
古い会社では、バックエンド開発者の近くに座っています。したがって、基本的には外部機関からデザインを受け取り、実装後にバックエンドを使用してコードの実装を支援し、必要に応じて変更を加えます。
新会社では、バックエンドがAPIを構築し、完全なソリューションを上から下まで提供します。 APIに関する質問がない限り、それらは必要ありません。彼らが本当に奇妙な構造を中に作ったなら、それは起こります。覚えておくべきことは、APIは可能な限りフラットである必要があるため、UIは重い処理を行わないため、アプリケーションが高速になるということです。したがって、バックエンドの人にフロントエンド用のapiを作成するように強制します（これは、今日の考え方では難しいですが、そのバックエンドはアプリケーションの主要なアーキテクチャです）。経験上、バックエンドはフロントエンドの開発プロセスを遅くし、クリーンなコードを実行しないようにします。
最良のワークフローは、フロントエンドが設計チームと緊密に連携することです（通常、これらはパターンに従っていないため、フレームワークを使用してプロセスを高速化すると、最終的にはフレームワーク自体に対して機能します。デザインに従う）。アプリケーションを開発し、api構造のmock.json構造を構築するためのフロントエンド。そして、それをバックエンドに渡します。フロントエンドは、バックエンドの前に4つではなくても3ステップである必要があります。最適化、seo、バグ、ビジネス要件の変更、デザインの変更などを忘れないでください...
幸運を ;）
pS最終的には、フロントエンドはWeb開発とデザインの最新のトレンドをすべて把握しているフロントエンドであり、それに対応できるバックエンドはないことを覚えておく必要があります。
理想的には、彼らは一人で自分のオフィスに座っているので、他の開発者の気を散らすことも、すぐに気を散らすこともありません。調査によると、開発者の注意散漫により、毎年数百万ドルが失われています。基本的に、支援を見つけてチームメイトとやり取りするのをより速くするために、戦略的に配置する場所を尋ねているように聞こえます。理想的には、チームメンバーが1日中絶えず相互にやり取りしたくない場合です。開発者は、中断することなくコードを作成するための時間の「ブロック」を必要とします。その右側では、チームメイトの気を散らすことは彼らにとって都合の良いものではないので、彼らが実際にどこに座っているかは問題ではありません。
しかし、彼らが非常にインタラクティブなオープンなSCRUMタイプの環境に座っている場合、エンジニアと言います。フロントエンド開発者は開発者です。また、専用のUI担当者がいる場合は、フロントエンドの担当者はまさにそれである必要があります...開発者。彼らが書いているコードはバックエンドのコードと互換性がなければならないので、彼らは中間層とバックエンドの開発者ともっと対話する必要があるでしょう。
ただし、正直に言うと、専用の「層」開発者がいるチームで作業するのはやめたいと思います。私の経験では、そのような環境を維持するのは境界線上不可能であり、人々は最終的にお互いのつま先を踏んでしまいます。私は各人が専用のプロジェクトを持っているチームで作業することを好みます。しかし、それは私です。
私はあなたの質問のこの点を心配しています、あなたがこれをまったく求めている理由の核心にあるかもしれないと私は感じています：
フロントエンドの開発者またはトランスレーターを介して開発者とより良い関係を築くことができるように、フロントエンドの開発者を追加することによって機能を拡張するように取り組んでいます。
...
- 開発者とUXの間のトランスレーターとしての役割を果たす
それは、フロントエンドの開発者の立場がそうではないことです！
さまざまなアプリケーション層の開発を異なる個人に分離するという問題にもかかわらず、これは、この質問に対する他の回答で提起された考慮に値する点です。
受け入れられているのは、フロントエンド開発者とは、アプリケーションのフロントエンド（ユーザーから見える部分）で作業する開発者のことです。
たとえば、Webベースのソフトウェアを製造している会社のフロントエンド開発者の立場を宣伝する場合、CSS、JavaScript、HTMLなどのテクノロジーに強い人とmightグラフィカルデザインや人間/コンピュータの相互作用に関する知識があるが、後者は主な焦点ではない。彼らは、何かがどのように見えてユーザーと相互作用するかについて合理的に堅実なデザインが与えられることを期待し、それらのことを実現するためのコードを書くことを任されます。
フロントエンドの開発者の立場を宣伝し、人々が開発作業を行う代わりに、他の開発者とUXチームの間で「翻訳」するよう求められることがわかった場合、せいぜい、応募者の受け入れ率は急降下し、それがそうしないと、あなたの保持率は急落します。
フロントエンドの反対側の開発者の立場は、UXチームと対話しない開発者ではなく、直接ユーザーに表示されないアプリケーションの部分（Webサービス、データベースコードなど）に取り組む開発者です。物）。
その他のポイント（将来使用するために再利用可能なコードとライブラリを構築し、UI/UX設計の技術的な実現可能性を確保し、アプリケーションを最適化して最大の速度とスケーラビリティを確保し、バックエンドに送信する前にすべてのユーザー入力を検証すること）は、とにかく、開発者はに向けて取り組んでいる（または向けることができる）べきです。開発者のanyがそうでない場合は、その理由を見つけて、その状況を修正するように努めます。物を欲する人と物を造る人の間に別の層を追加しても、そこには実際の違いはありませんし、どちらかと言えば、導入するように見えるでしょうリスク。
TL; DR：
UXと開発の接点として専任の担当者を任せることができるのは素晴らしいことですが、それは実際には開発の位置ではなく、誰かが理想的な 人間/コンピュータの相互作用 設計の役割ですプログラミングとソフトウェア開発の関連領域についての洞察。理想的には、この人物は、特に電子メールクライアントや画像ビューアーなどの一般的なものではなく、ニッチ市場を対象とする特殊なソフトウェアを構築する場合、構築するソフトウェアの使用に関する専門家でもある必要があります。
実際には、大企業でない限り、UXチームが望むもの（仕様、ユーザーストーリー、UIモックアップなどに基づいて）の実装可能性を確保する作業は、既存の開発チームのさまざまなメンバーにかかる可能性が高くなります。目の前の問題の焦点と個人のそれぞれのスキルに応じて。優れた開発チームは、「はい、私たちはあなたが望む方法でそれを行うことができ、X日かかるが、代わりにAをBに変更した場合、それを1/4の時間で完了する」または「確かに、私たちはあなたが望む方法でそれを行うことができますが、多くの人が期待する可能性が高いです代わりに[他の方法で説明してください]で動作するソフトウェア。」次に、UXチームは、利害関係者とともに、BではなくAを実行することが、追加の推定コスト（開発に費やされた時間/お金、および/またはソフトウェアの場合のユーザーの不満）に見合うかどうかを判断することになります ユーザーのメンタルモデルに違反している ソフトウェアの動作方法の違反）。
私自身、フロントエンドの開発者/エンジニアとして、デザイナーと協力することの方が価値があると思います。結局のところ、私はデザインをインタラクションに変える（これはデザインの形式です）を実行します。
デザインが正しく実装された後、データ依存のスニペットを、データ固有の開発者が簡単に「プラグイン」できるようにしておきます。
つまり、要するに。私は設計チームに「座って」いますが、データを特定のチームメイトに渡すためにコードを準備しています。
このアプローチで私が経験する唯一の問題は、開発者が既存のコードバインディングの相互作用の一部を壊す可能性のあるソリューションを見つけることがあるということです。その場合、その開発者と協力して問題を解決することが重要です。
仕事の種類で整理
フロントエンドdeveloperはDevelopmentと一緒に配置する必要があります。私の意見では、それは議論の対象ではありません。これにはいくつかの目的があります。
- 彼らは仲間と一緒に位置し、刺激を受けています。開発者。
- 彼らは、「それらの創造的なタイプの1つ」ではなく、チームの一員であることによって、より信頼性を獲得します。
彼らはソフトウェアを書きます。ソフトウェアのすべての側面は、「かなり」の部分だけでなく、ユーザーに影響を与えます。組織に人為的な線を引くと、その役割に対する価値観（肯定的または否定的）が伝達されます。そのメッセージは生産的ではありません。
開発者をエクスペリエンスチームに参加させると、理解できない一連の作業を評価および指示しようとするのが難しくなります。あなたは開発者ではないため、この役割に適切な目標と指標を設定することはできません。これは、プレートに追加する必要があるものではありません。
サイロを殺す
開発者とCXが異なるチームであるからといって、密接に連携していないわけではありません。反復的なプロジェクトに取り組み、それぞれの部門に報告する部門横断的なチームが答えです。テリトリーグラブと内紛でこの構造を妨害しない場合、結果が生成され、関心のある組織の不整合が解決されます。
フロントエンド開発者としての個人的な経験から、UI/UXチームと一緒に座っている方が便利だと思います。私はそれらのデザインを実際のプロトタイプに実装しています。UIを磨くのは簡単です。実装完了後も実装が進行するので、すぐに相談して批評できるからです。つまり、「フロントエンド開発者として、設計で遭遇する不確実性に関するガイダンスについて、UI/UXデザイナーに相談することがよくある」と要約します。何かについてバックエンド開発者に相談する必要はほとんどありませんでした。
私がコメントしたように、これは決定的に答えることは本当に不可能な質問です。それはすべて、会社とプロジェクト、およびその他の変数の数に依存します。
とは言っても、私は何度もこの立場にいて、UIの開発者がSCRUMチームに所属するためのシステム（私にとって、そして私が参加している会社でのプロジェクト）が最もうまく機能しているように見えました。
UXチームには、UI開発者も1人か2人いる可能性がありますが、ほとんどの場合、スプリントに先んじて作業する責任がありました。ただし、UI開発者は、これらの作業前のタスクに常にループし、途中で常にコンサルティングを行っていました。
メリットは次のとおりです。
- uXデザインがSCRUMチームに到達するまでに、UI開発者はすでに期待されていたことに精通しており、おそらくソリューションに貢献していた
- これにより、UI開発者はスプリント中に高速で物事を汲み上げることができ、残りの開発者はそれをすべて配線する時間を与えられました
- uXチームは不可能なことを設計していませんでした。 UXとテクノロジーを知っているUI開発者がいることで、スコープは現実的なレベルに保たれ、ソリューションは現実的なものではなく実際的でした（UXが実装とは無関係にソリューションを設計する純粋なウォーターフォールプロセスで常に発生することがわかります） ）