知らないことは真似ることからはじめよう
お願いだから、技量が要求やタスクの完了基準に満たないときは、オリジナリティとか創意工夫とか自由な発想とかを思いついて発揮する前に、誰かの確実に完了の定義を満たすタスクのやり方を覚えて欲しいんです。
まずは確実に、約束した日時に完了基準を満たしている成果物をアウトプット出来るようになりましょう。
そして納期に間に合う手段をまずは選択しましょう。
得てして、納期に間に合わない人は自分で一からタスクの進め方を考えてしまうようです。エンジニアが「あったら良いな。」と思うような便利なフリーツールは、誰かが大概作っているものです。見た目が違うとか、すこし仕様が違うとかはあるかもしれないけれど、それでもあるにはあるんです。必要とするタイミングで手元に欲しいと思うツールが無いときに一から作っていたら納期に間に合わないかもしれません。それはそのタスクの納期に依りますが、タスクの工期なんてタスクを集中してやったらこのくらいの日数、でも打ち合わせとかいろいろあるからそれを考慮してこのくらいの日数で、程度のものです。その工期にはツールの仕様を考える時間もツールを作る時間も考慮されていません。それでも必要ならタスクをアサインしたプロジェクトマネージャやSEリーダと交渉しなければ工期は見直されることはないです。
ドキュメント、例えば導入手順書や試験仕様の手順でさえ、一から作るなんてありえないです。プロジェクト指定のひな型があるか、過去の類似のプロジェクトのドキュメントを流用するかがほとんどですし、経験が豊富なエンジニアなら、ドキュメントの構成や体裁を一から作ることがどれだけ大変かを知っています。だから「サンプルを頂戴。」というんです。プロジェクト標準とかなら、ドキュメントの体裁を顧客と一から検討する必要もないし、過去の類似のプロジェクトのドキュメントなら書きっぷりを知っているから顧客への説明も負担ではありません。ドキュメントで一番面倒くさいアクティビティは様式を確定させるところです。あとは、その様式に沿ってコンテンツを書けばいいだけ、というのは少々乱暴ですけどまぁ、そんなものです。
タスクの進捗が遅れる原因は、難易度が高いとか技術的なトラップに嵌るばかりが原因ではありません。前述のようにタスクが求めるスキルレベルとエンジニアのスキルレベルのミスマッチが原因で引き起こされることだってあるのです。
オリジナリティは納期までに完了の定義を満たせるようになってから、です。