エンジニアとして社内でプロとして成長する方法。シリーズ「エンジニアがバーに足を踏み入れる」のミートアップのあらすじ

これは、会社のエンジニアの専門的な開発に関するミートアップのテキストトランスクリプトです。Miro、X5 Retail Group、FunBox、ManyChat、MadRobotsのCTO、技術リーダー、チームリーダーの間で話し合いが行われました。



この会議は、さまざまなIT企業のエンジニアが専門的な非エンジニアリングトピックについて話し合う「エンジニアがバーに入る」シリーズの一環として開催されました。一連のイベントは、DolgushevとStorozhilov DevRel-bureauの支援を受けて、Miro社のエンジニアによって開催されました。







シリーズの2回目のミートアップは8月20日に行われます。トピックは、チーム、企業、および業界における毒性です。スピーカー-Miro、SEMrush、Parma TG、Xsollaのエンジニアとテクニカルリード。登録はすでに開始されています。



目次：

• 会社の詳細とエンジニアの専門的な開発の現在のシステム
• 現在の開発システムにおける課題
• 新しいチームの開始時に開発の文化を実装する方法
• お金についての熱い質問
• 従業員が教育と開発のために自分の時間の一定の割合を必要とするビジネスについてどのように主張しますか？
• 専門的な開発ツールの調査

会社の詳細とエンジニアの専門的な開発の現在のシステム

Artyom Susekov、製品ソフトウェアエンジニアリング責任者、Miro。私たちは、チームのオンラインコラボレーションのための製品、オンラインコラボレーションホワイトボードプラットフォームを作成します。同社の従業員は400人で、エンジニアは半数弱です。PermとAmsterdamの製品開発オフィス。チームは機能横断的です：エンジニア、製品マネージャー、デザイナー、そして必要に応じてマーケター。彼らはスクラムを使用し、一部はかんばんを使用します。計画の場合-キャンペーンレベルおよび個々のチームレベルのOKR。



グレードがあり、それぞれの期待は特定の行動パターンとして定式化されています。これは、正式な期待だけにとらわれないために行われます（「非常に多くのタスクを実行し、そのような証明書を取得する」）。得られた知識が日常業務に適用されることがより重要です。これは、各グレードについて説明されている特定の例に示されているものです。 



標準グレード：ジュニア、ミドル、シニア、各グレードにはいくつかのステップがあります。シニアの後には、テクニカルスペシャリストに成長したり、チームリーダーになってから、ディレクションマネージャーになったりする機会があります。 



年に2回実施するパフォーマンスレビューがあります。その間、チームメイトからフィードバックを受け取り、チームリーダーはチームメイトの直属の部下からフィードバックを受け取ります。さらに、従業員はセルフレビューを作成します。つまり、自分の仕事を独自に評価します。



結果がまとめられた後、キャリアカンバセーションが実行されます：何がうまくいったか、何がうまくいったか、何を将来強調すべきか、何を扱うべきか。次に、マネージャーは、次の6か月または四半期の開発計画の策定を支援します。

Career onversation ( , , ), : , , .

X5 RetailGroupのInnopolisTechnology CompetenceCenterの責任者であるAlexanderBorisov氏。おそらく、ほとんどの人がX5に精通しています。私たちはPerekrestok、Pyaterochka、Karuselチェーンを所有しています。 3年前はトマトを販売する会社でしたが、今はトマトを販売するIT企業を目指しています。 



利益の大部分はITサービスから得られます。 Pyaterochkaの仕組みと価格は、おそらくこの大規模なプロセスのための十分に構築されたロジスティクスと管理システムによるものです。社内には2,000人を超えるITスペシャリストがおり、イノポリスだけでも150人近くの従業員がいます。 



過去1年間で、これらすべてが部​​門形式から製品チーム形式に変わり始めました。サービスと製品をマイクロサービスとサブ製品に分類し、1つのチームが責任を負うことができます。現在、各製品のプロダクトオーナー、機能横断的なチームがあり、各チームには開発者、テスター、アナリスト、および人々が互いに重複できる機能の一部があります。 



