幸せの工業生産

私の記事は、人生からの一連の物語と、それらからのいくつかの結論になります。 今私を心配している主な問題：顧客と開発者を幸せにする方法、そして利益とカルマは全体です。 具体的な最終レシピはありません。いくつかのネガティブな例と共有したい目標があります。

私は2003年（主にWebアプリケーション）から開発を続けており、その前に4年間、オムスク州立大学で数学学部の1年目のプログラミングの基礎を教えていました。 現時点では、私は自分の小さなアウトソーシング会社の共同所有者の役割で3年目になりました。 私の経験について排他的に話す理由は2つあります。比較できる3つの異なるタイプの企業を訪問しましたが、誰かの経験を伝えても全体像がわからないと思います。



おそらく誰かのために私はこのようになります：

実務経験について

2003年の終わりに、一方では、教育と学習の1つのタスクでは業界の生活の全体像が得られない一方で、収益の問題が直立したため、開発の真の実践に本当に欠けていることに気付きました。 プログラミング教師を人生から隔離する問題は、誰もが直接知っています。 これは、大学での研究は絶対に役に立たず、ただ作業を始めなければならないというプログラマーの認識の理由の1つです。 私はこのトピックについて長い間話すことができるので、次のように言います。私はこの意見に同意せず、議論を後回しにします。 アカデミック教育と業界のニーズとのギャップを埋めるために、実際に経験を積んでから、特定の知識を既に持っている大学に戻る必要があると決めました。

これは、2009年以降、オムスク州立大学で3〜5年生向けの「現代のソフトウェア開発プラクティス」という特別なコースを読んでおり、実際の仕事に必要なスキルや、彼らは最初の仕事を探しています。 具体的には、チームワーク、開発プロセス、ツール（バージョン管理システム、自動アセンブリ、タスクトラッカー、継続的インテグレーション）です。 高品質のコード、合理的なドキュメントとロギング、単体テストなどを書くことに多くの注意が払われます。 コースの一環として、学生はJava、Python、RubyのさまざまなWebフレームワークを使用して、2〜3人でチームプロジェクトを実施します。

そのため、2003年にオムスク州立大学を辞め、石油とガスのパイプラインの設計に携わるかなり成功した会社のソフトウェア開発部門に就職し、そこで社内作業の自動化に携わりました。

当時、オムスクでは最大の納税者の一人でした。 さらに、内部自動化用のソフトウェア開発のために2つの大きな部門がありました。 それらの1つは、外部顧客向けのソフトウェアであるTransneftも開発しました。 そこで私は、人事に焦点を当てた内部方針が何であるか、そして会社を設立せずに、支配権を取得して既存の会社に投資しただけの人々に支配権を移転することで、それがすべて崩壊することを知りました。 ディマルコとリスターの「ヒューマンファクター」の本を読んだ後、完全にやる気のない人が辞め、やめなかった人がまだ座って考えているという状況について、涙を流して笑いました。私はまだばかです、私も行って終了し、青い炎で燃やします。」

2009年、会社の基礎である膨大な数の優秀な設計スペシャリストと測量士の退社を背景に、当時は10人未満であった新生のアウトソーシング会社で働くという申し出を受けました。

私はそこで受け入れられた3番目の開発者でした。 開発者が3人しかいないことにすぐに少し不安になりましたが、スタッフには、ゼネラルディレクターとは別に、弁護士、マーケティング担当者、人事担当者、会計士、プロジェクトマネージャーがいました。 残念なことに、最終的にこのオフィスの悲しい歴史は、その存在を通してのポストの同様の分布に多く関連していることが判明しました。





最も逸話的なのは、収益性がすでにfo地に立たされているときにリソースマネージャーを雇うことでした。これにより、毎日無数の質問、私たちがしていること、そして突然私たちが形成する30分を別のプロジェクトに役立てることができなくなりました。 プログラマーは、これが何につながったのかを説明する必要はないと思います。 これらの対策は無意味であると経営者に説明することに成功しませんでした。

それにもかかわらず、外国の顧客とのコミュニケーションで非常に興味深い経験を得たのは、友人のミハイル・ポドグルスキー（ kmmbvnr habrayuzer ）のおかげです。 、その後、顧客が設定したタスクを解決するための1つまたは別のアプローチの適用性を評価するために、非常に良いアイデアを持っています。

2010年、オムスクをはるかに超える悪名高い会社がcrash落し、倒産したと宣言されました。当時私たちと一緒にいた顧客は、この状況に非常に落胆し、彼らと一緒に働いていた開発者にオフィスなしで続行するよう依頼しました。 そのため、オムスクでは、この注文で始まった私の現在の小さな会社を含め、いくつかのフリーランス協会が誕生しました。私たちは2011年末まで働いていました。

