経営者にどのようにしてプロトタイプを捨てるよう説得しますか?


16

ユーザーの前にUIを配置するための高速で効果的な方法としてのプロトタイプ作成が大好きです。

しかし、多くの場合、経営陣が邪魔になり、プロトタイプが主流の開発に追い込まれ、叫び声を上げます。

これを行わないように管理をどのように管理しますか?


11
子どもたちに光沢のあるおもちゃを見せないでください。彼らはそれで遊ぶことができなくなります。真剣に、それをくする、または何か、彼らはそれを望んでいないが、それでもあなたが表現しようとしているものを見せてください。
マイケルトッド

7
誤って

9
お気に入りの非メインストリームプログラミング言語を使用して、プロトタイプを作成します。それが機能しない場合、少なくともあなたはそれを維持することを気にしません。
ラリーコールマン


1
さて、プロトタイプはそのような理由で呼ばれます。彼らは投げられることになっています。彼らがそれを理解しないならば、私はラリー・コールマンに同意します。
サキスク

回答:


28

Microsoft SketchFlowなどのツールを使用するか、プロトタイプを他の言語またはプラットフォームで作成して、メイン開発に統合することをほぼ不可能にします。

また、スクリーンショットとプロトタイプの表示に関するjoelonsoftwareのエッセイもあります。未実装および未実装の側面が明らかに壊れている/未実装のように見えるため、作業を行う必要がある場所が明確になっています。

重要な結果2。プログラマーでない人に、100%美しいユーザーインターフェイスを持つ画面を表示すると、プログラムはほぼ完了したと思われます。

...

これについて何ができますか?Iceberg Secretを理解したら、簡単に操作できます。プロジェクタのある暗い部屋で行うデモは、すべてピクセルに関するものであることを理解してください。可能であれば、未完成の部分が未完成に見えるようにUIを構築します。たとえば、機能が表示されるまで、ツールバーのアイコンに走り書きを使用します。Webサービスを構築しているときに、それらの機能が構築されるまで、機能をホームページから実際に除外することを検討することができます。こうすることで、人々はホームページが3つのコマンドから20のコマンドに変化するのを見ることができます。

そのため、プロトタイプをVisual Studioの代わりにPhotoshopで作成するか、またはそれらに沿ったものを作成してみてください。


1
ええ、私はバルサミクが好きです!
オズ

+1 SketchFlowは、この一般的な問題に対して優れたアプローチを採用しています。UIをスケッチしたように見せます。これらのタイプの問題を解決するための黒/白、単調...素晴らしいアプローチ。シンプルに聞こえますが、UIを見る人​​には大きな効果があり、UIが実際にプロトタイプであることを理解できます。
アーロンマクアイバー

1
いい視点ね。動作中のアプリケーションである場合、それはプロトタイプではありません。
JohnFx

1
SketchFlowの代わりにPencilを試すこともできます。無料です: pencil.evolus.vn/en-US/Home.aspx
ブラッド

-1メインリンクが壊れています
マイケルデュラント

12

動作するコードでプロトタイプを作成しないでください。鉛筆と紙、またはソフトウェアと同等のプロトタイプ。

モックアップの使用は描画のように感じますが、デジタルであるため、簡単に微調整および再配置できます。チームは、会議中に設計を思いついて、それをリアルタイムで繰り返すことができます。

http://www.balsamiq.com/images/mockups/screenshots/components.png

紙を使用すると、チームメンバーが簡単に飛び込めるという利点があり、誰もがそれが単なる白紙であることを理解しています。これにより、それほど貴重ではないように見えます。


1
+1:これ!コードを使用して何かを正常にプロトタイプ化するたびに、意図した有効期限をはるかに超えた状況で再びそのコードを使用する必要が生じたときに後悔しました。言い換えれば...プロダクションコード言語を使用してプロトタイプを作成する場合、後でプロダクションコードになったとしてもそれほど驚かないでください。
ミイラ