当然、1対1の会議、OKR、360のフィードバックがあります。興味深いのは、リソースプールの所有者機能です。これらは、Java、JS、Python、テスト、分析などのプールを担当する人々です。社内の各エンジニアには、製品への投資額と仕事の利益を理解するビジネスリーダー（プロダクトオーナー）がおり、特定の能力の技術開発を担当する人がいます。



「ジュニアプラスからミドルマイナスに移行するには、これとあれを行う必要がある」などの学年間の移行の形式化を断念しました。移行の明確な基準を与えると、人々はこれにあまりにも正式にアプローチし始めるのではないかと心配しています。しかし、ここでは形式が有害です。各チームではすべてが非常に個別である可能性があるためです。1人の同じ人がより多くの責任を引き受けることができ、この開発により、または私たちに固有の技術の狭いセグメントを投入することができます。ビジネスにとってより価値があります。

シニアポジションにとって、知識の普及は成長のための重要な前提条件です。あなたは孤立したシニアではありません。あなたは自分の経験をチームと共有し、残りをあなたと一緒に引き出します。

Sergey Averyanov、CTO、Funbox。私たちはビッグスリーオペレーター向けのソフトウェアを10年以上開発してきました。現在、さまざまなプロファイルの約200人の開発者と、技術サポートのかなりの数の技術スペシャリストがいます。 



チーム全体が関与する単一の製品がない一方で、アウトソーシングのようにプロジェクトやタスクの大きな流れはありません。これは、エンジニアの特定の専門的な開発が成長する場所です。正式なグレーディングシステムを意図的に廃止しました。おそらくこれは経営陣と従業員自身が望んでいることですが、これは非常に柔軟性のないシステムであり、すべての人を同じブラシでスタイリングしようとします。これは実際には常に可能とは限りません。代わりに、かなり標準的なものを使用します。従業員の進捗状況の定期的な評価と1対1の会話です。各タスクトラッカーの貢献度を客観的に評価する機会があります。これらすべてをまとめることで、各エンジニアのレベルを理解することができます。 



一方、私たちの主な目標の1つは、各自がどこでどのように成長できるかを理解してもらうことです。私たちは、すべての人が異なるという事実を考慮に入れようとしています。誰かが技術専門家として働き、人とのコミュニケーションを最小限に抑え、管理上の事柄に飛び込むことに興味がない。誰かがコミュニケーションを取り、人々と働き、同僚の育成に参加したいと思っています。これはすべて正常であり、すべての開発オプションが可能です。



私たちは、エンジニアのレベルを上げ、ビジネスが彼らに何を望んでいるか、そして彼らが次にどこに行くことができるかについて明確なガイダンスを提供できるシステムを構築しようとしています。また、社内の成長にも細心の注意を払っています。私とチーム全体は、最高のスペシャリストはチーム内で育てたスペシャリストであると信じています。そのため、社内開発、ミートアップ、社内外の会議に積極的に投資しています。これも主要な目標の1つであり、すべてのエンジニアの完全で高品質な開発です。

抽象開発部門は、従業員の開発に関与すべきではありません。これは、ラインマネージャーの責任の1つです。

このアプローチは、私たちと従業員自身にプラスをもたらします。一方で、私たちはスタッフの間で絶え間ない有機的な成長を遂げています。一方、元ジュニアからシニアジュニアやチームリーダーを作ることもできます。従業員自身は、直属の上司が4年前にこのプロジェクトのジュニアだったと考えています。つまり、協力する前は、同じ機会と理解できる手順が成長。



ミハイルマゼイン、エンジニアリングリード、ManyChat。私たちは、企業とその顧客の間のコミュニケーションを手配できるSaaSマーケティングプラットフォームを開発しています。会社は活発に成長しています。3年前はチームに15人がいましたが、現在は120人以上です。最初の段階では、バックエンド、フロントエンド、テスト、設計チームなどの従来の機能チームと協力しました。各チームには、スプリントの計画とタスクの分解を担当するチームリーダーがいました。



成長の過程で、これが私たちが望ましい速度で動くのを妨げていることに気づき、仕事を機能横断的なチームに再フォーマットしました。現在、このような機能横断的なチームが9つありますが、チームリーダーは存在しません。チームは自己組織化されており、作業方法に責任を持つことができるためです。



