開発プロセスを管理して結果を達成する方法

それは何ですか



これは短い投稿になります。 最初に個人的な話、次に従業員管理のためにそれをどのように実践するか。

純粋な経験、理論なし。



最初に、彼らはしばしば結果に取り組むことについて話します。 プロセスまたは結果に焦点を当てた人々について。 比率は95〜5と言われています。 すべてのプロジェクトマネージャーに、このテーマで素晴らしいビデオ Sergey Kotyrevを開始することをお勧めします。 ところで、他のビデオも見ることを強くお勧めします-セルゲイは困難な市場で成功を収め、彼が話していることを知っています。







ビデオは、周囲の人々(あなたが本来プロジェクトマネージャーである場合)が責任を取りたくない、多くの場合、あなたがしたであろう方法でタスクを行いたくない、および一般的に、あなたの観点からは効果的で効果がない質問に答えます。 それらは意図的なものではなく、人生をプロセスに向ける人々のまさにそのような性質です。



パーソナルケース



今私の話。 私は長い間、先延ばしの闇にさまよいました。 そして最近になってようやく、結果が正確に何であるかを自分で判断できないことがしばしばあることに気付いたため、異なるタスクの間で迷子になりました。 これは今ではありません。毎日、毎週、目の前に自分用に設定したベクトルがあります。 正確に言うと、 myTinyTodoを使用します 。 非常に便利なツールで、Excelのように柔軟で、あらゆるホスティングに使用できます。



アイデア、仕事を辞める前のタスク、1か月、そしてこのタブを開いたままにするたびに、好きなだけタブを作成します。 これにより、目標を回避できなくなります。 このような単純なケースですが、私にとってはすでに2年間機能しており、多くの同僚にとっては機能していました(人々は他のツールを使用しましたが、本質-私の目の前で物事のリストを見る-は同じままでした)。



そして今、プロセス指向の人々を結果に向け直す方法(または、むしろ、結果を達成するための方法、生きているそして現在の方法)に。 また、人生からいくつかのケース。 それらのほとんどすべてがプログラマーに関係しています(私は何十人ものプログラマーとチェーンをつないで仕事をしていますが、プロジェクト全体では、専門分野の異なる何百人もの人々が関与しています)。



人と一緒にいる方法



1. RERO



RERO-「早期リリース、頻繁にリリース」の原則(早期リリース、頻繁にリリース)。

それはあなたの思考プロセス全体を経なければなりません。 「非常に高価なデザイン、スーパープロジェクトを作成し、適切なアーキテクチャですぐにレイアウトする」レベルから「できるだけシンプルで安価にブートストラップし、できるだけ早く市場に出て、明確かつ迅速にフィードバックを収集する」レベルまで、 「進化し、収集されたライブデータと実際のビジネス要件のアーキテクチャをリファクタリングおよび再構築するためのポイントを強調します。」



そして、プログラマー、デザイナーなどの残りすべてがあなたのチェーンに並び、効果的に考えてプロセス全体を見るときに最も効果的に働きます。



人生からの例。 現在、ERPにメガコンプレックスレポートを埋め込む代わりに、最初に単純なバージョンを作成し、使用統計を収集します。 個々のプロジェクトのリリース率は最大10倍に増加しています。



制限を最大化する問題の簡単な説明(これについては上で説明します)(具体的には、普遍的ではなく、100500フィルターや普遍化を行わず、10のデザインを描く代わりに既製のブートストラップ組版を使用するなど)は、タスクを評価するときにプログラマーと他のすべての参加者の両方を提供します許容できる期間、これは結果を達成します。



2.タスクの実装からのボーナス



1人のプログラマーでは、実装に関して連絡を取ることができませんでした。 その後、実装された機能に特別なボーナスを割り当て始めました。 ボーナスは、箱入りソフトウェアのコピーの販売に対する支払いのように、シンプルで、明確で、明確です。

