開発者の食事と世話（またはなぜ私たちがそんなに不平を言うのか）

ご注意 翻訳者-オリジナルでは、おなじみの用語「ソフトウェアエンジニア」が使用されました。 彼のロシア語版「ソフトウェアエンジニア」は日常のスピーチではめったに使用されないため、「開発者」という言葉を最も近いものとして使用する必要がありました。 また、著者が業界の多くの開発者の状況を比較する短期注文の料理職は、「使い子」として翻訳されました-それは、開発者に対する態度の問題の本質を完全に反映しているようです。 最後に、要件を低レベルの機械命令に変換するための原始的なプロセスとしてロシア語で開発された「コード」および「プログラミング」という言葉の否定的な意味のために、「コード化」および「プログラミング」という言葉の代わりに「開発」および「開発」を使用しようとしました高レベル。

オリジナル記事の著者は、有名なフロントエンド開発者であり、かつてYahooで5年以上働いていたJavaScriptエバンジェリストであるNickolas C. Zakasです。 これは彼のブログからのエントリであり、開発者との合意がなぜこれほど難しいのか、そしてそれについて何をすべきかについて彼が語っています。

少し前に、ジェンナ・ビロッタは、デザイナーと開発者がより良いパフォーマンスを達成できるようにするチームワークの方法を説明する素晴らしい記事「デザイナーと開発者の仲立ち」を書きました。 かつてデザイナーと（そして、UIで、そして開発者と）働いていて、同様の問題に直面したので、その実用的なアプローチを理解しています。 チームワーク中、同僚の仕事を尊重し、同僚の考え方を理解することは決して痛いことではありません。

この記事の主な考えの1つは、開発者があまりにも早く言っているということでした。 この考えはすぐに私の脳に入り、長い間そこから抜け出すことを拒否しました。 「しかし、待って、なぜ私たちがノーと言うのか理解できない！」 数百万の他の防御的な議論がすぐに現れました。 実際、彼女はもちろん正しいです。デザイナーだけでなく、すべての人に対して、私たちは本当に「いいえ」と言っています。 これにより、開発者の心理と、私たちの真の本質を構成するものについて考えるようになりました。

私たちの評判

正直に言って、開発者である私たちは、定期的にムードを揺るがすような誇り高い討論者の評判を得ています。 私たちは絶えず「いいえ」と言い、細部をわいせつな態度で明確にし、非技術的な同僚の仕事を自分よりもはるかに上手くできると信じています。 そして、すでにそこにあるもの、このステレオタイプはほとんど真実です-これは、コードを書いてからハッカーニュースでTwitterを読むことの間で、私たちが毎日やっていることです。

（注：あなたの一人は、すべての開発者がそのようなわけではなく、彼は正しいと言うでしょう。上位にランク付けできない開発者は少数です。スクロールダウンして、著者が馬鹿であるというコメントを急いで書いてはいけません。 ）

誰も評判をあげるだけでなく、彼らはそれを獲得します。 この評判で私を驚かせるのは、私が個人的に多くの開発者を知っていることであり、原則として、彼らは友好的で気持が良く（頑固ではないにしても）、ただ面白い人です。 仕事の後や週末に彼らと楽しい時間を過ごすことができます。 では、なぜ彼らは職場でまったく異なる人になるのでしょうか？

私たちはビルダーではなくクリエイターです

私には理論があります。 開発者は、自分の同僚とはまったく異なる見方をしているという事実にあります。 私は、大小のソフトウェア開発会社での10年間の仕事でこの結論に達しました。 そのような会社の従業員（製品マネージャー、デザイナー、他のマネージャー）は通常、開発者を単純なビルダーと見なします。 プロダクトマネージャーは独自のアイデアを考え出し、デザイナーはそれを美しい形で表現し、開発者はこれらのアイデアを実現するだけです。 実際、エンジニアは、言われたとおりのことをしているだけのことをしている使いの男の子と見なされます。

私の最初のマネージャーはこれについて私に警告しました。 最初に働いた会社がバラバラになったとき、将来のキャリアについて非常に率直な会話をしました。 私たちはいつも仲が良かったわけではありませんが、そのとき彼は私に素晴らしいアドバイスをしてくれました（以下不正確な引用）

ニコラス、あなたはあなたが書くコードよりも価値があります。 あなたがさらに仕事をするときはいつでも、お使いの男の子のように扱わせてはいけません。 何をどのように行う必要があるかを正確に伝えられた場合、働くことに同意しないでください。 製品を作ることができるという事実だけでなく、それをどのように改善できるかを評価する場所で働く必要があります。

