遅かれ早かれワークフローを確立したいチームは、特定のルールと理解を確立する必要に直面します。 実践が示すように、初期段階では、チームの作業は、全員が履行することに同意する条件付き合意に基づいています。 そして、たとえすべての参加者が責任を負い、適時に職務を管理したとしても、仕事のプロセスは最終的に苦しみ始めます。 なぜこのような問題が発生するのか、そして私たちのチームはそれらにどのように対処するのですか？ 私たちは、スタートアップの反対側を見ることで見つけることを提案します。
ステージ1.準備。
最初の段階（2年前）では、特定の方法で作業を構築する必要があるとはまったく考えていませんでした。 当時、夢と期待が実際の状況を上回っていたので、私たちは厳密に直感的に行動しました-誰もができるだけ早く仕事の一部を行うべきであり、他のすべては自分で形成されます。 特定のアクションの結果については考えず、起こりうるエラーを予測しようとしませんでした。そして、別のバンプを埋めるたびに、フラストレーションの状態に突入しました。 私たちはお互いに完全に対話することができなかったように思えました。
ステージ2.導入。
時間が経ち、ワークフローの混乱は少なくなりましたが、生産性は依然として望まれていませんでした：期限が切れ、無視できる量の作業が実行され、何よりも最悪なことに、この理解はすぐには得られませんでした。 問題は、生産性を客観的に評価する方法がなかったことです。 私たちは皆、記憶と感覚に頼っていました。
何かを変える時が来たので、チームワークの方法について考え始めました。 まず第一に、どこかにタスクとサブタスクを書き留めて配布することが決定されました。 これらの目的のために、ロシアのタスクスケジューラーチームを使用し始めました。
それは非常に便利であることが判明しましたが、そこでの活動が非常に速く停止した理由は明らかではなく、以前の生活様式に戻りました（すべての作業はSkypeチャットで行われ、まれな会議が交互に行われました）。 それにもかかわらず、しばらくしてからのこのような単純で一般に効果のない方法論は、プロジェクトの立ち上げにつながりました。
ステージ3.チップ
打ち上げには多くの問題が伴い、必要になりました。
-タイムリーなプロセスとフィードバックへの対応。
-サービスを改善するための実用的な提案を記録します。
-サービスで見つかったバグを監視および修正します。
-チーム内のアクションを同期します。
-特定のタスクに実際の用語を設定します。
-有能な実行のための作業量を評価します。
その後、Skypeでのチャットは実用的ではなくなり、非常に頻繁に電話をかけ始めました。 そのため、プロジェクトの立ち上げ後最初の6か月間住んでいました。 しばらくして、 サービスの 2番目のバージョンを作成する寸前で、ワークフローを大幅に変更する必要があると判断しました。 投資家でもある私たちの新しいパートナーも私たちをこれに追い込みました。
チームボックス
今日までメインチームの作業プロセスが編成されていたのは、 Teamboxでした 。 Teamboxでは、タスクとディスカッションの2つのツールのみを使用します。
タスクツールの構造
-デザイン;
-レイアウト;
-プログラミング;
-サービスの改善に役立つ機能。
-毎日の進捗レポート。
各セクションでは、必要なタスクのリストが公開されており、各タスクについて、可能であれば期限、優先度が設定され、追加の議論が行われます。 したがって、不必要な会話に時間を浪費することはありませんが、次に何をする必要があるかを常に把握しています。
ディスカッションツールの構造
-アイデア（アイデアが議論され、その中で最も価値のあるものがタスクのリストに転送されます）;
-デザイン（デザインに関するあらゆる瞬間/要望が議論され、スクリーンショット/他のサービスの例が公開されています）;
-プレゼンテーション（後ほど説明します）;
-チーム会議（一般的な電話の時間と曜日をまとめて話し合う）;
Github
現時点では、 GitHubはコードを保存するリポジトリの機能を実行するだけでなく、バグトラッカーとしても使用されます。 「チケット」を作成し、責任者を任命するには数秒かかります。
Skype会議
投資家との協力の初期段階でさえ、緊急事態や緊急事項については週に1回、無期限に呼び出す必要があることに同意しました。
毎週の呼び出しは、チームメンバーの1人が行っている作業の一部に関するレポートです。 通常、レポートは2つの部分に分かれています。
1.過去の期間に行われたこと。
2.チームメンバーが近い将来に何をするか。
投資家と他のチームメンバーは、それぞれの部分について話し合った後、もしあれば質問をします。 そのため、プロジェクトの作業プロセスに関する最新情報を常に入手できます。
チームには3人しかいない（デザイナー、タイプセッター、プログラマー）ので、4回目の呼び出しを共通の呼び出しにします。ここでは、短い心理セッションを配置します。 。 これにより、「蒸気を逃がす」ことができ、いつものように進むことができます。
機能優先度
時間が経つにつれて、私たちの意見では、サービスを改善できる非常に多くの異なる機能を蓄積してきました。 しかし、「シンプルで優れた」というルールを順守しようとするため、新機能に関するすべてのアイデアは厳密な選択プロセスを経ています。
各アイデアは、プロジェクトの4つの基準/目標に従って評価されます（評価は1〜10に設定されます）。
-この機能はユーザーを引き付けるのに役立ちますか？;
-どのくらいユーザーのニーズを満たしますか？;
-ユーザーをサイトにとどめるのにどれだけ役立ちますか？;
-この機能の実装の複雑さ。
おわりに
これが今日のチームの状況です。ただし、相互作用を改善するという点で取り組むべきことがあることを認識しています。 要約すると、チーム内の相互作用のプロセスは自然に変化するはずです。 チーム全体が変更を必要とする場合、変更が必要です。 別のケースでは、さまざまな作業方法の使用が完全に理解されず、改善されないだけでなく、活動の結果が悪化する可能性があります。
この資料がお役に立てば幸いです。 個人的な経験の交換と同様、どんな提案でも歓迎です。