私自身の会社の組織と並行して、私はロシアだけでなくヨーロッパでも最大のアウトソーシング会社に就職しました。

すべてがありました：大規模な顧客、オムスク標準による非常に高い給与、完全なソーシャルパッケージ。 私が働いていたそのプロジェクトで-平和で静か、あなたのために急いで、残業なし。 それどころか-自分自身で何をすべきかを自分で考えなければならないことがよくありました。 この状況は、次の図に最もよく示されています。





パラドックスは、非常に優秀なプログラマーがかなり多数いるということです。 私の意見では、そのうちの1人はチームリーダーでしたが、私がこれまで一緒に働いた人の中で最高のものです。 そして彼らは去りません。彼らは自分の主な仕事以外にやることを見つけます。 たとえば、彼らは常に彼らに頼る初心者に多くの貴重なアドバイスを与えます。

しかし、以下で説明するかなり退屈なプロジェクトを手に入れたので、そこでの仕事から感じる感覚はますます少なくなり、会社の経営と自分の雇用労働を組み合わせることがますます困難になりました。 そのため、2011年1月にやっと辞め、最終的に自分の会社だけを引き受けることにしました。

会社には私たちの多くはいません。私とイワン・ネミチェンコ（ habrayuzer nem ）を除いて、マネージャーも、外部委託された会計士も、人的資源とリソース管理者もいません。 もちろんこれには長所と短所がありますが、今のところはこのように生きています。 Ivanと私は、コードの作成、Webアプリケーションのアーキテクチャの設計、インターンシップの実施、マネージャーとしてのプロジェクトの管理、顧客とのコミュニケーションを行っています。 これは次のようなものです（多くのツールを備えた写真はありませんでしたが、残念です）。





時々このように：





さまざまなタイプのカスタム開発のアイデアを得ることができたという事実に加えて、私はスタートアップのたまり場に参加しました、アイヴァンと私はいくつかのアイデアに取り組み、実際のコードを作成することに加えて、いくつかのスタートアップを立ち上げようとしました-これはすべて、ユーザーを促進および誘致することでもありますが、現時点ではリソースがありません。

問題について

私のチームと私は、モスクワ、ノボシビルスク、エカテリンブルク、サマラでのさまざまなIT会議に定期的に参加しています。 そして最近、私は開発プロセスへの一般的なアプローチ、技術の組み合わせのある種の応用などについて話すスピーカーに絶えず尋ねたいという1つの質問に苦しみ始めました。 など：「わかりました、これはすべて素晴らしいですが、顧客のためにどのような問題を解決しましたか？」

codefest-2012マキシムTkachukの講演者は、レポート「ハードロックデザイン」 codefest.ru/program/2012-03/hard-rock-designで締めくくった 。 彼のレポートがPM + HRセクションに発表され、そこにいたすべての開発者が彼の話を聞くようになったのではなく、主にマネージャーとデザイナーが発表したのは残念です。 そして、彼は、もちろん、彼の鐘楼から、デザイナーがプロジェクトの作業プロセス全体に参加し、要件の初期コレクションから始めて、積極的な立場を取り、開発された製品の目的とユーザー（消費者）の聴衆を深く理解する必要があるという事実について話しました。 彼は非常に感情的に話し、問題が苦しんでいると感じられ、これを理解していないデザイナーに常に対処しなければならなかった。 そして、私はホールに座って、「デザイナー」という言葉を「開発者」、「テスター」などに精神的に変えました。



実際、私がつい最近策定した問題は、このように聞こえます：チームメンバーの大部分は、顧客とユーザーの問題を掘り下げたくないので、管理者と顧客は、解決する問題の多くの側面についてチームに通知する必要があるとは考えていません。

問題の症状は次のとおりです。

●ユーザーは、ユーザーの誘致、資金調達、プレゼンテーションなどに関する問題についてチームが知る義務はなく、チームの仕事はコードを書くことであり、他の人々はビジネス上の問題について頭痛の種を抱えているべきだと顧客は信じている;

●プロジェクトの交渉の開始時、顧客は実際のチームメンバーを知るよりもCMMIなどの正式な証明書を取得することに関心があり、多くの場合、マネージャーとアナリストのみと通信することを好みます。

●開発者は次のように述べています。「コードを書きたいだけです。明確なタスクを与えてください。すべてを行います。 顧客の問題について、アナリストとマネージャーに頭痛を感じさせます”（“休暇中のテレパス”）;

●チームは原則に従って行動します。私たちは彼らが求めたとおりに行動し、支払いをしますが、それは私たちには関係ありません。

●マネージャーは、主な仕事が致命的な退屈であり、酸性になるのを防ぐための特別な対策が必要であるため、人生から離婚したクリーチャーを何らかの方法で楽しませる必要があるクリーチャーと見なします。

