今日、私たちは新しいテクノパークマスタークラスの出版物のシリーズを開始しています。 そしてそれらの最初は、無料のトピックに関するアレクセイ・ライバックによるマスタークラスです。そこで彼は学生と実生活での仕事が勉強とどう違うかについての考えを共有しました。 当社のウェブサイトのビデオと、以下の改作されたトランスクリプトをご覧ください。



私は長い間Badooで働いていましたが、私のプロジェクトの前に、このプロジェクトは小さなスタートアップから数百人のエンジニアと数千の強力なサーバーを複数のデータセンターに分散する大企業に変わりました。 次に、プログラマーの職業を選択する学生にとって、私が十分に興味深いと思うことについてお話したいと思います。



現在の傾向についてはお話ししませんが、今日それは重要かつ必要です。多くの人がこのことについてあなたに話すことができます。 代わりに、各生徒が1年間、時には数年間経験する作業に、元学生が普遍的に適応するようなものについて話しましょう。 このプロセスはかなり苦痛であり、この「適応」を「正しく」行うことは決してできません。 このトピックは、ファッショナブルなテクノロジーチップよりも学生や卒業生に関心があるはずです。 自己教育のトピックに触れるときに、それらについても話しますが。

手荷物

大学を手荷物で仕上げます。これには、この世界での私たちの位置、特定の価値体系の考えが含まれています。 そして、最初の数年間は、この荷物は他の人にもはっきりと見えます。原則として、若い従業員の価値体系はやや偏っています。 理由を見てみましょう。



学習は一定のリズムを設定します。 試験では、勉強中に一生懸命勉強します。 異なる大学では異なる方法で勉強しています。 たとえば、私は大学で次のように勉強しました。セッションごとにかなりリラックスしていますが、セッション中は逆に複数の負荷がかかります。 一部の教師は中級の口語表現を試み、特定のリズムをサポートする追加の作業を求めましたが、本当に激しい負荷は年に2回だけでした。 その間、誰もができる限り勉強しました。



次は試験です。 また、事は非常に簡単です。 すでに1年目または2年目で、私は古い母親のローブを取り、それからA4のシートのサイズの部分を切り取り、ジャケットに縫い付けて、すべてのチケットを「爆撃」しました。 もちろん、私は彼らについて考えながら、準備に時間を費やしました。 私は優等で卒業しました。 「爆弾」の準備は、トピックの理解と記憶の両方に大いに役立ちました。 しかし、これは後で働き始めたときに私が待ち望んでいたものに近いものではありません。 大学では、概して、すべてがあなたのために決定されます-あなたの学習のリズムは完全に外部から決定されます。 しかし、作業を開始するとすぐに、すべてが変わります。



今、教えられたことについて。 私はコンピューターサイエンスを教えられなかったので、自分で基盤を引き上げなければなりませんでした。 そして、これらは、まず第一に、異なる難易度のアルゴリズムです。 すべてのITスペシャリストがアルゴリズムをよく理解している必要があるように思えました。 しかし、人生はそうではないことを示しています。 アルゴリズム作成の専門家であることが本当に必要な仕事はそれほど多くありません。 今日必要なことは、基本的なアルゴリズムを知り、プログラムのテキストを読み取ることでアルゴリズムの複雑さを判断できることです。



次のポイントは、テキストとしてのプログラムに対する態度です。 仕事を始めたばかりのときは、まずプログラムを、マシンが実行するものではなく、単にテキストと見なします。 そして、私たちはテキストが美しくてきれいであることを確認します。 それには何の問題もありません。 しかし、同時に私たちの主な価値が美しさであり、分解の便利さ、理解の容易さ、またはプログラムとハードウェアの相互作用ではない場合、作業することは非常に困難です。 転職した人たちは知っています。「私は、非常に美しくてクールなクールなアプリケーションを作ったので、会社は悪いです。 しかし、本番環境では速度が低下し、彼らは私のところに来ました。 なぜ私に？ 管理者は彼に彼女が減速した理由を見つけさせた。 鉄を買うか、何か他のものを考えさせてください。」 これは、価値体系の偏りの良い例です。 プログラマーは、最適に機能するようなコードを作成する必要があります。 そして、それが最適に機能しないことが判明した場合、プログラマーはそれを把握する必要があります。