彼は絶対に正しかった。 お使いの男の子を必要とする多くの企業があり、彼らは側に一歩を踏み出す権利なしに明確に定義されたパターンに従ってコードを書くビルダーを必要とします。 これらは大小の企業の大半であるとさえ言うでしょう。 著作権のビジョンの実現と引き換えに、何社のスタートアップの創立者が私に会社の出資を申し出たのか、長い間数え切れませんでした。 それらのすべては、彼らがすでにアイデアを持っているという事実から進んで、彼らはそれらを生き返らせるものだけが必要です。

そして、ここで問題の主な根は埋もれています-開発者は実際には従順なビルダーではありません。 開発者はクリエイターです。 あなた自身が、ある意味で、イケアの家具を組み立てるたびに組み立て工事に従事しています。 すべての指示が手元にあり、それらを段階的に追えば、とんでもないほど小さなテーブルを組み立てることができます。 創造性は完全に異なる仕事であり、特定の指示や指示なしに何かを創造することです。 空白のキャンバスから始めて、芸術作品で終わります。 開発者は、他の誰かの指示に従うことを望んでいるのではなく、それを使ってさまざまな興味深いことができることに気付いたので、プログラミングが大好きです。 私たちは皆、開発プロセスに夢中になりました。なぜなら、控えめながらも有用なアプリケーションを作成すると、夢中になったからです。

プロダクトマネージャー、デザイナー、開発者で構成されるソフトウェア開発の勝利では、開発者だけが創造力を切り離し、通常の生産に従事する必要があります。 しかし、開発者はまったく愚かではなく、彼らはそのような態度を完全に感じ、不満が現れ始めます。 開発者は創造的なプロセス全体の一部になりたいと望んでおり、彼らはそれを奪われています。 そして今、完全に普通の開発者は慢性的な不平を言う人に変わります。

ねえ、それで問題は何ですか？

プロダクトマネージャーは通常、並外れた人材です。 彼らのアイデアと市場動向を感知する能力は印象的です。 しかし、実際には、列車全体が通過できる穴がある一方で、彼らは自分のアイデアを完全に誤算がないと考える能力も持っています。 私はこれを非常に優しく言っています、いくつかのプロダクトマネージャーは私の良き友人であり、もちろん、私は彼らにこれについてしばしば直接話しました。 決して私は彼らを批判しません。それは彼らの本質です。 彼らは創造的な仕事に従事しており、希少なアイデアが理想として生まれています。 そして、これからまさに不平を言うのは開発者です。

開発者と製品マネージャーの両方が、製品の要件や仕様がIkeaの家具の完成品に似ていると誤って信じていることがよくあります。 実際、これらのドキュメントには、完全な製品を収集するのに十分な情報が含まれていることはめったにありません。 これは通常、出発点に過ぎず、開発者に解決すべき固有の問題を提供します。

この問題をよりよく理解するために、家を建てるタスクを見てみましょう。 誰かが特定の土地に家を建てようと決めたとします。 家には2階とガレージが必要です。 ナプキンに描かれた家の正面の大まかな輪郭もあります。 そして、クライアントはこれらすべての情報とナプキンを持ってあなたに近づき、「これはあなたが建設を始めるのに十分ですよね？」そしてあなたにどのようにそれで十分ですか？

論理的に考えると、とにかく建設を始めることはできません。 映像がわからない、フロアプランがない、市が新しい家を建てるのにどんな要件があるのか​​さえ想像できません。 基礎の下で地球を掘り始めても十分な情報がありません。 唯一の論理的な解決策は、クライアントにクレイジーであり、最初に必要なものを正確に決定する必要があることを伝えることです。 誰かが期限を設定し、鼻血の時間をとる必要があるため、これができないと想像してください。

「まあ...」クライアントはあなたに言った、「それを作り始めましょう。 可能な限り、新しい情報をお知らせします。 したがって、時間を無駄にしません。

構築するのに十分な情報がないことは確かであり、クライアントからのさらなる問い合わせではまだ何も得られません。 しかし、誰も締め切りをキャンセルするつもりはありません。クライアントが詳細に寛大になることを望んで、ズボンに座る余裕はありません。 そして、あなたには何が残っていますか？ 仮定と仮定を行います。

古い格言は、「あなたが仮定するとき、あなたは私とあなたの尻を作る」（あなたが仮定をするとき、私たちに両方のばかをする）を言います、そして、これは本当です。 仮定は危険であり、非常にしばしば間違っています。 それでも、仮定なしでは、プロジェクトを立ち上げることはできません。 それで、あなたは何をしていますか。 あなたはあなたが真実を確信しているという仮定から始めます-家には2つの床とガレージがあるということです。 質問があります-ガレージは拡張機能であるか、それとも別個ですか？ そして、どのサイズを作る必要がありますか？ たとえば、ガレージを個別に構築し、1台の車用に設計する必要があるなど、複雑にすることはありません。 これで、ガレージを別の建物として作業し、家の詳細が判明したら、ガレージの隣に建てることができます。