●開発者自身は主な仕事を退屈であると考えており、モチベーションを維持するために、サードパーティのオープンソースプロジェクトと小規模なスタートアップに従事しています。

●プロジェクトの開発には膨大なドキュメントが伴いますが、ほとんどの一般的な従業員は製品の典型的なユーザーを説明することができず、見たこともありません。

●さまざまな役割の代表者間のコミュニケーションは、戦場に似ています。

●あらゆる役割の代表者は、マネージャーの仕事やチーム内の他の役割の代表者に不満があることをすぐに示すことができます。

●まず第一に、チームの各メンバーは、他の誰かの責任を策定し、その後で自分の名前を付けることができます。

●チームメンバーの最初の主要なタスクは、他の人の故障に対する責任を過大評価し、プッシュすることにより、ある場所をフライパンで覆うことです。



チームへの影響（長期的に）：

●動機付けは重要なポイントまで低下し、誰もタスクを可能な限り最高にしようとしない。

●決定は「飛行しない」という原則に基づいて行われます。

●特に深刻な場合、意思決定にはいくつかの段階の書類への署名が伴います。

●コード、アーキテクチャ、内部プロセスを改善するイニシアチブは歓迎されません;ほとんどの場合、イニシエーターは「もっと必要ですか？」という質問を受け取ります。

●最初の機会に、最も有望なチームメンバーがプロジェクトを変更します。

●唯一の動機はお金とキャリアです。十分な期間、チームは最も商業的な市場アナリスト、または安定した給料と18:00に帰宅する機会以外に興味がない人々によって集められます。



内部管理への影響：

●タスクの実装を監視するには特別な手段が必要です。

●長い間、ほとんどのイニシアチブはチームを去ります。

●期限に間に合わなかった場合の責任は主にマネージャーにあり、故障を防ぐためにチームを動機付けるのはニンジンとスティックだけで可能です。



顧客管理への影響：

●顧客は、過大な期間とスタッフの離職に対して繰り返し過払いをします。

●製品の品質は紙の上でのみ優れています。実際、コードとアーキテクチャはひどいものになる可能性があるため、顧客は不満足な品質を過剰に支払います。

●ユーザーが自発的に製品を選択する幅広い人々である場合、以下に説明する理由でユーザー数を減らすことができます。



エンドユーザーへの影響：

●出演者と直接接触することはなく、迅速にフィードバックを提供する能力もありません。

●ニーズが完全に満たされているわけではありません;ほとんどの場合、ユーザーは製品が標準的な使用法とは程遠いため、製品を使用するために特別な訓練を受ける必要があります。

●新しい機能を追加するタスクを完了するための手順と期限は、ユーザーのニーズを満たしていません。

人生の物語

上記を説明するために、開発者またはマネージャーとして作業しなければならなかったいくつかのプロジェクトについて説明します。

そのため、同社はトランクパイプラインの設計に取り組んでいます。 ソフトウェア開発部門には、エコロジー部門向けの小さなプログラムを作成するタスクが与えられました。 ソースデータ：

• o誰もがBorland C ++ Builderの設計および調査作業を自動化するためのデスクトップアプリケーションを作成する部門。
• o落ち着いたばかりで、それほど複雑ではないデスクトップアプリケーションを作成できる新人。
• oエコロジー部門。一連のExcelテーブルを使用して、建設作業中の汚染物質排出量の計算を実行します。

部門についてもう少し：





2Dグラフィックスの個別のライブラリが、3D計画で作成されました（OpenGLと、すでにヤードにあるすべてのもの）。 データをメモリに格納する独自のcな構造が記述されています-リンクリストと直接アクセスのある構造の一種の組み合わせ、つまり 配列。 アクセスには、非常に低レベルのアプローチが使用されます。ギブレットだけでなくAPIレベルでも、抽象化は一切行われません。 入力時にメモリ内のアドレスを受け取り、この開始に関するアドレス計算を使用してすべてのデータを取得するグリッドが書き込まれます。 1バイト内のどこかにシフトすると、すべてが破壊されます。 ほとんどの叙事詩の名前は「myGrid」です。

若い戦闘機に-すなわち 私に-彼らは、ビルダーの将来のプログラムのコンポーネントとしてこれらすべてを使用することを提案します。これは、Excelsian計算の現在の動物園を置き換えます。 顧客-45歳以上の叔母（上司）と約25人の少女（通常のパフォーマー）-関係のない部分とみなされる計算のカテゴリに専念し、彼らの観点からは、開発は漸進的です-計算は1つずつ繰り返され、およそ同じ時間。

