豚の植え方



再びお金を集める問題に直面して、我々はどんな既製のソリューションが市場に存在するかを見ることにしました。 既存の製品の分析を行い、それらの欠点を特定し、独自の製品を作成することにしました(結局、ITでは「バイク」は常に近くにあります)。







この短い記事では、チームを結集し、大企業内の関連部門とやり取りし、一見してニーズに合った既製のソリューションを使用しようとする経験を共有したいと思います。









チームの集まり:







最上部でのプロジェクトの承認と製品所有者の登場の後、「誰がやるのか」という疑問が生じました。 利用可能な手順に従って、タスクは異なるグループ(フロントエンド、バックエンド、データベース)に分散する必要がありました。 さまざまなタスクキュー、優先順位、所有者。 少しずつ。







フロントエンド-小さなフォームのサイトでは統合が必要でしたが、最初は問題がありませんでした-リソースがあり、数週間ですべてを行うと彼らは言いました。 しかし、喜びは長続きしませんでした-明らかに、惑星のパレード、満月、その他の神秘的な出来事の合計によって(私たちは確かにそれを認識しませんでした)、私たちは「閉じたクラブ」に入ることを許されませんでした。 リソースは発行されず、タスクは後まで延期されました。







バックエンド-ここでは簡単でしたが、すぐにリソースがなく、近い将来にはなくなると言われました。







プロダクトオーナーは、「リソースがいつになるのか」、「スプリントをいくつかハイライトするかもしれません」など、さらに先へ進む意欲を失いました。 その後、彼女は一般的に私たちに不満を言いました-腐敗。











しかし、成功のために元気づけられ、どのプロジェクトもどのチームでも実行できると言われたアジャイルトレーニングが成功した後、チームがプロジェクトを作成することにしました。これは間接的にWeb開発に関連付けられています。 このようにして、小さいながらも誇りに思うチームの物語が始まりました。







開始:







新しいプロジェクト管理フォーマットを試すために、トップでゴーサインを受け取ったので、始めました。

バックログを収集し、役員会を立ち上げ、MVPについて話し合い、役割を配分し始めました。







各参加者にはチームにとって有用な役割があるはずなので、後者には好奇心が出てきました。 私の意見では、これはこのアプローチのプラスです。「必要な」人だけがチームに残っているからです。 たとえば、マネージャーはテスターに​​なりました。







通常2週間は社内にいるという事実にもかかわらず、私たちは毎週のスプリントを選択しました。 後で判明したように、それは無駄ではありませんでした-短いスプリントはプロジェクトにプラスの効果をもたらし、チームは作業の進行状況をより頻繁に認識し、プロジェクトの周りの変更を考慮して影響を与えるのが簡単でした。







突然、問題の1つは、毎日の朝の会議に時間通りに来るようにすることでした。 なぜお菓子の形で遅れた税が導入されたのか、その結果、チームは少し体重が増えました:)







テクノロジー:







製品は社内の製品の一般的な概念に非常によく適合しており、既製のソリューションとアーキテクチャを最大限に使用したいと考えました。 しかし、最終的に、既製の「自転車」を使用することの主な苦痛は、それがしばしば一輪車であり、右にしか乗っていないことであり、何人かの人々はペダルを回す方法を知っていました。











フロントエンド:







サイトでの実装のためのリソースを待たないために、私たちにとって最良の選択肢は、製品用に独自のサイトを作成することでした。







サイトの開発のために、SPAの束であるReact JS Reduxがアーキテクチャの基礎として採用されました。

NodeJSを台無しにしないために同形アプリケーションを放棄することが決定されました(ノードなしではできませんでした)、SPAはこの点で有利に際立っていました。







最初は、すべてがうまくいきました。 アプリケーションはますます多くの機能を獲得し、チームに自信を与えました。 ISペンテストの後に問題が始まりました。 承認スキームにアーキテクチャエラーが含まれていることが判明しました。 これにより、複数のユニットにまたがって実行すると同時に、近隣のプロジェクトで同様のスキームを拒否しました。 しかし、解決策は最終的に見つかりました。