Balsamiqリンクの+1。私はそれを頻繁に使用し、それは絶対に素晴らしいです。
ライアンヘイズ

私はBalsamiqが大好きですが、そのような大ざっぱなプロトタイプでさえ「貴重」になりすぎて、開発者をプロセスから除外してしまう可能性があります。多くの場合、古き良きペンと紙を使用して、すべてのチームメンバーの手にペンを刺すのが最善です!
アレックスファインマン

5

コードの品質を損なわないでください。

ジャンクコードを書くことは、誤った経済です。

他のポスターが示唆しているように、モックアップ用の特定のツールを使用してこれを達成できます。

ただし、プロトタイプを作成する理由はさまざまです。コードを記述せずに必要なものを表示できる場合もありますが、そうでない場合がよくあります。利害関係者は、機能の技術的な実現可能性を実証してほしいと思うかもしれません。

機能を実証/コンセプトを実証するために、できる限り無駄のないものを構築してください。他のものは省きます。

UI機能については、サーバー上で何も開発しないようにしてください。まったく触れないでください。組み込みのモック/フェイクを再度開発します。

UIをアプリケーションの残りのスタイルに適合させるために努力する必要がある場合は気にしないでください。手間をかけずに見栄えがする場合は、色を変更して目立たせるか、またはウォーターマークを付けてプロトタイプであることを示します。

プロトタイプを実動コードに変えてしまう可能性が最も高いのは、営業担当者です。彼らはあなたの製品を新しい顧客に売ります-この新しい機能がなければ、クライアントは署名しませんでした。彼らを責めることはできません。彼らには標的があります。それらに注意してください。プロトタイプであることを示すものを取り出さないようにしてください。あなたはあなたの地位に立たなければなりません-彼らはおそらくとにかく誤解を招く顧客であってはなりません。

経営陣は、プロトタイプを1つずつ生産コードに変えることを強制するようになります。最初のアドバイスに従って、くだらないコードを書かないようにすれば、問題はないはずです。徐々に、妥協することなくソフトウェアを構築します。

その後、経営陣が品質の低下を余儀なくされ始めた場合、その理由を自問する必要があります。彼らは受動的ですか?弱い?やけくその?これらのことはどれも、会社にこだわる正当な理由ではありません。


1
2番目にこれ。ある程度の経験を積んだら、ジャンクコードと同じくらい簡単に、プロダクション品質のコードでプロトタイプを構築できます。そして、そのレベルの経験に到達する主な方法は、ジャンクコードの作成を拒否することです。
エイミーブランケンシップ

4

本当に簡単です。彼らがこのバギーな混乱を見せてしまうと、お気に入りのクライアントを失うことになってしまうことを伝えてください。

そして、ええ、彼らが本当によく知っているなら、彼らに彼らのチャンスを取るように頼んでください。

最後に:プロトタイプに特定のバグA、B、Cがあるとは言わないでください。そうすれば、そのバグを修正せざるを得なくなり、経営陣はソフトウェア生産の準備を整えるためにエネルギーを集めたと主張します。

最近では、これらのパフォーマンスボーナスや将来の株式の付与が行われる可能性があります。


1

そもそも問題を回避してください。仕上げないで。つまり、見た目を美しくしたり、サイト上の既存のスタイルに合うようにしたりしないでください。目標は、可能な限り最も粗雑な作業バージョンを取得することです。これにより、非常に基本的なUIフローが機能することがわかります。既存のサイトスタイルを追加したり、過度に洗練したりすると、「プラグインする」だけで済むと思われます。管理は、スタートレックのPakledsのようなものです。彼らはあなたに「それを行かせたい」だけなのです。あなたがそれをより見やすくするほど、彼らはそれを考える準備が整います。

