任意の期限が開発者にどのように害を与えるか

締め切り自体は悪いことではありません、私はどこか良いとさえ言います。個人的には、ある時間枠に精神的に集中すれば、私の仕事はより生産的になり、プロジェクトに時間枠がまったくない場合、最終的にはそれを傷つける可能性があります。ここで重要なのは、現実的に考え、バランスを保つことです。



締め切りは正当化されなければなりません。 「なぜなら」は正当化ではありません。これは、企業と開発者の両方に影響を与える悪い時間設定の慣行です。幸運なことに、私が働いていた会社のほとんどには、締め切りを選ぶ習慣がありませんでした。しかし、例外がありました。この記事の例として、この種の1つの状況について説明したいと思います。



当時、私はスタートアップで働いていました。フロントエンドチームは3人で構成され、同じサイズのバックエンドチームもありました。私たちはモバイルアプリケーションの更新バージョンに取り組んでおり、明確にマークされた日の前にリリースを満たす必要がありました。 1つの問題：この日は、単純なディレクターまたは技術的なディレクターのいずれかによって、そのような決定の理由なしに任意に選択されました。



ええと、つまり、完全に正当化されていないわけではありません。日を選択するとき、開発者によって宣言された作業のおおよその期間が考慮されました。あなたがコードやそれを書いている人々と一緒に仕事をしているなら、あなたはおそらく問題が何であるかをすでに理解しているでしょう。おおよその日付は常におおよそのものです。つまり、実際に出てくるものとは大きく異なります。そして、それは開発者の無能さについてではなく、プロジェクト全体の作業量を見積もることは非常に難しいだけです。期限を変更する可能性があり、予測することが不可能なことがたくさんあります。



いずれにせよ、私たちの概算は2日間の会議の結果でした。最初に、新しい機能の一般的な概要、次にそれぞれの詳細な分析、さらに詳細な分析...最後に、作業の各段階について、私たちは時間数を見積もり、再チェックし、UXとUIの設計と相関させ、すべてをまとめ、数時間を上に投げました-そしてそれが作業の締め切りでした。



あなたはおそらく今考えているでしょう：まあ、彼らのUXとUIデザインはすでに準備ができていて、さらに多くの時間が予約されているので、おそらく、すべてがうまくいくはずですか？ほとんどの場合、日付を設定すると条件が悪化します。まあ、一般的にはありません。何もうまくいきませんでした。

作業期間は3〜4週間に設定されていました。少人数のチームで新製品のリリースについて話す場合、それほど時間はかかりません。もちろん、最初の2週間後、私たちはすでに予定より遅れていました。彼らがプロジェクトにゆっくりと取り組んだり、数時間を費やしたからではなく、すべてが常にうまくいかないからです。



バックエンドは、アプリケーションのAPIの実装を熟考していましたが、システムが単純なアドオンと正常に対話できないことが突然判明しました。つまり、この状況を考慮して、準備済みのAPIフラグメントを書き直す必要がありました。アカウント。エンドポイントを確定するのに予定外の2日かかりました。



この小さな変更により、APIはディスカッション段階で意図されていたものとは少し異なる動作を開始し、アプリケーションの個々の部分を書き直す必要が生じました。これは数時間の作業です。このような書き直しは、あらゆるサイズのモバイルアプリで一般的であり、誰も驚かないはずです。しかし、締め切りは厳しいです。そして今、私たちは適合できません。



それで、あなたは何ができますか？翌日、また先に進むにはさらに4時間働かなければならないと言われました。通常の8時間労働に加えて4時間。ええ、もちろん、私たちは栄養を与えられましたが、そのような12時間のシフトでは脳に役立つものは何もなく、そうすることはできません。それにもかかわらず、私たちはなんとかスケジュールに追いつき、追いつくことができました。



1週間後、アプリケーションがリリースされました。私たちは嬉しかったです、誰かが祝うためにいくつかのカップケーキを持ってきました、そして5分後、誰もがすでにモニターに座っていて、何も起こらなかったふりをしていました。



このアップデートでは、1日後ではなく、この特定の日にリリースする必要性を動機付けるほど重要なものは何もありませんでした。新しいバージョンが準備されていることをユーザーは誰も知りませんでした。誰も（クライアントも投資家も）日付に基づいて計画を立てませんでした。はい、機能は便利ですが、1日後にリリースされた場合、誰かが気分が悪くなるでしょうか？それは誰かに影響を与えるでしょうか？



しかし、開発者は影響を受けました。あちこちで人々はお互いに不快感を注ぎました。チームと経営陣の関係は明らかに損なわれました。そして、これは孤立したケースではありません。これは、私がそこで働いていたときに頻繁に発生しました。その頻度は、数か月に1回程度です。



そして、これらすべてからの結論は何ですか？いつでも完全に諦めますか？もちろん、そうではありません。記事の冒頭で述べたように、期限は実際には便利であり、私自身も期限を設定する方が簡単だと感じています。しかし、それらは厳格なコミットメントとしてではなく、ガイドラインとしてとらえるべきです。製品が数日後に発売された場合、それは世界の終わりと見なされるべきではありません。開発者に不必要なプレッシャーをかけることのポイントは何ですか？それとも、コードの品質がそのような行進の影響を受けないと思いますか？



不可抗力の旗印の下、夕方遅くに仕事をした後、さらに何時間も運動したとき、一般的な気分は「だから、できるだけ早くそれを終わらせる必要がある」でした。多くの場合、しばらくは機能し、その後リファクタリングが必要になるあらゆる種類の松葉杖ソリューションが導入されました。対応するリファクタリングがすぐにスケジュールされた場合もあれば、安全に忘れられた場合もあります。そして、開発者自身が、疲れていて家に帰りたいと思っていたので、自分たちが何か松葉杖をしていることに本当に気づいていなかったのです。



リファクタリング（それが起こった場所）に関しては、不可抗力自体よりもおそらくリソースの方が多いでしょう。急いで書かれたコードの一部にバグが現れ始めました。アプリはすでにリリースされていたので、特にみんなの神経質になりました。



私の見積もりによると（私は統計を収集しなかったので、保証することはできません）、この処理は短期的にしか役に立ちませんでした。はい、時間どおりにアプリケーションをリリースしました。そして、多くが書き直されていたので、次のリリースはすでに延期されなければなりませんでした。開発者たちは不満を持っていて（そして、あなたが推測したように、彼らは積極的に辞めていました）、チームの雰囲気は緊張しました。また、リリース後にユーザーが遭遇したバグの結果はまだ考慮されていません。

どのようにそれが必要ですか？

すべてを効率的に実行したい場合は、熱を出さないで、開発者の話を聞き、進捗状況を追跡してください。チームが適合せず、緊急の理由がない場合は、期限を移動してください。恣意的ではありませんが、現段階では十分ではありません。開発者に、遅延とリスクの潜在的な原因を伝えるように促します。誰かが明らかに一般的なスケジュールに合わないものを見た場合、計画している人の注意を引く価値があります。そうすれば、彼は推定日を修正する機会があります。



あなたは前もってすべてをしましたか？まあ、そのような状況では、誰もが勝つだけです。また、テストを適切に行うことができ、開発者にコードベースの何かを改善する機会を与えることができます。あなたが開発者であるか、仕事のために開発者とコミュニケーションをとっているなら、あなたはあなた自身が知っています：あなたが引き締めたいコードの場所は常にあります。1時間しかかからない場合もあれば、数日かかる場合もあります。コードをより良く、より正確にするために時間を無駄にしない方が良いです-私たち全員が確認できるように、アプリケーションには十分な欠点があり、ユーザーの誰もが理解することはありません。