1つの失敗の物語

プロジェクトを管理する方法について、紙のフェンスに書かれた手紙がたくさんあります。 これ以上ではないにしても、多くの人が、これからどのようなサクセスストーリーが生まれたのかを説明しています。 吐き気、面白くない、病気。 ひとつの失敗の話を考えてみましょう。それは常により面白くて魅力的です(明らかに、人類の性質のために、喜びよりも栄光があります)。 始めましょう。



初めに欲求がありました



プライベートプロジェクト。 単純ではありませんが、特に難しくはありません。 指使いのジャングルに入らないように、プロジェクト1と呼びましょう。A社とは、B社の重要なタスクの1つを実行する会社です。彼女と一緒に働いた人々の頭の改善と承認の形で。 そして、Bという名前の会社Aの代表者がいて、彼のボスGがいます。トゥマナは引き入れられました。悲しみは読者の頭に染み込んでいます。



ステージ1



まあ何と言って。 非常に興味深い段階であり、オープンスペースではアウトソーシングが古典的な意味で平凡であるという点で興味深い。 TKは、銀河の大きさの一種のフリップチャットのようなものを提供する、サードパーティのリソース上のある種の文字の寄せ集めであり、矢印、依存関係、および署名の複雑さをさまよう、無限にスクロールできます。 何らかの理由でプレゼンテーションやExcelファイルの形式で作成されたドキュメントの山ですが、まあ、慣れていません。



この動物園をすぐに知った私は、会社Aのオフィスに行き、彼らが本当に欲しいものについてBと話をします。 約4時間で、インターフェイスのスケッチセット、プログラムの動作のロジックが形成され、Excelの乗算、減算、除算、およびその他の括弧のごちゃごちゃがビジネスプロセス計算であると主張することが理解されます。 そして、これを行う方法についての理解もあります。 戦闘、実装、タイミング、支払いについて合意に達しました。 しばらくすると、プログラムが表示されます。



オフシーズン



単純なプロジェクトは、徐々に秋に補足され始めています。 Osenismは、プログラムに取り組む過程で顧客に現れる要件です。 原則として、これは与えられています。 Web、デスクトップ、組み込みシステム、およびマイクロコントローラー用のコードの開発に関する120を超えるプロジェクトのうち、元のToRに明らかに対応する単一のプロジェクトにまだ出会っていません。 あなたが火星人の前進と3本の柱の上の3頭のゾウを信じているなら、あなたは盲目的に固定TKを信じることもできます。 しかし、原則として、仕事中にニュアンスやアイデアが浮かび、私は「千を忘れた」だけです。少なくとも、私はそれに慣れました。 しかし、最終仕上げの反復の段階の1つで、それらがビジネスロジックにますます影響を与えていることを理解し始め、このプロセスを積極的に削減し始めました。 ビジネスロジックはソフトウェアの基礎であり、そうでない場合は、こぼれたケフィア(「小さなボタン」)と比較してmet石落下に似た問題です。 第二段階に同意します。



ステージ2.崩壊する道



この段階で、Bは次のことを申し出ます。A社のソフトウェアを作成し、スタッフに転職したプログラマーとして、新しいビジネスロジックをプログラミング言語で作成することに同意します。 その上、それは重要ではなく、重要です-私のものとは異なります。 実際、これは単なる頭脳ではなくても構いません。言語はほぼ同じです。文書化されたコードがあれば、プログラムの動作を理解するのは非常に簡単です。その本質はユーザーの行動を計算することです。 それが判明したように、それは私にそのように見えた、私のしゃれを許します。 私はソフトウェア開発の方法を判断しません。 すべてが起こる、私は別のことを見た。 個人的には、ある大規模な自動車メーカーのコメントのコントロールユニットのファームウェアのリバースエンジニアリング中に読んだことがあり、私を笑わせました。このソフトウェアで使用されているソリューションのいくつかは恐ろしいものでした。 そして何もない-どうやら生産中(私はそれを読んだので)、何百万台もの車を売った。 別のことが重要です。 ルールによって書き直されたデバッグコードは、計画よりも4倍の時間がかかりました。 コードをコピーして貼り付け、データ構造から変数セットへのコンバーターを作成し、コード開発の結果に基づいて変換し直すという考えさえありました。



