エンジニアリングプロセスを更新する時が来ましたか？

よく考えられたエンジニアリングプロセスはどの企業にとっても資産ですが、定期的に更新されていない場合、これらのプロセスによって速度が低下する可能性があります。

私は、ヘビー級のエンジニアリングプロセスの文化を持つ会社からインターコムに来ました。 それは、戦闘でテストされ、しばしば更新された手順を備えた、十分に油を塗ったマシンでした。

エンジニアリングの観点からは、コーディングに集中することができました。 タスクは常にJiraで十分に説明されており、明確に定義された期待が含まれていました。 デザインが入ってHTMLにエクスポートされたので、Sketchの使用について心配する必要はありませんでした。 あなたは仕事をした後、タスクをQAに移しました。 何かが戻ってきた場合、それは常に機能していなかったものの良い説明とともにありました。

しかし、インターコムを始めたとき、以前の会社と比較して、毎週のエンジニアリングプロセスがいかに軽量であるかに驚いていました。 見積もりはありません。 Jiraはありません。 個別のQAチームはありません。 当初、私は圧倒されたと感じました。 なぜそれがこのように見えるのか、なぜ誰もがちょうど整列し、私が慣れているように誰もプロセスを構造化しようとしなかったのか疑問に思いました。

「プロセスは製品の開発に役立つ必要があります」

主な理由は、これらの会社の両方で、表面的には似ているように見えても、解決すべきさまざまな問題があったためです。 インターコムは非常に製品優先の会社であり、非常に重いプロセスは製品優先の会社では制約が大きすぎる可能性があります。 この種の環境では、プロセスは、製品が所定のプロセスから開発されるのではなく、製品の開発に役立つ必要があります。

インターコムには、適切な問題を解決するという非常に強力な文化があります。 私たちは、本当の問題が何であるか、小さくて範囲の広いプロジェクト（またはカップケーキと呼んでいます）を使用してそれをどのように解決するか、そしてカップケーキが成功した場合に最終的にどのように見えるかを定義することに冷酷です。

要するに、私たちは問題が何であるか、そしてそれが解決されたことをどのように測定するかを尋ねます。 また、製品で作業するときにこのアプローチを使用するだけでなく、新しいエンジニアリングプロセスを追加したり、既存のエンジニアリングプロセスを調整したりする場合は、常に同じアプローチを適用しようとします。

プロセスの潜在意識の利点

どの組織でも、プロセスは重要で有益です。 それらはワークフローを合理化し、人々がミスを少なくし、ある程度の快適さをもたらすのを助けます–良い一連のプロセスを持つことは、仕事がすでに進んでいるという感覚を生み出すことができます。

「プロセスは通常、制度的な習慣であるという意味で快適です」

プロセスは通常、制度的な習慣であるという意味で快適です。 私たちはすでに仕事に夢中になっているので、プロセスに沿った仕事は習慣に似ています。 このプロセスはすでにリスクが軽減され、熟考されており、理想的には成功の確かな実績があります。 それはあなたのプレートから多くを取り除き、あなたが重要なことに集中することを可能にします。 皿に載せる量を減らすのは魅力的ですよね？

あなたが持っている問題を解決する

新しいプロセスを設計するときはいつでも、最も重要で最も難しい部分は、解決しようとしている問題を明確に定義することです。 このステップをスキップしないことが重要です。 問題を明確に特定できない場合は、なぜ始めているのかを自問する必要があります。 明確に定義された問題なしに進むことは、官僚主義の心配の傾向の兆候である可能性があります-そしてこれはしばしばあなたの最高の人々を疎外するための第一歩になる可能性があります。

「プロセスに沿った作業は習慣に似ています」

代わりに、プロセスはアジャイルで革新的でなければなりません。 彼らはあなたが速く動くようにする必要があります。 彼らはあなたが最も重要なことに集中できるようにするためにあなたのプレートから認知的オーバーヘッドを取り除くことができますが、それはあなたがそれらで適切な問題を解決する場合に限ります。

取り除こうとしている問題を少なくともいくつか簡単に見つけることができると確信しています。 それは「私たちが雇う人々と間違えている」というような巨大なものになる可能性があり、あなたの採用プロセスの再評価につながります。 ソフトウェアコンサルティングでは、問題は顧客の予測可能性と説明責任です。 インターコムでは、私たちの問題はお客様の問題であり、最高の製品を作ることを中心に展開しています。 これらの問題に取り組むためのアドバイスは次のとおりです。

成功基準を定義する

問題をよく理解したら、プロセスの成功基準を定義します。 プロセスから始めるのではなく、成功がどのように見えるかから始めます。 成功から始めることで、デザインに関する偏見（慣れているもの、慣れているものなど）を取り除き、代わりに可能な限り最良の結果に焦点を合わせます。 これは、プロセスの真の成功を定義します。 価値のない使用法は明らかに失敗であるため、プロセス自体の使用法は成功の尺度ではないことを忘れないでください。

「不快感の高い状況では、「使用は成功である」という考えに陥りがちです」

不快感が大きい状況では、「使用は成功である」という考えに陥りがちです。 あなたの周りの現在のレベルの構造に不快感を感じる場合は、構造を改善し、新しいプロセスを導入することを考え始めます。 しかし、プロセスが実際の問題を解決せず、成功基準を満たすために絶えず改善されていない場合、プロセスは人々が革新し、あなたの文化に害を及ぼすことを防ぎます。

エンジニアリングプロセスを定期的に更新する

古いエンジニアリングプロセスは、習慣からそれらに依存し続けるのではなく、有用性を超えた後、更新または削除することが重要です。 プロセスを設計する全体の演習は、問題の解決に基づいています。 ただし、この問題は現在、ソリューションを設計するときに存在します。問題は静的なままではないため、プロセスも静的なままであってはなりません。

「プロセスが実際の問題を解決しない場合、それらはあなたの文化に害を及ぼします」

間違った問題を解決していないことを確認するには、プロセスを使用しているすべての人に現状に挑戦するように勧める必要があります。 これを実現するには、プロセスを簡単に変更できるようにする必要があります。

あなたの習慣とあなたのプロセスをマスターする

プロセスは、官僚主義に悩まされることなく、有益で役立つものでなければなりません。 最高の状態で、彼らはあなたが革新し、速く動き、集中し続けるのを助けることができます。 ただし、すべての企業がさまざまな問題を解決しようとしているため、さまざまなプロセスが必要であることを覚えておく必要があります。 最悪のシナリオは、問題を解決しない、または会社の目標を達成しないプロセスを適用しようとする場合です。

習慣のように、いくつかのプロセスは良いもの、悪いもの、そしてそれらの有用性よりも長生きするものがあります。 そして習慣のように、プロセスを変えるのは難しいかもしれません。 しかし、成功する企業は、成功する人々のように、彼らに見守られるのではなく、彼らの習慣を発達させ、変える能力によって定義されることを忘れないでください。

これがあなたが働きたいと思うような環境のように聞こえるなら、私たちは積極的に採用しています–私たちの開口部をチェックしてください。