（ジュニア）開発者は、開発/ ITチームでより良いプロセスと実践を推進する必要がありますか？
私はジュニアデベロッパーで、変更を正当化でき、チームが仕事をやり遂げるのを助けることができれば、チームのプロセスを形作る能力を与えられます。私の過去の会社は多かれ少なかれ管理から生まれたプロセスを厳密に定義していたので、これは私にとって新しいものです。
私のチームはかなり小さく、やや新しい（3歳未満）。彼らは不足しています：
- 明確に定義されたソフトウェア開発/作業管理フレームワーク（スクラムなど）
- 強い製品所有
- 明確に定義された役割（例：ビジネススタッフが手動テストを行う）
- 定例会
- 統合された問題追跡プロセス（ツールはありますが、プロセスはまだ開発中です）
- ユニット、システム、回帰、または手動のテストスイートまたはリスト
- ビジネスロジックとプロセスに関するドキュメント
- 内部および顧客向けのヒントを文書化するためのナレッジベース
そしてリストは続く。管理は、価値が正当化され、最も重要な作業（つまり、開発）の完了を支援する限り、改善の実装に対してオープンです。しかし、根本的な前提は、誰もあなたのためにそれをするつもりはないので、実装の所有権を取る必要があるということです。そして言うまでもなく、上記のプロジェクトのいくつかは自明ではなく、間違いなく時間がかかり、明らかに開発作業ではありません。
時間が経つにつれ、（ジュニアの）開発者が努力して上記をプッシュする価値はありますか？それとも、「自分のレーンに留まり」、開発に集中し、プロセス定義の大部分を残して、最適化を管理に任せるのが最善でしょうか。
これまでのところ良い答えですが、すべての根拠を網羅しているわけではありません。
私の経験では、大学を卒業したばかりの多くの人は素晴らしい理論的な知識を持っています。私や、何十年にもわたって生活のためのソフトウェアを構築している他の多くの先輩よりもはるかに優れています。
しかし、それは重要ですが、その知識は実際のシナリオに基づいていません。現実の世界では、その理論の多くは横ばいか、少なくとも現実には現実の世界のシナリオではうまく機能しないことが判明しているため、大量の塩分を考慮する必要があります。
適例：私がずっと以前に取り組んだアプリケーションは、優れたOO理論家によって設計され、TにOOの原理と理論に従うように設計されました。どこにでもたくさんのパターンが適用されています。
それは素晴らしいソフトウェア設計でした。
悲しいことに、これは生産と保守の悪夢をもたらしました。コードベースは非常に大きく複雑なので、場所を変更することは不可能でした。それが特にもろくなかったからではなく、非常に複雑だったので、何が起こるかを恐れて誰もそれに触れませんでした（元の建築家/設計者は、長い間残っていた請負業者でした）。
また、パターンの多層構造と、設計に必要なクラスライブラリのため、パフォーマンスも非常に悪かった。たとえば、画面上のボタンをクリックしてデータベースを1回呼び出すと、数百のオブジェクトのインスタンス化とメソッドの呼び出しが発生します。これらはすべて、疎結合を保証するという目的で行われます。
この建築家は大学教授であり、彼の名前に関するトピックについて数冊の本を持っていました。彼は商業プロジェクトのプログラマーとして一日働いたことはありませんでした。
ソフトウェアの構築に実際的な経験を積んだ人なら、そのデザインが必然的に何をもたらすかを理解し、より実用的なアプローチをとることで、システムの維持と実行が容易になり、パフォーマンスも向上するでしょう。
同じことが、新卒者として、または実際に会社の新入社員として遭遇する他の多くの事柄にも当てはまります。あなたの理論的根拠が何かが間違っている、または次善であると言っているので、それがそのように行われる非常に正当な理由がないと仮定しないでください。
20年以上の経験がある今でも、私は一緒に仕事をしている会社で物事が行われている方法を批判することに警戒しています。ちなみに、私の経験は最適ではないが、好戦的な方法ではないことに気づいたことに言及します。これはしばしば、なぜそれらが現状のままであるかについての興味深い会話につながります。変化の価値がコストよりも小さいかどうかに応じて、変化が起こることもあれば、起こらないこともあります。
物事がより良く行われるかもしれないと恐れずに言ってください。しかし、あなたが知識のあるすべての鼻づかいな子供としてではなく、単に学ぶだけでなく、理論的な正確性だけでなく、会社の改善プロセスを改善するのに役立ちます。
はいしかし、十分に注意してください！
それを明確にさせてください
ソフトウェアの居住性の向上に努めるべきです。コード/チーム/ビジネス/プロジェクト/管理を見て、最初の応答がシャワーを浴びることである場合、それは居住可能ではありません。あなたの最初の対応がええと叫ぶことです！...そして、あなたがオフィスの外に押し出されたときに文句を言うなら、あなたはあなたの家をより居住可能にする必要があります。その感じ、そしてあなたはそれを知るでしょう。
そうは言っても、あなたは複雑な symathesis で作業しています。単純な変更には波紋があるため、実行することはすべて失敗する可能性が高く、少なくとも短期的には事態を悪化させる可能性があります。だから最初は謙虚になる、私はプッシュオーバーになることや物事が悪いに違いないことを受け入れることを意味するのではなく、私はあなたの善意が悪意を持ってあなたをオンにするという事実と折り合いをつけることを意味します。
問題
意図的に最善を尽くすと、広範囲に及ぶ変化が起こる必要があると感じるかもしれません。これらの状況が存在することに異論はありませんが、少し考えてみてください。現在のシステムは機能していて、あなたとあなたのチームはコードを生成しています。おそらく遅く、おそらく痛みを伴いますが、システムは機能しており、すべての人がこれを行う方法についての経験を持っています。あなたは大まかに何を期待するべきかを知っています、要するにあなたはこのシステムの専門家です。
抜本的な変更の後、おそらく実装者を除いて、誰が何を期待するかを知りません。つまり、システムのこの部分では、誰もが初心者レベルにリセットされています。それは良いことではありません。初心者は時間がかかる新しいルールを学ぶ必要があります。当時、新生物は実践されていないため、間違いを犯しています。それらの過ちはシステムの一部になり、あなたは今それと一緒に暮らさなければなりません。
A Way Forward
スラッシュ、バーン、リビルドが最善の方法である場合があります。失われている唯一のものは成文化された知識だからです。この知識が完全に理解できない場合、その知識はすでに失われており、最初からやり直すことが唯一の選択肢です。逆に、コード化の方法またはその使用方法が問題であるが機能している場合、その知識はまだアクセス可能であり、おそらくその価値はありますが、そうではありません-決定を軽くしないでください。
もう1つの選択肢は、システムを操作して全員が参照できるようにすることですが、システムの小さな部分を変更して、チームの全員が認識できるようにするか、変更に気付いていない場合は、どちらも簡単に行うことができます。気づきやすく、習得も簡単です。これが カイゼン と呼ばれるプラクティスの基礎です。プレゼンテーション「Shaving the Golden Yak」では、より開発者向けの公式が提示されています。これを見て、じっくりと考えることを強くお勧めします。
だから、あなたの人生を改善することができる変更可能な小さなもの、そしてうまくいけばいくつかの他のもののものを見つけてください。状況を修正または改善します。これにより、変更を実践するための練習と経験が得られます。あなたがフィードバックを得ることを確認してください：あなたはそれをよりよく議論できましたか、それは実際に有用でしたか、それはシステムの別の部分を混乱させましたか？何ができるか、どのように行うかについての感覚を養います。
これで3つのことが起こりました。
- あなたはシステムを改善しました、
- あなたはシステムを変更する方法の経験を得ました
- チームがシステムの変更に成功したことを確認しました。
ここで、改善する別の項目を選択します。経験が大きくなり、ぶら下がりの問題がなくなると、システムのより難しい問題に直面し始めますが、少なくともXを変更する必要があると言ったときは、次のようになります。
- 変更がシステムに与える影響を知っている
- どのような問題が発生するかを知っている（どのルールに再学習が必要か）
- 変更によってもたらされる問題を直接修正または改善する方法を知っている
- あなたの周りの人々はあなたがシステムに精通していて、それをうまく変えることができることを知っています
はいできます。だが...
あなたは注意する必要があります。
私のキャリアの初め（非常に昔）に、私は「ジュニア」として数ヶ月前のプロジェクトに参加できたのは幸運/不運でした。
最初に気付いたのは、（OMG）コードリポジトリがないことです。コードのすべてのマージは、郵便でZipファイルを相互に送信することによって手動で行われました。
そこで、私も（同じく新しい）マネージャーのところに行き、リポジトリを用意するように提案しました。答えは：わかりました、整理してください。
そのため、コードリポジトリを整理することは、助けがなくても社内で新しくなりました。
私がそれをすべて設定したとき、（ショック）誰もそれを使いたくありませんでした。それで私は物事をプッシュしようとしました、そして幸運にも私のマネージャーはそれが重要であることを理解したので私はサポートをしました。
しかし、その結果、私はあまり好まれず、残念ながらソース管理システムに由来するニックネームが付けられました。
ですから、私の考えは、最初にチームメンバーを感じ、次に設定することが重要だと彼らが考えていることです。
多分彼らもあなたのようなリストがあります。多分彼らはすべてを通り抜けて、彼らはリストでその「こと」をしたかったのです。多分彼らは....（何でも）...
チーム全体が連携する必要があります。
しかし、そうでない場合でも、プロとして働くことができます。そして、志を同じくする人々を見つけ、それがどうあるべきかについてあなたがどう考えているか一緒に働きなさい。これが良い結果をもたらすなら、より多くの人々があなたと働くでしょう、結局それは「the」プロセスになります。
コードと同じように、開発プロセスについても同じです。継続的な改善が必要です。
だからはい、あなたは常に改善しようとするべきです、それは改善することが可能です。
しかし、あなたが一緒に働いている、すでに専門家である可能性がある多くの人々を覚えておいてください、そして彼らは何が間違っているのか、何が必要なのかを知っています。
時間が経つにつれ、（ジュニアの）開発者が努力して上記のことをプッシュする価値はありますか？
はい、何かをより良くするために努力する価値は常にあります。結局、あなたはあなたが直面している問題を最もよく知っています。
しかし、あなたが言及するように、解決するべき多くの問題があり、それらの問題の多くはひどく価値がありません。そして、多くの場所で、あなたの成功や、彼らを擁護するのにはるかに優れた立場にある他の人々への克服できない障壁があります。したがって、それがwhichを選択することを意味する場合でも、常により良いものにしようとする必要があります。
結局のところ、あなたがソリューションの一部ではない場合、あなたは問題の一部です。
はい。しかし、高齢者にとっても組織の変更は難しいため、本当に変化を起こしたいのであれば、正しい方法でそれを行ってください。
最初の週ではありません：この時間を使用して、次のことを行います。
- 良い第一印象を作る。チームに合っていることを示します。
- 文化と政治またはあなたの会社を理解する。変更をプッシュしても安全ですか？
- 同僚と良い関係を築く
- チームのプロセス、ルール、ニーズについて学ぶ
- 自分の仕事を学び、最善を尽くしてください。きっと忙しいでしょう。
あなたの戦いを選択してください。初期の勝利を得る：あなたはすべてを変えるためにエネルギーと共に到着するかもしれませんが、これは非現実的です。ぶら下がっている果物に焦点を当て、アイデアが機能することを示します。あなたは彼らにもっと複雑な改善を受け入れてもらいたいのです。そして、物事は本でより簡単であることを覚えておいてください。
他の人への影響を考慮する：多くのファイルに影響を与えるリファクタリングを行います。彼らがコードを改善したとしても、私はマージをロバの苦痛に変えないように非常に注意しなければなりません。彼らがそのように働き続ける理由を理解することも試みてください。テストが欠けていて、テストされていないコードを頻繁に本番環境にプッシュすることを恐れているため、スクラムを使用できない可能性があります。実現可能なテストを書くのは簡単なことではありません。現在のコードはテストが本当に難しいかもしれません。さらに、チームはテストやテスト可能なコードを作成するために使用することはできません。現在のコードベースはテストが特に難しく、リファクタリングする必要があります。この問題を変更するには何年もかかる場合がありますが、少なくとも根本原因に焦点を当てることはできます。
- 判断してはいけません。要求しないでください。それを求めて注意深く聞いてください：これはコミュニケーションが重要な瞬間であり、プログラマーである私たちは通常、微妙なニュアンスがあまり得意ではありません。 役立つテクニックがあります 。答えに集中するのではなく、私たちのアイデアを押し続けるのは簡単です。まず、あなたが彼らのポイントを得ていると彼らが感じていることを確認してください。感情が重要であることを理解してください。この変化は彼らに何を感じさせますか？恐れ？不十分？怒り？欲求不満？望む？怠惰？愚か？ （決して人々を愚かにさせないでください）。もちろん、あなたは以前に多くの質問をしたでしょう、そしてこれは多くの誤ったステップを防ぎます。
例によって主導：文句を言うのは簡単です、変更を作成するのは難しいです。結果を表示すると、人々はあなたを信じます。テストを使用しない場合は、単体テストを作成できます。文書化しない場合は、Googleドキュメントをチームと共有できます。 「OK、Do it it」は可能な限り最高のシナリオの1つであり、それを実現する必要があることを理解してください。この場合必要なリソースを考えておく必要があります。例：小さなAmazonインスタンスと2時間の管理者からのJenkinsサーバーの提供
小さくシンプルな（そして安い）キープ：正式な予算承認を待ちたくない、または高価なプログラマから貴重な時間を奪われていると上司に思われたくない。このコードレビューソフトウェアまたはいくつかのオープンソースツールを評価するのは素晴らしいことですが、今のところはリポジトリを使用します。
クリティカルマスを取得：品質の向上に焦点を合わせた人々のグループを集めます。彼らと一緒に会議に行って、助けやメンタリングを求めることもできます。 Peopleware チームのベースが文字どおり生産性を低下させる愚かな慣習に反抗して、「巨大な現象を起こす」ことを説明します。これは個人的には非常に危険であり、私はお勧めしませんでした。しかし、すべてのグループが同意すると、変更はより簡単になります。
しばらくしてください。その後、両足で投票してください]数か月から最大2年間試してみることをお勧めします。しかし、簡単な解決策がない企業もあります。一部のチームは、変更を望まず、インセンティブを持ちません。そして、いくつかのコードベースは純粋な恐怖です。世界に反対していると感じた場合は、ジョブプールに多くのオファーがあることを思い出してください。あなたは良い習慣を学びたいと思います、そして長期的にはあなたは少しだけ賃金を下げてあなたをより価値のあるものにする経験を得ることでより良いでしょう。
ボーナス：成功した場合は、CV /インタビューのためにそれを書き留めてください。ジュニアとしては、通常、言うことはほとんどありません。あなたはあなたが個人的にやったことや他人からの仕事であったことについて非常に明確で現実的な見方をしたいと考えています。次のインタビューの質問を想像してみてください。
- あなたがチームに影響を与えた時期について教えてください。
- ええと、私は彼らが非常に昔ながらの慣習を持っていた場所にいました。多くの人々はそれに満足しておらず、生産性には改善の余地がありました。それで、私は遡及的なもので迅速な実験をすることを提案しました、我々はXとYをしました、そしてその結果として我々はこの素晴らしい測定可能な結果を得ました。
はい。しかし、あなたが提案するものではありません。
あなたのリストからユニット/統合テストはあなたが進歩を遂げることができる唯一のアイテムです。
最小限の時間投資で自分でこれらを追加し始め、すぐに価値を示すことができます。これは、広く受け入れられている利点を持つ技術的な問題であり、他の作業方法には影響しません。結果が受け入れられない場合でも、コードベースの知識を学ぶこともできます。簡単な販売。
その他は一般に、チーム全体または他のチームが関与するビジネスプロセスです。改善を提案することもできますが、後輩が変更するのは困難であり、変更のプロセスは一般に技術的ではなく、おそらく通常の作業とは無関係です。
また、CIパイプラインの設定、自動デプロイメント、バージョン管理、ライブラリのパッケージ化などを攻撃に適したものとして提案する
による：
- あなたはより良い実践から得ることを期待します
- そこに行くために費やさなければならないどのくらいの努力
- 成功とリスクの可能性-単純な採用の失敗から新しい慣行までは実際にひどい、コードの品質が低下し、主要な人々が去る、誰もがあなたを嫌い、誰もあなたの名前を知らない別の都市で別の仕事を見つけなければならない
基本的に、あなたが最善だと思うことを提唱するために妥当な時間を費やすことは、あなたの責任の範囲内ですが、決定はチームまたは管理責任である必要があります。あなたがより良い実践に終わったとしても、人々を疎外することはめったに価値がないことを覚えておいてください。
スクラムのような最も複雑なものから始めないでください。可能な最も簡単な手順から始めます。
あなたはソースコード管理について言及していません。ソースコードリポジトリ（git、svn、cvsなど）はありますか？タグ付けと分岐の戦略は？これらは初心者ができる簡単なステップです。これらのステップが解決しようとする（試行する）問題と、それが会社のコスト削減にどのように役立つか（経営陣が関心を持っていること）を読んでください。
次のステップは、毎晩またはすべてのチェックインの直後に自動化されたビルドです。ジェンキンスと。テストを自動的に実行することもできます。そして、コード品質を測定するためのいくつかのツールを追加します（そうです：コーディング標準を定義することも良いステップです）。
スクラムについては、「Extreme Programming」（XP）をよく読んでください。スクラムはXPの多くのアイデアに基づいており、それらの周りに形式化されたプロセスを追加します-XPの概念は、そのプロセスがなくても使用できます。
物事を提案し、背景情報を提供し、他の人にそれを試してもらい、結果を分析するように説得しようとします...しかし、他の人からの多くの協力を期待しないでください：ほとんどの人は古い悪い習慣を続けることを好みます。しかし、それを試さなければ、何も改善されません。
チームは非常に新しい（3歳）とのことですが、良い原則をすぐに紹介できないと、10年後には難しくなります。テストやバージョン管理システムなど、あなたが言及したことのいくつかは、すでに提案できるものの1つですが、その明白な利点を強調せず、開発スタックに必要なツールを選択することなく、そのような提案を投げないでください。
初めに、質問します
あなたのリストを読んで、私は以下の質問を提案します（それらがどのように適合するかを確認するためにあなたのリストをもう一度参照してください）：
- ビジネスオーナーが要求している作業を確認するにはどうすればよいですか？
- [スクラム]を試しましたか？
- これの製品所有者は誰ですか？
- どのような役割がありますか？
- [この役割]は何をしますか？
- [このアクティビティ]にはどのような役割がありますか？
- 毎日のスタンドアップを試しましたか？
- 障害をチームの他のメンバーに伝えるにはどうすればよいですか？
- チームの他のメンバーが働いていることを知るにはどうすればよいですか？
- [これ]を問題追跡ツールに入れますか？
- 問題追跡ツールで[this]をどのように記述する必要がありますか？
- [これ]が発生した場合、問題追跡ツールに[それ]として配置する必要がありますか？
- どのようにテストしますか？
- 他の人が再利用できるようにテストをどのように記録しますか？
- [JUnit]を試しましたか？
- [これ]はどこに文書化されていますか？
- [MediaWiki]を試しましたか？
質問が意味をなすように、または優先順位に合うように、[括弧]内のものを適宜置き換えます。私の言い回しがあなたのスタイルと一致しない場合は、言い直しを検討してください。
あなたはすでにそれを始めているかもしれません。グループの会話よりも1対1の会話を優先します。 1対1なので、他の人の考えをよく理解できます。この変更の人ですか？それに対して？弱い？狂ってる？
あなたが新しいとき、質問することは実質的に無料です。人々はあなたが質問することを期待するべきです。あなたの質問が彼らの反対する立場を暗黙のうちに支持しているとしても、彼らは怒るべきではありません。彼らはなぜその立場に反対するのか説明しなければならない。彼らと議論することはお勧めしません。議論は、それが納得する以上にポジションを固める傾向があります。誰がどのポジションにいて、次に進むのか注意してください。
後で、手順を実行します
あなたとおそらく他の人（つまり、あなたが以前あなたに同意したことに気付いた人）が希望する変更を開始できる方法を探します。誰もがスタンドアップを望んでいるわけではありませんか？何故なの？たぶん、あなたが欲しい人はあなた自身のスタンドアップを持つことができます。チーム全体ほど効果的ではありませんが、今よりも効果的です。
障害がある場合（スタンドアップでは共有できない場合）、チームにメールでサポートを依頼します。
おそらくあなたに同意する他の人の支援を得て、役割がどうあるべきかを特定します。仕事が、あなた（おそらくあなたがグループ）が彼らが持つべきだと考える役割を伴うとき、人々に一貫して行き始めます。プッシュバックする場合は、その役割を誰が所有すべきかを特定するように依頼します。
製品の所有者（特定した）に、製品が現在および将来どのように機能するかについての説明を書くよう依頼します。
テストフレームワークをインストールし（他のフレームワークがこれを支持する場合は、どのフレームワークで共同の決定を行うか）、それをプロジェクトに使用します。バグを修正するときは、テストを作成します。これを課題追跡のバグレポートに文書化します（バグを示すテストを記述し、[場所]に保存します）。他のユーザーが変更を加えたときにテストを実行するように勧めます。そうでない場合は、自分でテストを実行し、必要に応じてトラッカーに問題を送信します。
管理サポートを受けることができる場合は、wikiソフトウェアなどをインストールして、文書化を開始してください。ドキュメントを読んでいないことを示す質問をした場合は、関連するページを参照してください。ドキュメントが理解できない場合は、さらに質問するように促します。ドキュメントでカバーされている質問を続けて行う場合は、回答するときにドキュメントから引用してください。彼らが読んでいないのではなく、問題が構造的であると思う場合は、wikiを更新するように彼らに勧めることを検討してください。
一度に1つのタスクのみに集中することをお勧めします。そして、確かに一度に1つだけプッシュします。強くプッシュしないでください。 この例 グループが望むよりも強く押すことを参照してください。彼らの振る舞いよりもあなたの振る舞いを変えることにもっと集中してください。もしあなたのやり方が正しいなら、それはあなたを観察している人々にとって明白なはずです。アクションは言葉よりも雄弁です。ナッジをするとき、同じ人と同じことを繰り返さないようにしてください。馬を水に導いたら、いつ飲むのか、または飲むのかをもう一方に任せます。
最終的には、あなたは年長になります
時間が経つにつれて、チームは新しい人を雇います。あなたは新入社員であるのをやめ、新しい人々とあなたの立場を主張することができます。彼らと協力して変更を加えます。そして、あなたはあなたがあなたの既存のチームメイトと同様に進歩していることに気付くかもしれません。または、それがうまくいかない場合は、彼らがより良い実践をしている新しい仕事を探してください。本当の急ぎはありません。あなたは仕事がある。あなたはその仕事を改善するか、より良い仕事を見つけることによって、より良い仕事をするのにしばらく待つことができます。
短い回答：いいえ、他の回答で説明されているすべての理由によります。ミドルまたはシニアの開発者であっても、新しいチームに参加するときは通常最初に理解を求めるの方が良いです。
提案されたソリューション：
1）改善すべきと思われるものを見つけたら、それをメモしてください！ （ノート、デジタルノート...）
2）6か月後、メモに戻って確認します。現在、いくつのアイデアが無意味で不十分だと感じていますか？ほとんどの場合、あなたは自分自身にいくつかの恥ずかしさを保存しました。まだいくつかのアイデアが残っている場合は、可能であれば、最初に自分でテストして、それらを紹介する良い機会です。
遅い答え、そして他の答えの多くの良い内容に同意する。
ここでの重要な問題は特定のプラクティスではなく、チーム全体の文化であることを指摘する必要があると思います。
- 文化的な変化を生み出すことはhardです。
- もっと「ジュニア」と見れば
継続的な改善を達成する手段があれば、他のすべてが従うことができます。
それを達成するための私のアプローチは：
- 文書化されたプロセスと手順
- アクションがプロセスドキュメントの変更であるチームの回顧。
スプリントがない場合は、通常のレトロはまだありません。必要なのは、チームとの会話であり、それを実行するだけです。
あなたは簡単に文書化プロセスを開始できます。 「私は新しい人です、これは正しいですか？それを書き留めましょう。」次に、実際にプロセスを実際に実行するか、それがどこで壊れているかを確認して呼び出すことが重要です。
たぶん、あなたはそのような会話がアドホックで始まり、次に定期的な儀式を提案します。
このアプローチを採用することで、段階的でソフトにソフトなアプローチが可能になります。あなたは、彼らがそれをすべて知っていることのジュニアとして現れるのを避け、代わりにチームが変化を起こすためのファシリテーターになろうとすることができます。
いくつかの考慮事項：
- 一部のチームはプロセスが貧弱ですが、実際にはすでにそれを知っています。彼らは変化を望んでおり、それを触媒する何かが必要です。他のチームは本当に自分のやり方で立ち往生しており、変更がはるかに困難です。
- 同じことが個人にも言える。
- あなたはそれに敏感で、チームの誰が変化にオープンで誰がオープンでないかを理解する必要があります。理由を理解してください。
- 簡単な勝利を見つけてください。
- 変更をチームに歓迎します。個々の問題点を見つけて、それらの修正を支援してください。