| 最近の更新 | |
|---|---|
| ドライランのありがたみを改めて知る
| 2024/04/04 |
| 伊豆半島
| 2024/03/31 |
| お出かけチェックリスト
| 2024/03/29 |
| Ruby
| 2024/03/27 |
| Kubernetes
| 2024/03/22 |
| 音楽データをDisplayAudioで聞く
| 2024/03/09 |
| Redmine
| 2024/02/05 |
| git
| 2024/02/02 |
| 経済
| 2024/01/08 |
| どうする家康
| 2023/12/17 |
| MX-Linux
| 2023/11/06 |
| 國體関連学-休学のご連絡
| 2023/08/13 |
| Debian
| 2023/08/02 |
| CentOS
| 2023/06/13 |
| Dell-XPS13
| 2023/05/23 |
| ベルト
| 2023/05/18 |
| SourceForge
| 2023/04/17 |
| 確定申告
| 2023/02/19 |
| さらば「まぐまぐ」
| 2023/01/09 |
| 風猷縄学
| 2022/11/23 |
http://gettingreal.37signals.com/GR_jpn.php より、腑に落ちた一節:
机上の空論に夢中になっている人の話を聞くのはおかしい。（彼等は、最もシンプルなアイディアを言うことに満足しているのだ） 私に言わせれば、アイディアは実行しないと意味がない。そう、乗数にしかすぎない。実行することで価値は何百万倍にもなるのだ。 説明: ひどいアイディア = -1 イマイチのアイディア = 1 まぁまぁのアイディア = 5 良いアイディア = 10 素晴らしいアイディア = 15 最高のアイディア = 20 実行しない = $1 ほとんど実行しない = $1000 まぁまぁ実行した = $10,000 結構実行した = $100,000 かなり実行した = $1,000,000 最も実行した = $10,000,000 ビジネスを行うには、この２つの掛け算が必要になる。 最高のアイディアでも、実行が伴わなければ、$20の価値しかない。最高のアイディアを最もよく実行に移せば、その価値は$20,000,000になる。 私が人のアイディアを聞きたくない理由が分かっただろうか。実現していないものには、何の興味も持てないのだ。
コピーライターとデザイナーを一緒に仕事させ、 サポートへの問い合わせが開発者に見えるようにします。
注: すぐ前の「細分化」という節では、一週間単位にプロジェクトを短く細分化 するよう勧めている。つまり、時間は細分化し、タスクの人員への割り当ては 細分化しないこと、ということだ。
ミーティングは本当に必要ですか？ ミーティングはコンセプトがはっきりとしていない時に起るものです。 ミーティングに頼る前に、メールやIM、「Campfire」のソフト等を使って、 議論しやすいようにコンセプトをはっきりとしておきます。 目指すところは、脱ミーティング。 ミーティングの時間を減らせば、その分もっと現実的な仕事ができます。
本気です。人を雇わないのです。他の道を探しましょう。 GEのCEOジャック・ウェルチは、誰かをクビにしても、 すぐに代わりの人間を雇わなかった。 そのポジションに人がいなくてもどれだけ問題がないのか知りたかったのだ。 この理論をテストするために人をクビにするのは酷ですが、 ジャックの言わんとしていることは考えるべきです。
未来のスタッフ雇用は彼等のオープンソースへの寄与から
我々はスペシャリストを雇うつもりはありません。 彼等のディテールのこだわりは半端ではありません。 我々のような小さなチームには、 そのような一部にとてつもない能力を発揮する専門化肌の人間は合わないのです。
ページの中心部分から始め、外側へ組み立てていく
一見、前節と矛盾しているかもしれない。 けれど、そうではない。I/F の中心から作っていく、ということなんだ。
中核デザインでは従来の「フレームを組んで、それからコンテンツを中に」というモデルを避けます。
Mac OS X のUIで、スティーブ・ジョブスによって大いに影響を受けたと思われる 一面は、セットアップと初回起動時の体験だ。 ジョブスは第一印象の重大性を鋭く見抜いていると思う。 ジョブスは初回起動時の体験に注意を向けて考えていると思う。 それはユーザーがMacで体験する全てのことの1000分の1のことにすぎないかもしれない。 しかしそれは最も重要な1000分の1なのだ。 なぜならそれが最初の1000分の1であり、 ユーザーの期待と第一印象を決めるのだから。
アプリケーションは制作者が作り、デザイナーがデザインし、 人々が使用して初めて現実するのです。 機能スペックはただの紙に書かれた言葉にすぎないのです。
「スペック」は役立たずと言っても過言ではない。 私は役に立つ正確なスペックを見たことが無い。 私はこれまでスペックに基づいて行われたくだらない仕事を多く見てきた。 そういうソフトウェア開発は最悪の方法だ。 現実ではなく理論に基づき築き上げられたものだからだ。 -- Linus Torvalds
不要なペーパーワークにさよなら 機能スペックから離れるのは良い出発点ですが、そこで終わってはいけません。 過剰なペーパーワークもやめます。 書類が現実の何かにならないのなら、作らないのです。
新しい機能やコンセプトについて言葉で説明しないといけなくなった時には、 それについての簡潔な話を書きます。技術やデザインを詳述してはいけません。 普段の会話の様に、人間的に伝えます。 ソフトウェア開発者の多くもその様な違いがあります。 デザイナーやプログラマーは言わば厨房、 サポートスタッフが顧客と直接接するホールスタッフです。 残念なことに、ソフトウェアのシェフ達は顧客の生の声を聞くことがないのです。 顧客に耳を傾けることは製品の強み・弱みを知る最良の方法であるに関わらず。 解決法は顧客と開発＆デザインチームの壁を取り除くところからです。 *サポートサービスをコールセンターや外の業者に投げてしまうのはいけません。 *自分でやりましょう。 あなた、そしてあなたのチーム全体が顧客の声を知る必要があります。 顧客の悩み事や不便と感じることを知る必要があるのです。 不満や批判に耳を傾け、顧客の気持ちに同情する必要があります。 37signalsでは、サポートサービスのEメールは、 実際にその製品を作っている人間が直接返答します。