オープンプロジェクトのワークフロー

Webプロジェクトを共同で実装するための真にオープンなスタジオを作成することは可能ですか？



私はあなた方の何人かを望みます、この質問は私と同じくらい関連性があります。



彼は閉鎖されたスタジオで働いていましたが、今はフリーランサーとして働いています。 同時に、「通常の」スタジオとの協力も、注文の独立した実行も正しいとは見なされません...



スタジオ、つまり独自のスタイル、プロジェクトのチームワーク、クライアントへの単一の責任を整理する方法を考えますが、同時に私はオープンになります：専門家のコミュニティがチームの場所を表している（多分大きくない）場合、責任は最小限になります（参加します）そして、すべての利益はプロジェクト参加者の間で分配されます-クライアントがアプリケーションを提出した瞬間から、スタジオ内で作品を配布するためのオープンメカニズムの機能に関する私の考えを詳しく述べました。



だから、プロジェクトに取り組むオープンプロセス。 彼はどんな人ですか？



まず、定義しましょう...

私が話しているコミュニティは開かれています。適切なレベルの能力を持ち、開発された価値を認識している人は誰でも簡単に参加でき、必要に応じて退出できます。 そもそもそれぞれの個人的な利益であり、互いに対する義務ではありません。

コミュニティの強さは、幅（参加者の数）ではなく、形式-構成の質、一方向に考える能力にあると思います。 これはfreelance.ruコミュニティではありません。

私が見ているスタジオのコミュニティは、特定のスタイルを失わないように大きくはありません。 男50、そして構成は一定ではありません（誰かが去り、誰かが来る）。



スタジオでの作業は、クライアントのアプリケーションから始まります。 「アプリケーションはどのようにしてスタジオに入ったのか」という質問に対して、別のトピックを取り上げることを提案します。

おそらく、クライアントはコミュニティメンバーの1人に連れて来られたので、感謝の気持ちを頼りにすることができます（たとえば、将来のプロジェクトで作業の一部を実行する権利）。

おそらく私たちの架空のスタジオは長い間働いており、よく知られており、多くのアプリケーションがスタジオのウェブサイトから直接来ています。



これで、プロジェクトの実装の申請書が到着し、実装のためにコミュニティが集まる時が来たと信じています。

1.プロセスの開始-クライアントからのアプリケーション。

これは、完全に形成されたTK、簡潔なもの、または何かを開発したいという欲求に関する単なるメッセージです。

すべてのアプリケーションは、コミュニティメンバーに表示されます。 プロジェクトマネージャーの「能力」を持っている人だけが答えることができます。 答えは、このアプリケーションに取り組む意欲を表しています。 答えには、マネージャーがアプリケーションで作業するために取得したい金額や、その計算方法（プロジェクト予算の割合など）も含まれます。

誰が誰に申請に回答し、誰に回答しないかを決定しますか？

コミュニティが決定！ 将来のマネージャーの仕事は、自分自身を宣言し、必要な能力があることを全員に示すことです。 提示された情報に基づいて、コミュニティはマネージャーがマネージャーであるかどうかを（たとえば、投票により）決定し、同時に彼はスキルのレベルを評価します（評価は、0から10などの標準化されたスケールで行うことをお勧めします）。

2人のマネージャーが1つの申請に回答した場合はどうすればよいですか？

-最初のマネージャーがすでに2つのアプリケーションで作業しており、2番目のマネージャーが1つだけで作業している場合、2番目のマネージャーが選択されます。 これにより、コミュニティ全体に注文を均等に配信できますが、最も興味深い注文は最も経験豊富なマネージャーに届く傾向があります。

-ジョブの数が等しい場合、スキルの高いマネージャーが選択されます。

-同様のスキルを使用して、より低い価格を呼び出す方が選択されます。

マネージャーの欲に対処する方法は？ 彼が自分の仕事を客観的に評価するのをどのように助けますか？

-競争を作成します。 複数のマネージャーが申請に回答することができ、同等の条件下で、勝者はより低い価格を要求する者になります。