少し始めに戻りましょう。 A社はB社の製品を製造しています。A社は非常に大規模なB社です。B社は定期的に中間結果を示しています。 なぜ-明確ではありません。 ミーティングのたびに、視覚的なデザインとユーザーインタラクションのロジックに関する多くの要件があります。 まだ解決されていないコードに新しいロジックが導入されました。 各会議後の期限がさらに短縮されます。 決定論的カオスの流れは成長しています。



その結果、従業員BはGの長により仕事から除かれ、Gは自分の手に問題を取ります。 また、論争点。 コードと同様にビジネスロジックを取得しました。 転送中の調整では、多くの丸い目がありました-私は、ソフトウェアの平凡な要件が与えられていないという事実から学びました。それは、そして最も重要なことには、「super_top_secret」ではありませんでした。 G-彼がビジネスで作成されたロジックの意味を掘り下げたとき、それは必要なものから数桁も複雑でした。



ビダ、憧れと悲しみ。



結果は?



私は素晴らしいプログラマーです。 私はすべてを時間通りに借ります。 常に。 私は間違いを犯しません。 私は完璧なコードを書いています。 すべての顧客は牛でありoligo占であり、彼らがどれほど幸運であるかを理解していません。



何も忘れていないようです。 したがって、この話を終わらせる必要があります。 ベストで泣きたいなら。 しかし、記事の冒頭を覚えていますか? 何をすべきかを分析するために、成功事例ではなく、ファカプの例を取り上げましょう。 私たちは皆後知恵に長けているので、平凡な「作業明細書のすべての要件を書き留め、契約書に署名し、作業明細書の完了直後にロバに座る必要がありました」と書きません。 この間違いは神の日として明白であり、それを間違いと呼ぶことは困難です-火星人と象を思い出してください。



間違い



第2ステージの開始前の到着の欠如。 覚えている-最初に私が到着し、仕事について話しました。 第二に、私はこれをしませんでした、それが同じであると確信して、プロフィールだけで。 その結果、「これを移動して、ここに追加してください」という多くの改善がありました。



テキストジョブではなくコードに同意します。 主要な間違いの1つで、最初の間違いよりもさらに悪い。 ああ、この栄光の「私はかつて…。」。 誰もがこれを「昔々」持っています。 車の修理にも使用していました。 私自身のサービスもありました。 そして、これは彼らがサービスステーションで率直なナンセンスを持ち始めるとき、私を弱く助けません。 しかし、私たちの記憶の性質は、私たちが良いことを思い出し、悪いことを消去するようなものです。 はい、私はすべての時間を仕事に与えて、燃え尽きてしまったため、車を投げました。 病気になりました。 しかし、私が病気だったときの気持ちを覚えていますか? いや。 これは単なるブナセットです。 事実 裸 そしてそれだけです。 しかし、夜のブハロボは、仲間、ポカトシキ、興味深いチューニングプロジェクト、おかしなケースの会社で、私は自分の顔に書いて笑顔を誓います。 あと5年が経ち、多分私は再び自動車に関わるようになるでしょう。 知る方法は?

「昔々」は楽しい思い出と非常に密接に関連しています。 したがって、それは単純で、面白く、面白そうです。 そして、あなたが仕事に移すと約束したモデルが突然機能しないとき、現実にはコードが借方に記入される必要があるという事実を突くとき(それは、境界条件の脆弱性の後に発見された)-そして、はい、仕事など優先順位ではありません。 そして、喜びはありません。 なし。 したがって、ロジックは宣言されたものから6倍遅れて送られました。

そして、私は耳が大きいばかです。 「私がコーディングに使用したもの」に精通している。 彼はこれが最も恐ろしい顧客であることを完全によく知っています。 しかし、それにもかかわらず、もう一度行動しました。



改訂に同意します。 むしろ、彼らのコントロールの欠如。 作業中、中間または最終配信の前に、元のタスクからの変更の10%以下を実行しようとします。 ここで、スコアは私によって失われました。



期限を短縮することに同意します。 「計画、設計、執筆、テスト」 奇跡はありません。 宣言からの条件が2倍に削減されると、2倍に増加します。 いずれにしても、何かが省略され、結果の期間が増加するだけです(「準備」を報告する期間は増加しません)。



今日は以上です。 この経験が仲間に役立つことを願っています。 おやすみなさい



All Articles