実現経験 パート2/2

弊社の例による37signalsからのRealingアプローチの実装の経験に関する記事の2番目の最後の部分。 昨日公開開始。

制限のヘルプ

小さな会社の欠点の1つは、大量の作業を迅速に完了できないことです。 たとえば、多数のグローバルな変更を含む新しいバージョンの製品を準備している場合、大規模なチームでは小規模なものよりもはるかに迅速に対応できます。 そして、私たちが小さい場合、製品の出力が遅れ、競合他社はイノベーションの類似物をより早くリリースし、一部のパートナーは待つのにうんざりして競合他社に行きます。



実際、「朝のビールは有害であるだけでなく、有益である」というよく知られていることわざとの類推により、限られたサイズが役立ちます。 私たちがやりたいことを何もできないので、どうにかして出ることを余儀なくされます。 タスクを細かく分割し、重要性の低い作業を後で残し、目標をより速くより良く達成する方法を探します。 これにより、作業効率と効率が大幅に向上します。



バージョン4.5の構成を決定したとき、私たちは3つのソースからアイデアと願いを集めました。パートナー、従業員、経営陣です。 大きなモジュールのみが18個を獲得しました。 予備的な見積もりによると、少なくとも1年は開発する必要があります（そして、今ではもっと長くなっていたことを理解しています）。 それから、私たちは何をするのか、そして「後で」延期するのかを決めることができる評価方法を思いつきました。



この方法は非常にシンプルで非科学的です。 各タスクを評価する3つの基準を策定し、各タスクには0から3までのポイントが与えられました。 これらは基準です：

1. これを行うと、売上が増加しますか？ 0-おそらくそうではない、1-ありそうもないが、おそらく2-おそらくそうだ、3-間違いなくそうだ。
2. このことから判明する情報の機会はどれほど重要ですか、この機能の存在によって潜在的なパートナーやオブザーバーに興味を持たせることができますか？
3. これはどれくらい速くできますか？ 0-数か月、1-1〜2か月、2-3〜4週間、3-2週間まで。

この表のスニペットは次のとおりです。

機能的	お金	情報ライン	スピード	合計
新しい検索モジュール	2	1	0	3
モジュール「minimagazin」	3	2	1	6
モジュール「マイアカウント」	2	2	1	5
ウィジェット埋め込みプラットフォーム	2	2	1	5
Tag Cloudモジュールの変更	0	0	2	2
オンラインストアモジュールの変更	3	3	0	6

その結果、合計18ポイントに基づいて、最も高いポイントを獲得した8つを選択し、さらに3つを議論し、5つを獲得した後、開発を開始しました。 新しいモジュール「Minimagazin」、「削除されたオブジェクトのバスケット」、「マイアカウント」、モジュール「サイト検索」の完全な変更、サードパーティサービスのウィジェットを埋め込むためのプラットフォーム。 これらのうち、私たちの期待を完全に満たすことができなかったのは1つだけであると言うことができます（これは、「カート」モジュールで、思ったほど人気が​​ありませんでした）。 残りの13のタスクのうち、次のバージョン4.6で2つをリリースしました。近い将来に2つを実装し、残りの9つはこれまでのところ実行しないことに決めました。 常識によると、それらは最近登場したいくつかのタスクほど関連性がありません。



そして、スタッフが18のポイントすべてを実現できるとしたらどうなりますか？ 私たちの時間の半分は、最終的には役に立たない、あるいは有害でさえあることが製品管理を複雑にすることに費やされることになります。 もっと多くのお金を使って、もう少し便利になります。 そして、すべての新しいタスクは長い列になります。



上で書いたように、会社の規模が小さいことは、従業員が専門的に成長するのに役立ちます。 制限もこれに寄与しています。 今年の初めに、1つの副産物のインターフェイスを開発する必要に直面しました。これは来年リリースする予定です。 このタスクは最も緊急のものではなく、十分な時間がありました。 プロのインターフェイスデザイナーを雇うこともできますが、そのようなスペシャリストのプロ意識を評価する方法はわかりません。 専門の会社にこの作品を注文することもできますが、その価格はかなり高いです。



その後、技術仕様の開発に携わり、設計の経験を積んだ人は、インターフェース設計の原則を研究し始めました。 私はいくつかの本や記事を読んで始めました。 インターフェイスは何度も再設計および調整され、現在でも変更が加えられていますが、必要なものが得られ、従業員は専門的なスキルを身につけました。 もちろん、数冊の本は人を専門家にしないと言うことができます、そして、彼は何年もの間この問題を扱っている専門家と比較することができません。 これはそうです、私たちは悪い結果を招き、経験を節約しました。 しかし、私たちのケースでは、インターフェイス設計の分野でロシアの大手企業の監査に中間ステップを与え、それが私たちの間違いを修正します。



そして今、私たちはインターフェース設計がはるかに優れており、次のそのようなタスクはより簡単になります。