トレーニング中、私は疑問に思いました。 スーパー企業の雇用は誰ですか？」 それから私は最初に彼らがオリンピアードを取ると思った。 もちろん、それは悪いことではありませんが、オリンピックでの勝利は間接的に仕事に関係しています。 はい、オリンピック選手はストレスの多い状況下で複雑な問題を短時間で解決できます。 実質的にすべての真面目な大学が1つではなく、オリンピックのいくつかのチームを持っていることは注目に値します。 厳しい選択の結果、立派な人々がピラミッドの頂点にいます。 ただし、このプロセスには欠点があります。

• 人々は非常に特定のタスクを解決しますが、実際には非常にまれです-それらの1％しかありません。
• 非常に短い時間で彼らがすることは悪いことです。 はい、これは注目に値する能力とストレス耐性の指標ですが、人生のアプリケーションでは通常、このような短い時間間隔ではなく、単独で書かれています。

バイアス値システム

現代社会は私たちに自己中心的な価値体系を課しています。 芸術作品、科学的発見-これらはすべて、明るい個性によって、そして多くの場合完全に個々に作成されます。 しかし、ソフトウェアの生産において（だけでなく）状況はまったく異なります。ほとんどすべてのプロジェクトの成功は、個人ではなく、人々、チームの努力にかかっています。 大学で勉強していると、 コラボレーションがないという印象を受けます。 無人島に出かけ、そこで科学を行い、素晴らしいプログラムを書き、傑作を作成し、誰かと対話することは完全にオプションだと思いますか。



過去数世紀にわたって、社会は教育と公民権に関してますます均質化してきました。 多くの人はこの声明に議論の余地があると思うかもしれませんが、全体として、社会はより人道的になっていると言えます。 そして過去数十年で、超自由主義の考え方は、国家がもっぱら市民に奉仕するための機関として考えられているということで、人気を博しています。 全体としてはかなりきれいなアイデアですが、同種の社会では一般的に多くの留保が行われている小規模でしか機能しないのではないかという懸念があります。 しかし、私たちの多くは、何が良くて何が悪いのか、理想的な状態がどうあるべきか、そして外の世界が私たちとどのように関係するのかという特定の考えを持って、彼らが働くようになる企業にこのビジョンを投影します。 これは大きな間違いです。 非常に大規模な場合にのみ、あなたの会社を州として扱い、州と同じようにあなたとやり取りすることを期待できます。











次の瞬間。 過去20年にわたって、インターネットのおかげで、さまざまな種類の関心コミュニティが形成され、非常に強力な発展を遂げました。 人々は新しい言語、プログラミング環境、コンポーネントを作成します。 原則として、これらの社会は一部の企業や教育機関の周りではなく、愛好家の周りに作成されます。 そして、これらのコミュニティのいくつかは非常に疑わしい価値を宣言しています。 Perlコミュニティには、「プログラマの3つの大きな美徳を開発することをお勧めします：怠iness、焦り、hub慢」（「プログラマの3つの最も重要な美徳：怠iness、焦り、誇り）を開発することをお勧めします」） 。 とても奇妙に聞こえます。 同時に、このフレーズの作者であるラリーウォールは、長い間、自分が何を念頭に置いていたのか、そして一般に、最も肯定的な性質ではなく、これらを選んだ理由を説明する必要がありました。 しかし、それはずっと前のことです。 そして何が起こったのか。 相互に接続されているかどうかはわかりませんが、このコミュニティでは、Perl言語を開発する代わりに、すべてのプログラミング言語用のマシンを作成し、Perl 6を使用することにしました。 Perl 5、および実際にプロジェクトを行き止まりに導いた奇妙な人々に残っています。 （注：非常に正確に言うと、2015年9月には安定したリリースに似たものが表示されますが、第一に、本番環境で使用する準備が整っていないか、第二に、その間に15年以上が経過していますperl開発者コミュニティは非常に貧しい。）



