私の同僚のザウアは、メディア出版を再開するプロジェクトの開発について話しました。 そのようなプロジェクトでのマネージャーの仕事の特徴についてお話したいと思います。
2007年以来、私はプロジェクトとして働いています。 Articul Media GroupのLebedev Studioで働いたのは、主に大企業（TNK-BP、Euroset、VTB、Samsung、OKOI Sochi-2014）でした。 2012年5月にLenta.ruに来て、再起動プロジェクトの最中にいたときまで、メディアでの作業経験はありませんでした。 新しいテープが2013年1月にオープンしました。 2014年3月、編集長が解任された後、私たちはVedomostiに移り、現在、再起動の準備をしています。
以下では、顧客として行動した編集オフィスで働いているときに出会った最も重要なポイントの概要を説明します。
TKは
古典的な形式（ボリューム、冗長、ただし網羅的）での開発用TKはまったく存在しないか、マグカップのスタンドとしてのみ使用されます。 これは、顧客とエグゼキュータにとっての本格的な作業ツールである可能性のある作業指示書のコンパイルには、両方の当事者の時間と参加が必要なためです。
顧客が編集オフィスであるとき、彼は重いTKを読み、編集し、苦痛について議論する時間がありません。 24時間年中無休のニュース出版物では、編集者は読むべきものとおしっこしないものがあります。 また、TKが厚い場合でも、プロジェクトの過程で多くの変更が行われるため、その関連性がすぐに失われ、役に立たなくなります。
しかし、ドキュメントなしでは何もできません。 テープでは、私がファイルに記録した口頭討論のすべての結果-次の形式の「ログ」：質問はそのようなものであり、それから議論し、そしてそうすることを決めました。 次は議論/変更履歴です。
並行して、タスクは開発者と話し合い、タスクマネージャーで修正されました。 これにより、簡単に触れられ、最終的な解決策をまだ受け取っていない問題を見失うことがなくなりました。 Vedomostiでは、編集ユニットに関するドキュメントに同じ形式のログファイルを使用し、GitHubのwikiに持ってきます。 これらのログから開始した後、システムの最終バージョンの説明を作成して、参照として使用できるようにします。
プロジェクト参加者とのコミュニケーション
ほとんどの場合、コミュニケーションのほとんどは口頭で突然行われ、新しい参加者はいつでもワーキンググループに参加することができます。 タスクマネージャーはタスクを交換しません。 郵送および会議開始時の会議結果の確認は必須ではありません。
理由は同じです-お客様は年中無休でニュースをお届けします。いつでも何でも起こります。 このようなコミュニケーションでは、プロジェクトの参加者の1人が1つのことを知っており、他の誰かが他のことを知っている可能性が非常に高くなります。 したがって、プロセスのすべての参加者の「同期」に努力を向けることは論理的です。
これは、口頭での議論の結果に続く文字で、ログファイルに記録することで行いますが、私が何かを思いついて話すだけです。 議論中の問題の重要性に応じて、この方法またはその方法を選択します。 質問が根本的に重要な場合-もちろん、この手紙。 些細なことなら、読む時間がない文字で人々をあふれさせないように、あなたはただ立ち上がって言うことができます。 通常の顧客には、コミュニケーションを組織し、手紙の受け取りなどを確認するマネージャーがいます。しかし、編集部にはそれがありません。 我慢する必要があります。 そして、これらすべての「正しい」管理手法で編集者を苦しめないでください-これは害を及ぼすだけです。
共通の分母とバランス
私の最も深い信念において、プロジェクトの重要な機能の1つは、顧客（この場合は編集スタッフ）の「人間的すぎる」思考と、プログラマーのあまりにも概略的な思考の「共通点」を見つけることです。 Zaurは例を示しました。普通の人は、1対1の関係から1対多の関係に移行するのに困難を感じません。 より正確には、普通の人はこの移行をまったく見ません。 プログラマーはそのようなことを考えないでしょう。
そのような場合それぞれにおいて、顧客がプログラマーの頭の毛を作る何かを望むとき、あなたはそれを別々に理解する必要があります。 編集タスクを上回ると、完成した作業の一部を破棄し、他の部分を完全にやり直す準備ができている必要があります。 開発者が正しければ、編集オフィスの「ウィッシュリスト」の実装は、1週間以内に熊手で行われます。 そして編集部はそのような「ウィッシュリスト」を放棄しなければなりません。
これはマネージャーにとって何を意味しますか？ マネージャーにとって、これは次のことを意味します。a）タスクのセマンティックおよび技術的側面を常に調査する必要があります。 b）共通分母を見つける。 c）編集部の希望と開発の利便性と正確性の間のバランスを維持する; d）何ができないのか、何をする必要があるのかを説明できる。 顧客として機能する編集オフィスで作業する場合、これは特に重要です。編集オフィスにはさまざまな要望があるためです。 それについて-さらに。
「そこでボタンを1つ作成しましょう」
月ごとに存在し、大規模なアーカイブを持たないプロジェクトでは、通常、いわゆる「パッチワーク自動化」の「魅力」に遭遇することはありません。 または、「魅力」には、自分自身を顕現する時間がありません。 しかし、それらは5年以上生きており、巨大なアーカイブがあるプロジェクトの力と主なものとして現れています。
これはマネージャーにとって何を意味しますか？ マネージャーにとって、これは、将来、開発者が突然出現した「クランチ」の修正に時間を費やす必要があることを意味します。 彼らは、最も適切でない瞬間に出てくるでしょう。 そして今回-費用は、貴重なものの生産ではなく、彼ら自身が掘った穴にパッチを当てる費用です。 これを理解し、このようなことをするよう求められるたびにリスクを顧客に説明する必要があります。
開発者とタスクの実装の可能性について議論するとき、これを念頭に置くことも同様に重要です。 すべての開発者が同じように先見の明があるわけではなく、松葉杖を作ることに同意する場合もあります。 長期的には、このアプローチは多くの問題を引き起こします。 あなたがサポートするためにますます多くの人々を必要とする巨大で食いしん坊の構造で終わるリスクがあります。 開発者は、新しいものを作成して開発する代わりに、座って松葉杖に浸り、最も不快なことに退屈します。 そして、あなたは誰もが仕事で詰まっているように見える、彼らは働く、彼らが行う、彼らが行うが、...彼らは何とか何もしなかったことを理解するでしょう。
控えめに言っても、この状況は目新しいものではなく、編集者との共同作業だけではありません。 しかし、編集者との共同作業では、出版物の技術部門がサービス部門であるため、成長する機会がありません。
人間の顔プログラマー
「ログ」側からではなく、単純なユーザーの側から問題を確認する機能は、編集スタッフと協力する場合に特に重要です。 開発者に頭を下げて説明し、編集者に問題があり、不満を言ったら（そしてあなたがチェックし、問題が実際に存在するなら）、問題は本物であり、「ログ」ですべてが正常であっても解決しなければならないことを確信させます。 さらに、開発者が編集者と直接チャットできると便利な場合があります。
マネージャーは、開発者がエンドユーザー（エディターとリーダーの両方）を無視してコードを掘り下げないように、チームと定期的に「教育」作業を行う必要があります。 このコードは、ユーザーが満足している場合にのみ重要です。
マニュアルの習慣
編集部で発生する問題を解決するには、人間のプログラマーに加えて、マニュアルが必要です。 これを原則として、それらを書くことを学ぶ価値があります。 新しい機能を作成-マニュアルを更新しました。 夜間/リモートエディターが多いほど、ある時点で、たとえばWikiの記事へのリンクを単に提供することが必要になります。 マニュアルの形式は関係ありません。矢印付きのスクリーンショット、テキスト、またはスクリーンキャストです。主なことはそれを明確にすることです。 私は、リボンの新しい管理機能のマニュアルの作成を練習し始めましたが、これを絶えず練習することはしませんでした。 Vedomostiで計画を実現します。
合計
編集スタッフや出版物の他の部門と協力するとき（Vedomostiではこれはサブスクリプションを扱うための商業単位でもあります）、多くのことを行う必要がありますが、理論的にはマネージャーはすべきではありません。 マニュアルを書いたり、ビジネスプロセスの図を描いたり、電話でinしている人を安心させたりする必要があります。 これはすべて、出版物の技術部門が小さく、デザイナー、テクニカルライター、ビジネスアナリスト、テクニカルサポートオペレーターの軍隊がいないためです。 そして、これらの人々の機能をある程度実行する必要があります。
顧客が編集スタッフである場合、多くの標準プロセス（たとえば、技術仕様の開発）が異なって発生し、プロジェクトの段階は異なる順序になります（たとえば、最初に設計し、次に設計、プロジェクト構造に依存します）。 またはまったく起こらない。 そして、これは正常で良好であり、出力は想像以上に優れた結果をもたらします。
重要なのは、編集委員会は非常にやる気のある顧客であり、彼らは本当にすべてを必要とし、結果が気に入った場合、経営陣は「それをまとめる」ことはできず、編集長は彼の決定を打ち破ります。 これにより、さまざまなレベルのti病なマネージャーの承認や改訂に行き詰まることなく、クールな製品を手に入れることができます。