ガレージでの1週間の作業の後、クライアントから新しい詳細が通知されます。 家には3フロア（ええ、まだ家を建て始めていないのは良いことです）と8つのバスルームがあるはずです。 ガレージに関する情報はまだありませんが、家は青く塗られているはずです。 ガレージも青であると判断し、ペイントを進めます。

数日後、ガレージはほぼ完成しました。 情報がほとんどなかったため、結果の品質に満足しています。 クライアントが新しい詳細を提供したら、家の建設を開始する準備ができています。ガレージは2台の車用に設計し、家に取り付けます。 あなたには悲劇があります-あなたはそのようなクールなガレージを作りました、そして今、それは「必要な」ものを造るために取り壊されなければなりません。 さらに悪いことに、プロジェクト全体を終了する時間が少なくなりました-そして今、あなたはすでに不平を言い始めています。

この類推がおかしいと思われる場合は、開発者として働いたことがないことは明らかです。 私たちはこれを初日ごとに観察します。 私たちはすべての創造力を使ってプロジェクトを浮かせようとしますが、最終的には他の人の考えを読むことができず、私たちが構築しているものを誤って推測しました。 ただし、これを行わなかった場合は、時間を無駄にしてそのまま待つことになります。そして、ご存じのとおり、カスケード開発モデルには多くのファンがいません。

何かを構築する必要があるほぼすべての業界では、建設が始まる前にすべての要件と要望が特定され承認されることが期待されます。 しかし、ソフトウェア開発ではそうではありません。 ソフトウェアを開発する場合、すべての要件を事前に収集するための「十分な時間」が常にありません。 私たちは毎日前進する必要があると言われます-そして、開発者はプロジェクトを動かさなければならず、製品マネージャーが残した穴を埋めることを学ばなければなりません。 プロダクトマネージャーは、常に心を変えたいという愛で有名であり、そこから開発者の仮定がしばしば途中で間違っていることを忘れないでください。

そして、開発者が非常に迅速に「燃え尽き」て仕事を変えることに驚いた人はいますか？

最優先事項

クリエイターの主な敵は、状況の変化です。 ディープクリエイティブモード、いわゆる「フロー」に入るとすぐに、外部からの介入はプロセス全体を即座に破壊します。 はい、コードを書くことは、創造的かつ論理的な創造的なプロセスでもあります。 コードを書くだけでなく、作成します。

開発者の時間管理に携わる人々の間で、あるタスクから別のタスクに切り替えることは彼らにとって些細なことであるという意見があります。 彼らは、労働時間はアフリカの労働時間でもあると主張しています。 必要なタスクに十分な金額を費やすだけで、結果が得られます。 もちろん、これはそうではありません。 あるタスクの上に2日目がすでに座っていて、別のタスクに移動した場合、終了した場所に戻ることはできなくなります。 コンテキストに参加するには、ある程度の時間を費やす必要があります。それは、それを変更するための価格です。 別のタスクに数分しかかからない場合でも、これにより「フロー」が中断され、開発者の生産性が低下します。

これは、開発者が不平を言う主な問題の1つです-優先順位の絶え間ない変更。 今日、私たちには一つの主要な優先事項があり、明日はもう一つの優先事項があります。 クリエイティブな人々は事件の途中で引き裂かれることを好みません。そのため、多くの開発者は仕事を完了するためだけに朝まで喜んで書きたいと思っています。 コンテキストの変更により、生産性が低下します。

しかし、真に重要な優先事項は決して変わらず、一定です。 私たちの周りの人々が心を変える頻度は、開発者を激怒させます。 一般的に、私たちは常に警戒しており、敵が私たちに向けられるのを待っています。 しかし、今日、あなたが私たちに家を建てることを要求し、明日-車にそれを作り直すために、あなたがランクで不満を増していると感じても驚かないでください。

開発者のひどい欠陥

開発者は常に困難な立場に置かれていますが、私たちの中で最もヒステリックな人たちが自分自身を知ろうと努力しているにもかかわらず、私たちは犠牲者ではありません。 私たちの不機嫌な部分は内部から来ています。これは、ほとんどの開発者の奥深くに配線されている理由によるものです。 ひどい欠陥がありますが、それは知識と能力を過大評価していることにあります。