大学院生の最初の数年間、私はインタビューで仕事とは関係のない質問をすることに気付きました。 最も奇妙なのは、「カルロスカスタネダの仕事についてどう思いますか？」 私は答えた：「私は属していません。 そのような人がいることは知っていますが、ごめんなさい。」 私はインタビューで「悪いプログラマー」とは何かを尋ねるのが好きです。 一見すると、これはかなり奇妙な質問でもありますが、少なくとも特定の対話を伴います。なぜなら、人は自分の価値を明らかにし、何が良いか、何が悪いかを話すことを余儀なくされるからです。 「優れたプログラマとは何か」という質問に対する答えは、多かれ少なかれ予測可能です。ここでは、いくつかの決まり文句を使用できます。 そして何が悪いのですか？ 気に入らない点は何ですか？ これは知っておくと便利です。

集団

私が働き始めたとき、私は突然多くの企業で個人的な資質がプロのものよりも高く評価されていることを知りました。 非常に多くの場合、必要なのは「クールなプログラマー」や「クールなコーダー」ではなく、「健全な人」であると聞くことができました。 これは私にとって新しい要件でした。 当時、多くの企業が非常に奇妙な動機付けスキームを使用していたと聞いたことがあります。慈善係数がありました。つまり、従業員は定期的に慈善の等級を受け取りました。 ユートピアのように聞こえますが、それは現実です。 本当にそのような会社がありました、そしておそらく今でも。



生産性は非常に高くなりますが、どのプロジェクトでも他のチームメンバーとやり取りする必要があります。 また、大規模プロジェクトでの失敗や損失はすべて、他の誰かの病気や寝坊したために起こるわけではありません。 通常、多くの問題の根本は、誰かが誰かと仕事をしなかったことです。 非常に重要なコンポーネントを選択する際に人々は同意せず、ルールにも同意しませんでした。その後、全員が自分で毛布を引っ張り始めました。 したがって、大規模なプロジェクトでは、協力などのスキルを高めることが非常に重要です。 これらは相互接続されていますが、これはのれんと同じではありません。 ポイントは、大規模なプロジェクトは何年も存続する必要があるということですが、変位した価値システムという形での私たちのエゴセントリックな荷物はこれを大きく妨げます。

優れたプログラマとは何ですか？

ロンドンのエンジニアによると、優れたプログラマーは、チームが担当するすべてのコンポーネントを理解し、適切で優れたデザインの読みやすいコードを書く人と呼ばれます。 また、優秀なプログラマーの兆候には、彼との作業のしやすさが含まれます。 非常に重要なのは、コードレビューの建設性です。同僚からのコードレビューです。 大企業では、同僚が見ない限り、リポジトリにコードはコミットされません。 コードが基準を満たしていない場合、または何かが間違っている場合、同僚はトローリングフィードバックを提供するのではなく、対応しないものとその理由を説明し、いくつかの推奨事項を提供します。 つまり、対話は建設的でなければなりません。 これは、一部はのれんの証拠です。



また、優れたプログラマーの資質には、人が会議で効果的であるべきという事実がありました。 これも非常に興味深いです。 同僚との会議でどのように効果がなくなるのでしょうか？ 私たちは何かについて話し合うために集まった。 しかし、会社で働き始めると、人々が決定を下すことができないか、討議プロセスを管理するファシリテーターがいないという理由だけで、会議によっては非常に時間がかかることがわかります。 したがって、多くのアジャイルシナリオでは、スタンドアップ会議が使用されます。 人々は長い間立っていることにうんざりしているという事実のために、彼らはできるだけ早く共通の解決策を考え出そうとします。 原則として、効果的であるとは、おそらくあなたが何かを好まない方向に行動することですが、一定期間内に目標を達成することは確かです。 コストを計画および予測する方法を学び、リスクの少ない方法を選択する必要があります。 たとえば、興味深い新技術（これまで使用したことがない）を使用し、期限が厳しい場合は、リスクを冒さずに、実績のある技術に基づいたソリューションを選択することをお勧めします。