約1か月間、私は正直にBuilderですべてを行いました。メガグリッドを介して入力されたデータはメモリ内のメガ構造に落ちました。ディスクに保存されると、バイナリファイルにそのままドロップされ、ファイルからそのままメモリに読み込まれると単純にドロップしました。 しかし、私は反抗した。 彼女は部門の長に、このタスクにはデータベースの使用が公然と関係していること、特に必要なマルチユーザーモードを考慮していることを伝えました。 別の月の戦いと私は許可を得ました。 彼らはJava + Oracleで企業情報システム（CIS）を作成しようとしており、私はこのCISの一部としてシステムを作成する機会を得ました。

タスクに突入すればするほど、計算は相互に関連しているだけでなく、ほとんどの場合、それらのデータはさまざまな規範書や参考書にあるか、他の部門の従業員からのものであることに気付きました。 どんな種類のシステム生態学者が本当に必要であるかについての理解があり、それは彼らが説明したものに少し似ていました。 私は彼らの部署にこだわって、与えられた計算の枠組みをはるかに超えた質問をしました。その結果、徐々に研究所全体の仕組みを掘り下げました。

私は彼らが本当に求めていたよりもはるかに多くのことを彼らが本当に必要としていたが、最初に想定されていたよりもずっと多くの時間がかかった。 最初のバージョンでは6か月、残りの部分では基本的な計算、2.5年で完了します。 この間、最初の1か月から2か月で目に見える結果がなかったことで解雇されそうになりました（正確には覚えていません）。また、部門長や当時のITディレクターとの関係は、プログラマーではなくデザインエンジニアからのものだったため、かなり損なわれました。

それから私は上司の敷居を張り始め、自動化のプロセスを開始し、研究と設計の全プロセスのモデルを構築しようとしました。プロジェクトのデジタルモデルのレベルで。 CIS部門もありましたが、テキストドキュメントの種類に関心があり、図面は通常のバイナリファイルと見なされていました。 私にとって、主なものはモデルであり、すべての図面とテキスト文書は、モデルを持っていつでも作成できる単なるレポートでした。

その結果、このグローバルなシステムは官僚的および経済的な理由のために決して現れなかったので、辞めました。 ちなみに、このプロセスのピース単位の自動化は他の設計機関で利用できます。IT企業の1つは、それについての最後の知識（2010年）でカバーした商用製品で収益を上げています。 内部でモデルを使用する測量作業（測地学、地質学など）をカバーするいくつかの製品があり、AutoCAD形式の図面はレポートとして受信されます。 しかし、残念ながら、パイプラインの設計には継続性がありません。



タスクに戻りましょう。 すべてが正しく行われたようです。ユーザーは、期待以上にニーズに合った製品を受け取りました。 しかし。 彼らは望んでいたよりもずっと後でそれを手に入れました。 彼らにとってはどうでしたか？ ルーチンの時間の大きな損失、およびその結果、余分な年の残業。



どのような間違いが行われたか：

1.上司の調査およびExcelファイルの調査による要件の収集。

2.その時点で開発者がほとんど研究していなかった開発技術の選択。これにより、最初のバージョンの登場が遅れました。

3.システムの最初のバージョンを即座にメガユニバーサルにする試み。

これらすべてのエラーの世界的な原因は、私が目標に夢中になりすぎて、顧客の目標を忘れていたことです。 私は新しいテクノロジーを研究しながら、優れた普遍的なシステムを作りたかったのです。 そして、顧客は計算を実行して時間通りに帰宅する時間を短縮したかっただけです。



理想的な球状の現像剤は真空で何をすべきでしたか：

1.しばらく部門を完全に浸すことによってビジネスドメインを研究することから始めて、部門の普通の従業員の基本的な面倒な作業を実行するまでの内部からのすべてのプロセスを研究します。

2. 1週間以内に、最大2つ、Visual Basicでいくつかのマクロを記述します。これにより、一部の計算結果を他のソースデータとして使用できるようになります。また、Excelで最も頻繁に使用されるディレクトリをデジタル化します。

3.すでに部分的に満足している顧客を近くに置いて、実際のシステムを冷静に開発し、すべてのジャッキーと主要なリスクをすでに理解します。これにより、開発プロセスも3分の1以上加速します。

一見したところ、この例は上記の問題と症状に適合していません。 一見したところ、そうです。 顧客の問題を調査し、可能な限り最善の方法で問題を解決しようとする開発者が非常に動機付けられていたため（マクロの初期エラー、より正確には、それらの不在を除く）。 問題は、周りにいた他の全員が会社の全体的な状況を改善しようとする動機がまったくなかったことです。 問題は、私が定期的に聞いた他の誰よりも本当に必要なのかどうかです。 そして、ある時点で、忍耐力が切れました。