次に踏んだレーキはSEOです。 ロボットは、JavaScriptレンダリングの操作方法を知りません。 その結果、2つのオプションがありました。









NodeJSは、静的をロボットに配布するために使用されました。







バックエンド:







バックエンドにはほとんど必要ありませんでした。フロントからの要求を受け入れ、データベースを操作し、QIWIループ内の他のサービスと通信します。 負荷はメインサイトのように置かれました。 プロジェクトは、環境の機能の一部が既製のマイクロサービスに引き継がれたため、社内でのマイクロサービスアーキテクチャの積極的な実装の波に乗り、開発時間を短縮できました。







要件と機会を評価した後、「何を書くべきなのか?」という疑問が生じました。 応募者の中には、Java、NodeJS、Golangがありました。









その結果、管理者はアプリケーションを構築および展開する方法を知らず、IBにはコード分析用のツールがなかったため、Golangが選択されました。 しかし、もちろん、すべての問題は結果として解決されました。







PostgreSQLがベースとして選択されました-データを保存するタスクに対応しており、これで十分でした。







テスト:







チームには当初プロのテスターがいなかったため、ある時点でテストのための多くのタスクが蓄積され、緊張し始めました。 実際、これはアジャイルの初心者にとっては古典的な状況でした。つまり、1か所でタスクがブロックされるため、開発を続ける前に掘り下げる必要があります。 しかし、私たちは出口を見つけました: 得点 アジャイルから撤退し、仕事を続けました。











その結果、テスターをチームに連れて行かず、QAチームをサービスユニットとして使用して、テストのタスクを提供しました。 予期せぬことに、このアプローチは成功しました。アウトソーシング担当者は非常に迅速かつうまく製品を完成させ、多数のバグを見つけてボードに新しいステッカーを追加しました。 プロジェクトが生産に向けて動いているという喜びと理解をもたらしました。







実行方法:







パイロットのローンチは社内で行われ、オファー、要望、バグを収集することができましたが、全体的にレビューは好意的でした。 prodですべての重大なバグを直接修正したので、実際のユーザーで既にテストして、メインサイトから少しのトラフィックを送信しました。 その後、ユーザーに電話をかけ、製品に関する小規模な調査を実施しました。 この製品はユーザーにとって理解しやすく有用であることがわかりました。 さらに、彼らは私たちにいくつかのより良いアイデアをバックログに投げ入れ、ユーザーの生活をさらに簡単にする改善を備えたプロジェクトの第2段階をスケーリングしてすぐに開始することにしました。







結果:







プロジェクトの過程で、プラス面とマイナス面の両方がありました。 チームと一緒にこの道を歩き、私は自分にとって非常に貴重な経験を得て、いくつかの結論を出しました。







  1. アジャイルは、製品を起動するための非常に便利なツールセットであることが判明しました。
  2. しかし、アジャイルの実装のために、ユニットマネージャーは役に立たないことを認めなければなりません。
  3. 関連チームでは、人々も働きます。
  4. しかし、彼らは長い間会社で働いているという事実にもかかわらず、より頻繁にあなたはこれらの人々を異なる方法で見始めます。
  5. ISはその文脈にあり、何をする必要があるのか​​、またその理由は必ずしも明確ではないので、もう一度尋ねて明確にする方が良いでしょう。
  6. 新しいことを恐れず、あなたが決してしなかったことをしてください。
  7. SPA、React、Redux-優れたファッショナブルですが、NodeJSはどこにもありません。
  8. Goは、軽量で、高速で、安定しており、重要ではない製品に完全に適合します。
  9. 定期的に立ち上がることは、遅れをとらないための良い習慣です。
  10. 決定がまとめて議論され、行われると、各チームメンバーは自分の貢献を感じます。
  11. 毛づくろいは犬の毛づくろいだけでなく、活動を計画する素晴らしい方法でもあります。


PS







この男は何について書いており、「豚」はそれと何の関係があるのでしょうか? 私は新製品についてです。 QIWI Piggy Bank-シンプルで便利な団体募金サービスです。 テーマ別の貯金箱を作成し、リンクを友人と共有してそれを補充するだけです。 追加の詳細はありません。








All Articles