優秀なプログラマーの兆候には、オフィスでの生産的な娯楽が含まれます。 ある人がオフィスで8時間働いているように思えました。 これは非常に楽観的です。 気晴らしはたくさんありますが、気を散らし、何かを読み、何かを勉強する必要がある場合があります。 その結果、生産的な作業に費やされる時間は8時間未満です。



優秀なプログラマーの最も重要な特質の1つは、チームで働いて、プログラマーが期限に責任があるということです。 チームが何かを再構築し、一部のタスクを変更し、準備ができるように、開発プロセスが意図したとおりに正確に進行していないことを少なくとも事前に同僚に警告する必要があります。 あなたは最後まで耐える必要はありません。そして締め切りの時に、「まだ準備ができていません」と言います。 あなたの仕事を計画し、約束を果たし、タイムラインを適切に評価することが必要です。



これらの値はすべて非常に単純で、些細なように見えます。 しかし、私が働き始めたとき、私自身の価値体系は、多くの点で、リストされた優秀なプログラマーの基準と一致しませんでした。



どのプロセスでも、モデルを見つけて構築し、属性を見つけて試して、それらをねじって、モデルがどのように変化するかを見るのは非常にクールです。 そのような属性として、プログラムのサイズとその寿命を考えてみましょう。 モデルとして、プログラマーを検討することを提案します。 何か役に立つことをした一人のプログラマーから始めましょう。 彼は、ユーザーが何らかの問題を抱えていることを認識し、インターフェイスを設計し、必要な機能をプログラムして、どこかに配置しました。



属性を変更してみましょう。アプリケーションをより大きくし、より長く存続させます。 品質の問題があります。 プログラムが小さい場合、バグの可能性はそれほど高くありません。 しかし、コードベースの拡張と動作寿命の延長により、バグを検出するリスクは大幅に増加します。 架空のプログラマーがモバイルアプリケーションを作成する場合、たとえばさまざまなデバイスに関連する追加の問題がたくさんあります。 製品は各モデルで同じように動作するはずですが、一部のタブレットやスマートフォンではアプリケーションが正しく動作しないことが判明する可能性があります。 そして、ユーザーの忠誠心を維持するために、できるだけ早くこの問題を解決する必要があります。



リリース後、一度にいくつかのエラーを修正する必要が生じることがあります。 あなたが一人の場合でも、少なくとも破裂し、あなたはそれを修正する必要があります。 そして、あなたが1つの問題を解決している間、人々は他の人についてのろいをしています。 したがって、チームが表示されます-数人。



ここで、コードを理解できるように変更を簡単に行えるように設計することが重要です。 同僚がコードをすばやく理解し、必要に応じて変更を加えることができるようにします。 複数の人がコードを操作する場合、新しい手順を導入し、古い手順を修正するためのすべての手順に事前に同意する必要があります。

「アダルト」開発の機能

Webアプリケーションを作成し、十分な数のユーザーを受け取っている場合は、24時間動作を保証する必要があります。 これは、サポートインフラストラクチャを構築する必要があることを意味し、できるだけシンプルにする必要があります。 多くの機能を備えたアプリケーションを作成する場合、これは異なるレベルの複雑さです。開発者のグループがいくつかあり、それぞれが方向を決定し、グループ間の関係を確立する必要があります。 したがって、スケールの手順は次のとおりです。

• 一人のプログラマー。
• 小さなチーム/部門（5-7人）;
• 互いに対話するいくつかのグループ/チーム。
• グループで構成される部門で構成される会社。

あるステップから別のステップへの移行では、他の要件が前面に出てくるため、特定のものに対する態度が大きく変わります。 小規模で、大規模に作用するものは、まったく機能しないか、有害であることが判明することさえあります。 かつて、このことに気付いたのはすぐに気づかず、かなり大きな発見になりました。 私は新しい価値体系に適応していました。 仕事を始めた元学生のほぼ全員がこれを経験すると思います。

チームワーク

大企業には疑問があります。新しい従業員ができるだけ早く適応できるようにする方法、適切な文化を構築する方法などです。 基本的に、この問題はコミュニティと対話するときに存在します。 このコミュニティのメンバーの現在のニーズを受け入れ、何かを隠し、誰かを操作して、目標を達成しようとすることができます。 または正直に言ってください：「みんな、あなたは間違っていた。 このようにしなければなりません。 一方で、劇場、もう一方-アカデミー。」 そのため、多くの企業は、チーム内で価値のあるシステム、優れた従業員とは何かについての独自の理解を明確に促進しています。