このストーリー全体の結論は何ですか？

1.ユーザーは直接知っている必要があります。 そして、マネージャーとビジネスアナリストだけでなく、チーム全体です。

2.機能要件およびインターフェイス要件を作成するプロセスでは、チーム全体が最大限に参加する必要があります。

これらの条件が存在することで、チームは創造的である機会を得ることができ、ユーザーとそのタスクを個人的に知ることで、これらの問題を最適に解決できます。 ユーザーが抽象的で非人格的であるとき、誰も彼の魂を彼の製品に入れません。

しかし、実際のユーザーにアクセスできない場合はどうすればよいでしょうか？ ラバーユーザーを持つことができます。 もちろん冗談です。 このため、ユーザーのポートレートを開発するための特別なプラクティスが開発されました。 チームは、名前、年齢、職業、習慣、さらには製品を使用する際に生じる恐れ、およびこの製品が彼らにもたらす恩恵を持つ人物の本当の肖像を作成します。 ゲームの瞬間、ジョーク、内部ミームがあります。 練習はScrumtrek AgileCampトレーニングでかなりよく現れます。



ユーザーとのミーティングと特定のニーズの調査については、さらに2つのケースを挙げます。 つい最近、私たちは顧客のオフィスに座って、将来のシステムのライブユーザーとチャットする機会がありました。 そして、インターフェースの女の子デザイナーはこのフレーズを数回繰り返しました。「ああ、まあ、このようなユーザーと話すのはなんてクールなんだ！」 通常、それが誰であり、最終的にどのように製品を使用するかはわかりません。」

実際、顧客の経営陣と連絡を取りながら、考えられるすべてのセクションの図と要約データを表示でき、ユーザーが現在作業している大きなExcelを多少思い出させる超普遍的な分析システムの作成を提案しました。チャートテーブル付き。 たまたまモスクワに飛んで、すでに決まった要件について話し合い、合意に署名するために集まりました。 2つの問題がありました：私たちの側では、タイミングの明確な理解の欠如、いくつかの普遍的なものは評価するのがより困難であるため、要件はより曖昧であり、ユーザーインターフェースを開発するチームの側では、ほとんどのユーザーはこの普遍的なインターフェースを必要とせず、理解しないという感じです

当初から、エンドユーザーを招待し、ステッカーとマーカーを付けて黒板に立ち、ストーリーマッピングを実行することを提案していました（もう一度、ScrumtrekのAgileCampを参照します）。 これはうまくいきませんでしたが、それでもユーザーを招待し、各ユーザーと話をして、彼の主なジャッキーとシステムの使用に対する期待を理解しようとしました。 その結果、超汎用性は浅く、最も重要な機能の80％をカバーするいくつかの透明なジャスキーを受け取りました。 これにより、作業プロトタイプをより迅速にリリースすることが可能になり、既にビジネスに利益をもたらします。

最近、他の顧客でも同様の話がありました。 彼は優れたプログラマーであり、ある時点からテクニカルディレクターになりました。 したがって、彼は実際にはビジネスタスクではなく、特定のアーキテクチャソリューションを提案しました。 彼は再び、すべてを行う超普遍的で超モジュラーなシステムを私たちから得ようとしました。 実際に具体的なケースを引き出すことはできず、エンドユーザーにも提示されませんでした。

半年前、彼はオムスクにいました。私たちは半日、無駄のないキャンバスの作成とストーリーマッピングを行いました。 その結果、最初のプロトタイプに特定のケースを選択し、最初の数回の反復ですべてがほぼ完璧に進むように見えました。 しかし、ある時点で、組織、ジオロケーションなどのディレクトリを作成するために、ストーリーマッピングのヒントさえもなかった予期しない要求が突然到着しました。 チームは理由を尋ねませんでした-そして、顧客はそれを説明する必要があるとは考えませんでした。 さらに2週間後、顧客が緊急の重要なイベントに直面していることが明らかになりました。そのためには、準備する製品が必要でした。 時間内にシステムをデータで満たすためにユーザーを事前に配置したかったのですが、事前に警告していなかったため、システムはユーザーが現時点で必要なuscaseを正確に処理する準備ができていませんでした。



これらの2つのストーリーからの結論は何ですか：

1.ユーザーを直接知るだけでなく、ユーザーのニーズの80％をカバーし、そもそも実現すべきシステムを使用するための最も重要なオプションに関する情報を取得する必要もあります。

2.顧客側の技術管理の影響を可能な限り制限することをお勧めします。製品の目標を最大限に理解するために、ビジネスおよびエンドユーザーの人々とのコミュニケーションを主張します。