機能的なものを同期させるために、開発が無秩序にならないように共通のアプローチを開発します。これは、たとえば、バックエンド開発者が異なるチームに分散しているが、1つのプロジェクト、1つのコードベースで作業し、そこでコードをコミットする場合に必要です。これらの問題に対処するために、機能コミュニティを編成します。時間の経過とともに、非公式のリーダーがプロセスとコミュニケーションを推進するコミュニティに登場します。その結果、開発者の役割をコードを書くだけのエンジニアの役割に限定することなく、会社にとって有用であると同時に本人にとっても興味深いさまざまなことを実行できるフラットな構造になります。 



チームリーダーの役割を放棄したため、エンジニアの成長トラックを明確かつ透過的に構築できるプロセスが必要でした。このために、私たちはメンタリングシステムを使用します。各従業員には、社内での成長と発展に責任を持つメンターがいます。

ランダムな人のところまで歩いて行って、「あなたをメンターにしよう」と言うことはできません。まず、いくつかの要素を収集する必要があります。本人の欲求。チームに対するその人への高いレベルの信頼。会社自体と経営陣からの信頼。メンターの仕事の1つは、新しいメンターを育てることです。メンターからメンターへと、そのような芽が出てきます。

開発の3つの主要なベクトルを区別します。

• 最初の大きなトラックは、製品開発のための製品チームでのより深い作業であり、ビジネスの価値、指標をより深く理解しています。
• – , , . 
• – , . 

また、グレーディングシステムの作成も試みました。まだすべてのグレードを正式に説明することはできないため、システムは、個人の貢献、チームのレベル、会社全体のレベルで構築されています。各レベルでの期待、責任の領域または人に期待する影響の領域を、理解できる例とともに説明しました。一方、メンターは、目的のポイントに到達するためにどのスキルをポンプする必要があるかを人に伝えることができます。 



MadRobots、開発責任者、AntonGrisin氏。当社は一見ガジェットを扱うeコマースですが、一般的にはロシアでの流通やかっこいいもののブランド開発に取り組んでいます。 



私たちのチームは比較的最近集まったので、社内のエンジニアの育成に伴う問題はまだありません。マドロボットの前は、6年間アウトソーシングに携わっていましたが、そのうち3年間は代理店で直接生産を担当していましたが、この経験について詳しくお話ししたいと思います。



アウトソーシングでは、私たちの苦痛はプロジェクトの大規模な流れとスタッフの離職でした。アウトソーシングでは、これは常に当てはまります。どういうわけかこれを克服する必要があると判断し、従業員の育成に投資し始めました。



はい、私たちはグレーディングシステムを持っていました。6か月に1回、技術マネージャーからフィードバックを受け取り、次の6か月間は自分の道を築きました。

, . , . , , , .

その後、私たちは別の痛みを感じました。多くの場合かなりの数があったプロジェクトの流れの中で、人々は個人的な開発への焦点を失いました。これは、十分な時間がなかったためではなく、ジャンプする必要のあるタスクの数にうんざりしていたために発生しました。月に一度、人と話をし、開発計画があり、それを守るべきであることを彼らに思い出させることを目的とした、1対1の会議の実践を紹介しました。これに時間が必要で、日常的または絶え間ないオフサイトから解放される必要がある場合は、チェックポイントが近づいていて、それについて何かをする必要があるため、それについて話し合いましょう。それは助けになりました。原則として、これはチームのPMによって行われました。なぜなら、チームのPMは、そうでない場合でも、将来のリソースの計画をよく知っていたからです。 

現在の開発システムにおける課題

アルテム・スセコフ、ミロ。グレーディングシステムのバランスをすぐにとることは難しいので、繰り返します。たとえば、チームリードのトラックの最初のバージョンは過負荷であることが判明しました。期待が高すぎる、普遍的なスーパーソルジャーであり、人生ではほとんど不可能です。



現在、チームリーダーの役割に入る際のしきい値を単純化して、純粋なエンジニアリングブランチからマネージャーブランチに簡単に切り替えられるようにしています。バーを過大評価したくないので、この新しい活動分野にスムーズに移行する機会が必要です。



