Pisahkan waktu fokus dan waktu respons
Untuk pekerjaan seperti desain atau debugging yang membutuhkan pemahaman konteks dalam waktu lama, jadwalkan satu blok waktu di kalender. Pagi hari tidak selalu cocok untuk semua orang. Pilih waktu ketika Anda benar-benar dapat berkonsentrasi, dan sepakati terlebih dahulu dengan tim cara menerima kontak darurat.
Uraikan pekerjaan menjadi tindakan berikutnya
Jika hanya menuliskan nama besar seperti “mengembangkan fitur pembayaran”, titik awalnya tidak akan terlihat. Uraikan menjadi tindakan berikutnya, seperti memeriksa kebutuhan, menulis kondisi kegagalan, menambahkan pengujian, mengimplementasikan, dan meminta review. Tentukan prioritas harian berdasarkan tenggat, dampak bagi pengguna, dan apakah orang lain sedang menunggu pekerjaan tersebut, bukan dengan memaksakan jumlah tertentu.
Gunakan timer sebagai alat pilihan
Pomodoro adalah metode untuk fokus selama waktu tertentu lalu beristirahat. Jika 25 menit tidak cocok, gunakan interval yang lebih pendek atau lebih panjang. Anda juga tidak perlu menggunakan timer jika justru mengganggu alur kerja. Yang penting adalah menentukan satu hasil sebelum mulai dan mencatat tindakan berikutnya setelah selesai.
Pastikan tujuan rapat sebelum durasinya
Jika hal yang harus diputuskan, peserta yang diperlukan, dan bahan persiapan belum jelas, periksa terlebih dahulu apakah semuanya dapat digantikan dengan dokumen atau pesan. Untuk hal yang membutuhkan percakapan cepat, seperti diskusi desain yang kompleks, adakan rapat, tetapi catat keputusan, penanggung jawab, dan tanggal pengecekan berikutnya sebelum rapat berakhir. Tidak semua rapat harus dijadwalkan pada sore hari atau dibatasi hingga 30 menit.
Masukkan waktu menunggu review ke dalam jadwal
Setelah menulis kode, masih ada waktu untuk review, perbaikan, pengujian, dan deployment. Dalam rencana kerja, masukkan bukan hanya waktu untuk pekerjaan Anda sendiri, tetapi juga waktu yang dibutuhkan orang lain untuk memeriksanya. Bagi perubahan besar menjadi unit yang mudah direview, dan sertakan alasan perubahan serta cara memverifikasinya untuk mengurangi bolak-balik.
Pilih otomatisasi berdasarkan frekuensi dan biaya kegagalan
Tidak semua hal perlu diotomatisasi hanya karena membutuhkan 5 menit setiap kali dilakukan. Uji otomatisasi kecil terlebih dahulu untuk pengujian yang sering diulang, pemeriksaan format, atau pengecekan sebelum deployment—terutama hal yang mudah terlewat oleh manusia. Jika waktu pemeliharaan lebih besar daripada waktu yang dihemat, daftar periksa sederhana mungkin lebih baik.