2017-11-17 02:28:49 +0000 2017-11-17 02:28:49 +0000
72
72

無能なソフトウェアプロジェクトのボランティアに丁重に告げる

私は現在、オンラインボランティアで運営されているソフトウェアプロジェクトのプロジェクトリーダーをしています。元々は私が作ったもので、空いた時間を利用して活動しています。他にも何人かの人がこのプロジェクトに興味を持ち、ボランティアで手伝ってくれています。私はこれまで他の開発者と一緒に仕事をしたことはありません。現在、もう一人の開発者がボランティアでプログラミングを手伝っています。

開発者になる前は、彼らがこのプロジェクトに興味を持ってくれたので、オンラインで知り合いました。彼らはソフトウェアエンジニアリングの経験はあまりありませんでしたが、プロジェクトで使われているプログラミング言語はある程度知っていました。この時、私は開発をスピードアップするために別のプログラマーを探しており、彼らにプロジェクトのコーディングを手伝ってくれると伝えました。私は彼らの経験不足にもかかわらず、私の指導で彼らをスピードアップさせることができるだろうと期待していましたが、私は間違っていました。現在のところ、彼らのスキルはプロジェクトに取り組むには十分ではなく、ほとんどすべてのタスクを完了させるためには私の助けが必要です。振り返ってみると、新しい開発者を育成するのに必要な時間を計算違いにしてしまった私のせいかもしれません。しかし、純粋にビジネスの観点から見ると、私が彼らを指導することに費やす時間は、プロジェクト自体に費やす時間に見合うものではありません。しかし、現状では、仕事をした後の楽しみのためにやっているので、毎晩帰宅して誰かに教える気力がないのが現状です。また、私は次の3ヶ月までにこのプロジェクトを放棄したり、終了したりする予定なので、いずれにせよすぐに放棄するものに投資をするのは無意味です。しかし、これは次の3つの理由から厄介です:

  1. 彼らはこのプロジェクトのボランティアです。実際には、彼らは熱心に手伝っている様子を見せてくれていたし、開発者になってよかったと思っているような気がします。彼らはこのプロジェクトのために息抜きや自由な時間を犠牲にしているのだから、有給の労働者を解雇するのと同じではありません。単純に「解雇」するのは非常に失礼なことだと思います。彼らはすでに開発者になって2ヶ月ほど経ちます。もし私が未熟さを理由に彼らを却下するとしたら、私は(普通は)すぐにそうしていたでしょう。先ほども言いましたが、彼らの未熟さがこれほどまでにプロジェクトに支障をきたすとは思いませんでした。この方とは以前からネット上で知り合いで、友人でもあり、このプロジェクトの熱心なサポーターでもあります。架け橋になりたくないので、アドバイスをお願いします。私は現在、この他の開発者がいなくても自分で仕事をしたいと思っています。

注意: 彼らはボランティアであり、私は開発者とはむしろ非公式であるため、これはThe Workplaceには当てはまらないと思います - 実際、私は彼らと友人であることを述べました。

同様に、私はスキルのために誰かを解雇することについて この質問 を見ましたが、それは専門的な環境のためです。私は気まずい理由#1で述べたように、彼らはボランティアであり、このプロジェクトのために彼らの貴重な自由な時間を犠牲にするために、何らかの敬意に値する。

回答 (6)

106
106
106
2017-11-17 07:19:54 +0000

あなたはその問題を完全に傍観することができます。

単に、彼らが現実的に手伝うことができるプロジェクトの一部はもう終わっていると言ってください。これは重要な利点があります:

  • あなたはどんな橋を燃やしていません。
  • それは、プロジェクトに関連するスキルを得るための努力でより多くのことを学ぶためにジュニア開発者を促すかもしれません。

この戦略を使うことで、あなたは彼らを「クビにする」という問題を完全に回避しています。

あるいは、開発者が必要としないタスクや、二次的なタスクに再割り当てすることもできます。通常、これには次のようなものが含まれます:

  • ドキュメントの作成
  • コードレビュー
  • 大規模な Q/A テスト

彼らが下手に行われている場合は何のコストもかかりませんが、彼らが熱心にそれらを完了するときに多くの助けになるタスクのために見張りをしてください。

20
20
20
2017-11-17 10:15:52 +0000