もう1つの問題は、プロセスに対する過度に正式なアプローチです。たとえば、「計画の10ポイントのうち8ポイントを実行しました。これは、期待に応え、次のレベルに進むことができることを意味します。」ゲームのように、これらすべてを次のレベルに移動するために閉じる必要があるチェックリストに変えたくはありません。

計画に基づいて見通しを考え、興味のある分野を独自に考えてもらいたい。つまり、正式な課題のリストではなく、戦略として取り組んでほしい。

アレクサンダーボリソフ、X5リテールグループ。明確なアルゴリズムがないため、人々は会社で成長する方法を正確に理解していないことがよくあります。同時に、すでに昇進できる人は、成長できるもの、成長すべきもの、自分自身を引き受けてより良くすることができるものを見つけます。しかし、たまたま「ただ成長する」必要があります。しかし、あなたが成長したいので、そのように会社で成長することはおそらく不可能です。

あなたはより多くの責任を引き受け、新しいプロジェクトを引き受けるときにのみ成長します。

Sergey Averyanov、Funbox。私たちは長年働いてきたので、多くの問題と課題を抱えてきました。最初の1つは、誰と協力したいのか、誰を開発したいのかを理解することです。その結果、うまくやる方法を知っている人と一緒に仕事をしたいという結論に達しました。何をするかは問題ではありません。私たちは、使用するものを使用する準備ができているスタックからスペシャリストを喜んで受け入れます。これはかなり成功した実践であることが判明しました。関連する主題分野ですでに能力を持っている人々を育成することは常に快適で便利です。彼らが持っている知識のギャップは致命的な欠陥ではなく、人にとっての新しい動機、新しい活動分野の研究です。 



2番目の課題は、社内のエンジニアがどのように成長できるかを理解することです。開発のためには、快適な労働条件を作り出す必要があります。通常のオフィス、明確でシンプルだが厳格な手順と労働規制、労働法の遵守、過労嫌い。これはすべて、面倒なことなく、急いでレベルを上げることができるという自信を人に与えます。彼らは彼を見せ、彼に話し、彼を助けます。 

ポテトで好きなだけ叫ぶことができます。「ポテト、成長しなさい！トマト、さあ！」-しかし、これからは成長しません。彼らは良い土壌と水やりが必要です。

最後の課題は、すべての人が私たちが成長させたい場所で成長したいとは限らないということです。どんな状況でも、強力なスペシャリストが管理上の負担に対処し、若い同僚と協力したいとは思わないことがあります。ここでの問題は、正式なものではなく、給与ではなく、単に人が何に興味と傾向を持っているかということです。そのため、すべてのエンジニアで情熱、複雑なタスクを実行し、最初から最後まで複数のステップのプロセスを実行する能力を重視しています。原則として、これができるエンジニアは誰でも私たちにとって面白くて楽しいです。しかし、私が言ったように、これに伴い、私たちは常に、管理および管理機能に突入することなく、人が技術専門家になる機会を残しています。



ミハイルマゼイン、ManyChat..。グレードの要件を形式化することは十分に困難であり、開発のさまざまな段階でエンジニアに期待することの例に焦点を当てて、厳密に形式化しようとはしませんでした。これはすべて、人々がチームまたは企業レベルのプロセスにもたらす特定の影響にまとめられました。 



これは困難を生み出します。一方では、成長する人々を制限することはありません。彼らの前に空白のキャンバスが表示され、その上に開発トラックを描くことができます。しかし、白紙の紙に新しい絵を描くことは、殴られた道に沿って移動するよりもはるかに困難です。私たちはメンタリングによってこの問題を解決します。メンターは、人々の要望に基づいてトラックを構築し、それを会社のニーズと同期させるのに役立ちます。また、エンジニアがプロセスの問題を見つけて自分で解決を開始できるように、問題検索の考え方を発展させようとしています。これでも、メンターが助けてくれます。



アントングリシン、MadRobots。成長が自分たちの必要である人々もいれば、それが周りに確立されているために成長する人々もいます。そのために条件が作られました。しかし、それらはすべて定期的に質問があります-何のために？これは現在の現実や現在の同僚には当てはまらない可能性があるため、新しいことを学び、開発するという個人的な動機は失われます。 