この欠陥はさまざまな形で現れますが、ほとんどの場合、タスクの時間を評価するときに現れます。 友達の開発者のほとんどは、特定のタスクに費やす必要がある時間を慢性的に過小評価しています。 締め切りを設定してそれに応えることができるのは、私たちだけです。 ほとんどの場合、間違いは2回以上発生します。 これは、他のクリエイティブな人々と同様に、開発者が直面するすべての問題を予測できないことが多いという事実によるものです。

多くの開発者は、プロダクトマネージャーが心を変えることに不満を述べていますが、タスクの時間を評価するときにこれを考慮に入れている人はほとんどいません。 会議の時間、要件の明確化、可能な変更を考慮に入れている人はいません。 バグ？ はい、私たちの理想的なコードには何もあり得ず、心配する必要はありません（そして突然、テスターがすべてを見つけるでしょう？）。 プロジェクトで休暇をとるのか、病気になるのは重要ですか？ 大丈夫、誰かが間違いなくそれらを置き換えるでしょう。

この直接の道はすべて期限を逃しますが、開発者が問題領域を調査する時間を考慮していないという事実ほどプロジェクトを遅らせるものはありません。 これは、主な欠点に直接関係しています。 私たちは、タスクを完了するために必要なすべてをすでに知っていると思いますが、多くの場合、私たちは人生で初めて見るテクノロジーを使用する必要があります。 定義する用語は、IKeyの指示に従ってソフトウェアを作成できる理想的な知識を意味します。 実際、多くのタスクでは、バックグラウンドを詳細に調査する必要があります。

専門職で大学を卒業した開発者は、卒業後に誤った安心感を抱きます。 彼らは自分たちがソフトウェアと開発プロセス全体の専門家であると想像していますが、実際には彼らの知識はゼロよりわずかに高いです。 最初の仕事に行ったとき、私は卒業生と同じくらい誇りに思っていました。 何年も経って初めて、私は本当に何も知らなかったことに気付きました。

コンピュータ大学は、業界であなたを待っている挑戦にあなたを準備しません。 まず第一に、それらは幅広いトピックに関する概念的な知識を提供するので、後で恥をかくことなく、現在の作業中にそれらに遭遇することはありません。 変数、関数、オブジェクトを教えられるのは、ほとんどの時間をそれらと一緒に使うからです。 データベースを教えられ、それらを照会します（ただし、通常のフォームは実際には役に立たないことが証明されます）。 ほとんどの時間を異常に費やして、専門家の開発中に抽象化レイヤーの下に隠れてしまうソートアルゴリズムとデータ構造を研究します。 要するに、コンピューター大学は、実際には解決する必要のない問題の解決を検討しています。 何かを並べ替える必要がある場合は、sort（）メソッドを呼び出します。 キューまたはリンクリストが必要な場合は、作成する言語のネイティブ実装を使用します。 これらの問題はすべて私のためにすでに解決されています。

大学を卒業すると、世界中で何でもできると信じていますが、実際には、私たちの前でやったことしかできません。 しかし同時に、私たちは尊大な知識人のように振る舞い、知識が理想的であることを考慮して、新しいことを学ばなければならないと考えることなく、開発時間が短すぎると判断します。

この問題の一部は、虚弱な虚栄心から生じています。 締め切りが長すぎると、人々は私たちの能力に疑問を投げかけることを恐れています。 「良い開発者」はすぐに働かなければならないと言われ、私たちはこれに喜んで同意します。 開発者が最初にプロジェクトの期間を決定し、次にリーダーの1人がこれが多すぎると不平を言う状況に常に感銘を受けました。 まず、すでに気づいたように、締め切りはおそらく短すぎます。 第二に、開発者はマネージャーよりも開発にどれだけ時間がかかるかをよく知っている必要がありますよね？ そして、これは別の問題につながります。

私もプログラムしていました

開発者が「私もプログラムに使用したことがある」ほど怒っているフレーズはほとんどありません。 それを言う人は誰でも、プロダクトマネージャー、デザイナー、またはリーダーシップの誰かが、彼らの無実の証拠としてそれを使用することは、開発者からの軽toにつながります。 レブロンジェームズ（有名なバスケットボール選手）に試合前のトレーニング時間を尋ねると、私が学校でバスケットボールをしていたからといってアドバイスを始めたら、彼は非常に驚いたでしょう。 開発者は常にこの方法で教えられます。

ここに、私の目の前でマネージャーが発した無知のいくつかの例を示します。

わかりません、これは大きな問題ですか？ ここで、コードを数行追加するだけです。

技術的には、「コードを数行追加する」ことで問題を解決します。 これから簡単になることはありません。

