エンジニアはあなたの最高のデザイナーです

テクノロジー企業で働いている人なら誰でも、製品設計者とソフトウェア開発者の違いを知っています。彼らは、さまざまなスキルセット、さまざまな責任を持ち、多くの点で脳の機能が異なります。デザイナーと開発者はあまり似ていないので、プロジェクトでそれらを分離しておくことは理にかなっています。

右?

従来は、マルチステッププロセスの個々のアクティビティに特化したサイロを作成し、スペシャリストを割り当てて、それらの独立した各ステップに専念していました。これは、製造プロセスへのかなり一般的な組立ラインのアプローチであり、現在もそうです。

それでも、組立ラインは本当に奇跡です。

上記のキーワードは製造業です。すべてが単一の青写真に基づいて同じ製品の何千ものユニットを生産している場合、そのアプローチは今日でも素晴らしいです(もちろん、組立ラインの作業に関与する人はそれほど多くありません)もう)。

絶え間ない技術革新の現代世界に移りましょう。イノベーションとは、定義上、何か新しいものを作成することを意味します。一般的に、ややカスタマイズされた、他にはないデジタル製品です。ここで最も簡単なことは、同じ馴染みのある組立ライン、ウォーターフォールアプローチを適用することです。

従来の滝アプローチ。

まあ、これは私たちには正しく見えません。アジャイル手法は多くの人々の答えとなり、企業は開発チーム内で迅速かつ柔軟なスプリントベースのスケジュールを採用しています。

アジャイルにヒントを得た滝のアプローチ。

アジャイルにインスパイアされていますが、ビジネス全体にそれほど多くのアジリティを追加するわけではないため、真のアジャイルアプローチとは言えません。そのことを念頭に置いて、多くの企業はさらに進んで、開発チームの外でスプリントベースのスケジュールを延長し、製品管理および設計グループを含めます。

より優れたアジャイル風の滝のアプローチ。

悲しいことに、非常に多くの場合、組織がアジャイルアプローチを見る程度です。はい。今では、市場から簡単に習得し、コースをかなり迅速に変更できるように、製品チームを実行する俊敏性を楽しむことができます。

ただし、スプリント内の実際のワークフローは依然として本質的に組立ラインです。多くの場合、ある専門チームから別のチームに「フェンス越しに」投げ出される成果物があります。フォードの生産工場では、組立ラインの作業が製造プロセスの製造(「実装」)ステージに完全にカプセル化されました。同じ製品を何年も効率的に何度も生産する一方で、現代の技術革新作業の複雑さはアジャイルを求めていますアプローチは本当にあります。 1〜4週間単位で作業をスケジュールすることはそれほど重要ではありません(もちろん、ビジネスに望ましい柔軟性を与えます)。収集され、提供されたデータに基づいて適切な意思決定を行うことです。適切な作業—共同で。

アジャイルアプローチの真の力は、組織のすべての部分から、バックグラウンドとスキルセットが多様なさまざまな人々を集めたときに初めて実現されると真に信じています。

ハンサムでは、サイロを分解し、製品チームのメンバーが一緒に物事を構築できるようにします。これには、デザイナーとロックステップで作業するエンジニアが含まれます。

コラボレーションアジャイルアプローチのサンプル。割り当ては、プロジェクトごと、製品ごとに異なります。

プロジェクトのすべてのフェーズに参加するエンジニアを含めることで、クライアントのビジョン、ビジネスニーズ、タイムライン要件を完全に理解することができます。また、エンドユーザーのニーズを理解するために直接アクセスできるため、製品開発プロセスに多くの共感を抱きます。

ただし、設計チームに開発者を追加することの利点はそれだけではありません。

適切な製品を一緒に定義する