解決策の1つとして、私たちは社内ミーティングを開催しましたが、趣味のグループとしてではなく、社内会議として、新しいトピックの実際の準備を行いました。これから前向きな話が浮かび上がり、たとえばフロントエンドが何か新しいことをすることができれば、私たちデザイナーとデザイナーは私たちのアプローチを再考し、新しいツールを試すことができるということを彼らは理解し始めました。お互いの自然な動機は、一緒に何か新しいことをしようとすることであることがわかりました。

痛みは常に、個々の人の成長への個人的なアプローチを引き起こします。

新しいチームの開始時に開発の文化を実装する方法

Sergey Averyanov、FunBox：会社の成長という事実そのものが私たちを助けてくれました。エンジニアが少ないときは、みんな一緒に料理をし、お互いを知り合い、同じような仕事をします。そして、さまざまな種類のプロジェクトとその中での役割が並び始めるとすぐに、すべての人々がさまざまな力に恵まれるようになります。誰かがタスクを実行し、誰かが展開、クラスターに従事し、誰かが製品設計に関与します。



各チームメンバーが、開発者からより高いレベルの開発者またはチームリーダーに移行するために何をアップグレードする必要があるかを理解することが重要です。

, 125 , , , , .

内部ミーティングは非常に便利です。会社に多くのチームといくつかの製品がある場合、人々はそれぞれ独自のソースで調理し、会合で彼らは話し、彼らが何をしているのかを話し、知識を交換します。これはチーム間の競争を生み出すのではなく、卓越性の追求を生み出します。



Artem Susekov、Miro：チームの成長のある段階では、テクノロジーを中心に形成されたさまざまなギルド（バックエンド、フロントエンド、QA）が役立ちます。ギルドでは、異なるチーム間で知識が交換されます。



内部イベントも役立ちます。チームが共通のコンテキストを共有するミートアップ、公開スプリントレビュー、結果について話します。ここでは、エンジニアがそのようなパフォーマンスの準備をするのを助けることが重要です。



アレクサンダーボリソフ、X5リテールグループ：ミートアップが必要だと言うことを期待することはできません、そして人々は彼ら自身を組織し始めます。それらも対処する必要があります。私たちの規模の場合、それを組織する責任ある人々を選び出すことは理にかなっています。チームの中にはクールなものがあることがよくありますが、チームは自分たちの中で料理をします。ミートアップを開催してベストプラクティスを共有するのに十分な時間がありません。30分かけて会議室に集まって過ごしたようですが、違います。微妙な違いがあります。



Mikhail Mazein、ManyChat：新しい人々のための適切に構造化されたオンボーディングプロセスにより、チームとプロジェクトの全体像を正しく形成するために、一般的な原則とアプローチを彼らに伝えることができます。ですから、新しい人がやってくる文化が蓄積され、受け継がれていきます。 

お金についての熱い質問

視聴者からの質問：「あなたは組織の財政的健全性に触れていません。従業員が勤務時間中に本を読むために会社の費用の割合はどのように決定されますか？ 2つ目は例です。問題の解決には、そのような問題をすでに解決している開発者の場合は80時間かかり、コンテキストに慣れていない開発者の場合は150時間かかりますが、同時に成長してポンプを使用します。問題は、開発に費やした70時間の差額を誰が支払うかということです。」



アレクサンダーボリソフ、X5リテールグループ：私たちの場合、顧客はいません。能力は私たちにとって非常に高価であり、あなたの家の近くの特定のPyaterochkaのビジネスの限界を高める最終的なコストをもたらすことを理解しているため、私たちはいくつかのものを外部委託し続けるのではなく、積極的に内部チームを構築し始めました。将来への投資です。



しかし、ある人が3時間150時間のタスクを実行する代わりに、本を読み始めた場合、問題は製品の所有者またはリソースプールの所有者からのみ発生します。これが人が成長したという事実への理解できる投資である場合、再び、これらの2人のレベルで、これは簡単に解決されます。たとえば、それぞれスプリントの計画の中に、読む必要のあるものを配置し、それに適合させました。これは通常の話です。