Nは、このタスクには数日で十分だと言います。

はい、Nはすでに問題領域を完全に把握しているためです。 知りません、勉強する時間が必要です。

プロセスを高速化するために何ができますか？ さらに開発者を割り当てますか？

原則として、問題に関係する開発者の数の増加は、問題を悪化させるだけです。 より速く何かをする唯一の方法は、小さな問題から始めることです。

しかし、あなたができる最悪のことは、あなたもかつてプログラミングしたことを開発者に伝えることです。 これは、過去にプロの開発者であることとまったく同じではないことに注意してください。 原則としてマネージャーになる開発者は、最終期間中にいくつかのスキルを保持します（原則として、5年間で、その後、テクノロジーはすでに完全に変化しています）。 しかし、プロのソフトウェア開発に一度も関与したことのない人にとっては、自分の趣味を自分の無実の証拠として使用するよりも、自分の趣味を守る方が良いでしょう。

（公正であれば、デザイナーもそのような無知に悩まされます。誰もが美しいものが好きなので、誰もが自分をデザインの専門家だと考えます。しかし、それはあなたをプロのデザイナーにしません。）

より多くのベビーシッター

開発者は、「チーム内の7人の乳母」という問題に常に直面しています。 タスクを完了するための実際の期限を常に過小評価しているため、ほとんどのソフトウェアは遅れて登場します。 大企業であろうと中小企業であろうと、未知のスタートアップや評判の良い製品であろうと、それらはすべて遅れて出てきます。 通常、問題全体が開発者の不足であると判断する、遅刻を遅らせるマネージャー。 「だからもっと多くの人を選び出そう」と彼らは言う、「それは私たちのすべての問題を解決するだろう」。

間違いなく、開発者の数を増やすことで問題を解決できることは間違いありません。 ほとんどの場合、それらの分離は追加の困難につながります。 創造的な人々をチームで働かせることは容易ではありませんが、彼らがチームにいるほど、それを行うことは難しくなります。 開発者はただじっと座っていることは許されていません-マネージャーが何もする必要がないと判断するとすぐに、彼らはすぐに彼らのために仕事を思いつきます。

同様のことが、まったくばかげた形で私に起こりました。 1つの小さなチームで、ゼロから作成された新しいYahooホームページのデザインを開発しました。 これは理想的なプロジェクトであり、ページアーキテクチャの基本的なグループを小さなグループで設計しましたが、誰も気にしませんでした。 8人の新しい開発者が割り当てられたため、設計が完了し、プロトタイプの開発を開始する準備が整いました。 さらに、これらの開発者はすぐに新しいページのプログラミングを開始するように指示されました。 最終的な形のアーキテクチャがまだ存在していなかったので、他のタスクは何でしたか！ しかし、開発者はアイドル状態のままにすることはできず、プロジェクトに割り当てられているため、タスクを与える必要があります。 鶏と卵に関する古典的な問題。

理想的な状況では、最初にプロトタイプアーキテクチャを完成させてから、その実装のために追加の開発者を受け入れます。 実際、立ち往生しています。 その結果、私は別のプロジェクトから既に準備されたアーキテクチャを使用することに決め、彼女のためにそれを新しいものと呼ぶことができるシンプルなインターフェースを書きました。 開発者は作業を開始でき、アーキテクチャの開発を継続できました。 これは、開発者がまだ実装されていないインターフェイスのその部分に到達したときに動作を停止したひどい問題に対するひどい解決策でした。 その結果、マネージャーに、新しいアーキテクチャを完成させる時間が与えられなかった場合、カードのきちんとしたハウスがすぐに崩壊することを伝えなければなりませんでした。

チームの開発者が多すぎると、プロジェクトが非常に複雑になります。 もちろん、彼らは互いに独立したタスクに取り組むことができますが、原則として、プロジェクト内のそのようなタスクの数はそれほど多くありません。 より多くの開発者がプロ​​ジェクトに関与するほど、開発ではなく、チーム作業の計画と組織化により多くの時間が費やされます。 家を建てるという比phorに戻ると、1階を建てる前に2階を建てることはできません。 ほとんどのソフトウェア開発タスクは厳密に順番に実行されるため、追加の開発者を割り当てても開発プロセスはスピードアップしません。 私の前の同僚の一人が言ったように、あなたがどんなに多くの女性を持っているとしても、あなたは生後9ヶ月までの赤ちゃんを産むことができません（実際、フレッド・ブルックスの本Mythical Man-Monthからの有名な引用）

不機嫌そうな