実生活の例を挙げたい。 2000年代初頭のどこかで、Netflixの大規模なプレゼンテーションがネットワークに流出します。その意味は次のとおりです。「従業員を完全に形成された大人として扱い、見方を逸脱する場合は、次のように説明します。それは私たちには合いません。」 また、従業員が満たすべき基準の例を示しました。 すべてが優先事項を中心に展開されました。 大企業では、明らかに適切なソリューションがない場合に多くの困難な状況がありますが、一方を選択する必要があります。 どうする たとえば、個人的に必要なものとグループに必要なものを選択する場合、個人ではなく製品を作成するのはグループであるため、グループの利益を選択する必要があります。 また、選択は、グループの利益と会社全体のニーズの間で行われることもあります。 グループが製品を開発したが、何らかの理由で、あなたが正しいと思ったものとは異なる方法でそれを変更する必要がある場合、会社全体の観点からそれを見てみてください。 難しい選択をするときは、まず会社が何を必要としているかを理解しようとします。 会社が特定の規模に達するとすぐに、非常に興味深いタスクに従事し、初心者にあらゆる種類のジャンクを提供している、かすんだりまたは特権チームの大きなリスクがあります。 会社が健全な文化を作りたい場合、この行動は受け入れられません。



同じNetflixプレゼンテーションのもう1つの仮定：「華麗なジャークを容認しないでください」（「天才がジャークのように振る舞う場合、天才を容認しないでください」）。 従業員がどんなに才能があっても、彼が人々と仕事をしなければ、彼は別れを告げなければなりません。



次の瞬間。 どの会社も特定の予算を割り当てており、2つのアプローチがあります。これを規制し始めるか、「すべての大人。 あらゆる場合に一連のルールを思い付くわけではありませんが、このお金を自分のものであるかのように単純に使うでしょう。」 例を挙げましょう。 多くの従業員がモスクワからロンドンに移ります。 費やした資金を報告する最も簡単な方法は、小切手を提供することです。 しかし、おそらく多くの小さな費用があるため、それらの多くが存在する可能性があります。 これを行うには、これらのチェックを処理する人を選択する必要があります。 また、別の方法で行うこともできます。「ここに金額があります。好きなように処分できます。報告せずに、ささいなことで私たちのところに来ないでください。」 その結果、会社は各小切手をチェックする時間を費やす必要がなくなり、従業員がお金のために小さな費用を払うことがなくなるため、取引コストを節約できます。



ルール「50 to 50」に言及したいと思います。 誰が金銭的または時間的費用を負担し、誰が責任を負うべきかを選択する場合、多くの場合、従業員はすべての費用を会社が負担すべきだと考えます。 簡単な例。 私の同僚と私はしばしば会議に行き、異なる国のオフィス間を移動します-それには多くの時間がかかります。 「50対50」のルールは非常に単純です。1営業日全体をフライトに費やす（出張に行った-仕事だ）か、半日働いて半日を旅行に費やすことができます。 少し遅れて到着し、午後遅くにホテルにチェックインしますが、離れることはありません。 私はその時間の50％を働いたが、50％はこの時間を飛行のために奪った。



これは、多くの規定されたルールを取り除くのに役立ちます。 あなたは言うことができます：「みんな、私たちは大人です-お互いに、会社に、そしてコストに対応しましょう。 すべてが規制されている場合、これは会社の内部文化に利益をもたらしません。 多くのルールは非常に退屈です。」

最高のシェアを検索

多くの企業では、従業員に次のように言われています。「私たちと一緒に仕事をすれば、恐れることなく面接に行くことができます。 あなたが得るよりも高い自分を売る。 現在の市場の状況を確認してください-これがあなたの給与を決定するものです。 独自のスキルをお持ちの場合は、ほとんどの場合、需要があります。 市場を歩くことは絶対に普通です。 彼らが私たちが支払うよりも多くをあなたに提供するならば、私たちがそれを保ちたいならば、我々は給料を上げます。 そうでない場合は、別れを告げます。 私たちは本当にあなたを握りたくありません、あなたはより多くのお金を得ました。 一般的に、誰もが幸せです。 こんにちは。」



