監督者がプログラミングを知らない会社での完了時間
私たちは約10人の開発者を抱える小さな会社です。私はチームリーダーであり、開発プロセスの責任者です。
私たちは小さなチームなので、監督者やセールスマンは私たちの近くにいますが、ソフトウェアがどのように開発されるかについての手がかりはありません。
製品の変更（バグ修正/機能）にどれだけの時間を必要とするか尋ねられたとき、私の応答は「計算させて」です。彼らにスケジュールを与えた後、彼らは最初に私の計画とは大きく異なるXX時間でそれを行うことができるとOKを言うことから始めます。私たちはアジャイルの基本原則に近いモデルを使用しており、週ごとまたは3日間ごとにサークルがあります。
もちろん、私はこれを行うことができないと主張し、言います。彼らは私たちが行っている努力について何も知らないようです。彼らはWHYを見たくないです。私のスケジュールはその時間のためのものです。
この動作が愚かであることは知っていますが、どうすれば問題を認識させることができますか？
担当のセールスマンも兼任している場合は、「よろしければ、スケジュールに沿ってご利用いただけます。締め切りまでにどの機能または責任を犠牲にしていただきたいですか」と言うことができます。そうすることで、担当者に「いいえ」と言っているわけではありませんが、不可能なことはしていません。どのようにビジネスを運営するかは、彼らの決定にかかっています。変更のための時間を作るために他のものを斧たい場合は、彼らに任せてください。
編集：私たちは尊敬し、権威のある人々に服従する必要がありますが、卓越した仕事をしています。これを行う唯一の方法は、謙虚であることです。上司が私に働きかけてほしいと思うことなら何でもしますが、できることはたくさんあります。あなたが提出の態度であると彼に言ったとき、彼はより良い決断をするのにより良い立場にあり、彼はあなたのようなより多くの従業員を望んでいるでしょう。
コミットメントが不合理である理由と状況がどのように解決されたかを説明するために、これらも文書化されていることを確認してください。同僚が将来同じような状況に対処するのに役立ちます。
私の経験では、営業担当者はすべてがあなたが途中でお互いに会う交渉だと思っています。それは基本的に彼らがどのように機能するかです。彼らはクライアントに製品を売ろうとし、高く尋ね、クライアントは低く提供し、最終的には両者が合意する価格が合意になります。
彼らはまた、この考え方を作業現場にも取り入れています。彼らはあなたがあまりにも多くの時間を求めていると仮定して、交渉と同じように、彼らは時間のいくつかを議論しようとします。
正確な見積もりを出すことは、頭痛の種に過ぎません。
あなたができることは一緒に遊ぶことです：彼らが「交渉」の間にいくつかを切り捨てることができるより高い見積もりを与え、最終的に、それが実際にあなたがするのにかかる時間に終わります。
それらを表示しないtheirエラー！
何を変更するかについてより適切に議論し、より詳細な見積もりを与えてください。 「ソフトウェアのテストを外部委託する場合、Y時間ではなくX時間でこれを行うことができます」のような提案をします。または、「要求された機能のこの部分を除外すると、これをより速く実行できます」。
「彼らにスケジュールを与えた後、彼らは私の計画とは大きく異なるXX時間でそれを行うことができるとOKから始めることから始めます。」まず、XX時間の計算方法を尋ねます。
記録はあなたの推定値と彼らの推定値で作られていることを彼らに提案します。次に、実際の結果を予測と比較して、誰がより正確かを確認できます。
「私は自分の見積もりを支持します」と言います。そして、もちろん、あなたの見積もりに達します。それが3回起こるとき、彼らはおそらくあなたを信頼するでしょう。
「彼らが私に変更のためにどれだけの時間を欲しいか尋ねたとき」
その時点でそれらを停止します。それはあなたがどれだけの時間ではないwant。それはあなたがどれだけの時間であるか必要。彼らが主張するならば、彼らにあなたが望む時間とあなたが必要とする最小の両方を与えてください。
また、セールスによって強制されるすべてのショートカットが原因で発生する技術的負債の非常に目に見える尺度を維持するのに役立つ場合もあります。 Nikolayは広く楽観的で、彼らの現在の行動が彼らにボーナスを与えるとき、あなたは話によってセールスに影響を与えることができます。
実際、セールスがそのようなインセンティブによって本当に推進されている場合は、応答を策定するときにそれを考慮に入れる必要があります。 「エンジニアリングによってコミットされていない機能」は、セールスリクエストを破棄する正当な理由です。
何時間にもわたる彼らの専念から逃れるには、ゲームを変更します。時間を推定する代わりに、ベースラインを形成する特定のユースケースに関連して複雑さを推定します。
あなたはあなたがアジャイルアプローチの何かを持っていると述べました、スクラムを試してみませんか？
つまり、短いスプリントを行い、「1週間で5つの機能のうち3つを開発できるようになる」と伝え、これら3つの機能を確実に提供できるようにします。変更/機能/バグに優先順位を付け、厳密にこの順序で作業してもらいます。 （もちろん他にもあります。）
時間、コスト、品質、範囲の鉄の三角形について教えます。あなたは3つを固定し、4つ目は三角形の領域なので、他の関数です。最終的には、配信する際のコスト、コスト、そしてできれば高品質で配信することのほうが、正確に配信することよりもおそらく重要だと思います。
これは、セールス/コンサルティング主導のプロジェクトにおける私の大きなバグベアであり、困難な状況です。これは多くの場合、会社の運営方法の問題です。
これは、犬を振ろうとするテールの典型的なケースであり、セールス担当者は販売を成約するためにできることは何でもし、機能に世界を約束し、滑稽なタイムスケール、ソフトウェア開発プロセス、およびその他すべてを非難することを保証します。
彼らがあなたの言うことに耳を傾けるか、聞かないかは、必ずしも彼らが理解していないという事実ではありません、おそらく彼らはよく知っていますが、彼らが気にかけているのは、セールを終了し、ビジネスを獲得し、後で期限を心配することです。
そうは言っても、顧客は裏側に苦痛を感じることがあり、安価に物事をやりたい、そしていつ行われるのかを知りたいと思っています。そして、彼らは起動するための割引を望んでいます。
これを軽減する1つの方法は、技術担当者を営業会議に参加させることです。現在、これはすべての会社で必ずしも実現可能ではありませんが、少なくとも営業担当者を統治する唯一の方法である可能性があります。
何かにかかる時間と請求される時間を区別するのに役立ちます。どれだけ時間がかかるかは技術的な決定であり、彼らはあなたに反対する根拠がなく、頑固です。営業担当者がその時間に請求する金額は、彼らの決定であり、クライアントに販売する責任です。
それ以外は、インセンティブを整理する必要があります。そうしないと、常に困難な戦いが繰り広げられます。販売ボーナスが販売のあからさまな価値ではなく、販売の価値とそれを提供するコストの差額で支払われる場合、彼らはあなたに耳を傾ける動機を持っています。
スケジュールを削減したい場合は、除外する機能とその優先度を尋ねます。
次に、優先度の高い順に機能に取り組み、いつでも製品を提供できることを伝えますが、最初に指定した終了日までは、要求した機能がすべて含まれるわけではありません。
問題が解決しない場合は、営業担当者を1〜2週間開発チームに派遣してみませんか。彼らにXプログラミング言語に関する本を渡して、それをtheir見積もりで行うように伝えます。 99％の確率で惨めに失敗し、再度見積もりに疑問を投げかけます。彼らはまた、ソフトウェア開発を行うために必要なことを理解し、プロセスを支援していないことに気付くかもしれません。
あなたが推定ではなく、見込みあなたはその時間で完了します、そしてあなたが数を減らすことは話をすることに他ならないことを明確にしますあなたは彼らに嘘をつく。実際には、魔法のようにソフトウェアを高速化することはできません。
妊娠の推定値を9か月から7か月に下げるように女性に話しかけると、どれほど効果があるかを尋ねます。
さらに良いのは、製品マネージャーを取得することです。セールスマンは、商品全体を気にかけるインセンティブがほとんどなく、現在のセールを追いかけるインセンティブがないため、商品をコミッション追跡の結び目に結び付けます。
問題を解決する必要のある2つの問題があります。
時間の見積もりを停止し、ドルでの見積もりを開始します。これにより、コスト/利益分析を迅速に行うことができ、標準の「分析する時間」の見積もりを追加できます。実際の作業量（1日、5日、または3週間で40時間かかる可能性があります）を反映していないため、時間があまりに粘りがあり、非常に簡単ですnotこのようなリクエストに対しては、予算のリリースサイクルを押し戻します。
時間を節約するために、開発サイクルへのリクエスト入力をセールススタッフに提供します（できれば人間以外のインターフェース（お金で測定））。
営業担当者は（Xがあれば、このセールを終了できる）という点で考える傾向があります。彼らの要求は、製品の現在のアーキテクチャと一貫性がないことがよくありますが、顧客の現在のneedと一貫性があります。
そのようなリクエストが製品に対してvitalであることを営業担当者に伝え、したがって、needで「クイックリクエストでそれらを失わないようにするには、期間より長くかかります。関心のある、要求をドロップして、繰り返す」サイクル。このような要求は、キャプチャされ、分析され、優先順位が付けられ、製品に統合され、テストされ、次のリリースサイクルでリリースされる必要があります。
次に、アクションで言葉をバックアップします。リリースサイクルを2か月未満に短縮し、リリースに含める予定のアイテムを指定して、期限を守ります。これが必要な内部的な理由について販売スタッフを教育するのではなく、サイクル外のリクエストが最低限必要とする費用（ドル単位）と、費用がかかる可能性があるリスク（追加の費用と発生率）を分析してください。問題が最小限の複雑さを超える場合。次に、売り上げがサイクル外のリクエストをサポートするのに十分な大きさかどうかを営業担当者に尋ねます。
インサイクルリクエストのプロセスがあり、アウトオブサイクルリクエストを処理するのにかかるコストがわかったら、アウトオブサイクルリクエストをインサイクルに変換できる可能性が高くなります。サイクルリクエスト、またはサイクル外リクエストが費用を正当化するのに十分な収益性があることを決定します。
まあ、私は仕事に取り組むために、あなたとセールスが要件を満たすことに同意する必要があることは価値のある価値があることを理解していると思います。
あなたとセールスが同意できない限り、彼らは販売を行うことができず、仕事は起こらないことを強調します。そのため、顧客のカウンターオファーに同意する必要があります（小さいスペック、長いタイムフレームなど）。別の顧客を見つける必要があります。
あなたが達成できないことを知っている顧客との契約に署名することは意味がありません。それは単にみんなの時間を費やしてしまい、顧客や他の人を失うリスクがあり、仕事のためのお金さえも得られないかもしれません。
私はこのキャリアの中でこの否定的でポジショナルな分裂をたくさん見てきましたが、それを扱う最良の方法はできるだけ正直で透明であると思います。 （「行動が愚かである」、「手がかりがない」、「実行できない」などの否定的なフレーズは避けてください。解決策/根本的な原因を探してください。）
まず、誰もが採用しているようです ポジション交渉 （ 本 ）。彼らは彼らが望むものを欲し、あなたはあなたが望むものを望んでいますが、本当にそれを推進しているものは何ですか？彼らの位置を動かしているものを見て、それをターゲットにします。例えば。売上高は、より多くの売上高を生み出し、会社の利益を支援するために、できるだけ早く製品を出したいだけです。それの何がいけないの？そして、あなたはあなたができる限り最高の品質のソフトウェアを作りたいと思っています。したがって、必要なのは 中点 を見つけることだけです。これを行うための最良の方法は、教育、誠実さと透明性です。 「私たち対」ではなく、チームの一部として扱います。
アジャイルとスクラムのメソッドは、プロセス全体に これを組み込む を試みます。スクラムの特定の側面はこれをうまく処理します：
- A product owner that prioritizes features and chooses what goes in each sprint. This person is part of the team. This should be a person that has the clients' best intentions in mind. e.g. this could be a sales person or supervisor. They are involved on a regular basis in deciding what goes into the product so there's great motivation and responsibility (they'll learn to NOT Push for time vs quality/features)
- いかなる利害関係者もチームメンバーであり、バックログ/スプリント/タイムラインで制御を取得できません。それらをそのように扱うと、推定の計算方法とソフトウェア開発の背後にある複雑さの継承について学ぶことができます。
- スクラムマスターは、時間の経過とともにプロセスを改善します。どんな状況でも無理なので、すぐにスクラムになるとは思われません。彼らはすべてのチームメンバー（および会社）の障害を取り除くことに取り組んでいます。
要約すると、正直で前向きになり、教育するようにしてください-最終的には改善されます。アジャイル/スクラムを正式にフォローしていなくても、これらの概念と動機をよりよく理解するためにいくつかの文献を読んでください。
あなたの見積もりが正確であり、歴史がこれを使用していることを反映していると感じる場合.
あなたがXX時間を持っていると彼らが言ったとき、それがこの時間まで下がるまで機能を取り出すあなたの見積もりを修正してください。テストを行わないでください。
次に、それは時間だけでなく、機能と時間についての交渉であり、歴史はあなたが変えることができないと言っています。彼らが時間をかけて否定することを主張する場合は、その時間を達成するためのボーナスの否定を開始します（チームがそこに到達するために時間外労働をする意思がある場合）。私たちはあなたが望む時間を作ることができますが、そこに到達するためにあなたに1000ドルのボーナスがかかるとしましょう
ソフトウェア開発は工場のようなもので、工場はX in Yの時間を生産できることを彼らに思い出させてください。再びボーナスに行く、あなたは残業することができますが、それは費用がかかります。残業と呼ばないでください。それも書き留める必要があります。 ZボーナスのY日までのX製品。チームはその後燃え尽きるので、あなたはまた、休みの日を主張するかもしれません。また、通常の時間のX％を超えて機能またはバグ修正を追加すると、スケジュールに時間を追加するという契約を結んでいます。
時間を変更することはできず、機能を取り出すだけです。