私はあなたがプロジェクトから完全にそれらを解雇する必要があるとは思いませんが、あなたはまた、彼らが他の人(あなたを含む)をブロックしない位置にそれらを移動することができます。あなたは次のようなことを言うことができます:

ねえボブ、現在私の人生で起こっている多くのことがあり、私は単に私たちのトレーニングセッションのための時間を見つけることができません[または何でもあなたがそれらを呼び出す]もはや、それについて申し訳ありません。

その後、非緊急の優先順位を持つ1つまたは2つの単純なタスクを割り当てることによって、それらを “方法のうち "移動します。彼らは自分で学習し、タスクを完了することができる場合:偉大な、彼らにもっと挑戦的な何かを与え、あなたが彼らの能力のレベルを発見するまで繰り返します。そうでない場合は、そのタスクの優先順位が上がったとき(すぐに必要とされるとき)に戻ってきてください。もしあなたがそれについて外交的になりたいのであれば、次のように言うことができます:

ねえボブ、私たちはすぐにドキュメント/翻訳/テストを実行/foobarを必要としています。あなたはそれの世話をすることができますか?

それはあなたが自分自身を納得させることができれば本当に役立ちます ドキュメンテーションとテストは重要なタスクです - なぜなら、彼らはareだからです。多くの開発者はドキュメントを書きたがらないので、小さなオープンソース・ソフトウェア・プロジェクトの運命を封印してしまいます: 彼らのソフトウェアは問題を解決しているのですが、ほとんどの人は使い方がわからず、誰も使ってくれません。ソフトウェア開発を整理することは非常に貴重なスキルセットなので、この機会に自分自身を学び成長させるために使ってみてはいかがでしょうか。作業をタスクとサブタスクに分解し、依存関係を把握し、必要な時間を見積もり、重要なものと後回しにできるものに優先順位をつけ、誰が何をできるかを判断することを学びましょう。仲間の開発者とのコミュニケーションの取り方を学び、期待通りにいかなかった場合の再計画の立て方を学びます。コラボレーションツール(課題追跡、バージョン管理システムなど)を使う。

今、ビジネスの世界で流行っている方法論(スクラム、カンバンなど)を使えば、役に立つガイドラインが得られるかもしれない。

7
7
7
2017-11-17 16:37:39 +0000

最初に、私は、これまでの彼の時間/努力のためにボランティアに感謝し、あなたが彼を必要としていた主要な開発の一部が終了したと言うことについての部分に同意します。

私はあなたのために、あなたがもう1つのメンタリングセッションに投資することをお勧めしてもよいです。トピック。ユニットテストを書く方法を彼の悪い自己を示す。そして、彼がより多くの技術支援をしたい場合は(他の種類とは対照的に)、彼はDeepLの安定した拡張を開始する必要があることを彼に教えてください。利点:

  • あなたはユニットテストを得る!

  • ボランティアはユニットテストの重要な性質に導入されます!

  • ボランティアが遅くなったり、立ち往生したりした場合、それはメインラインの開発に干渉しません

その後、他の回答のように、あなたはあなたのスケジュールの任意のたるみを失ったように、より多くのトレーニングをオフに懇願することができます。

3
3
3
2017-11-17 06:29:58 +0000

彼らはボランティアなので、「解雇」する必要はないと思います。その代わりに、彼らが必要としているボランティア活動は今のところ終了しています、と言った方が適切かもしれません。また、彼らがすでに行った仕事に対して親切にお礼を言い、その成功と彼らの個人的な成長についてコメントし、新しい仕事を与えないようにしましょう。仝それにしても、このようなことがあったのですか?

仝それにしても、このようなことがあったのですか? もしあなたがもう少しぶっきらぼうな態度をとるか、嘘をつくかを選択しなければならないならば、ぶっきらぼうな態度をとることは、長い目で見れば、おそらく役に立つでしょう(悪い方に焦点を当てるべきだと言うわけではありません!)

あなたは私たちを助けてくれて、多くのことを改善してくれましたが、私は{others}と私が残りのタスクを完了させた方が良いと思います。

今後、あなたのスキルに適したものが出てきたら、必ずあなたの方に送ります。

2
2
2
2017-11-18 02:31:41 +0000