このアプローチは非常に効果的です。 もちろん、昨日、今日ここであなたがどのようにそこにいたかについてみんなに話すべきではありません-これはチームにあまり良い影響を与えません。 ただし、現在の状況を理解するには市場を歩き回る必要があることに留意してください。



結局のところ、人間の心理学は、あなたがいくらお金を受け取っても、ある時点であなたが低賃金になっているように見えるように設計されています。 特に、他の会社がより多くの支払いをしていることを人が突然見つけたときに、この考えが思い浮かぶことがよくあります。 「だから彼らはここで私たちを欺く！ 実際、どのような給料がクールなのか。」 つまり、適切な統計情報なしで、1つの次元で結論が下されます。 したがって、雇用主にできることは、「他の場所に行き、これが本当に一般的な状況なのか、最も才能のある状況なのかを理解し、理解することです」と言うだけです。 彼らがあなたに提供してくれるかどうかを確認します。多分あなたは本当にそんなに費用がかかります。」



上記を要約すると、古い荷物を取り除き、周りを見回し、人々とやり取りし、共同プロジェクトを作成し、共同作業とコミュニケーションに力があると感じます。 チームで働く方法を学ぶことは、特にすでに仕事を始めている場合は、タスク番号1です。

個人の生産性

x軸は、抽象的な「外部圧力」を表します。通常、これは会社、同僚、上司から発生します。 Y軸は生産性を示します。 グラフの2つのバリエーション：「デトネーションなし」と「デトネーションあり」。 誰かまたは何かがあなたを押している場合-それは良いことです。 これは通常、生産性の向上に役立ちます。 別のことは、すべての人にとって異なる、特定の心理的限界があるということです。 そして、あなたがそれを越えた場合、それから良いものは何ももたらされません：生産性は単に低下するか、非常に段階的に低下します。 生産性の向上とは、自分自身を管理することです。 自分を管理することは：

• 計画：達成する必要がある目標を自分で計画します。 目標がない場合、生産性を高めることはできません。
• 組織：何かが計画の実施を妨げる場合-削除または変更。
• 動機付け：自分自身の動機付けをする必要があります。
• コントロール：中間点で結果を追跡します。

実際、これらはあらゆる管理の4つの機能です。これは、チームと状態の両方を管理する場合にも当てはまります。 あなたがやっていることで少し違って見えるようにしてください。 そして、目標が何であり、どのように達成したかを理解したら、すぐに質問をすることができます：目標をより早く達成するために何ができるでしょうか？ できるだけ早くこれを開始してみてください。



自制心と自制心はストレスに関連しています。限られた時間で何かをするように強制する必要があります。 そして、何もせずに自分自身に何もさせたくない人がいます。 彼らが外部から押し出されると、彼らはそれを攻撃として認識し、変化する代わりに、彼らは去り、逃げます。 逃げる方法については後で詳しく説明します。



自分と同僚が目標を計画しやすくするために、 SMART原則を使用できます

• S-特定。 各目標は具体的でなければなりません。 つまり、特にここでこれを行う必要があります。
• Mは測定可能です。 目標は測定可能でなければなりません。 不適切な目標設定の例は、コードカバレッジの改善です。 「まあ、皆さん、改善しましたか？」-「改善しました」-「改善しましたか？」-「改善しました」-「そして、どのように？」 正しい言い回しは、「テストでコードカバレッジを50〜55％増やします。
• A-達成可能。 目標は達成可能でなければなりません-これは明らかです。 あなたは自分自身にグローバルな目標を設定することができます：1年で非常に豊かになること。 しかし、ほとんどの場合、目標は少数のサブゴール、特定の数の特定のステップである必要があり、それらがより現実的であるほど、この方法に対して前向きな態度を身に付けます。
• Rは関連しています。 タスクを計画するときは、それらの実装が目標の達成に役立つことに注意する必要があります。
• T-時間関連。 すべての目標には何らかの期限があります。すべての期限があります。 5つのポイントすべての中で、これが最も重要です。

