Tutu.ruに入社する前は、ERPプロジェクトのITコンサルティングとカスタム製品開発で働いていました。ここでは、内部製品Aviaのシステム分析に従事しています。 システム分析部門は、9人のアナリストと1人のテクニカルライターで構成されています。 さらに私の経験では、分析の観点から活動の形式を内部製品開発に変更するときに、スペシャリストの頭と作業プロセスでどのような変化があるかを説明しますが、同時にプロセス全体がTutu.ruでどのように機能するかを共有します。
1.ドビーは無料です！ 分析における架空の枠組みについて
カスタムカスタム開発（つまり、特定のビジネスタスクのプロジェクトの実装-ほとんどの場合（ただし、必ずしもそうとは限りませんが）ゼロから）または既存のITソリューションを実装するプロジェクトでは、アナリストは、その分野のコンピテンシーの第一人者である顧客の要件によって制限されますビジネスの方法論と法律、または実装されたソリューションの標準機能によって制限されます。 ローカリゼーションパッケージは、後者（ビジネスや特定の地域の法律に焦点を合わせた標準機能の追加部分）向けにリリースされることがありますが、状況を少し緩和するはずですが、率直に言って、それらはあまり役に立ちません。 そのような作業において、アナリストの仕事は、現在のアーキテクチャを壊さずに実装するのがそれほど難しくないソリューションを提案することです。 そして、これらすべては、基本機能によって課せられる制限内で繰り返します。
私は同意します、このフレーズは読むのがかなり退屈でした。 そして、これは創造性にとってはかなり狭い分野ですね。 それにも関わらず、創造性はここに存在し、制限は非常に奇妙で同時に機能するメカニズムを開発するインセンティブとして役立ちます！
製品のあり方：製品開発に切り替えたとき、絶対に何でも思いつくという考えに切り替えるのは簡単ではありませんでした。 長年にわたって獲得した本能は、既存の決定の枠組み内での行動を求めました。 結局のところ、それがあなた自身の製品に関して言えば、想像力をつなぎ、オプションと選択肢を提供する必要があります。 新しいプロセス、機能、および一般的な変更の作成まで。
この反射に対する戦いには時間がかかります。 最初は、ときどき、境界線、境界線、境界線の周りにいると思うようになります。 しかし、これらの境界は頭の中にしかありません。
Tutuでの仕組み：各タスクの作業の一環として、チーム、チームリーダー、製品の所有者（別名製品所有者、別名ソフトウェア）と可能な解決策について話し合います。提案された。 必要に応じて、ブレーンストーミングセッションを収集できます。他の部門（たとえば、コンタクトセンターやツアーセールスサポート部門）の同僚と意見やヒントを喜んで共有できます。
2.責任範囲について少し
常に確立された顧客がいる設計作業では（One Bigのフレームワーク内に個々の「サブ顧客」が何人いるかに関係なく）、多くの場合、この要件またはその要件が必要な理由についてあまり考える必要はありません。 顧客によると、これは受け入れられているビジネスルール、方法論、および以前に開発された機能と矛盾しないということです。 顧客は自分自身と彼のビジネスに反対しません！ したがって、システムアナリストのタスクには、ビジネスプロセスの詳細な説明、要件の収集と仕様、アーキテクチャのローカル調査、および場合によっては上記のすべての文書化が含まれます。
製品では、専門知識が内部にあることが多く、開発チームとして、ソリューションを実現するための独立性を高めるために、カルテブランシェが必要な場合もあります。 重要な新しい質問-概念的に何かを別の方法で行うことは可能ですか？ 本当に必要ですか？ 問題、問題、痛み、ニーズを他にどのように解決できますか？ これは最良の選択肢ですか？それはユーザーや企業にとって有用でしょうか？ 私たちは私たちの決定で誰かを助けますか？ これらは、アナリスト（および他のチームメンバー）として、分析の最初に考えるべき質問です。 ある意味で、同僚と私は意思決定において具体的な力に恵まれていますが、同時に非常に大きな責任を負っています。
Tutuでの動作：顧客（つまり、エンドユーザーの声）は、ほとんどの場合、製品（ソフトウェア）の所有者です。 しかし同時に、私たちのソフトウェアは開発チームの意見に注意深く耳を傾けていますが、決定点は彼らの側にあります。 彼らが言うように、1つの脳は良いです、そして6つはより良いです。 それが時々タスクを一緒に議論する理由です。 最終的に、私たちはすべて開発者であるだけでなく、最終製品を使用する乗客でもあります。
3.分析後の分析について
ソフトウェア開発プロセスのさまざまなフレームワークとモデル（ウォーターフォール、RUPなど）について言えば、これらは異なるアプローチと管理手法だけでなく、根本的に異なる文化と行動パターンでもあり得ることを覚えておく価値があります。 たとえば、コンサルティングでは、請負業者が、新しい重要な要件または新しい導入要件（忘れられている-これが起こる、大規模なプロジェクト）が作成され、新しい要件が示されていないときに、そのような作業量と作業範囲に同意した手紙を見つけることは非常に一般的です計画の一部として。 このような手紙は、現在の要件を考慮しない、プロジェクトの次の段階への開発を延期する、新しいタスクの一部として、および追加資金のための公式許可として役立つ場合があります。 つまり、極端な場合、義務は顧客の痛みの解決よりも高くなる可能性があります。そうでなければ、プロジェクトと計画の境界が無限に拡大する可能性があります。
アジャイル全体では （ここでは特に製品開発を主張していません）、新しい知識の出現により、行動と開発計画を過大評価し、変更することが可能になり、多くの場合必要になります。 この開発がすでに進行中である場合や、完了したばかりの場合でもです。 はい、これはあまり快適ではないかもしれませんが、システムアナリストを含め、災害ではありません。 ただし、重要な注意点として、すべての新しい要件を今すぐ実行する必要があるわけではありません。 新しい要件は、他のタスクのカルーセルで評価および優先順位付けする必要があります（たとえば、MoSCoWメソッドが役立ちます）。
Tutuでの仕組み：開発を開始する前に、できる限り完全に分析を実行します。これにより、開発者はそれぞれの分野の問題やテスターに対処でき、将来の機能の動作を正確に把握できます。 しかし、多数の利害関係者とさまざまなキャリアにより、タスクの新しい優先度要件が実際に到着することが起こります。
そのような場合、状況に応じて行動することができます：都合が悪い場合でも開発計画を変更する決定をすぐに行う（外部の状況が変わった場合、たとえば特定の期限のある運送業者の新しい要件が現れた場合）、または新しい要件のない最終バージョンを作成する、ただし、次のスプリント2の新しい要件でタスクを設定してください。 したがって、私たちは常識の枠内で分析の速度/品質のバランスで遊んでいます。
4.「参照用語」とドキュメントに関するいくつかの言葉
すでに、プロジェクトのドキュメントを処理および保存するための方法は12種類または2種類あります。 ああ、プロジェクト文書とその構造に関するこれらの要件... 文書は最新の状態に保たれ、どの従業員も任意の文書を参照し、そこで何でも修正できます（もちろん、著者、申請、変更の性質を示します）。 また、予定どおりに「サポートされない」場合、作業監査の改善は考慮されますか？
しかし、ここにはあなた自身の製品があり、突然-あなたはあなた自身とあなたの知識ベースのマスターです。 プロセス、製品、機能、要件の説明に一生懸命取り組みます-それは良いことです。 あなたがひどく書くならば、ひどくひどく、あなた自身を含む要件と説明でこれらのテキストを必要とする人々がいるでしょう。 誰も神殿の近くで銃を持って立ったり、死の痛みのもとでGOSTに従ってテキストを書かせたりすることはないという事実にもかかわらず、知識を文書化し、それを最適に行うことはあなたとあなたのすべての人にとって便利な方法です。
Tutuでの動作：さまざまなドキュメントを維持するために、Confluenceとローカル分析標準を使用しますが、タスク自体はJIRAで実行できます。 どれだけ必要で十分かについては同意します。会社では軽量のドキュメントが一般的ですが（不必要な詳細はありません）、一部のチームでは要件をより詳細に説明しています。 ドキュメントは（カスタム開発で発生する）調整ツールではありませんが、当社、開発チーム、外部の関係者（他の製品や部門の同僚など）が製品と機能の個々のブロックを完全に理解できるようにします。
5.柔軟性とパニック
時々、過去からのこの絵は、今日まで起こります。 バグが発生したため、すべてをドロップし、10分でロジックとコードをすばやく描画し、テストにさらに5分、実稼働環境にインストールするのにさらに5分かかる必要があります。 そして、別の同様のバグが到着していない場合、息を吐くことができます。 同じ会計を導入すると、毎月データ修正のためのいくつかの緊急の重要なタスクが到着しました-データは手動で修正できず、アカウント内の不正なデータで会計期間を閉じることができませんでした。 プロジェクト契約の下でSLAを思い出してみましょう。違反した場合、罰金を科されるか捕まることができます。 そして、ユーザーは心配している、私は再びそれらを心配したくない。
そして、これらの改善は深夜まで、午前1時まで続きます。システム管理者が自宅のコンピューターにアクセスして生産性の高いデータベースに格納し、ユーザーに「すべてが修正されたので閉じることができます！」 そして週末にも同じ...
しかし、違います。 それでも、ダウンタイムのコストが非常に高い負荷の高い製品について話していない場合、少しパニックする必要があるため、タスクを本当にブロックする製品では、非常にまれにしか発生しません。 標準的な状況では、ほとんどのバグ（誰もが主張しているわけではありません）は、ここで解決策を必要とすることはほとんどありません。すぐに解決できます。 ほとんどの場合、問題のあるタスクには単に高い優先順位が与えられ、プランまたはスプリントの他のタスクに比べてキューなしで移動しますが、同時に通常のリリースを通過します。
したがって、プロジェクトと製品の間にはそれほど違いはありませんが（ここでは違います）、ユーザー側と利用可能なデータボリューム側の使用済み機能の負荷の程度に違いがあると言えます。
とはいえ、正直に言って認めます。時々、長く忘れられていた反射が引き起こされることがあります-今、あなたは今すぐ、10分後にそれを売る必要があります！
Tutuでの動作：旅行サービスは非常に負荷が高いため、もちろん、「ブロックタスク」という概念があります。これは今すぐに行う必要があります。 それにもかかわらず、私たちは、より運用的なモードで実行しない限り、すべての必要なスタンドでの分析とテスターによる品質チェックを含む、すべての役割でこのタスクを実行しようとします。 これにより、リスクを特定し、将来の変更、コードの不必要な松葉杖、およびユーザーロジックの違反を回避できます。 他のケースでは、タスクに優先度「増加」が与えられるか、親のテスターによって監視されるバグバックログに移動します。
***
プロジェクトと製品のどちらが良いですか？ ここでは、「より良い」または「悪い」などの言葉は完全に不適切です;このITの世界では、一方と他方の両方に場所があります。 さまざまなアプローチの特徴を理解し、正しい期待を形成し、各プロジェクト/製品を個別に検討する価値があります。 一般に、私は自分の選択をしましたが、それを全く課しません。 誰もが自分の経験、背景、仕事に対する期待を持っています。 私-製品について、そしてあなたは-自分で決める。