-マネージャーに、フィギュアについて話す幸運ではなく、彼の作品を評価するためのスキームの選択を提供すること。 いくつかのスキームがあります。 それらのそれぞれがコミュニティによって承認され、最適と見なされることが重要です（スキームの例は、マネージャーがプロジェクト予算の10％に相当する金額を受け取る+ TK作成はキロサインあたり15ドルで支払われます）。 同時に、いくつかのパラメーターを変更することもできます（たとえば、彼はこのプロジェクトを非常に複雑であると考えています-10％が15％変化します）

-仕事の費用は未払いです。 この金額は、すべてのプロジェクト参加者に表示されます。 マネージャーは、自分の「カルマ」（スキル）が著しく低下したコミュニティの調停に自分の間違った行動が関与する可能性があることを知っているため、コストを過大評価する前に3回考えます。



マネージャーが選択されました。 アプリケーションで作業できます。

2.アプリケーションの評価。

ほとんどのアプリケーションは、よく聞かない質問（簡潔ではなく、明確なTKなど）に対する明確な回答（価格と条件を示す）を求める要求であることを誰もが理解しています。

マネージャーは非常に困難な状況にあります。 一方では、ToRの開発に対する支払いをクライアントに求めることはできません。その後、エグゼキュータが決定され、明確な予算が形成されるまで待機します（クライアントがそれを受け入れる準備ができているかどうかはまったくわかりません）。 一方、その価格と条件に名前を付けて、マネージャーはコミュニティを非常にタイトなフレームワークに入れますが、必ずしもそうではありません。

になる方法 「互換性のない」ものを再度組み合わせてみます。



最初に、できるだけ早くアプリケーションを処理する必要があります。 マネージャーは、クライアントに、アプリケーションに関する質問を明確にします。これは、パフォーマーが大まかにそれを見積もることが可能になるのに十分です。 おおよその評価では、多くの場合、完全なTKは必要ありません（これはプロセスで確実に必要です）。



マネージャは、処理されたアプリケーションをパーツに分割します（たとえば、design-layout-programming）。 そしてそれらをコミュニティにもたらします。 誰もが答えると同時に黙秘する権利を持っていますが、鑑定士には多くの義務と特権が課されています。



-アプリケーションの評価は、マネージャーによる公開の瞬間から12時間を超えない期間内に行われます。

-アプリケーションの作業は、主にその評価に参加したパフォーマーに配布されます。

-請負業者は、請負業者が指定された価格で作業する意向を表明していない場合、評価したアプリケーションの作業を拒否することはできません（拒否した場合、コミュニティからカルマから「-」を受け取り、他のプロジェクトに参加することはより困難になります）。



マネージャーは、自分の考慮事項に基づいて、評価なしで残されるポイントを評価します。



これで、マネージャーは必要なすべての番号を取得し、さらにコミュニティによって承認されました。 予算を作成できます。 再びひっかかったが、パフォーマーは同じように考えたくないし、彼らの数は非常に異なっている。 どうする？



この問題をマネージャーに相談して検討する価値があると思います。 彼は、他の誰も知らないように、クライアントが何を望んでいるか、彼が同意する金額について知っています。 あるケースでは、彼は最も安いオプションを選択します（クライアントがタスクを完了することは重要ですが、お金では非常にタイトです）、反対に、彼は一番上にバーを上げます（クライアントは品質を高く評価し、それを支払う準備ができています）同時に、クライアントは自分が選択しないことを理解しています-タスクは時間通りに完了し、必要な仕事の質を設定するだけです。



予算が承認されました。 クライアントはスタジオを完全に信頼し、最初の分割払いを行いました。 TKのコンパイルを開始できます。

3.タスク、設計チーム、および実装者。

プロジェクトを理解する過程で、TKが書き込まれ、そこからタスクが形成されます。