プログラマーにとって、最大の問題は期限です。 「みんな、単に締め切りがないように開発を進めましょう」と言う人もいます。 締め切りはストレスです。」 おそらく、そのような人々は人生で何かを達成しますが、このアプローチでは予想外の損失が非常に多くなる可能性があると確信しています。 本当に生産的になりたいのであれば、それぞれの目標は特定の用語で決定する必要があります。 この期限を混乱させることはできますが、次の質問を自問することができます。「なぜ期限に間に合わなかったのですか？ どこまで完了していませんか？ 時間通りにそれを行うにはどうすればよいですか？」 そして、おおよその用語を指定している場合は、自己改善せずに、反射せずにそれを移動します。



大規模プロジェクトの開発において最も重要なことは、さまざまなコンポーネントの一貫性が弱いことです。 自分の目標を設定します。 接続性が低いほど、1つのコンポーネントのブレーキングまたは操作不能により、他のすべての目標と目的の達成が停止する可能性が低くなります。 複雑な計画を作成していて、複雑な関係があることを理解している場合、目標のリストを分解および修正できます。



多くの場合、私たちは楽観主義のtrapに陥ります。「さて、前進しましょう。 「私たちはいくつかのことを完全には理解していませんが、私たちは間違いなくこれに対処します、私たちはそれをします。」 このアプローチ-目標を確認し、障害を確認しない-は非常に重要です。 しかし、あなたが過度に楽観的な人であれば、計画にいくつかのグレーゾーンがあり、それについて「地獄はこれを行う方法を知っています」と言います。 そして、パフォーマンス、品質、サポートなど、正確に何が議論されるかは関係ありません。 それから、この灰色のゾーンは、大きな何かを起動するための障害です。 したがって、計画では、これらの灰色の領域が存在しないことが非常に重要です。または、灰色の領域を完全に担当し、作業のこの部分が時間通りに完了することを保証する人が必要です。

マネージャーの相互作用

リーダーが来てあなたにいくつかのタスクを設定したとき-これは責任のシフトです。 そして、この状況で彼が望むのは、誤解がないようにこの切り替えをできる限り明確にすることです。受け入れられません。 そのような状況では、責任はしばしば互いにシフトされます-これは明確ではありません、これは明確ではありません。 , . . — «» . - , , : «, ».



. , . : « . , - ». , - , , . , . , — . : «, - ».



. , , : «, ». , , . : - , — . , , , - , , -. , .



, , , , . -, « ». . — . - . . . , , , , . .



, . - , , , — , - . , , -, , . , .



それをどうしますか？ , - , . , .



— . : «, . , ». , , — - , . : , . , , . , , .



, .

• — , , , , . . : , , , . «, - -. -. - . — ». , . , , , , .
• , - . , . , — - , , .

, «»: - , . . : « , ». , , devops .. , , , release engineering .. . , « », — , . , , . .



: « , , . ». , . , , . , , , . , , . , . , - .

. , , , . — . - , , ! , , , , — . - , , ó -, - - . , - , , .

, . , MySQL. , , , , ? , . , .



, - , : «, , ! - . - , ORM SQL, ORM- data storage». , «, ? , ». : « Python , — , , - . , , ». , , ORM — , .



, . , , — . .



. , . , . , , . , , — . , . . .



— . , - — . , .



— . , : « , ». , , . , , — .



, , . , localhost' — .



, , — , , , . , , .



, , : , . , .

, , . — , — - . - , - , - , - , - . , : — . . : , , , .



. , . , . , . . , , . , . , .



: . , . , , , - . , , , . - , , . server side — , . , .



- , . : « , , ». ? , - , , . , , .



, « ». , . : , , . backlog. , , . , , , .

, , . , . — . , , , , . , . , ( 1 , 2 , 3 , 4 ). :

• « ». — . SQL, - .
• « ». — . C, . computer science, . .
• « -». . , , , , .
• « ». — . , , , . , .
• « ». IT, , . , , , , , . , , , , , QA.

, , .