3.スケジュールされたデモンストレーションやその他の重要なイベントのタイミングについては、自分で考えない場合があるため、顧客に質問する必要があります。製品が展示に使用されるイベントの日付は、エンドユーザーによるアルファテストのために1週間または2週間前に置かれる必要がある場合があることを理解することが重要です。

設計研究所のすぐ後、私は愚かな倒産した小さなアウトソーシング会社で働きました。そこではマネージャーと私が共同で最初の仕事をしました。このシステムは、監視カメラからのビデオストリームを2つのモード（オンラインと録画）でストリーミングして記録し、カメラの設定を構成するWeb管理パネル、録画したビデオのストレージシステム、イベントに関するさまざまな通知の2つの部分で構成されました。



マネージャーは、ビデオ録画とストリーミングという大きな技術的リスクがあることを知っていました。開発者が1か月以内にメインカメラの形式を調査し、ビデオストリームを記録する可能性を顧客に示すために消化しやすいものを書く時間がないという深刻な懸念がありました。したがって、彼は私がすぐに顧客の目をぼやけさせるために使用できる管理パネルをリベットし、コメントと希望に夢中になり、しばらくの間ビデオを忘れて、2番目の開発者に操作する時間を与えることを望んでいました。

ただし、これらの考慮事項はすべてマネージャーの心の中にありました。開発者は期限を見て-3か月-特に心配していませんでした。私たちは実際にはお客様と個人的にコミュニケーションを取りませんでした;マネージャーはこれに従事していました。情報はすでに注文の形で私たちに届きましたが、私たちはそれを主張し、いくつかの場所でそれを独自の方法で行い、マネージャーが設定した期限を遅らせました。私たちは確実に完全な期限（もちろんプラスまたはマイナス）を満たします。しかし、私と2人目の開発者の両方が顧客をあまり気にせずに目標を追求したため、約束された月の後、作業システムはありませんでした。したがって、私は2つの鳥を1つの石で殺すための新しいフレームワークを開発することにしました。マネージャーはこの問題を止めませんでしたが、彼は私が研究の締め切りに間に合う時間がないと疑っていました。

その結果、顧客の目にはマネージャーと会社全体の権限が大きく揺れ、コミュニケーションの中断が始まり、最初の金融トランシェは延期されました。

問題は、適切な開発プロセスの欠如であると言えます。それはスクラムであり、幸福が来るでしょう。ただし、ここでのポイントは、プロセス自体またはその不在ではなく、受け入れ基準を使用して説明されたスコープを繰り返しましたが、事実は、お客様の問題を一緒に解決しなかったことです。納期の変更により顧客が失った利益について頭痛の種は絶対にありませんでした。

環境保護主義者との以前の経験を考えると、私は絶対に刺激を受けて、マネージャーではなく顧客である方向に向かって考えます。マネージャーはテストするプロトタイプを立ち上げるよりも、フライパンでロインを覆うことに興味があるので、障害のある商業利用も可能です。しかし-彼は適切にファイルしなかったし、私は十分な好奇心を示しませんでした。当時の技術的特徴を備えた新しいフレームワークは、私にもっと興味を持ちました。彼の選択も最終的には失敗し、研究は容認できないほど長い時間がかかった。このタスクでは、動的言語の1つとDjangoやRailsなどのフレームワークを選択できます。



この物語からの結論は何ですか？

1.チームは、顧客のビジネスのすべてのリスクと問題を認識している必要があります（彼がなぜそれを立ち上げるべきなのか、まさにその時に、どのような機能がプロトタイプに適しているのか）。

2.チームは、自社の動機を認識している必要があります（評判、ポートフォリオ、または経済的幸福のためのプロジェクトの重要性）。

3.技術的なソリューションを議論して選択するとき、まず技術的な管理はビジネス上の問題に導かれ、顧客に対して新しいフレームワークを実践することは非人道的であることを開発者に説明する必要があります。それにもかかわらず、開発者が新しいことを学ぶことに興味を失わないように、新しいテクノロジーを適用する機会を与える必要がありますが、内部プロジェクトやオープンソース開発のための時間を与える必要があります。

これにより、開発者は顧客とマネージャーの両方を率直に無視することができなくなるという事実につながります。ポートフォリオ内のプロジェクトは、企業と特定の開発者の両方の財務状況の改善の可能性は言うまでもなく、誇りの理由です。



小さなアウトソーシング会社の破産の2週間前に、私は大規模なアウトソーシング会社の支店で働きに行きました。

面白かったです。市内の非常に尊敬されている会社のニーズに対して自分のスキルをチェックするために、私は好奇心からちょうど面接に来ました。そして、インタビュアーに完全に魅了されました。私たちは彼とさまざまな技術的な問題について非常にうまく話をしました。彼はとてもクールで、彼から多くを学べることに気付きました。結局のところ、彼はヘッドハンターが積極的に誘惑し始めるのに十分なほど高く評価してくれました。最終決定は、私のインタビュアーが私が参加する開発チームのチームリーダーになるという事実に影響されました。

