Gitpab Senang bertemu denganmu

Halo Saya gitpab . Senang bertemu denganmu. Saya dibuat untuk membuatnya lebih mudah untuk mengawasi programmer. Saya mengambil waktu yang dicatat pengembang di Gitlab dan menghitung siapa yang menghabiskan berapa banyak waktu mengerjakan tugas. Dan untuk proyek secara keseluruhan. Rumor mengatakan bahwa bos besar, dengan bantuan saya, mempertimbangkan gaji para proger dan keuntungan proyek. Dan memang benar. Dengan bantuan saya, Anda dapat meningkatkan margin proyek perangkat lunak. Dan sekarang saya akan memberi tahu Anda bagaimana saya dapat berguna bagi tim Anda dan bagi Anda secara pribadi.

Bagaimana saya bekerja

Saya bekerja tanpa hari libur dan istirahat tidur dan makan siang. Kedengarannya menakutkan, tetapi Anda dapat melihatnya dengan menempatkan saya di server Anda. Untungnya, ada instruksi tentang cara melakukan ini di readme.

Jangan lupa untuk mendaftarkan proyek di konfigurasi yang harus saya ikuti. Saya akan melihat ke Gitlab sekali dalam satu jam dan mengambil yang baru dari sana - sprint baru, tugas, komentar, waktu penghapusan, informasi tentang peserta.

Ke depan, saya akan mengatakan bahwa saya sendiri terlihat seperti ini:



Ini adalah dasbor saya, berikut adalah indikator utamanya. Yang paling menarik dari mereka adalah Balance. Ini mencerminkan berapa jam pengembang telah maju, atau sebaliknya harus membayar saat ini.

Tapi sekarang, mari kita lakukan secara berurutan. Saya memutuskan untuk menceritakan tentang diri saya karena suatu alasan. Faktanya adalah bahwa saya secara pribadi melihat cukup banyak proyek dan manajer proyek yang berbeda. Bukan masalah pribadi, biarkan saya memberitahu Anda tentang tekniknya, ibu kami.

Proyek di gitlab

Saya sendiri adalah pendukung Scrum. Karena Scrum adalah teknik yang terburuk kecuali yang lainnya. Sekarang saya akan menyalin dokumen internal kami di sini, yang harus dibaca oleh karyawan baru kami.

Apa yang hilang

Instruksi singkat, tetapi membantu membangun Scrum di proyek saya. Itu tidak mengatakan sesuatu. Mari kita buat istilah yang modis untuk ini. Masuk! IED. Keren kan? IED. Disiplin Telur Besi. Disiplin Telur Besi. Tanpa perhatian yang layak pada proses pengembangan, setiap instruksi dengan proyek akan macet.

Kenapa saya berguna, Gitpab

Tim yang aktivitasnya menjadi tanggung jawab penulis artikel terdiri dari karyawan non-staf - semuanya bekerja dengan pembayaran untuk waktu yang disediakan untuk proyek. Saya harus mengatakan bahwa mengelola tim semacam itu dengan cara yang berkualitas adalah sedikit permata. Semakin besar tim, semakin sulit untuk melacaknya. Dan ada lebih dari beberapa poin yang harus diperhatikan.

• Apakah ada pengembang yang menutup telepon?
• Apakah mereka dikaitkan dengan tugas lebih dari layak?
• Apakah faktur dikeluarkan khusus untuk karya-karya yang dilakukan selama periode tersebut?
• Berapa banyak kita berutang pengembang sekarang? Dan untuk semua pengembang pada umumnya?
• Apakah kita melampaui anggaran proyek?

Saya, Gitpab, menjawab semua pertanyaan halus ini, di sepanjang jalan, dan menyelesaikan masalah lainnya.

Ditulis waktu

Laporan ini saja layak untuk apa. Di sini Anda dapat menyaring waktu penghapusan sesuai dengan kriteria yang diinginkan.