制約は、作業の質も向上させます。 サイト管理システムに加えて、私たちよりも大きな会社である市場における当社の主な競争相手は、さらにいくつかのタイプの製品を生産しています。 新製品の発売とメンテナンスには多額の投資が必要なため、他に何もすることがないため、主要製品の開発に焦点を当てて競合他社の手順を繰り返しませんでした。 「狭い」製品は、設計段階、販売段階、およびサポートの両方で、制御がはるかに簡単です。



制限が利益だけを意味するものではないことは言うまでもない。 より多くのお金または労働者またはマーケティングツールがある場合、これは一般的に優れています。 営利会社と同様に、利益を増やすことが私たちの主な目標です。 リソースが限られているために、大規模な機能をすぐに立ち上げたり、興味深い会議のスポンサーになったり、大規模な広告キャンペーンを注文したりすることはできません。 私たちはこの問題に哲学的にアプローチしようとしています。 あなたが本当に必要な場合-あなたは少し自分自身を行使し、合理的な量のお金を見つけることができます。 うまくいかない場合は-次回はうまくいきますが、今のところ、利用可能なリソースをより効果的に管理する方法を学んでいます。

仕様を作成しないでください

昨年、私は「参照条件-プロジェクトの礎」というタイトルのレポートを作成し、いくつかの都市でそれを読みました。 レポートの主なアイデア：可能な限り詳細な技術課題を作成し、すべての利害関係者と調整し、将来はそこから一歩も踏み出さないでください。



今、私はこのアプローチの正確性についてあまり確信が持てません。 少なくとも内部プロジェクト（サードパーティの顧客用ではなく、自分用に作成されたプロジェクト）の場合、これは間違いです。



仕様に関するGRの章を読んだ後、私は最近書かれたいくつかの技術的課題の回顧展を、それらがどれだけ需要があったかというテーマで行うことにしました。 37の信号は絶対に正しいことがわかりました。私がTK、機能要素のリスト、フローチャート、およびデータ回路のコンパイルに費やしたほとんどすべての時間は、実際に誰も使用しなかったために無駄になりました。 最後の例は、検索モジュールの技術的なタスクです。ここでは、操作スキーム、データ構造、他のモジュールとの相互作用インターフェースについて詳細に説明しました。 私は細心の注意を払ってこれを行いました。 モジュールはリモート開発者によって作成されました。 その結果、モジュール制御インターフェースが説明されている部分、つまり設定と出力画面のみが彼にとって有用でした。 彼は残りの章を調べましたが、自分のやり方でやりました。 彼はデータベース構造に関する章も読んでいませんでした。 つまり、画面のプロトタイプを描画するだけでなく、モジュールが行うべきことを一般的な用語で記述することにより、文書の80％を削減できます。



それ以来、APIの説明など、本当に必要な場合を除き、非常に少ない数のドキュメントを詳細に記述しています。 うまくいくものを描いて、それがどのように機能するかについてのあなたのビジョンを簡単に書く（あるいは伝えることさえする）方がはるかに効率的です。 グローバル評価を行うのは時期尚早ですが、中間結果は品質が劣化していないことを示しています。 そして時間が自由になりました。



仕様について言えば、成長の問題について言わざるを得ません。 私が知っているほとんどすべてのデザイナーと開発者は、数十人ではなく数十万人のユーザーが使用する場合、または格納されたオブジェクトの数が数百万のドキュメントにある場合に、製品のアーキテクチャを成長させて不快にならないようにすることをお勧めします。 本物の著者を取得することは、それが起こるまで忘れることを勧めます。 この問題は心地よい問題ですが、ほとんどの企業はこのような深刻な成長を達成することはありません。 なぜ役に立たないものに時間を浪費するのですか？ そして、あなたがまだ便利になっているなら-それで、あなたはそれについて考える必要があります。



私たちは、そのような状況に気を取られないようにし、そのような状況が発生したときにどの程度おおよそ行動するかを念頭に置いています。 これらの理由で当社の製品が適合しないユーザーがいる場合は、別の製品をアドバイスします。 または、そのタスクのために製品を「仕上げる」方法について開発者にアドバイスを行います（これはすでに複数回行われています）。 そして、そのようなアピールの流れが具体的なものであれば、この問題に密接に対処します。



最後に、仕様に関する最終的なGRの論文：ささいなことは忘れてください。 この画面の設定にはどのような特定のポイントがありますか、画像のプレビュー間にどのくらいの距離がありますか、リスト内の何行のデータが表示されますか？このような質問が実際に発生するまで考える必要はありません このアドバイスに従うことは、それほど長くはありませんが、私たち自身の実践が示すように、これは確かにそうです。 ライブプロジェクトでは、半製品であっても、意思決定は設計段階よりもはるかに簡単で正確です。

成功しなかったもの

「ベータ版は必要ありません。 バージョンは1でなければなりません。」 私たちの場合、サービスを作成するのではなく、スタンドアロン製品を作成するため、バージョン管理なしで行うことは困難です。 ユーザーにコピーの更新を強制することはできないため、バージョン管理を維持する必要があります。 ベータ版に関しては、最も重要なリリースをテストのためにパートナースタジオに提供します。つまりベータ版です。 この場合、バージョニングにはもう1つの利点があります。マーケティングです。 機能とモジュールが作成されたときにリリースすることにより（製品開発の観点からは完全に正しい）、1つのパイルでいくつかの大きな変更を収集し、これにラウンドバージョン番号を割り当て、それに関するプレスリリースを送信する機会が失われます。 これは考慮される必要があります。