私は正直に支店長とマネージャーに自分の小さなチームがあることを警告しました。それは並行して対処し、同意を得てチームに参加し始めました。 45人のプロジェクトチームのうち、開発者の3分の1に満たない人は、私を少し驚かせました。この場合、アーキテクト、プロジェクトマネージャー、プログラムマネージャーなど、各チームには独自のリーダーがいます。

プロジェクトは長い肝臓であることが判明しました。 Fortranで30年間存在していましたが、2000-2001年に書き直され、Java + OracleのWebプロジェクトになりました。同時に、インターフェースの外観は完全に維持されました。ユーザーが慣れているからではなく、システムの本質とデータ入力用のこれらすべての画面の意味を完全に理解している開発者は一人もいないからです。社内にプロジェクトが存在する間に、100人以上の開発者がプロ​​ジェクトを置き換えました。私が知らないテスターとアナリストの数です。その結果、私が入社したチームには、システムを完全に理解する人は一人もいませんでした。わかりにくい用語を喜んで私に浴びせたアナリストでさえ、ユーザーの目標とニーズに関する質問のほとんどに答えることができませんでした。

このすべてが、パッチを適用する方法によって開発が行われたという事実につながりました。アナリストやテスターに​​よって作成されたシステム上のドキュメントは、多くの場合、コードの現在の状態に対応していませんでした。いくつかのユーザーストーリーによると、顧客と開発チームは同じ機能の2つの異なる写真を持っていました。

上記の私が発した症状のほとんどを観察したのは、このプロジェクトでした。ビジネスドメインを理解したいという私の願いは、不可解でした。結局のところ、小さなタスクを実行することは、それが関係していないと思われるという事実を掘り下げることなく、はるかに簡単です。私を悩ませたのは、使いやすさの観点から、このシステムが今まで見た中で最悪の例だということでした。それを使用するユーザートレーニングの時間は膨大でした。ユーザーは膨大な数の有効なパラメーター値とそれらの組み合わせを覚えることを余儀なくされました。システムはヒントを与えず、巨大なフォーム検証でさえ「エラー！」というメッセージだけを表示することが多く、入力されたデータをすべて消去してページをオーバーロードした後、不運なユーザーが入力を余儀なくされたためですもう一度。

同時に、主にプロジェクトに携わった人々は技術的に非常に有能であり、使用済みおよび関連技術の膨大な数の微妙さに精通していた。それにもかかわらず、多くの人の目には憧れがありました。市のほぼ最高の開発者を集めた会社は、これらのリソースを非常に奇妙に処分しました。小さな開発チームと文字通り1-2人のテスターが定数モードで残業したプロジェクトがありましたが、テストのためにコードが与えられたときに何をすべきかわからず、次の反復がまだ始まっていなかったので、隅々までさまよいました。しかし、会議のプログラムマネージャーは、緊急に必要な人に配給するのではなく、人々を遠ざけるために最善を尽くしました。社内に座っている多くの開発者が、フリーランスで稼ぎ、1日の大半をそれに費やしました。

その結果、数人のかなり積極的な従業員が退職し、最終的には都市の動的に発展する企業で指導的地位に就いたか、退職しました。前の会社でアイデアを実装する準備はできていましたが、これらのイニシアチブは経営陣の注意を引くことなく残されました。なぜなら、高度な管理では、エンドユーザーの問題、さらには開発チームの内部問題さえも見えなくなったからです。



私にとっては、次の結論を出しました。この場合、大きな階層構造で完全に快適に感じる人が非常に多いため、この場合は非常に物議を醸しています。

1.このような構造では、責任を負わず、「安定性」を重視する多くの人々が重要になります。これは、チェッカーを使用して新しいプロジェクトをすばやくブレインストーミングする必要があるまれな瞬間に、このタイプのアクティビティの準備ができていないという事実につながります。したがって、そのような企業にもたらされるプロジェクトは、すでに開発中のプロジェクトと同じくらい退屈で長期にわたるものです。

2.それにもかかわらず、異なるタイプのプロジェクトが漏れた場合、最初はすべてが楽しくて面白いように見えます。ほとんどの場合、そこにいる開発者は、他のプロジェクトから逃れた新しく到着した従業員または情熱家です。しかし、常に廊下でチャットしたり、キッチンでお茶をしたりする他のプロジェクトの半眠りのチームの近く、または明らかに営業時間中に釣りに行く人は、私が非常に素早く疑問に思います-なぜ多くの人々がほとんど無料で支払われているのか自由時間がたくさんあります。これにより、モチベーションがかなり早く低下します。さらに、給与と昇進の見込みだけが人々を保持し始めます。ただし、多くの人は最終的にスタートアップ、小規模だが楽しいチーム、またはフリーランスに行きます。

