私は約3人の他の人（開発者以外）と一緒にまともな小規模プロジェクトに取り組んでいるソロ開発者です。これらの他の人々は開発以外の方法でプロジェクトに関与しており、1人は私のマネージャーでもあります。誰もがその場限りの議論にもかなりオープンです。
私のマネージャーはちょうど夢のように見えるものを私に与えてくれました-私はどの会議構造がプロジェクトに最適かを決定することを任されました。これは、会議の過負荷や無意味な会議に対処するための素晴らしい方法のようです。
今のように、大きな力には大きな責任が伴います。もし私が最終的に多くの無駄な時間をもたらす何かを提案した場合、それは私のせいです。
会議をどのように構成するかを考えるのにこれほど白紙の状態はありませんでした。私の考えは：
- 毎日の目標を伝え、前日の内容を確認するために、15分以下（スタンドアップミーティングと同様）の毎日の「タッチベース/ステータス更新」ミーティング。または、ホワイトボードを手に取り、自分の机に置いてこの情報を伝えることもできたようです。
- 特定の決定を下すため、またはチームのいずれかが持っている質問に対処するために必要に応じて会議
...毎週の「ステータス」プロジェクト会議の必要性はないと思います。また、2番目の箇条書きで正式にスケジュールされた多くの会議が必要になるかどうかもわかりません。
私の懸念は、これらの「開発者に焦点を当てた」（つまり私）が他の人との疎外を引き起こしたり、この構造がほとんどのプロジェクトが実行されるものとはかなり異なるため、プロジェクトに対するコントロールの喪失を感じたりする可能性があることです。
1人の開発者が選択する必要のあるプロジェクト会議の構造は何ですか？
コメントへの対応：
他に貢献している人は何ですか？彼らはこのプロジェクトの対象ユーザーですか？開発の非側面（ウェブサイトのテーマと画像、DBA、QAテストなど）に取り組んでいますか？他のレベルの管理/管理？
彼らは最終的なユーザーの一部であり、全体的なワークフローに関心があります。また、フォーム/ドキュメントのいくつかの領域にも貢献しています（その形式は開発作業に影響しません）。
他の2人のメンバーからフィードバックを得ることができますか？一部のマネージャーは、定期的に会議をスケジュールする必要があります。そうしないと、会議をスケジュールに合わせることができません。
時間を稼ぐことは今後の問題ではないようです。