1つのプロジェクトをきっかけにバグに取り組む

少しの背景

尊敬されているコミュニティに、この夏に費やした最初のプロジェクトと、その後の結論について伝えたいと思います。 私が以前にプロジェクトを実施したことはありませんでしたが、それらは残余ベースで行われ、締め切りは非常に無料でした。 たとえば、ロシア連邦中央銀行とファイルを交換するためにユニバーサルトランスポートアダプターに切り替えるプロジェクトの場合、私はゆっくりと1年以上（最終的にはすべてが時間通りに機能し、正常に機能していました）見ました。



名前といくつかの詳細を示していないことに注意してください。そうでない場合、パーティクルボードに関連する情報に触れます。



しかし今年、私は仕事をサポートからプロジェクト管理に変更し、レースをしました。 新しい場所では、非常に短い時間で、コンベアモードであらゆる種類の実装と改善に取り組んでいます。 個人や法人など、さまざまなオブジェクトのさまざまなソースから情報を収集および構造化するために設計されたソフトウェアの実装のための^1つの部分的に開発されたプロジェクトを手渡されたとき、1週間も経っていませんでした。 彼らはメッセージで私にそれを手渡しました：「このことはすべてをすることができて、それを実行します、それは正しいことです。」 開発者は、「私たちは何でもできる！」と言っており、確認の結果、胸のかかとで自信を持って自分自身を叩きました。 私は魅了され、働き始めました。 ²

プロジェクト段階

以前は、プロジェクトは1つのユニットに統合されましたが、価格が高すぎたため、全員で共有することにしました。 さまざまな部門から顧客を募集する必要がありました。 それから、コールドコールと呼ばれる以前は馴染みのないサポートアクティビティに出会いました。 今まで、私について、提案されたプロジェクトについて何も聞いたことのない人々は、一般的に忙しくて時間がありません。 誰もテストに参加したくありませんでした。 ³ファンタジーに夢中になり、「このことですべてができる」というモットーの下で、さまざまなタスクの理論的な可能性についてプレゼンテーションを書きました。 私の上司が管理リソースをハッキングし、物事が動き始め、ボランティアが任命され始めました。 それで2週間が過ぎました。



人々が自発的かつ強制的にプロジェクトに興味を持った後、その有用性を説得する必要がありました。 この目的のために、彼らは私が宣伝したシステムを使用して解決できるすべての人のためにタスクを収集し、それらを開発者に送信して準備および表示するというアイデアを思いつきました。 その結果、約20のタスクのリストが表示された結果によると、約1週間（または2週間）が経過しました。 リストを開発者に送ったところ、彼らは事実上頭を横に振った-「はい、できます、できます」。 上司は、彼らが何を得るかを見るために私を思いました



それから私は最初のバンマーと最初のベルを待っていました。 なぜ、ベルがあります-アラーム全体と船のサイレン。 保証にもかかわらず、ソリューションにほぼ似たものが20のタスクのうち2つで実証されました。 残りについては、「私たちがどのようにあなたを完成させるか教えてください」という言葉しかありませんでした。 私はすでに開発者と誓い、プロジェクトを終了する準備ができていましたが、その後、より高い勢力が再び介入し、「そのままで、それを実装する必要があり、改善のコストを評価してください」と言いました。 試用期間の半分で同じ新しいボスを送らないでください。 ⁵



潜在的なユーザーにインプレッションを送信します。 結果はわずかな困惑から完全な失望であり、テスト参加者の1人が私の電話や手紙にまだ答えていません（いいえ、彼は辞めず、休暇もありませんでした）。 想像力を刺激したのは改善のコストであり、ソフトウェア自体のコストの4倍（非常に大きい）です。

プロジェクト概要

ショーは終了し、交渉が始まり、「なぜこれがそうなのか」の明確化。 どこかで彼らは数パーセントの割引を勝ち取ることができましたが、一般に、開発者は彼らの製品を高く評価し、死に立ちました。 その過程で、システムのアーキテクチャを見つけることができました（もちろん、もっと早い段階で行う必要がありました）。 実際、多少なりとも読みやすい形式で情報を取得するには、各ソースに対してシステムを手動でプログラムする必要があり、システムのアーキテクチャ上の特徴などにより、検索エンジンの結果を使用することは不可能であることが判明しました。 さらに、開発者はプログラムする必要があります（そして、それらを再度支払います）。なぜなら、SDKが存在しているにもかかわらず、システムですぐに何かを理解することは明らかに不可能であり、手作りの改善によるパフォーマンスは保証されておらず、テクニカルサポートに含まれていないためです。



結果と結論を注意深く記録し、プロジェクトに関する結論を書きました。 これをすべて読んだ後、CIOはクワッドフェイスパームを実行し、プロジェクトは終了しました。



______

¹すぐに大きなプロジェクトを提供するのは間違っているわけではありません。私自身は、「新兵を訓練する際に完全にサポートしてくれた「戦闘でライフルを手に入れる」という原則を支持しています。 しかし、プロジェクトでは、「オーバークロック用」を提供します。

²実際、プレゼンテーション資料や中古の意見ではなく、システム自体とその機能を掘り下げることから始める価値がありました。

³ここでの間違いは、おそらく、最初は「クールなアイデアを思いついた」から、それを必要とする人を探し始めたことです。

⁴そして彼は正しかった、今私はいつもそうする。 突然の失望を避けるのに役立ちます。

⁵ 「理由を整理するのではなく、さらにカットする」ここでは、当局による間違いが間違いなくあり、それにより、1か月半の作業が無駄になりました。

_____

結論

プロジェクトは当初、なんとなく曲がりました-ユーザーのニーズからではなく、設計部門のアイデアから。 システムのアーキテクチャからではなく、それに関するストーリーやアイデアからです。 そして、それは私によって始められたものでもありませんでした。 合計：

• プレゼンテーション資料を信頼しないでください。生きているシステムで、すべてがどのように機能するかを自分で確かめてください。
• 他の人がプロジェクトに干渉しないようにしてください。 顧客/上司には結果と期限に関する要件があるかもしれませんが、結果を得る方法は彼らのビジネスではありません。
• プロセスを外に出さないでください-キック、到達するすべての人をスピードアップしてください。 あなたが到達できない人に-レバレッジとキックを探します。 計画に従って厳密に進み、タイムリザーブなどのない不測の事態に陥るよりも、計画を超えたマージンを確保することをお勧めします。
• アイデアに魅了されないでください;それがどのように実現されるかを見てください。
• 人々のために彼らのニーズを発明しないでください-聞いてください。

尊敬されるコミュニティの意見を聞きたいと思います。何かを忘れましたか、すべての結論を出しましたか？ これはHabréに対する私の最初の投稿なので、何かがおかしい場合はあまりキックしないでください:)