3.いくつかのレベルの管理階層を持たない小さなチームのプログラマー人口の1人あたりの幸福の割合は、はるかに高くなっています。個人的には、このようなチームにはもっと感銘を受けました。燃えるような目を持つ人々の間でいることがはるかにいいです。したがって、上記の種類のチームとプロジェクトを1つの企業内で組み合わせることはお勧めしません。

4.小規模チームでの顧客の要望に対する反応率が高くなり、顧客の幸福度が向上します。すべての顧客がまだ「チャンスを得る」準備ができているわけではなく、小さいながらも誇りに思うアウトソーサーを雇います。しかし、それらは私たちの幸せのためです。

幸せの愛の式

私とパートナーにとって、それは次のコンポーネントで構成されています。

•ユーザーが非常に重要な問題を解決できるように主に設計された製品を開発し、利益を上げることは副作用です。理想的には、製品は余暇に無料でやりたいと思うほど興味深いものでなければなりません。したがって、お金のためにそれに取り組む能力は、チームにとって本当の幸福です。理想的には、製品はあなた自身のものです。

•小規模ですが、非常に高いレベルのスキルチームで、余分な人がいないだけです。各愛好家と伝道者は、メインの仕事に加えて、積極的に自己啓発に従事し、教育ブログを維持し、興味深いオープンソースプロジェクトに貢献し、または自分で作ります。

•チームは顧客のビジネスやエンドユーザーの問題を掘り下げ、彼らが彼らと同じ言語を話し、ビジネス価値の観点から製品を見ることができるようにし、すべてのプロセスと技術的ソリューションをビジネス/ユーザーのニーズに適合させます。

•顧客は非常に適切であるため、技術およびプロセスソリューションの選択においてチームを信頼し、指定された予算内でビジネスニーズを満たす方法を決定できるようにします。

•さまざまなテストの展開や実行などの多数の日常的な操作が非常に自動化されているため、チームは脳のアプリケーションを必要とする本当に興味深く複雑な作業に十分な時間を割くことができます。

•チームには、犬に関する仮説をテストする時間があります。プロトタイプを作成し、開発の各段階の終わりにデブリーフィングを行い、成功したか失敗した決定の経験を社内および社外のチームと、たとえば会議で交換します。比較分析と最終的に最も成功したものの選択の可能性を備えたいくつかのソリューションの並行開発を行うことが可能である場合-これは一般的におとぎ話です。



「ありがとう、キャップ！」スタイルの素敵なコレクション実際、私たちにとってこれはまだ理想であり、私たちは全力を尽くして努力しています。私はここで究極の真実を装うわけではありません。利益に関して、言及された項目のいずれも持たない多くの成功した企業があります。または、それらの1つまたは2つのビット。しかし、私は利益を最大化することではなく、まったく異なることについて話していることを強調したいと思います。これは主に哲学的な瞬間です。お金だけでは本当に必要ありません。無人島のお金の袋は役に立たない。人は幸福感を必要としますが、それは決してお金そのものではありません。

実際、会議とこの記事での私のスピーチの目的は、ビジネスと開発チームの間の相互作用の側面、この相互作用における誤解と不信の問題の関連性を同僚と議論することです。したがって、まず第一に、読者に質問する準備ができています-私が話していたことはあなたに関連していますか？これらのトピックをより詳細に議論したいですか？



質問は怠idleではありません。私たちは、ここ数年出席した会議とは少し異なる原則に基づいて会議を開催します。特に、エカテリンブルクのdump.it、ノボシビルスクのコードフェスト、モスクワのdevconf、アジャイルデイズ、アジャイルキャンプ。会議は9月29日に予定されています。

アイデアは、レポートをチームの専門分野（開発者、テスター、デザイナー、マネージャー）に従ってではなく、使用されているテクノロジーに従ってではなくセクションに分割することです。各セクションの複合施設の特定のケースを検討し、ビジネスタスクのタイプに応じてセクションで人々を結び付けたいと思います。企業、銀行、その他の大企業で働く人々は、投資ラウンドを得るため、または仮説をテストし、KPIを測定するためにプロトタイプを迅速に作成する必要がある限られた予算の新興企業を聞くことに興味がありません。開発プロセスを整理し、解決する問題のニーズに基づいて技術的ソリューションを選択するためのアプローチを共有してもらいたいと思います。

読んでくれて時間を割いてくれたみんなに感謝します。このトピックに関するトリッキーな質問やアドバイスがあれば嬉しいです。