そのため、毎日、情報の不足、要件の変化、問題領域の理解不足、自分の考えを推測する同僚に直面する必要があります。 創造的な人間として、私たちはこのすべてに我慢します。なぜなら、私たちの仕事の結果は生きている人々によって使われるからです。 これが開発者の主な動機です。1日あたりの訪問数が100万のサイトやレストランチェーンの販売システムに関係なく、私たちの努力によって知らない人の生活も変わるという考えです。

私はもう一度繰り返します-開発者が「燃え尽きる」のは、作業が難しいからではなく、指示が絶えず変化し、リリース日が遅れているためです。

誰かが再び考えを変えたためにリリースが遅れると、ひどい不平を言う。怒ってうなり声。私たちの努力の結果をエンドユーザーにもたらすという私たちの夢は、再び実現することを妨げられました。驚くべきことに、開発者はめったに完璧主義者ではありません。最善は善の敵であることに同意し、徐々に作業をレイアウトし、それを1つの大きな全体にまとめる準備ができています。なんで？なぜなら、これが私たちの仕事を時間通りに人々に届ける唯一の方法だからです。

いいえ、遅延はソフトウェア開発プロセスの不可欠な部分であることを理解しています。開発者は、設定された期限に間に合うように、10人で作業する準備ができています。私たちは1日12時間働く準備ができていますが、それは通常の結果につながるだけです。

ありがとう 他に何

開発者として、他の従業員のモードとは根本的に異なる操作モードに慣れます。サーバーまたはアセンブリで何かが故障した場合、夜中に目を覚ますのはマネージャーと一緒のデザイナーではなく、開発者です（目覚めさせる必要があるマネージャーも知っていますが）。ある日、私がデートに女の子を残そうとしたとき、彼らは私に電話をしました。私の問題を解決しようとして失敗した間、私のカップルは辛抱強く1時間待って座っていました。結局、彼女は去り（私は彼女を責めることはできません）、私の仕事や同僚とIRCクライアントで一人で苦しむことになりました。

同時に、長い就業日について非常に不満を言う開発者もいれば、別のバグのために夜に目が覚めたという開発者もほとんどいません。私たちのプロジェクトは私たちにとって子供のようなものであり、私たちは彼の世話をする準備ができています。朝の2時に彼を養う必要があるなら、問題ありません。彼が週末に時間をかける必要がある場合、私たちはいつも笑顔で私たちの創造物がどのように成長するかを見て、彼を見つけます。

開発者は、タスクを自分で完了する機会を与えられると特に満足します。タスクが完了し、レビューを行う準備ができているという手紙を送る喜びと比較することはできません。しかし、コミットの10分後に、新しく作成された頭脳にバグが書き込まれると、彼らの喜びはすぐに消えます。

自分の場所を想像してみてください。1日（または1週間（または1か月））をタスクに費やし、それに対処しました。あなたは、あなたが前に持っていなかった知識を必要とするかもしれない仕事からの自尊心に圧倒されます。あなたが望むのは、あなたの成果を賞賛することです。誰かがあなたの仕事を称賛してくれればさらにいいです。そして、あなたは何を得ますか？バグメッセージ 動作しません、そのように動作しません、など。欲求不満の気持ちでバグに取り組み始めなければなりません。

なぜノーと言うのですか。

上記のすべてを要約するために、開発者がノーと言う（または単に不平を言う）主な理由を強調しましょう。

• 開発の最後に新しい要件が登場し、その実装の時間は絶対にありません。
• 新しい要件は、プロジェクトを遅くしないように、以前に行った仮定と矛盾しています。
• 新しい要件は、以前の要件とはまったく反対です。
• 別の方法での新しい要件は、完了する必要がある作業量を増やし、期限を満たします。
• 私たちは非常に疲れているため、新しい要件を実装するのは信じられないほど困難に思えます。

これらの問題は、最初の問題を除いて、短時間で労働条件に関連していることに注意してください。期限までにすべてのタスクを完了する必要がありますが、作業中にタスクが絶えず変化しているときにこれを行う方法はありますか？これが起こると、私たちの不満（およびうなり声）に制限はなく、文を完成させる前に「いいえ」が飛び出します。

摂食とケア

では、マネージャーは実際にこの不平をどのように処理しますか？開発者を動かしているものを思い出しましょう：

• 作成する欲求;
• 問題を解決したいという欲求。
• ビジネスでの仕事の結果を見たいという願望。

次に、このリストにないものについて考えます。お金。現金報酬を増やすことは、開発者を満足させることはめったにありません。下品なスタンプのように聞こえますが、開発者にとって、真実はお金に関するものではありません。お金は彼らに自分の喜びのために生きる機会を与えますが、基本的に彼らは開発プロセス自体に興味があります。そして、ほとんどの場合、彼らが必要とする主なものは、通常の労働条件の下でそれに対処する能力です。