Biarkan saya menceritakan sebuah kisah. Suatu ketika kami bergerak menuju tenggat waktu. Proyek ini dilakukan dengan cara yang berkualitas tinggi dan bertanggung jawab, semuanya berjalan dengan baik, dan kami telah menyelesaikan pekerjaan, ketika tiba-tiba seminggu sebelum batas waktu 63 komentar dikirimkan kepada kami. Nuansa hubungan Bla-raodny Dons direksi sedemikian rupa sehingga perlu untuk menutup tugas-tugas ini selama seminggu, sehingga kami tidak akan tertunda pembayaran. Ini bukan untuk mengatakan bahwa tugas-tugas ini sangat sulit, ini adalah komentar tentang "menjilati" sistem. Tapi kami melakukan tugas dengan kecepatan 20 per sprint. Maksimum yang dimiliki tim dalam seluruh sejarah proyek adalah sekitar 40 tugas per minggu. Bagaimana cara melakukan satu setengah kali lebih banyak? Menurut penilaian, tugas ditunda selama beberapa minggu.

Tapi kemudian lahirlah pikiran. Tim memiliki saya, Gitpab. Oleh karena itu, penulis mengusulkan kepada pemilik anggaran pada minggu yang sangat penting ini untuk menaikkan tarif satu setengah kali, asalkan tarif ini berlaku khusus untuk komentar-komentar ini. Semua tugas ini diberi label terpisah di Gitlab dan mulai coding. Saya pikir itu mungkin untuk menghibur keputusan seperti itu, tetapi disajikan dengan baik kepada tim. Dan semua 63 tugas ditutup untuk sprint mingguan. Serius. 63 dan berkualitas tinggi.

Untuk menghitung premi, kami cukup memfilter untuk setiap peserta waktu penghapusan untuk label ini untuk periode tersebut.

Tugas Kelas

Mengapa mengevaluasi tugas? Pertama, seperti yang disebutkan di atas, agar tidak mendapatkan terlalu banyak ke sprint. Saya seorang pendukung untuk mengambil tugas selama tim memiliki waktu untuk menyelesaikan kereta. Dan jika ada waktu, ambil sesuatu yang lain untuk bekerja dalam proses. Jadi tim terlihat lebih menguntungkan di depan pelanggan, karena itu membuat janji nyata yang dihormati, dan bahkan membuat sedikit lebih dari yang dijanjikan.

Tetapi ada alasan lain. Cerita lain Tim termasuk pengembang yang ingin menghapuskan lebih banyak waktu untuk tugas daripada nilainya. Dan terkadang 5, dan terkadang 10 kali lebih banyak. Penulis tidak begitu menyukainya. Tapi pengembang ini, harus saya katakan, cocok untuk semua orang kecuali nuansa ini. Tidak ada keinginan untuk berbenturan atau mengatur pertikaian. Saat itu, kami tidak mengevaluasi semua tugas. Di Gitpab, tidak sulit untuk melihat bahwa banyak waktu dihapuskan hanya untuk tugas-tugas yang tak ternilai. Mereka mulai mengevaluasi semua tugas, tanpa kecuali, dan ini membantu.

Dan saya, Gitpab, memberi Anda alat untuk merekonsiliasi perkiraan dan menghabiskan waktu untuk tugas.

Laporan Pelanggan

Sepanjang jalan, saya menghemat waktu pada persiapan laporan tentang pekerjaan yang dilakukan untuk sprint. Lihat, Anda membuka sprint, dan ada laporan yang sudah jadi. Luncurkan tag baru di Gitlab dan salin deskripsi dari sprint di sana. Sudah dalam penurunan harga.



Salin-tempel di Gitlab:



Pelanggan mengakui bahwa senang bekerja dengan tim yang menempatkan Gitlab mereka dalam proyek, dan juga memberikan laporan mingguan terperinci tentang pekerjaan yang dilakukan.

Dan beberapa pelanggan bisnis, kadang-kadang, meminta beberapa daftar tugas gila yang tiada taranya dengan status pelaksanaannya. Dalam kasus seperti itu, sangat mudah untuk membuat label terpisah untuk daftar tersebut dan membongkar tugas-tugas yang difilter oleh label dari waktu ke waktu. Cukup klik tombol "Ekspor ke csv". Sobat, tahukah Anda berapa banyak waktu yang dihemat ...

