Handytime Timecodeオンラインストア

少し前まで、オンラインゲームのファンのために新しいオンラインストアを立ち上げました。

Valvetの従業員が開発プロセスに関する記事を執筆しました。これが彼のストーリーです。

こんにちは

ゲームタイムコードのオンラインストアであるHandytimeプロジェクトに注目してください。投稿を読んで、サイトにアクセスして意見を述べていただければ幸いです。

多くのテキストが判明しました。同僚にとって興味深いものになるように、開発プロセスについてさらに詳しく話したかったのです。

店について簡単に

現時点では、Handytimeを使用すると、ゲーム通貨のタイムコードとキーを購入できます。

他のオンラインゲームストアとそれほど違いはありません。

迅速な購入（注文は1ページ内で行われます）;
注文には登録は必要ありません（後で実装されます）。

この店は最近立ち上げられました。これまでのところ、幅広い品揃えと支払いシステムの長いリストを誇ることはできませんが、まだ先を行っています。

計画の開始

プロジェクトの作業は、チームが集まる前から始まりました。そのため、将来のメンバーがオンライン取引に興味を持つようになりました。私たちはすべてゲーム業界で働いているため、当然、ゲーム市場の主要な代表者に主な注意が払われました。

私たちはそれぞれ、状況について自分の意見を述べ、その後、実際にチームに集まりました。私たちは：

私は、プロジェクトマネージャー（契約書、事務処理、その他の官僚機構、およびコーダーを蹴る）として;
2人のWebプログラマー。

まず、「グローバルな」行動計画を策定することにしました。今後は、「グローバリズム」で興奮したと言います。

計画では、次の主要なポイントを特定しました。

プロジェクトの目標;
対象読者;
USPおよび主な機能。
基本的な機能;
計画された支払いシステム。
計画された広告。
開発の段階。

これは完全なリストではなく、最も標準的なトピックのみを強調しています。また、各項目の詳細がドキュメントに記載されています。このような計画を立てることは、最初に新しい製品を作成する人にとっては本当に良いアイデアですが、慎重にアプローチする必要があります。次の問題が発生しました。

「夢の店」をどうするかについての誤解は愚かです（多くの同様のゲームの例があるので、それを理解すべきでしたが）。
計画と協力して、終わりのない議論になりました。

1ヵ月後のどこかで、紙の廃棄に苦しむのを止めて行動に移すことが決定されました。ドキュメントを現在の状態に修正し、主要な要素を基礎として、プロトタイプの作成に進みました。

しかし、最初に、別のレーキ。

CMS

ストアエンジンの選択についてお話しします。私たちに100％当てはまる状況の例を見た記事は見つかりませんでしたので、簡単に説明します。

したがって、最初からストアを作成するか、既製のcmsを作成するかを選択できない状況がありました。後者が必要でした。そして、この問題で主な間違いを犯しました。開発者の言葉に基づいて、cmsの機能を単純に比較しました。一般的にcmsで利用可能な機能のうち、それが私たちにとって有用であるとは思わず、レビューを探しませんでした。

その結果、WebAsystの非常に優れたShop-Scriptエンジンが選択されました。

問題は、大部分のエンジンと同様に、Shop-Scriptは小売店のある本格的なオンラインストアに焦点を当てており、それほど拡張性がないためです。

機能の冗長性、およびその結果としての冗長コード。
新しい機能の追加に費やす時間の増加。

物事は明らかなように見えますが、実際、誰もこれについて考えることはめったにありません。

試作機

プロトタイプの作業では、現在人気のあるスクラム方法論を使用しました。この方法では、会社の主任の責任者が私たちを助けてくれました。この方法論に対するほとんどのプログラマーのよく知られた敵意にもかかわらず（少なくとも、当社の経験によると）、スクラムは実を結びました。プロトタイプは1か月で完成し、ほとんどリーダーシップを発揮しませんでした。

この段階では、次の2つを除き、機能やエラーを特定することは困難です。

私とチーム全体に対する製品のビジョンは一致していましたが、特定の機能の実装が異なるように見えたため、将来多くの問題が発生しました。
私にはリーダーシップの経験がなく、将来的にも影響を受けます。

開発

実際、主要な作業が開始されました。私たちはそれに損失を出してアプローチしました。プログラマーの一人が脱落し、別の方向に切り替えました。

経営陣によって定められた期間は、短い月で1か月でした。

実際、4つになりました。

「軍事評議会」で、私たちはプログラマーが実績のあるスクラムから離れるべきではないと決定しました。「昨日は必要だった」という原則に取り組みました。

この段階で発生した多数のエラーについては説明しません。エラーが多すぎます。私は、開発時間に影響を与えた主な2つだけについてお話したいと思います。

期限を誤って設定しました。
デザインスタジオで作業する際のエラー。

期限はすべて平凡です。一般的な作業計画を作成するとき、タスクは月に収まるように設定されていたため、小さなタスクは破棄し、作業中に解決されると単純に信じていました。

さらに、プログラマーとの誤解が生じました。タスクの要件を完全には詳しく説明しておらず、プログラマーは彼の裁量でこれらのギャップを実装しました。その結果、一見既成の機能の議論とやり直しに時間を費やす必要がありました。

デザインスタジオは、私にとって非常に有益な状況であることが判明しました。彼らはすでに私たちの会社のためにいくつかの注文をしていたので、私は彼らを前もって良き友人だと考え、それに応じて彼らと連絡を取りました。仕事のスタイルがフレンドリーからフォーマルに変わって初めて、仕事は生産的になりました。

私たちは彼らの仕事の最終結果が好きで、今それが好きだとすぐに言いたいです。ちょうど今、ビジネスでは友情に頼る価値がないことを理解しています。

合計

実際、結果として、現在の形式で作業ストアを取得しました（記事の最後に、現在の機能を実証しようとしたスクリーンショットがあります）。

厳しい現実が私たちの代わりになったので、私たちは店の立ち上げに喜びを感じる時間がありませんでした-私たちは仕事が始まったばかりであることに気付きました。私たちはスクラムを去りました。事実は、現在の作業スタイルでは初期開発時ほど正確な計画を必要としないため、かんばんに来ました。

次のタスクから：