それでは、開発者の通常の労働条件をどのように作成しますか？

彼らと働く

開発者は、デザイナーと一緒にプロダクトマネージャーと同じくらいクリエイティブです。そのため、クリエイティブプロセスに含めるように注意する必要があります。開発者は、ブレインストーミングと要件の議論のミーティング中に平等な存在はありません。開発者にプロジェクトチームと会って直接作業する機会を与えます（必ずしもすべてを同時に行う必要はありません）。言い換えれば、できるだけ早く開発者を創造プロセスに含めます。説明のない仕様のドキュメントを投げ込んだとき、誰もそれを好きではありません。

開発者は限りなく論理的であるため、初期の会議に出席することで、要件の根拠を理解し、多くの問題が発生する前に解決できます。開発者がビルダーのように扱われると、彼らは絶えず質問をするため、開発プロセスが遅くなります。クリエイティブワークショップで開発者が同僚のように扱われると、開発者は質問が少なくなり、開発が迅速に進みます。

開発者ができることとできないことをよく知っていることも重要です。たとえば、フロントエンドの開発者は、残りの何年も前にブラウザに実装できるものについて学習します。この知識を他の人と共有することで、私たちの能力に基づいて、製品を改善する方法に関する新しいアイデアを生み出すことができます。写真をアップロードするサイトを考えて、デスクトップからブラウザに直接投げることができることを知らないと想像してください。これは設計にどのように影響しますか？

そのため、開発者はプロジェクトの最初から創造的なプロセスに参加する機会を与えてください。プロジェクトに関する意見や、技術的に実装可能なものを聞いてください。何をすべきかがわからないほど、他の人の意見に耳を傾け、仕事を改善します。これを達成する唯一の方法は、プロジェクトの創造的な作業に参加させることです。

創造的な雰囲気を作る

開発者をクリエイターとして考えてみましょう。創造力を発揮できるように、すべての可能性を提供してください。ハックデイとハックトンは偶然ではなく人気があります-開発者がコードと開発への愛を創造的に復活させることができるため、人気があります。 hackotonesでは、開発者は通常の作業の制限から解放され、完全に創造性に専念しています。

四半期に一度、開発者に喜びを与えるには1つのハカデで十分です。もっと知りたいですか？テーマhackodeyを配置します。最も創造的で実用的なソリューションなどに賞を与えます。主なタスクは、開発者が作成できるようにすることです。そうすることで、通常の作業に戻り、プロジェクトの開発と改善を続けられる自分自身の強さを感じることができます。

これは開発者だけに適用されるわけではないことに注意してください。時々、彼らは創造的な仕事をしたいと思っています。しかし、私の経験では、プロダクトマネージャーとデザイナーには、このためのより多くの選択肢があります。すべての種類のトレーニングと会議は、マネージャーとデザイナーのために定期的に開催されますが、開発者はしばしば忘れられます。

ところで、ハットンは創造的な雰囲気を作り出す唯一の方法ではありませんが、最初のステップとして最も簡単です。また、開発者をカンファレンスに送り、開発者が会社の費用で本を購入できるようにすることで、開発者の創造的な流れを目覚めさせることができます。たとえば、開発者が20％の時間を自分のプロジェクトを開発するために使用できることは誰もが知っています。これはすべて、開発者との長期にわたる友情の始まりにつながります。

リラクゼーションを奨励する

作業中に定期的に費やす精神的努力の時間を考えると、開発者は休憩を取ることを覚えておく必要があることが明らかになります。残念ながら、時間を計画する際に大きな成功を収めることはめったにありません。仕事に没頭していると、休暇を忘れてしまうことがあります。キャリアの最初の5年間で、合計7日間の休暇を取ったようです。理由はわかりませんが、ストレスを軽減する方法はわかりません。これは大きな問題です。

開発者の燃え尽きは、この状態で作業することに慣れているという意味で独特です。しかし、燃え尽き症候群がピークに達するのは価値があり、私たちは辞めて別の仕事を探すために去ります。さらに、開発者の誰も、彼らが耐える力がないとあなたに言うことはありません。彼らはこれに対してあまりにも誇りを持っています。私の最後のチームでは、すべての開発者に、彼らがすべて疲れていると感じたらすぐに私のところに来るように言いました。私は、彼らのための唯一の方法が解雇になるまで彼らに耐えてほしくありませんでした。私は彼らが仕事をやめずに楽しんでいる必要がありました、そしてそれを達成する唯一の方法は彼らがいつ燃え尽き始めるかを理解することです。