アルテム・スセコフ、ミロ：勤務時間内に開催されるコースやワークショップを通じてエンジニアの育成を支援するという企業レベルの合意があります。つまり、会社がそれを支払います。これはチームの各メンバーへの投資です。この種の投資は、チーム全体が将来より速く動くのに役立つと信じているからです。 



スプリント教育のためにエンジニアのために予約された特定の時間は、特定のチームレベルで議論されます。ここで重要なのは、他の方向に歪みがないこと、スプリント中は常に勉強するだけで他には何もしないことです。



Sergey Averyanov、FunBox：80時間と150時間についての質問は、アウトソーシングにとってより深刻だと思います。経験豊富な開発者が80を超えて同じことをしたのに、経験の浅い開発者が顧客として私に150時間を費やす必要があるのはなぜですか。私たちはアウトソーシングではないので、アウトソーシングがこれをどのように解決するかは言えません。製品会社の枠組みの中で、これは予算が統合され、チームメンバーがレベルを上げ、より良く、より速く働き始めるという事実のために開発のための人件費が利益で表されるという事実によって解決されます。



勤務時間中に本を読むことについて。私たちは、何かを学ぶ必要性は、問題に取り組む上で完全に自然なステップであるという慣習を持っています。「本を読む」や「究極の目標のない技術を研究する」などのタスクを設定して、開発者を大混乱に陥れることはありません。人が座って考えているようなものであってはなりません-私はすでに技術を勉強しましたか、それとももっと勉強する必要がありますか？文脈から外れた、目標から外れた仕事は、先入観につながり、人は自信を失い、いつ何かをすべきかわからないという事実につながります。

文学を研究して読んだり、何かを研究したりすることは仕事の一部であるべきですが、この研究を適用できる最終的な具体的な目標がなければなりません。

アントン・グリシン、MadRobots：私は、1時間ごとに誰かが稼ぎ、誰かがお金を失った世界から来ました。原則として、顧客は正直に言われます：「私たちはあなたからこれ以上お金を取りませんが、私たちはより長く仕事をします。」彼の雇用主である会社は、とにかくエンジニアの育成にお金を払っています。顧客はもう少し待つだけですが、将来的には1人ではなく、2人の開発者が製品の開発に従事し、すべてがより迅速に解決され、実装の規模が拡大していることを理解しています。



プロセスが通常構築されるスタジオやエージェンシーでは、開発者は、開発で稼ぐよりも多くの損失を会社にもたらすため、客観的に彼を引っ張らないプロジェクトに決して置かれることはありません。



アレクサンダーボリソフ、X5リテールグループ：X5での仕事の他に、私は自分の小さなアウトソーシングスタジオを持っています。私はその経済をよく理解しています。有償時間を80時間に設定しましたが、150時間であり、有償時間数や開発期間が大きく異なることがわかりました。私たちはいつもある種の株を取り、私たちは自分のお金からこの株の代金を払っただけでした。どこかに何らかの力の威厳があるとすれば、それは彼ら自身のお金から支払われることを意味します。



ミハイル・マゼイン、ManyChat：外部の顧客がいない製品開発は、この点で私たちの手を大きく解き放ちます。通常、個人のパフォーマンスを追跡するのではなく、チームのパフォーマンスを測定します。



各チームには独自の能力と速度があり、大きく異なる可能性がありますが、一般的には、チーム全体のパフォーマンスに重点を置いています。特定のエンジニアが現在のスプリントでどれだけの空き時間を持っているかは、会社として私たちにとってそれほど重要ではありません。この時間は常にトレーニングのために残っており、スプリントごとに原則としてエンジニアごとに異なります。スプリントのどこかで、フロントエンドにかかる負荷が大きくなり、次のスプリントではバックエンドにかかる負荷が大きくなり、このストーリー全体が長期的に横ばいになります。 



一人一人のパフォーマンスを評価することについて話す場合、チーム自体がこれに責任があり、それは自己調整構造のようなものです。たとえば、この人のメンターから、パフォーマンスに問題があるというフィードバックがあったり、機能コミュニティの仲間からフィードバックが来たりする場合があります。

, ?

, Miro: , , . , , … , .