Uang

Setiap peserta proyek dapat menentukan tarif per jam kerja:



Pengguna dengan hak keuangan melihat bagian ini bersama dengan saldo. Saldo di sini adalah dalam jam - berapa jam prabayar (hijau). Atau berapa jam Anda harus membayar (merah). Nyaman bukan?

Tapi itu belum semuanya. Saat memasang taruhan, Anda dapat menetapkan biayanya - berapa banyak yang harus Anda bayarkan agar seseorang mendapatkan taruhannya di tangannya. Untuk masing-masing, ini adalah persentase.



Tunggu, itu belum semuanya. Ada antarmuka untuk melakukan pembayaran. Di sini Anda dapat melihat riwayat pembayaran, jam pembayaran.



Dan ketika melakukan pembayaran, jam yang dibayarkan secara otomatis dipertimbangkan, dengan mempertimbangkan biayanya.



Jika Anda memiliki karyawan dalam kondisi perbaikan, maka pertanyaan yang masuk akal adalah - mengapa ini bermasalah dengan pemeliharaan pembayaran? Saya setuju, Anda tidak membutuhkannya. Tetapi jika Anda memiliki orang dengan kecepatan per jam, maka alat seperti itu sangat berguna. Saat membayar, Anda tidak perlu membuat laporan tentang waktu yang dihabiskan, mencari di mana laporan itu berakhir terakhir kali. Dan tidak akan ada kebingungan, Anda tidak akan menangkap pekerjaan yang sudah dibayar tanpa sengaja. Dan Anda tidak akan kehilangan waktu yang belum dibayar.

Sekarang yang perlu Anda lakukan adalah melihat saldo karyawan dan memberikan cukup uang kepada orang tersebut untuk membuat keseimbangannya hijau.

Anggaran proyek

Karena Anda sekarang memiliki angka untuk setiap masalah, tidak sulit untuk menghitung jumlahnya. Berkat ini, Anda akan memahami apakah proyek melampaui anggaran:



Statistik serupa dibangun di atas sprint.

Hai Gitpab, dan kapan penulis Anda berhasil?

Menguraikan tugas, memantau kemajuan, mengoordinasikan tim, ditambah semua hal lain yang dijelaskan di atas, plus Anda mungkin berpikir bahwa itu membutuhkan banyak waktu. Tentu saja, ini memakan waktu. Tapi ini jauh lebih baik daripada proyek apung yang tidak terkendali. Jika penulis saya tidak membuat saya, ia akan menjadi manajer yang hilang yang lupa seperti apa IDE itu (jangan bingung dengan IED, lihat di atas). Dan terima kasih kepada saya, dia berhasil mengeluarkan kode tidak kurang dari rekan-rekannya.

Untuk meringkas

Teknik ini dijelaskan di atas dan bagaimana saya dapat membantu Anda mengikutinya menggunakan Gitlab bersama dengan Gitpab. Ini berfungsi baik dalam kasus penulis. Mungkin Anda ingin mengubah sesuatu untuk diri sendiri. Tidak masalah, ubah, sesuaikan sendiri. Pada akhirnya, Anda mungkin memiliki tujuan - untuk melaksanakan proyek-proyek dengan kualitas tinggi dan menghasilkan keuntungan dari mereka, dan saya, Gitpab, hanya membantu Anda dalam hal ini.

Dan sekarang cookie di studio

Ngomong-ngomong, saya diciptakan oleh seorang paman yang baik, penulis artikel ini. Dia begitu baik sehingga dia membuat saya terbuka hati. Saya akan senang tentang bintang di Github .

Saya hampir lupa tentang hal yang paling penting. Saya adalah alat. Dan salah satu kenalan saya, pengusaha sukses dan miliarder Rusia sederhana, mengatakan bahwa alat tidak berfungsi. Orang-orang bekerja. Saya harap Anda mengerti apa yang saya maksud. Manfaatkan, saya siap melayani Anda. Proyek yang sukses.

ps saya melihat ke publikasi dan menemukan banyak minus. Saat Anda memberi minus, jangan malas berkomentar, saya tertarik dengan umpan balik.