タスクは明確であるだけでなく、二重の理解と隠された場所を除いて主題を明確に記述するだけでなく、完全なものであるべきです。 理想的には、実行者はタスク自体を掘り下げて、プロジェクトのどの部分であるかを考えてはいけません。 同時に、これらの問題の解決策を単一のユニットにまとめることは、不可欠な有機物です。

マネージャーがTKから割り当てることができるタスクが多いほど、スキルが高くなります。



タスクはコミュニティで公開され、すべての参加者に表示されます。 公開時に、マネージャーはどのカテゴリの参加者がタスクに回答できるかを示します（たとえば、プログラマーとExtGWTに精通したユーザーのみが「ExtGWTでインターフェイスを構築する」タスクに回答できます）。マネージャーは、タスクの限界費用も示します。 タスクに回答した人が実行者と見なされます。 答えるとき、請負業者は自分の仕事の費用を示します。



タスクにはアプリケーションと多くの共通点があります。 タスクは、それ自体がコミュニティアプリケーションであると言えます。 知識のレベル、タスクに回答した複数のパフォーマーの1人の選択-これらの質問は、マネージャーからのリクエストと同様に解決できます。



アーティストが選択されました。 今、彼らは設計チームと呼ぶことができます。 これはもはや伝えられず、むしろプロジェクトの成功がすべての人の手にあるチームです。 同時に、タスクの分離は、グループが仕事の結果を頻繁に交換し、密接にやり取りしなければならないことを除外するものではありません。



たとえば、2人のプログラマーがプロジェクトに参加しており、両方ともいくつかの機能モジュールに取り組んでおり、モジュールは論理的に完成しており、APIを介して対話します。 完全に分離されているように見えます。 しかし同時に、彼らは共通のプロジェクトコードを持ち、コレクション内のすべてを観察し、他の人の仕事で何がうまくいっているのか、そして「私はもっと良くする」と見ることができます。



別の興味深い点は、グループが「一緒に成長しない」ことです。 プロジェクトチームの一員となる人物を確実に言うことは不可能であり、思考と実現のさまざまな驚くべき織り込みを観察することができます。



経験の交換があります。 それは素晴らしいことです。



作業中です。 完成を待っています。

4.誰もがそれに値する。

フィナーレは何でしょうか？ ポジティブだと確信しています！

実行者の1人がタスクに対応していない場合、これはプロジェクトを破壊する理由にはなりません。 コミュニティは集団よりもはるかに広いです。 過失を置き換えることはより速く見つけることができます。 グループは動的に変化しており、個人的な関係はそれほど強くありません。 問題は、すべてがすでに落ちているときではなく、開始時に解決しやすくなります。 「同僚」に対する道徳的義務は最小限に抑えられています。プロジェクトマネージャーまたはコミュニティ全体に質問を送信することで、仕事をやめるかどうかを安全に尋ねることができます。



作業が完了しました！ 石を収集すると同時に、お互いに評価を行います。

プロジェクトマネージャーは各パフォーマーのレビューを書き、パフォーマーはマネージャーと彼自身の仕事を評価し、タスクの実装の強みを示します。 一般的なレビューとプロジェクト全体は、コミュニティに行き、プロジェクト参加者のそれぞれの「カルマ」を修正します。



時間が尽きており、創造性の時が来ています。 知識よりも関心が高まり、感情がささやくと、きっと成功するでしょう。

5.ポテンシャル。

私たち全員が何かを隠しています。 私たちが「プロ」にふさわしいものであるという事実でさえ、かつて他の人にはアクセスできませんでした。 これを抽出するには、自分自身と「同僚」の両方のために、自分の手から面白い作品を奪い取り、自分が思っていたよりも悪化させることに気づいて、たくさんの円錐形を埋める必要がありました。 または意識的に「完全な道楽」に参加します。誰も仕事を取りたくないので、気分が悪くなります。そこから一粒の経験を取り、プロフィールで別の貴重なレビューを取得します。



コミュニティがマスターのスキルのみを活用し、ゴミ（興味深い仕事ではない）が経験の浅い参加者をマージするとどうなりますか？

