プログラマーは締め切りを作るのが好きですか? 私は Web 開発者であり、私の分野ではスケジュールや締め切りがあちこちにあります。しかし、締め切りを嫌うソフトウェア エンジニア/プログラマーと仕事をしたことがありますが、それを回避する方法はありますか?
4649 次
8 に答える
32
まず、締め切りと見積もりを区別する必要があります。
- 締め切りは、「機能 X はトレード ショーの準備が必要」などの外部ソースから来ます。
- 見積もりは内部情報源から得られます。たとえば、「機能 X の完成には N 週間かかります」などです。
一般に、プログラマーは見積もりを作成する必要があり、セールス/マーケティングは締め切りを作成します。
この 2 つが解決できない場合、つまり締め切りが見積もりよりも迫っている場合に問題が発生します。
開発者 (リード) に役立つヒント:
- 作業を行う人に見積もりを作成してもらいます。
- 見積もりは、それぞれが 1 日か 2 日以内の小さなタスクに基づいていることを確認してください。
- フィードバック ループを使用して、開発者が見積もりスキルを向上できるようにします。
- 正確な見積もりスキルにより、締め切りの要求に対してより強くプッシュできます。
マーケティング担当者や締め切り作成者に役立つヒント:
- 見積もりを締め切りで上書きしないでください。
- 締め切りが見積もりと矛盾する場合、唯一の現実的なオプションは、(a) 開発者が残業する、(b) 締め切りの要件を調整する、または (c) 締め切りに間に合わないことです。
- 締め切りが重要な理由と、機能の締め切りの目的を説明します (「顧客 X は 6 桁の契約に署名します」)。
- 厳しい締め切りに間に合わないと感じている人はやる気にならないことを理解してください。
于 2008-12-19T14:36:22.720 に答える
10
プログラマーは非常に正当な理由で締め切りを嫌います!
コードの一部が設計、作成、およびデバッグにかかる時間を、実際に実行するまで正確に見積もることはほとんど不可能です。
私の個人的な経験から言うと、「単純な」シェル スクリプトを動作させるのに 1 週間以上費やしましたが、これには約 1 時間かかると見積もっていました。一方、COBOL データ定義のパーサーを作成するのに約 1 週間かかりました (すべての奇妙な COMP COMP-3 OCCURS が SYNC とスラック バイトを再定義します)。
もう 1 つの大きな問題は、厳しい締め切りに直面すると、プログラマーがベスト プラクティスをスキップしてハッキングを開始することです。したがって、コーディング時間の約 50% を節約できますが、テストとデバッグの時間は 300% 追加されます。
于 2008-12-19T14:37:25.277 に答える
5
従来、調整できるのは品質、機能、または時間のみで、最後は締め切りでした。あなたが本当にいじりたくない品質。あなたが使用しているプロセスで機能を調整して締め切りに間に合わせることができる限り、私は問題ありません。
于 2008-12-19T14:35:39.633 に答える
5
開発者は期限の作成に関与する必要があります。それらが恣意的であり、開発者からの入力なしに作成された場合、彼らには文句を言う権利があります. プロジェクトは当然のことながらビジネスから時間の制約を受けますが、それを補うためにリソースと機能を調整する必要があります。これらの調整は、開発者 (BA、QA、および運用担当者は言うまでもありません) からの入力なしでは行うことができません。
于 2008-12-19T14:38:01.093 に答える
4
私が会った唯一のソフトウェア エンジニア/開発者で、締め切りが嫌いな人は、次の 2 つの理由のいずれかでそのように感じています。
- 彼らは完全にまとまりがなく、締め切りに間に合わないことを知っているため、締め切りに間に合わないと見栄えが悪くなるため、好きではありません。
- 仕事の内容を理解している人が締め切りを設定している限り、彼らは締め切りに問題はありません。最悪の締め切りは、マネージャーがプロジェクトを売り込もうとして「3 週間? 問題ない!」と言うものです。そして開発チームに、動作するバージョンの MS Office を作成し、CEO の小さな子供のためにインターネットを再構築するのに 3 週間かかることを伝えます。
于 2008-12-19T14:38:18.833 に答える
2
スケジュールの立て方次第だと思います。開発者は、スケジュールを立てる上で重要な役割を担う必要があります。そうでなければ、それが合理的かどうかをどのように知ることができますか?
上層部の誰かが、「機能 X は Y が行う必要がある」とだけ指示するだけで、実際にかかる時間について十分な洞察が得られない場合 (いくつかのことは、見た目よりも実装がはるかに複雑です)、それは悪いことです。もの。ただし、開発者と協力して実際に必要な作業量を見積もり、それを会社の残りのニーズとバランスを取れば、通常はうまくいきます。
于 2008-12-19T14:34:37.793 に答える
1
定期的なレビューは非常に重要です。
- 主なマイルストーンと成果物を列挙する
- それをより小さなチャンクに分割します
- より小さな見積もりのコレクションを作成する
- 期限を合理的にする
締め切りが必要ですが、同様に、それらの締め切りは現実的で測定可能でなければなりません。仕様を変更することは、開発者を悩ませることになります - やむを得ないことかもしれませんが、(議論の後で) 変更することを恐れないでください。
締め切りと作業の見積もりが特に正確になることは決してありませんが、基本的なプロジェクト管理のテクニックは、人々がそれらを見逃していること、そしてなぜそれが起こったのかを認識していることを意味するはずです.
于 2008-12-19T14:37:02.360 に答える
1
マネージャーとエンジニアの両方からの意見を取り入れたよく考えられた見積もりプロセスを通じてその期限が決定され、その期限に納品されるはずの要件が明確に定義されている場合、私はその期限に非常に満足しています.
于 2008-12-19T14:33:02.633 に答える