この状況についての私の見解は…少し皮肉なものです。外では、新しい開発者に対して、将来の雇用主に向けて GitHub の信頼性を高めるための方法として、プルリクエストに名前を載せるようにとのアドバイスが常になされています。他のサイトを見てみると、経験を積むための方法としてオープンソースプロジェクトに参加するようにとのアドバイスが常にあります。そのような経験は、プロジェクトでより年配の開発者を指導するための時間を犠牲にしています。これは、あなたが運営するボランティアプロジェクトの費用で、無料のメンタリングとレジュメ作成を受けているジュニアの開発者です。(私の意見では)ボランティアプロジェクトのメンタリングのコストは、人がプロジェクトにコミットされ、GitHubの信頼を超えてそれに本物の関心を持っていない限り、めったに時間の価値があります。

考慮すべき2つのパスがあります。あなたはすべてのコミットを管理し、提出された素材がプロジェクトのためにあなたの基準に沿ったものであることを確認し続けます。これにおけるあなたの主な役割は、あなたのプロジェクトとジュニア開発者のプロジェクトへのコミットの両方があなたが期待しているものであることを確認するためのメンターのことです。

ジュニア開発者を指導しないでください。あなたのプロジェクトでの作業のためのボランティアであなたの時間は、彼の時間よりも、そうでない場合は、同じように貴重です。その完了 “と言って、別のプロジェクトに移動するための準備のために店を閉鎖する多くの可能性があります。多くの場合、これらは退屈で退屈なタスクですが、彼らはまだ行われる必要があります。このようなもの:

  • ドキュメンテーション - 別の人に書かれたテキストをすべて読んでもらい、正しいスペル、句読点、文法、書式などがあることを確認してください。スタイルクリーンアップの項目をすべてファイルごとのissueとしてログに記録してください。

自分でやるのに4時間かかるタスクがある場合、自分の時間の3時間とジュニア開発者の時間の8時間、ジュニア開発者が経験を積むことの価値を考慮に入れていない限り、ジュニア開発者がそれをすることにはあまりビジネス/時間の意味がないことを認識し、覚えておいてください。あなたも後輩もボランティアです。ボランティアがやることがなければ、それはそれでいいのです。

0
0
0
2017-11-19 03:55:09 +0000

それはプロジェクトの仕事をするためにあなた自身の能力を妨げるようになっています。あなたは、プロジェクトの作業をやめようとしています。その理由を伝えましょう。(例えば。(例えば、より良いサポートや資金を提供してくれる新しいプロジェクトに取って代わられるかもしれない、あるいは、やるべき仕事があまり残っていない、など) - このプロジェクトに費やしたすべての努力に感謝し、その経験が彼らの能力開発に役立っていることを願っていることを伝えてください。

  • 開発作業を続けることができる別のプロジェクトを見つける手助けをすることを申し出てください。もし可能であれば、意図的にもっと手を離すようなアプローチをとって、doneが終わったときに(例えば、プルリクエストとして)彼らの仕事を見直すことを検討してもいいかもしれません。これが実行可能かどうかはあなた次第です。もしあなたが彼らが実装するための小さな変更点を見つけられたら、これを検討するかもしれません。もしそれを試してみてうまくいかなかったら、彼らの仕事のどこに問題があるのかを具体的に示すことができるでしょう。不誠実だからではなく、自分の感情や考えが完全に客観的ではないことを知っているからです。私たちの判断は、時々私たちの満たされていない欲望によって曇っているので、時々私たちは本当に有効ではないことを知っている思考や感情について私たちの口を閉じておきます。

はい、あなたが彼らの感情を傷つけるかもしれないといういくつかの固有のリスクがあります。ここでのアプローチにはリスクがあります。何もしないでいるとイライラして非建設的な方法でそれを放出してしまうリスクがあります。正直であることは、状況を自分で評価し、あなたがするように物事を見に来るように相手を信頼するという美徳を持っています。相手は、あなたが不公平ではなく、客観的に状況にアプローチしようとしていることを見ることができます。彼らはあなたの視点のポイントを理解していない場合は、それは彼らとそれを話し合って説明することは大丈夫ですが、あなたがストレートではない場合、それは本当に可能ではありません。どのようにすればいいのかは、相手がどのように反応するかの具体的な内容に依存しているので、この質問の範囲を超えています。

Verwandte Fragen

11
3
24
7
14