開発者に休暇をとるように勧めます。あなたの会社は休暇のために一定の時間を提供します-したがって、開発者が少なくとも4〜5か月に1回は休暇を取るようにしてください。プロジェクトスケジュールを監視するマネージャーがこれを行うのが最適です。

休暇中の定期的な休息により、開発者は創造力を回復する機会を得ることができ、絶え間なく続く期限から守ることができます。はい、休暇中はおそらく開発にも携わるでしょうが、労働者ではなくプロジェクトに専念します。そのような仕事は、私たちがエネルギーを獲得し、新しい戦いに備えるのに役立ちます。

それらを開発させます

皮肉なことに、多くの企業は開発者を雇い、開発を止めています。代わりに、彼らの日々は生産性を損なう役に立たない会議でいっぱいです。一般に、開発者は、気を散らされることなく、少なくとも4時間コードに座ることができる場合に最も効果的です。

数時間で会議に出席する必要があることがわかっている場合、プログラミング中に良い「ストリーム」に入ることは常に困難です。開発プロセスにとって、最初に時間コードを記述し、次に1時間中断し、次に時間コードを再度記述し、さらに1時間中断するプロセスほど非生産的ではありません。開発者の脳は、プログラミングのために「正しい」状態に切り替えるのにある程度の時間が必要です。

開発者が連続プログラミングのために少なくとも1日4時間を確保できるようにしてください。これが開発を加速する唯一の方法です。それは非常に論理的です。人々が1日8時間働く場合、この時間の少なくとも半分をメインタスクに費やす必要があります。たとえば、私にとって最も生産的な期間は午後1時から5時の間であることがわかりました。毎日この時間に仕事ができれば、すべてのタスクに簡単に対処できます。この時間が会議によって中断される日には、今日は多くのことをすることができないことを理解しています。

そして、少なくとも週に1日は、毎日のハエを含む会議を行いません。開発者が自分の時間を独自に配分し、すべての問題に対処できる1日を用意しましょう。気晴らしがまったくない1日でどれだけのことができるか、あなたは信じられないでしょう。かつて、私のマネージャーは、少なくとも週に2日は自宅で仕事をすることさえ要求しました。その結果、私は信じられないほどのスピードで働きました。

感謝の気持ち

重要な結果を達成して、今すぐ何かを行うことができます。タスクを終了したばかりのときにどのように激怒するかについては既に述べましたが、バグはすでに書き込まれています。開発者が耳を傾けるのは言うまでもなく、後戻りして仕事を賞賛する機会はめったにありません。

タスクを完了したばかりの開発者への小さな感謝の手紙は、特にタスクが困難だった場合、信じられないほどの成功を収めることができます。 「聞いてくれて、仕事をありがとう、間違いなく見ます」と言っても、これはバグの最初のストリームが現れたときに起こる悲観的な気分を取り除くのに十分です。開発者が自分の仕事を評価することは非常に重要です。なぜなら、彼らが受け取るフィードバックのほとんどは、バグ、問題など、否定的なものだからです。いくつかの親切な言葉、そしてこれはもうそれほど怖くないようです。

最も努力を重ね、最も改善を加えた開発者などに四半期ごとに与えられる報酬のようなものを割り当てると素晴らしいでしょう。賞はiPadのように高価で望ましいものである必要はありませんが（感謝して受け入れますが）、チーム全体または部門へのわずかな贈り物と功績の承認の手紙になります。

そして、完了した作業に人々に感謝するときは、開発者について決して忘れないでください。私は、誰もがマネージャーやデザイナーの仕事を賞賛する無数のプロジェクト会議に出席しましたが、汗、血、涙がプロジェクトに命を吹き込んだ開発者を完全に忘れていました。各プロジェクトの成功は、3つのグループのそれぞれの努力にかかっています; 1つのグループだけではそれを達成できません。会社がチームの一部ではなく、チーム全体の努力を認識していることを確認してください。

おわりに

原則として、開発者は優れた人々です。私たちは皆間違いなく個性的であり、可能な限り最高の結果を達成したいのです。私たちを使いの男の子のように扱うのをやめて、創造的なプロセスの一部として私たちを尊重し始めるなら、あなたはすぐに優れた結果を達成するでしょう。私が働いていたチームは常に、開発者の考え方や動機についての理解が不足していたため、何らかの摩擦が生じました。この記事が開発者と彼らの同僚との相互作用の改善に役立つことを心から願っています。これはそれほど難しくありません。通常の働き蜂ではなく、全体的なソリューションの一部を感じるだけで済みます。