ユーザー、機能、ダンスベア

何らかの理由で、1年以上にわたって取り組んでいるプロジェクトが突然、不必要な機能を大量に取得し始めると、ある仮想顧客が必要とするだけで、非常に苦痛でcustomer辱されます。 しかし当初、この製品は公共サービスとして計画されていました。 細い建物が文字通りばらばらになり、瞬間的な機能の不愉快なアドオンで破裂する様子を見るのは痛いです。



私は理解しています：市場、競争、タイミング、顧客。 しかし、ユーザーにマニュアルを提供し、盲目的に彼らの気まぐれに従うことほど悪いことはありません。 機能性の競争は偽りの競争であり、勝つことは、おそらく顧客への奴隷制を除き、いかなる賞品も受け取りません。 製品の魅力は豊富な機能ではなく、適切なフィット感、バランス、利便性にあります。

この状況で唯一の解決策は、製品をブランチすることです：別のユーザーブランチを作成し、これが開発ポリシーである場合、必要な機能をそれに追加します。 清潔で理解しやすい状態を維持するための公開ブランチ。 このアプローチだけが、ユーザーや開発者に喜びをもたらさないでしょう。なぜなら、両方のブランチが徐々に機能するモンスター、「熊の踊り」に変わっているからです。

顧客の動機は明らかです-彼は単一の製品を入手してそれを使用したいと考えています（ただし、必要な機能は他の製品と統合することで実現できます）：私はすべてを一度に同じお金で欲しいです。 今では、何百もの断片から織られた多彩な祖母の毛布のようではなく、暖かく美しい結果になりました。 とにかく使用することが可能になります-それだけが困難で不便です。 そして、その品質ではありません。

問題の原因は、少なくとも2つあります。高レベルのイデオロギー設計の欠如（いわゆる対話設計 - システムアーキテクチャと混同しないでください）と、現時点で架空の顧客を喜ばせたいという欲求です。 これらの2つの要素がない場合、機能を可能な限り正確に詰め込むことで（製品-使いやすさ-テスト、再設計）、製品の極悪さを軽減することしかできません。

道徳：しかし彼女ではない。 もっと正確に言えば、それは明らかです-共通の真実、いわば。 システムアーキテクチャに加えて（およびその前でも）、明確化の段階、私たちがしていること、および製品の助けを借りて解決できるタスクが存在する必要があります。 しかし、最も重要なことは、これを顧客に伝えることです。 顕微鏡で釘を打つ必要がないように。 公共サービスと特定のクライアント向けのサービスを混在させないでください。