それでも問題が解決しない場合は、少なくとも1つの会社で1年間、有名なブランド名で就職してください。電子メールと番号をオンライン履歴書に記入すると、採用担当者とスティックで戦うことになります。これにより、自分が何をしているかを知っており、新しい仕事を得ることができる開発者の自信を持って「絶対にそうではない」と言うことができます明日、問題に関するあなたの専門知識がより真剣に受け止められることを願っています

現在、2つではなく、トリプルスタックのRails、.NET、およびJavaを備えたコードベースに取り組んでいます。Railsをタックした理由は、プロトタイプがRailsで行われ、会社のトップドッグが「成功させる」と言ったからです。時々ノーと言う必要があります。私たちが常にそれをしていない限り、彼らは私たちを真剣に受け止めるべきです。

ええ、プロトタイプで何をするにしても、それが本当にいものから始まることを確認してください。


1

心配しないでください。

座って「プロトタイプ」用のUIコントロールを投げる場合、そのデザインを自動的に捨てるべき理由はまったくありません。管理を示すのに十分であれば、「実際の」プログラムをいつコーディングするかを開始するのに適した場所です。

プロトタイプからより「洗練された」UIへの移行は、一連の完全に正当化可能な手順に過ぎません。2番目のボタンを追加する必要がありました。ユーザーから、注文が混乱しているというフィードバックを受け取りました。組織の標準グループは、小さな変更を指示しました。国際化のためにテキストボックスのサイズを変更する必要がありました。

これらの理由の1つが「まあ、それは単なるプロトタイプ」ではありません。UIデザイン、コード、または書面で、何でも永遠に生きることができます。そして、すべてではない人は、彼らを殺す非常に正当な理由を持つべきです。

そして、経営陣はおそらく気にしません。

現実的には、UIを既存のコードにドロップしなかった理由が「正しいフレームワークで書き直さなければならなかった」のであれば、それで十分なはずです。そうでない場合は、おそらくUIフレームワーク自体について議論する必要がありますが、それは別の質問です。


0

以前は、この問題は問題ではなく、ほとんどの店で課せられていた時代遅れの開発基準から解放される方法であると気付くまで、この問題を抱えていました。

そのため、管理者にプロトタイプを作成していることを伝え、この問題領域に最適なテクノロジを選択して、ソフトウェアが本番に使用されることを十分に理解して作成します。

「Webを使用するアプリケーションはJava 1.6でなければなりません(管理者が選択する高価なJ2EEエンジンを挿入する)」と無意味な命名標準などの退屈な作業から逃れます。

私が現在選択しているプロトタイプ言語は、「php」(完全にヘビーデューティーのプロダクション環境に拡張可能です-Facebookに問い合わせてください)と、Groovy / JavaとTomcatまたはJettyの非常にエレガントな組み合わせです。

groovy / javaの組み合わせは、迅速な開発に最適です。Groovyは迅速に開発できて便利ですが、老人向けのカタツムリのように機能しますが、パフォーマンスクリティカルセクションを純粋なJavaにリファクタリングするのは簡単です。TomcatまたはJettyにアプリケーションを組み込むことは、EJBや他のJ2EEの恐怖に二度と対処する必要がないことを意味します。

いくつかのポスターで提案されているスケッチとは対照的に、動作するプロトタイプを持つ主な利点は、ユーザーのフィードバックです。プロトタイプは、ビジネスを設計に真に関与させる優れた方法です。彼らが気づいたら、「そのフィールドはメイン画面にあるべきではない」などのことを言うことができます。次回のデモでメイン画面に表示され、プロジェクトに長年の貴重なビジネスエクスペリエンスをもたらす設計に参加します。


「Groovyは迅速に開発できて便利ですが、老人向けのカタツムリのように動作しますが、パフォーマンスクリティカルなセクションを純粋なJavaにリファクタリングするのは簡単です。」Groovyを使用してプロトタイプを構築する場合、プロトタイプ全体をJavaにリファクタリングする必要があります。
ヴォルグヴァンガイア14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.