5年間、私はWeb開発を行ってきました。 この間、私は数百ドルでひざの上にサイトを作り、かなり大きなプロジェクトに参加しなければなりませんでした。 過去1年間、deja vuの感覚は私を去りませんでした。 すでに私が見たどこか：神経質な顧客、激怒したマネージャー、開発者の仕事と期限に圧倒されました。 しかし、私にとって何も変わっていません。 同じファジーで絶えず変化する要件、プレッシャーがあり、単一のプロジェクトが時間通りに配信されませんでした...
そして、これは、「レーキ」が常に同じであったという事実にもかかわらず。
ここでは、私が観察したWebプロジェクトの管理における最も一般的な問題について説明します。 おそらく、以下で述べられていることの多くは、一般的なソフトウェア開発に起因する可能性があります。 しかし、深刻なソフトウェアプロジェクトでの私のささやかな経験では、そのような一般化を行うことはできません。 また、すべてのプロジェクトで開発者として行動したことにも注意したいと思います。
だから。
一般的な態度：
友達のWebプロジェクトマネージャーのほとんどは、開発者から成長しています。 この場合、多くの問題がしばしば発生します。
すべてのアーティストが結果に焦点を合わせているわけではありません。 時々、仕事はプロセスとして認識されます。 一方、マネージャーは、プロジェクトのタイムリーな配信に個人的な関心を持っているようです。 そして、これは興味を得ることにそれほどではなく、特定のムード、世界観にあるべきです。
実装に対する過度の関心。 つまり、管理機能の代わりに、マネージャーはコードの記述やアーキテクチャの形成に関するルールを指示し始めます。
開発者がPMに昇進したときのことを覚えています。 しばらくして、彼は自分のプロジェクトのコードを調べ、恐ろしくなりました。 「何かをうまくやりたいなら、自分でやる」と彼は言い、コーディングに取りかかりました。 同時に、彼は優れたスペシャリストであり、今でも残っています。 PMがコードの処理を開始すると、気が散ってプロジェクトの制御を失うため、おそらくこれは彼の個人的な失敗でした。
人の性格も重要な役割を果たします。 私は意思決定をし、それらに対する責任を負う意欲を意味します。 多くの場合、適切なタイミングで電話がかけられなかったり、未送信の手紙が原因で問題が発生する状況に遭遇することがあります。
エラーに対する一般的な態度に注目する価値があります。 また、当局への恐怖のために、いくつかの問題が表明されないことも起こります。 しばらくすると、問題が早期に解決された場合よりも深刻な結果につながる可能性があります。 （「カーペットの下にゴミをかき集めている」反射は気づかなかった-まあ、大丈夫。）
そして最も難しいケース：「マネージャーが私を追いかけました。今私は追いかけています」。
つまり、ガバナンスについてではなく、自己肯定についてです。 同時に、マネージャーの主なタスクは従業員を駆り立てることではなく、人々が仕事をしてプロセスを制御するための条件を作成することです（この機能が特定の時間に、特定の予算で実装されるように）ことは忘れられています。 制御不足も一般的な問題です。 特にPMが責任のあるエグゼキューターである場合。
人は資源であると信じるリーダーと協力することは非常に困難です。 そして、マネージャーと開発者の両方が同じ従業員であるという事実にもかかわらず、彼らはプロジェクトで異なる役割を持っています。
タイミング
おそらく最も痛いトピックの1つです。 時々、PMはある種の自分の世界に住んでいると感じます。 Web開発市場が飽和していることは明らかです。 また、クライアントごとに戦わなければならず、時間を短縮して価格を下げる必要があります。 同時に、なぜ作業の非常に初期の段階で非常事態に何度も何度も開発チームに入る理由は謎のままです。
時には別のアプローチがあります。 タスクのタイミングは、実行者によって指定されます。 ただし、そのような推定値の妥当性について考える人はほとんどいません。
そして、実践が示すように、複雑さはせいぜい4分の1だけ過小評価される可能性があります。
また、顧客によって締め切りが課されることもあります。 これは見かけほど悪いオプションではありません。 ただし、顧客が作業量に同意し、予算を採用する準備ができていること（またはその逆）を条件としてのみ。
プロジェクト計画の欠如
もちろん、計画があります。 マネージャーの頭の中だけがあいまいです。 ただし、通常、これはまったく計画ではなく、プロジェクトを完了するために必要な作業の一般的な理解です。 プロジェクト管理の主なタスクは予測可能性を作成することであるように思えます。 この時点で、完了した（完了していない）作業量と呼ばれる可能性が高い。 緊急の場合、計画はプロジェクトの現在の状態を判断し、すばやくナビゲートし、正しい決定を下すのに役立ちます。 計画を立てることで、仕事の進行を制御する機会として別のボーナスが与えられます。
要件管理
どんなプロジェクトでも、要件の収集と分析から始めるべきだと思います。 クライアントが本当に必要とするものを理解する他の方法は？ 問題は、すべての顧客がこのプロジェクトに何を望んでいるかを明確に理解していないことです。 サイトを作成するとき、これはかなり一般的な状況です。 開発者の間では、かつて「マネージャーが先日私たちのところに来て、私をウェブサイトにしよう」と冗談を言っていました。 この状況では、2つの主な解決策があります。
1つ目は、プロジェクトの作成から実際の要件と望ましい結果をネゴシエートし、決定することです。 はい、これは必ずしも簡単ではありません。 交渉だけでは不十分な場合があります。 ただし、このアプローチでは、顧客が本当に自分のお金を使いたいと思うものを受け取る可能性が高くなります。
2番目のソリューションはより一般的です。 「必要なものはわかっています」というインストールに基づいています。 このアプローチを選択すると、製品は既製のモジュールで構成されます。 Web開発では、これはおそらく非常に重要です。 確かに、「ゼロから」サイトを定期的に作成することは（大量の注文で可能であれば）、リソースの過剰な浪費です。 ただし、この場合、最終製品に課せられる多くの制限が顧客に課せられます。 したがって、プロジェクトの準備が整うと、状況がより頻繁に発生し、顧客は次のように述べます。
さらに、要件を収集するプロセスには特別な注意が必要です。 通常、これは偶然に起こります。 つまり、要件は、マネージャーの記憶、メール、またはICQログに保存されます。 同時に、不可能ではないにしても、フローを制御することは非常に困難です。 さらに、電話で表明された要件を追加すると、次の問題が発生します。
- 作業量は増加しており、制御された方法ではありません。
- 日付はランダムに変更されます
- あいまいな要件を持つ完全な設計を実行することは不可能です。 これは、最終製品の品質に影響を与える可能性があります。
- 顧客はいつでも言葉を放棄できます。 結果として-失われた時間（せいぜい）
- 要件の一般的なリストには一貫性がありません。 したがって、最終製品が顧客を満足させない場合があります。
リスク管理。
Webプロジェクトでは、本格的なリスク管理を見たことはありません。 一般に、それらが同じであることは明らかです。作業量とタイミングの不十分な評価、TKまたはレイアウトの調整の遅れ、機器のタイミングの悪い提供などです。 さらに、同じレーキを何度も何度も踏む理由は明らかではありませんが、これらのリスクは無視されます。 契約内の対応する条項を単純に示すだけで十分な場合（もちろんそうであれば）。
はい、そのような予約をすると、「これらの人はすべてを迅速に、不必要なトラブルなしで行う」という理由だけで、競合他社に逃げる普通のクライアントを怖がらせることができます。
これもリスクです。 そして、定期的に締め切りを逃しました-これはあなたの評判を台無しにするリスクではありませんか？
ミーティング
Webプロジェクト会議を開催することは非常にまれです。 いずれにせよ、彼らが実行された場合、彼らは通常、事前に議題を準備して送信することを忘れます。 当然、このようなアプローチでは、プロトコルを作成することはまったく問題ありません。 会議自体はしばしば技術的な問題のペアの議論に要約されます。 その結果、時間の無駄であることが判明しました。何が議論されたか-どの決定が下されたかが明確ではありません-次に何をすべきか誰も覚えていません-それも明確ではありません。
エラー処理
私の知人PMのほとんどは、彼が参加したプロジェクトの数を私に伝えることができませんでした。 この問題は、メモリ不足ではそれほど問題ではありません。 プロジェクトの結果を分析する人はわずかです。 この記事を執筆する過程で、興味を持たせるためにアンケートを実施しました。 公表時点での主要な意見は、「心に留めていますが、文書化していない」-25.32％です。 さらに、同じ投票から、回答者の35％だけがプロジェクトの本格的な分析を行っていることが明らかです。
プロジェクト管理の経験が蓄積されないことがわかります。 関連する文書を作成する習慣がないため、彼らの知識は会社の管理者にも残されるため、業務を引き渡すときに常に共有できるとは限りません。 したがって、管理の開発プロセスは非常にゆっくりと移動できます。
合計：
おそらく、Web開発の主な問題は未熟です。 この分野では、経験や特別な教育を受けていない若い専門家がたくさんいます。 この非常に初期の経験を受けた多くの人々は、より深刻なソフトウェアプロジェクトに移行し、初心者のためのスペースを解放しました。
深刻なプロジェクト管理を導入することで、サイトの開発プロセスを複雑化することが望ましいかどうかに関して疑問が生じる場合があります。 あなたは信念を満たすことができます-「よく考えないで、このサイトを作ってください。 次のプロジェクトがあります-そこですべてを賢明に行うでしょう。」これにより、より短い時間でより良い製品を生産できるようにすることをお勧めします。 したがって、これはコストの削減につながります。 さらに、より落ち着いた、より予測可能な仕事としてボーナスがあります。これは、スタッフの離職を減らすための鍵の1つだと思います。
そして、実際には、顧客はまだ品質開発のために数万（数十万）ドルを支払う準備ができていないのかもしれません。 そして、真実は、なぜ、学生の友人が同じ仕事をするのであれば、たった1000年半だけ...
それにもかかわらず、ユーザーストーリーを使用してデザインを準備するサイトを作成するための技術仕様、開発への反復アプローチをますます満たすことができます...これは、開発が正しい方向に進んでいる良い兆候だと思います。
オリジナルはこちら