「何かをして、速く行きましょう。」 これはスタートアップにとって完全に真の原則です。リリース/プロジェクトに含まれる新機能を作成しました。 しかし、そのような開発サイクルへの切り替えはまだ成功していません。 理由の一部は客観的です。私たちはスタートアップではありません。製品は十分に大きく、長い歴史があります。 そして主観的な理由は、私たちとパートナーの両方が特定の開発サイクルに慣れているからです。 自分自身を破ることは非常に困難です。



「選択してください。 設定を放棄します。」 プログラマーは設定が大好きで、ユーザーはプロファイル（定義済み設定のグループ）が大好きです。 たとえば、「News」コンポーネントを開発する場合、プログラマーは「アナウンスメントを表示するかどうか」、「ページのリストを表示する」、「リンクを見出しまたは単語に全文で入れる」設定を入力します。 ユーザーは、フルまたはショートのプロファイルから選択する方が便利です。 そしてユーザーは正しいです。 私たちはまだ設定を無効にすることができませんでした-私たちの製品は非常に柔軟であると考えており、このプロパティを奪いたくありません。 昨年、システムに「コンポーネントテンプレート」の概念を導入し、この問題を部分的に解決しました。 したがって、この面ではまだ途中です。



「開発とサポートを共有しないでください。」 開発者の現実からの分離は悪いです。 あなたが、サイト開発者から、CMS開発者として再訓練されたとき、あなたは製品を作っている人々のように考えることをやめます。 開発とサポートの組み合わせは、この変換の欠点を相殺するのに役立ちます。 一方、サポートのコミュニケーションはプログラマーを頻繁に切り替えさせ、リズムを崩し、不快感を与えます。 したがって、開発とサポートを分離しようとしています。 一方、従業員の1人がWebサイトを作成してパートタイムで働いていても構いません（もちろん、仕事に対する偏見はありません）。



「ユーザーにノーと言う。」 ...イノベーションを求めるとき。 理論的には、これは正しいです。 製品を製造する場合、他の製品よりもよく知っている必要があります。そうでなければ、単に革新的で優れたものにすることはできません。 ユーザー（およびパートナー）は現在のニーズを解決したいと考えており、将来関連性のあることを実行する必要があります （傾向を推測して作成しないとさらに良くなります-Appleは嘘をつきません）。 私たちのケースでは、日々の要件を系統的に無視するために、パートナーの満足度に依存しすぎています（Webスタジオやフリーランサーによる売り上げが売り上げの90％以上を占めています）。 したがって、多くの場合、私たちの見解とパートナーのビジョンの間を行き来する必要があります。



「トレーニングを必要としない製品を作成します。」 また、理論的にはこれは素晴らしいことですが、私たち（サイト管理システム）にとっては実装が困難です。 オンラインサイトのデザイナーは、エンドユーザーに焦点を合わせているため、これに努力する必要がありますが、このクラスの製品は開発者向けです。 開発者は、ドキュメント、ビデオチュートリアル、およびサポートサービスのコンサルティングなしで、システムAPIが提供する機能を使用せずにテンプレートプロジェクトのみを作成できます。

おわりに

私たちは、GRを面白いおもちゃや他の新しい管理手法とは考えていません。 人生の12年は深刻な時期であり、その間に企業は大企業に成長するか、死ぬか、停滞します。 停滞の理由は通常、経営者が通常の仕事の原則を変え、変化する市場に適応することをためらう、またはできないことです。 日常的な作業、ふくらんでいるドキュメント、長いプロジェクトがこれに非常に貢献しています。 GRは、そもそも不要で二次的なものを取り除き、プロジェクトへの関心を失わず、個人的および専門的な開発にとどまらないようにします。



過去1年間について言えば、GRを実装した後、作業効率が何パーセント向上したか、または工数をどれだけ節約したかは言えません。 主な効果は感覚のレベルです。 例：

• 小規模なスタッフと非公式の管理慣行は欠陥であると考えるのをやめました。 自己認識と自分のモチベーションに大きく影響し、誤った目標を取り除きます
• 従業員または請負業者に彼らの仕事のプロセスに関するビジョンを課すことをやめました。 専門的な信頼がなければ、まったく協力しない方が良い
• 横から見ることにあまり関心がなくなりました-もっと重要なのは自分自身をどう見るかです
• 開発がはるかに管理しやすくなりました。 問題の定式化からその解決までの時間が大幅に短縮され、迅速な結果は非常に刺激的です
• 設計時、効率が大幅に向上し、独学と研究の時間がありました

そのため、Getting Realを実装した経験は間違いなくプラスです。 あなたが私に興味を持ち、GRを自分で試してみたいと願っています。