実績があります。より多様なチームがそれを構築すれば、より高品質の製品を手に入れることができます。私は単に人口統計を話しているだけではありません。多様性には、過去の経験、スキルセット、問題解決へのアプローチ、さらには多様な考え方の幅が含まれます。はい、設計者と開発者はしばしば反対と見なされます。そのため、お互いを非常によく補完しています。開発者は当然、デザイナーが考えていないかもしれない質問への回答を取得しようとします。

エンジニアの主な責任は製品を構築することであるため、エンジニアはエクスペリエンスを設計する人の完璧な仲間です。彼らはデザインのアイデアとコンセプトの実現可能性を確保し、デザインプロセスを強化する独創的なテクノロジー思考を導入します。

最初に正しく構築する

適切な製品を構築するだけでなく、適切な方法で製品を構築することも重要です。ユーザーのニーズ、クライアントの目標、ビジネス上の制限など、すべての適切なコンテキストを使用して、開発者は最初からエンジニアリングの意思決定を改善できます。

開発者がサイロ化すると、意図しない将来の制約で製品をセットアップするものを構築することになります。適切なコンテキストがあれば、必要に応じて柔軟性を高めるコードベースをより適切に構築できます。これは、MVPを構築する際に特に重要です。最近のEPFLの調査によると、特に4社中3社のスタートアップが最終的にピボットするためです。

難なく終わらせた。より多くのコードではなく、適切なコードを記述します。適切な環境内では、これらの理論的原則は現実的な実践になります。

所有権の奨励と管理オーバーヘッドの削減

開発者が質問の背後にある理由を理解し、ビジネスニーズを理解し、ユーザーを念頭に置いて作業する場合、構築しているソリューションを所有するのがはるかに簡単になります。この新しい種類の説明責任はマネージャーによって義務付けられているのではなく、開発者自身から本質的にもたらされます。

エンジニアは、特定の製品の決定を(意識的であろうと無意識的であろうと)問わずに、何をする必要があり、なぜそれを行う必要があるのか​​をすでに知っています。チームのリーダーは、実行を細かく管理する必要がなくなり、適切なフレームワークの構築を支援して、エンジニアの生産性と効率性を最大限に高めることができます。

チーム内の共感を高める

多くの場合、開発者がプロ​​ジェクトの最後で立ち往生しているときに発生する、指さしやフェンスを介した成果物の送信を排除します。チームが1日目から設定されると、各メンバーはお互いに対してより共感を持つようになります。

この構造は、より自然で効果的な共同問題解決につながります。また、チームがすべて同じノーススターのビジョンに従っている場合、対人関係の課題もより簡単に解決されます。

従業員の幸福と定着を高める

多くのエンジニアは、コードが書かれた後に何が起こるかを把握していないため、仕事に飽き飽きしています。彼らは残りのプロセスから切り離されており、彼らの仕事の多くは無意味に見えるかもしれません。影響を与え、人々の課題を解決し、本当に重要なものを作成したいのは私たちの性質です。ユーザーのニーズと問題点から始まる全体像を見た場合にのみ、開発者としてこれを感じるようになります。

Maslowの階層の最上位からの自己実現の必要性を決して軽視すべきではありません。多くの企業で最高の給料を支払っている従業員であるにもかかわらず、退屈なB2Bアプリと思われるものを構築している場合でも、開発者が仕事から得た充実感のために、多くの場合、彼らは留まることを望みます。ユーザーのストーリーとその理由を理解することが、すべての違いを生み出します。

このワークフローを採​​用するための特効薬や普遍的な方法はなく、ほとんどの企業で異なります。すべてのプロジェクトがプロセスの各ステップでエンジニアを必要とするわけではありません。また、純粋に短期的な経済学の観点からは、コード以外のことをエンジニアに支払うのは高価に思えるかもしれません。

しかし、設計と開発機能を真に統合することにより、デジタル製品の設計と開発に対する典型的な組立ラインのアプローチに挑戦することは、さもなければ単なる平均的な製品になり得る賞を受賞したアイデアを解き放ちます。