Sergey Averyanov、FunBox：固定レベルのスペシャリストに焦点を当てている会社があるかもしれないと思います。彼らは常に同じ資格で同じ仕事をしていて、誰も育てたくないのです。これは、離職率が高く、成長する可能性のある従業員が新しい仕事を見つけるという事実によって解決されます。従業員の育成と会社の拡大に投資するか、売上高があります。 



Artem Susekov、Miro：これはすでに計算できます。売上高について話している場合は、この指標に固執します。お金についてはそうですか？新しい人を引き付けるためのコスト、採用担当者に費やす時間、オンボーディングに費やす金額、そしてその人が去ったときに空席を再び閉じるために費やす金額。これはすべてお金で数えることができます。



Sergey Averyanov、FunBox：ちなみに、自分でも見てもらえる興味深い指標は、会社での勤務期間の中央値です。これにより、売上高、つまり中央値で働く人の数を見積もることができます。中央値が大きく、この分布の端に、8年から10年働いていて、燃え尽きていない人がいて、彼らはうまくやっていて、みんながお互いに満足しているのを見ると、これは朗報です。



MadRobots、Anton Grishin：今では、ビジネスでこれらすべてを説明する必要はないように思われます。自己開発の必要性は、知的製品を作成する人々に内在していることは明らかです。したがって、私たちが使用する技術そのものが私たちに開発する必要があることを指示するので、同じレベルの専門家が必要とされる例を考えることさえできません。



Mishanya Storozhilov、DevRel Bureau：これは、固定されたパフォーマンスと固定されたテクノロジーを持つ人々だけのものではないように思えます。この話は、大きなリファクタリング、大きな技術的負債についてもあると思います。私たちはエンジニアを育成する必要性を理解している企業と協力していますが、教育と開発のコストを正当化するという問題は常に浮かび上がります。



Sergey Averyanov、FunBox：ここで「リファクタリング」という言葉が聞こえましたが、それに対する態度は興味深いものになる可能性があります。多くの人々、特に技術者以外の専門家は、これらは何もせずにお金を使うセーターの男の奇妙なジェスチャーであると誤って考えています。ここでの問題は正確にコミュニケーションにあります。つまり、マネージャーは、今日発生しなかったリファクタリングが明日の開発時間の増加であることを理解する必要があります。今日は人時間を節約し、明日はそれらを使います。

チームリーダーは、タスクを完了するために必要な条件はリファクタリングを実行することであると言う権利があることを社内で合意しました。リファクタリングがないと、作業が不可能になるほどナンセンスになります。

当然、これは最終的には合意の問題ですが、リファクタリングを副次的な活動やリソースの浪費としてではなく、ワークフローの一部と見なしています。



Artem Susekov、Miro：製品開発について話す場合、合意は重要です。たとえば、製品マネージャーはスコアに基づいて優先順位を決定し、チームまたはチームの声、技術リーダーまたはチームリーダーが正確にそれを行う方法を決定します。製品は今最も重要なことを言います、エンジニアは私たちがそれをどのように行うつもりかを言います。

リファクタリングは自然なプロセスです。今日のリファクタリングは、四半期のリファクタリングよりもはるかに安価です。それはローンのようなものです-あなたが支払わなければ、次にあなたはもっと支払わなければなりません。

X5 Retail Group、Alexander Borisov：「技術的債務」という用語があります。チームと製品の間のコミュニケーションの段階で、これを今行っていない場合、これは技術的債務であると理解しています。したがって、スプリントによる技術的負債はさらに多くなり、6か月でさらに多くなり、この割合で支払う必要があります。実際、通常のローンと同様に、チームが製品と交渉するのとまったく同じ方法で、より速くまたは人間的に製品が必要な場合に使用します。それが速いなら、いつかあなたははるかに多くを支払わなければならないでしょう。ローンと同じように。 



Mishanya Storozhilov、DevRel-bureau：この借金は単に「技術的な住宅ローン」に変わるだけです。 

私たちは5人のエンジニアを集めました。彼らはたった1時間半で話し、すでにリファクタリングについて話し始めました。

* **

シリーズの2回目のミートアップは8月20日に開催されます。トピックは、チーム、企業、および業界における毒性です。スピーカー-Miro、SEMrush、Parma TG、Xsollaのエンジニアとテクニカルリード。



登録は受け付けています。