まず、私たちは自分のスキルの人質になります。 たとえば、netkatでサイトを構築するのに優れたプログラマーは、それらをさらに収集することを余儀なくされます。 彼がこの仕事にうんざりしたときでさえ、彼は他の技術を学びたいと思っています-誰もが彼をnetcatのサイトのコレクターとして知っています。

第二に、コミュニティに悪いレイアウトデザイナーとして知られていない優秀なデザイナーは、まだ自信を得ていないが、すでに何かを学んでいるので、彼が「オープン」することを許される場所で長時間離れて仕事をする可能性があります。



どうする 「フリースキル」のシステムを導入することを提案します。

これは何でもあり得るスキルです。 私たちは、各参加者がそれを持っていると信じています（多かれ少なかれ）。 フリースキルは、タスク（またはアプリケーション）への回答で使用できます-回答する場合、たとえば、フリースキル= Symfonyフレームワークの経験であるとみなされ、参加者の応答は他の人と同じ立場で考慮されます。 また、いくつかのルールを紹介します。



-参加者の「カルマ」が高いほど、コミュニティに利益をもたらすほど、フリースキルのレベルは高くなります。

-タスクに回答するとき、無料のスキルを持つ参加者は経験豊富なパフォーマーによって保険がかけられます。

-タスクが適切に実行された場合、無料スキルのレベルが増加します+彼が実行したスキルは参加者に帰属します。 悪い場合は、逆に、次回は彼にとって珍しい作品を演じるのがより難しくなります。



健康なコミュニティはそれ自体を消費者として扱いません！ そして、各参加者の可能性を解き放つのに役立ちます。

6.仲裁。

良いコミュニティとは何ですか？ 仲裁人として行動するために、人々の間の対立の客観的な評価を与える能力！

これを誇ることができる「閉じた」スタジオは1つもありません。 定義上、彼女の決定は常に主観的です。

経験豊富なPMが対立を解決するか、スタジオ管理者とペアになるかどうか-決定は常に画像の主観的な認識に基づいており、（ほとんど）常に関心があり、発生するイベントから抽象化することは非常に困難です。各決定は誰かの利益をロビー活動した結果です。



したがって、私はまだスタジオとの共同プロジェクトに公然と参加する余裕はありません。 関係でロビー活動をするためには、力のバランスを好みます。 私は常に進歩を求め、全額支払いがある場合にのみ結果を管理します。 この力の調整により、社内の関係から解放されます。 デザイナーがレイアウトデザイナーについてどう考えているかは関係ありませんが、PMはすべてをまとめて考えています。 私には関係ありません。 私の方のスタジオに関しても同じことが言えます。 私たちは私たちが望むすべてを公然とお互いに表現できますが、これは共同作業にはほとんど影響しません。なぜなら、彼らは個人的な関係ではなく、お金、費やされた時間、顧客への義務によって私に結びついているからです。



コインの反対側-結果を隠すことは、特に多くの人々がプロジェクトに取り組んでいる場合、多くの技術的な問題を引き起こします。 時々、すべてを家に置いたままAPIを介してインタラクションを確立することが判明します。結果の制御を失うことなくコードの一部を開くことができます。時には、制御を与えてロビー活動の不快な条件に陥る必要があります。



メッセージは何に送られますか？ それにより、オープンになり、結果を制御するという余分な負担を取り除くことができます！

オープンスタジオでは、フリーランストランザクションで作業する準備ができているのと同じ程度に、作業を進めているプロジェクトのコードを隠したり、進歩させたりすることはできません。 なぜなら、プロジェクトの資金は、紛争が発生する可能性のある（またはそうでない可能性のある）利害関係者の手にないことを知っており、紛争は私が信頼するコミュニティによって解決できるからです。



PS：オープンスタジオのアイデアに近い人のために、グループが作成されました-http://groups.google.ru/group/semaco

私はそこに集結し、質問への答えを一緒に見つけ、私たちの考えを生き返らせることを提案します:)