そして1週間後、同僚が機能の実装のトピック(これは一般的なプロジェクト間コンポーネントです)で私のプログラマーがなぜそれらを叩いているのかと私に尋ね始めました。 実際に、彼らはプログラマーを実装し始めました-結果を達成し、それによってボーナスを獲得します。 私は彼を誇りに思っています。



3.非質問+破砕タスク



通常、私は目標をオリンピアードに設定しようとします。 問題の本質、ユーザーのストーリー、入力、出力、確認するデータ。 もちろん、多くの人はこれを必要としませんが、最終タスクを設定し、最終リリースの外観と動作を示すと、必要なものを手に入れる可能性が高くなります。



別に、あなた自身がタスク(またはプレゼンター)を1〜2日のリリースで分割する必要があると言います。 そのように。 そして、Baduのようなリリースを提供できるようになります(1日に5回のリリースか、長時間視聴していない人が何人いるか)。



人生からの具体例。 歴史的に混chaとした2つの顧客ベースを複雑に統合する必要があります。 システム全体のアーキテクチャを念頭に置いて、回路の基本的なメカニズム(CRM側の改善)のみを説明します。 顧客関係のシステム全体(ホテル、ネットワーク内のホテルの組み合わせ、スーパーネット内のネットワーク、複雑なACLを含む)を説明する場合、決定の作成には1か月かかります。



また、問題の一部(ホテルとネットワーク、および単純なACL)を解決するための簡単な改善には2、3日かかり、プログラマーはそれらが完了したことを確認します。 タスクが有能に壊れているからです。



4.マーケットチェック



これはStratoplanのスタッフによるコースの1つで非常によく説明されています(後払い、INFA 100%)。 ポイントは簡単です-市場のアイデアをテストするために1000ドル以上を費やさないでください。 ターゲットを絞ったスパムを顧客に費やし、機能のリリースを待つためにメールを残す人の数を確認するのが最善です。



このタスクを人々に説明するとき、検証はできるだけ簡単かつ迅速であるべきであることを伝える必要があります。 可能であれば、開発に1日かかります。 1か月のコーディングは必要ないということです。

そしてプログラマー-そして彼らは、原則として賢い人々-は、後で必要とされない1か月間何かをするよりも、アイデアをテストするために1日の間何かをする方が良いことを理解するでしょう。 動作します。



5.物の本質の説明



問題解決者がいる場合があります。 私自身もそうです、これはプログラマーとプロジェクトマネージャーにとって非常に重要な品質です。

人は他の人の問題を解決するのが好きです。



したがって、タスクの問題の本質を説明すると(上記を参照)、多くの場合、プログラマーは思い付くよりも簡単で高速なソリューションを提供できます。 彼は主題、コード、アーキテクチャーにいて、プロジェクトの技術的能力をあなたよりよく理解しているからです。



人生からの例。 2つのカオス的基盤を接続する問題と、何を得る必要があるかを説明します。 プログラマー自身(!ハンサムで賢い)は、さまざまなレポートとフィルターを提供し、これらのレポートから結論を引き出します。 そして全体像が完全に見えます。 これにより、システムをどのように配置するかというビジョンを得ることができました。



6.複製可能な(再利用可能な)ソリューション



ホテルプロジェクトのグループがあります。 そこで、ホテルの会計のために、システムに入ったホテルのIDを受け入れる特別なカウンターを作成するタスクを設定しました。 そして、プロジェクトのすべてのプログラマ(私はホテルのプロジェクトとインフラストラクチャの一部のみを管理しています)は、自分でやるのではなく、喜んでカウンターを台無しにしました。



過去にプログラマである場合、再利用の力を理解しています。 既に書き込まれたブロックからシステムに新しい機能をアセンブルするときの話題は、伝えることが不可能です。

そうでない場合は、信じてください。複製してスケーリングするソリューションを提供すれば、プログラマは喜んでそれを終わらせます。なぜなら、急いでいる人々の再利用と創造性のある製品を使用するとき



次は?



コメントでは、経験を共有することに恥ずかしがらず、自分の人生で成功したケースについて話す経験豊富な同僚をお勧めします。



All Articles