Untuk melihat bahasa pemrograman baru dan sejauh ini kurang dikenal dalam sebuah startup kecil atau proyek kesayangan bersama teman adalah hal yang lumrah. Anda akan bertanya mengapa mereka mengambilnya, mereka akan mengatakan bahwa Anda baru mempelajarinya karena penasaran, menyukainya dan memutuskan untuk bereksperimen, karena Anda bosan dengan Java / .Net / JS yang kekal di tempat kerja.
Tetapi jika sebuah perusahaan berbicara tentang dirinya sendiri dalam frasa seperti "bisnis internasional", "kantor di seluruh dunia", "kultus produktivitas", "hasilnya penting bagi kami, bukan prosesnya", "kami membutuhkan mata yang menyala-nyala dan keinginan untuk berkembang" - biasanya mereka tidak menunggu kejutan. Beberapa bahkan menempatkan stoplists pada teknologi baru sampai mereka menambah berat dalam industri. Untuk pertanyaan tentang berbagai kekurangan alat, katakan: "yang utama adalah orang, bukan bahasa."
Wrike, dengan sekitar 400 pengembang, memiliki pendekatan yang berbeda. Mereka tidak menutup mata terhadap kekurangan JavaScript dan bahkan tidak memilih kompromi, seperti Flow atau TypeScript - tetapi pergi dengan cara yang sepenuhnya radikal. Mereka menulis ulang bagian depan menjadi bahasa yang tidak diketahui oleh ribuan orang saat itu, dan, tampaknya, masih sangat percaya diri.
Wrike menempati posisi ketiga terhormat di antara perusahaan-perusahaan menengah di peringkat pemberi kerja terbaik di My Circle IT dengan peringkat rata - rata 4,82. Kualitas paling tinggi dari perusahaan termasuk: paket sosial, kondisi kerja yang nyaman, hubungan dengan rekan kerja, gaji yang memadai dan pertumbuhan profesional.
- Wrike didirikan oleh Andrey Filev pada 2007 di St. Petersburg. Kemudian dia mulai mengembangkan bisnis di Amerika, di Silicon Valley. Lalu itu adalah perusahaan yang sama sekali berbeda, dan sekarang kami telah berkembang pesat.
Pada awalnya, Andrey memiliki perusahaan outsourcing. Mereka mulai mencari perangkat lunak di dalamnya yang akan membuatnya bekerja lebih efisien - untuk mengatur waktu dan sumber daya. Tidak ada alat yang sangat keren pada waktu itu, dan muncul ide untuk membuat sendiri. Kemudian Wrike lahir.
Kami mulai dengan hal-hal sederhana, tetapi secara bertahap produk mulai tumbuh. Ini 12 tahun yang lalu, dan kita dapat mengatakan bahwa kita mengambil bagian dalam pembentukan pasar untuk sistem manajemen kerja seperti itu. Wrike sekarang digunakan oleh lebih dari 18.000 perusahaan di seluruh dunia.
- Apakah perusahaan outsourcing itu masih ada?Ya, ini disebut Perangkat Lunak Murano. Tapi dia tidak ada hubungannya dengan kita. Wrike adalah perusahaan produk tunggal lengkap, yang merupakan percobaan dalam kerangka perusahaan outsourcing, tetapi melonjak dan berpisah dengan sangat cepat.
"Apakah mereka masih menggunakannya di sana?"Ya, tetap saja.
Apa itu Wrike
Wrike adalah platform untuk manajemen dan kolaborasi proyek dalam arti yang sangat luas: dari daftar pekerjaan pribadi hingga sistem yang cocok untuk perusahaan besar.
Di dalam, Anda dapat membuat proyek dengan banyak tugas dan subtugas, menyiapkan laporan untuk pengumpulan data, menampilkan bagan Gantt, melacak tugas dalam kalender, dan mengeditnya secara bersamaan dengan peserta lain. Pengaya tambahan membantu Anda mengelola beban kerja Anda secara langsung atau menjalankan kampanye pemasaran multi-channel yang kompleks. Ada API untuk diintegrasikan ke alat lain. Ada ekstensi, misalnya, untuk Adobe Creative Cloud. Ini memungkinkan Anda untuk melihat dan mengomentari file tanpa meninggalkan sistem.
Wrike tidak berupaya fokus pada fungsi, industri, atau profesi tertentu. Ini diposisikan sebagai alat universal untuk semuanya - hingga menggantikan sistem surat, messenger, basis pengetahuan, pelacak bug dan banyak lagi.
- Mengosongkan fokus pada semua orang dan untuk segala sesuatu tidak membuat bagian individu lebih buruk?- Kami sengaja tidak masuk ke ceruk profil sempit. Misalnya, kami tidak ingin melakukan sistem pelacakan bug khusus untuk pengembang seperti Jira. Kami tidak ingin membuat perangkat lunak hanya untuk programmer atau hanya untuk desainer. Kami tertarik untuk membuat produk universal. Pada saat yang sama, kami memahami bahwa ada beberapa kasus khusus yang tidak kami bahas.
Tapi ini bukan tujuan kami - untuk menyenangkan semua orang, atau untuk sepenuhnya menempati ceruk TI. Meskipun kami, mengembangkan Wrike, menggunakannya sebagai sistem untuk tugas dan pelacak bug.
- Artinya, Anda dapat mengambil pelacak bug lebih cepat, messenger lebih cepat, tetapi itu akan menjadi lima alat yang berbeda dan akan sulit untuk menyinkronkan di antara mereka.
- Tetapi kemudian Anda harus bersaing dengan semua orang. Atlassian di satu sisi. Kendur sebagai utusan - di sisi lain.- Ya, sekarang hanya yang malas yang tidak mengembangkan sistem manajemen proyek dan produk.
- Tetapi pada kenyataannya, tidak banyak perusahaan yang akan bersaing dengan kami dalam semua hal.
- Bukankah Atlassian seperti itu?- Dia lebih fokus pada pasar IT. Misalnya, untuk desainer Jira terlalu rumit.
Sangat sulit untuk menyesuaikan. Bahkan ada profesi - Jira Setup Manager. Kami mencoba memastikan bahwa Anda pergi ke situs, mengambil akun gratis dan itu saja - sejak hari pertama Anda dapat menggunakannya tanpa masalah.
- Tetapi Anda mengatakan bahwa Anda juga bekerja sama dengan klien dan juga mengarahkan manajer yang membangun proses.Ya, kami memiliki tim manajer Keberhasilan dan Penempatan Pelanggan, serta seluruh sistem tur, panduan, e-book, dan semua jenis dokumentasi. Ada manajer yang akan membantu Anda mengonfigurasi Wrike untuk proses yang sudah jadi. Terkadang mereka bekerja dengan klien satu-ke-satu yang besar. Terkadang langsung dengan banyak (misalnya, rekaman webinar). Bahkan jika seseorang mendaftarkan uji coba dan tidak memahami produk, ia akan memiliki kesempatan untuk mengobrol langsung dengan salah satu rikers dan memahami cara kerjanya.
- Secara umum,
memperkenalkan produk ke perusahaan dengan ribuan pengguna adalah tugas lain.
- Kebetulan sangat sulit dengan salah satu klien besar?Biasanya semakin besar perusahaan, semakin banyak proses kerja yang dimilikinya - semakin sulit untuk bekerja. Kami, tentu saja, bukan outsourcing. Tidak ada semacam kantong uang datang dan berkata: "Ini ada banyak uang untukmu, lakukan padaku hal seperti itu." Manajer produk kami menentukan jalur pengembangan produk itu sendiri. Tetapi ada pelanggan dengan permintaan menarik.
Airbnb, misalnya, menggunakan platform dalam kasus yang sangat tidak biasa. Setiap apartemen dan setiap orang yang menyewanya adalah proyek terpisah di Wrike.
Atau perusahaan mobil Coil [nama diubah]. Pelanggan memesan suku cadang dari mereka. Memberi orang-orang ini akun Wrike hanyalah sebuah ide. Anda tidak akan masing-masing pemilik Coil melakukan akun Anda. Tetapi perusahaan benar-benar menginginkan kesempatan yang nyaman untuk bekerja dengan pelanggan.
Tentu saja, kami tidak mengatakan bahwa saat ini kami akan membuat fitur seperti itu untuk mereka. Tetapi manajer menyadari bahwa dia akan meningkatkan produk secara keseluruhan. Ini adalah bagaimana "formulir permintaan eksternal" muncul untuk orang-orang yang tidak memiliki akun Wrike.
- Ternyata, apakah Anda melakukan untuk Coil [nama diubah], tetapi apakah itu cocok untuk orang lain?"Tidak juga." Kami secara bersamaan menganalisis pasar dan berhipotesis - tugas ini terletak pada peta jalan potensial. Jika ada permintaan yang tidak sesuai dengan kami sama sekali, kami tidak akan melakukannya.
Struktur internal Wrike
Kami bekerja di Scrum. Perusahaan ini dibagi menjadi beberapa tim berdasarkan fitur - masing-masing sekitar 10 orang. Mereka memiliki komposisi yang berbeda, tetapi masing-masing memiliki backend, frontend, scrum-master, QA, otomatisasi QA, perancang UX, obouner produk, analis produk (analis kadang-kadang datang dalam beberapa tim). Komposisi seperti itu berfungsi penuh dan dapat membuat fitur dari dan ke.
Ada tim internal yang membuat kerangka kerja, komponen, kit desain, dan terlibat dalam transisi dari satu versi bahasa pemrograman ke yang lain.
Beberapa tim adalah hal biasa bagi seluruh perusahaan. Sebagai contoh, ini adalah SysOps, yang bergerak dalam infrastruktur server, dan DevOps - mereka terlibat dalam penyebaran dan pengiriman produk. Kami memiliki rilis dari satu hingga 3 kali sehari.
Kami juga sebagian menggunakan struktur Spotify yang terkenal dengan guild. Misalnya, frontend, di mana front-end terdiri dari semua tim. Ada ujung depan yang berhubungan dengan manajemen dan arsitektur. Dan ada lead guild.
Kami belum mencapai titik mengisolasi mereka dari tim. Tetapi secara umum itu logis dan organik. Sekarang orang-orang dengan keterampilan arsitektur teknis tinggi berada dalam tim infrastruktur.
Wrike sebenarnya bukan tentang struktur birokrasi. Tetapi ini tidak berarti bahwa kekacauan sedang terjadi di negara kita. Jika seseorang melakukan apa yang dia suka dan melakukannya dengan baik, maka dia akan memiliki peluang untuk tumbuh, terlepas dari posisi apa yang dia duduki.
- Dan di kantor apa yang sedang dilakukan?- Di kantor r'n'd rekayasa St. Petersburg dan Voronezh. Kami memiliki 400 orang di St. Petersburg dan 40 di Voronezh. Ada kantor di San Jose, San Diego. Kantor di Praha akan dibuka tahun ini. Kantor baru-baru ini diperluas di Dublin. Pada bulan Januari tahun ini, kantor dibuka di Melbourne, Australia.
- Di kantor Amerika kami memiliki departemen penjualan, pemasaran, manajer (CSM). Dublin juga memiliki CSM dan penjualan. Ada juga tim analis. Di St. Petersburg - kantor terbesar dan menyatukan. Di sini kami memiliki manajer layanan pelanggan, manajer produk, analis, desainer, pengembangan dan back office.
- Apakah semua orang bekerja di kantor atau Anda membuka lokasi terpencil?- Perintah scrum jarak jauh sangat sulit. Kami ingin orang-orang dekat dan berhubungan satu sama lain. Di departemen yang mungkin melibatkan pekerjaan jarak jauh (misalnya, Dukungan Pelanggan), kami tidak membatasi banyak orang.
- Udalenka dalam pengembangan - titik diperdebatkan. Sekarang ada banyak pembicaraan tentang itu, di Twitter berbahasa Inggris kami terus-menerus membahas topik ini. Ada pro dan kontra. Menurut pendapat kami, ada lebih banyak "kontra". Sebagai manajer tim, akan sulit bagi saya untuk memastikan produktivitas dan semangat bersama, untuk tumbuh dan melatih karyawan yang jauh.
Kami memiliki jadwal yang cukup fleksibel, orang tidak duduk di kantor ketat dari sepuluh hingga enam. Jika ada stand-up, mohon berbaik hati - datanglah, dan ketika itu berlalu dan berapa lama, tim akan memilih sendiri. Jika sesuatu terjadi, juga tanpa masalah - orang tersebut menulis bahwa ia bekerja dari rumah.
- Ketika produk internasional, pengembang sering diminta memiliki pengetahuan bahasa Inggris yang baik untuk berbicara dengan pelanggan.- Kami tidak memiliki pelanggan, kami bukan agen outsourcing. Perusahaan ini bersifat internasional, dan bagian dari komunikasi memang dilakukan dalam bahasa Inggris, tetapi ini tidak berlaku untuk semua orang. Untuk pengembang di Rusia, kami tidak memiliki persyaratan khusus untuk bisa berbahasa Inggris.
Sebulan sekali ada pertemuan di mana kita berbicara tentang semua perubahan dalam perusahaan dan kinerja keuangan. Komunikasi dengan dukungan dilakukan dalam bahasa Inggris. Tiket dengan bug pelanggan juga, tentu saja, dalam bahasa Inggris. Bagi mereka yang ingin memperketat atau belajar bahasa, ada kesempatan seperti itu - kami memiliki kelas yang berkelanjutan dengan guru, untuk karyawan mereka bebas.
Tetapi pendapat saya adalah bahwa jika seorang pengembang tidak mulai mengembangkan kemarin, dia tahu bahasa Inggris setidaknya di tingkat membaca dokumentasi. Tanpa lidah, Anda bahkan tidak dapat google apa pun.
Tentu saja, para pengembang mungkin tidak memiliki aksen Inggris yang benar dan tidak ada Oxford di belakang mereka, tetapi mereka biasanya dapat berbicara dan membaca sesuatu.
Mengapa Dart Lebih Baik dari JavaScript dan TypeScript
- Sekarang semua ini adalah sistem rumit yang besar. Tapi itu tumbuh dari pengembangan internal sejak lama dan telah banyak berubah sejak saat itu. Karena itu, tidak ada kesalahan perhitungan arsitektur yang sekarang mengganggu kehidupan?- Tentu saja, proyeknya besar. Kami memiliki backend baik satu setengah, atau dua juta baris kode Java. Ujung depan juga sebanding. Tapi saya tidak tahu satu orang pun yang dapat merancang sistem selama lima tahun di muka, dan itu akan berkembang tanpa membangun kembali.
Kebetulan ada sesuatu yang jatuh. Terkadang kita menyadari bahwa dua tahun yang lalu adalah bodoh. Tapi ini wajar dari sudut pandang insinyur. Bagaimana lagi?
- Oleh karena itu, ada tim internal yang secara berkala menulis ulang bagian lama.
- Ya, saya kadang-kadang mengatakan bahwa kita perlu duduk dan refactor, kalau tidak itu akan menembak sehingga semuanya akan ditembak. Kami duduk dan refactor. Arsitektur mengganggu - kita membuat arsitektur.
- Apa tumpukan Anda?- Di backend Java. Database SQL. Di ujung depan, hal yang menarik. Sekali waktu kami memiliki JavaScript, tetapi kami menyadari bahwa itu tidak skala sama sekali dan memilih Dart.
- Apa yang kamu pilih ??- Dart. Ya, ini adalah reaksi normal. Bahasa yang diketik dari Google, yang sekarang hampir tujuh tahun. Kita mungkin adalah penginjil paling penting dari tumpukan ini di Rusia.
- Yang paling penting atau satu-satunya?- Omong-omong, sekarang ini sedang aktif berkembang. Google meluncurkan Flutter - ini adalah kerangka kerja seluler yang ditulis hanya pada Dart. Ada
Komunitas Dart Rusia yang telah kami buat dan dukung. Sudah ada sekitar satu setengah ribu orang. Tentu saja, dengan standar JavaScript, ini tidak terlalu mengesankan, tetapi juga banyak.
Desember lalu, kami menyelenggarakan
konferensi DartUp - ada aula besar dan banyak orang datang. Dan banyak yang benar-benar menggunakan Dart dalam produksi. Bahasa ini berkembang secara bertahap, dan itu sangat keren.
"Jadi kita menunggang kuda sekarang." Mengatakan "di dunia" mungkin sok, tapi, sebenarnya. DartUp adalah konferensi Dart terbesar di dunia. Bahkan lebih dari Google.
- Ada sekitar tiga ratus orang di konferensi. Meskipun dua tahun lalu sepertinya kami sendirian di bidang pejuang.
- Ini semua menarik, tetapi bagaimana mengerjakan proyek skala besar, jika Anda tidak mempekerjakan orang, tidak ada perpustakaan atau kerangka kerja.- Ini adalah kekeliruan. Baru-baru ini, kami mengambil seorang pria di tim yang pada umumnya Dart merupakan bahasa pemrograman pertama.
- Di Dart, semuanya ada di sana. Ini adalah bahasa dari kategori C # dan Java - semua yang Anda butuhkan ada di sana. Dan umumnya tidak benar bahwa semuanya kosong di sana dan jatuh berguling-guling. Bahkan ada lebih banyak built-in daripada dalam beberapa bahasa dua puluh tahun. Perpustakaan, alat, dukungan kerangka kerja - Angular juga ada di sana.
Tentu saja, tidak ada infrastruktur seperti di JS. Tetapi masalahnya adalah ketika orang menulis jutaan perpustakaan, mereka mendapatkan jutaan perpustakaan buruk. Dan mungkin hanya seratus yang normal.
Dan jika perpustakaan ditulis oleh Google, yang menggunakan Dart di AdWords dan AdSense, maka kualitas rata-rata jauh lebih tinggi.
Keindahan bahasa ini sederhana dan mirip-C. Artinya, kami mempekerjakan pengembang di C ++, C #, Java, JavaScript - siapa pun. Kami tidak memerlukan pengetahuan tentang Dart. Secara alami, tidak ada pengembang panah di jalan.
Di tim saya ada pengembang dengan pengalaman C Sharp, siapa tahu. Di depan, dia bahkan tidak pernah menulis. Dan dalam lima hari dia membasahi fitur. Karena bahasanya seolah-olah Anda telah menulisnya sepanjang hidup Anda.
Dalam cara yang baik, insinyur pengembangan menulis logika bisnis, tidak peduli bahasa apa.
"Tetapi orang-orang tidak mulai menulis dalam bahasa mereka yang lama?" Julukan JS yang sama berasal dari bahasa dinamis ke bahasa statis.- Karena itu, proses seleksi kami bukanlah yang termudah. Tapi adil dan jujur.
- Ok, mengapa bahasanya bagus?Saya akan mengatakan itu adalah salah satu yang diketik paling kuat yang mengkompilasi di JS. Ketika kami duduk di ujung depan empat tahun yang lalu dan ada sekitar 8 dari kami - Anda setidaknya dapat menutupi diri Anda dengan segala macam linter, aturan, semua yang ada di dunia - tetapi dia masih akan kehilangan sesuatu. Kami membutuhkan pengetikan statis, seketat mungkin.
Di Dart, jika Anda menulis sesuatu yang salah, Anda akan segera memahaminya. Ini memiliki deteksi kesalahan sebelumnya, yang memungkinkan bahkan tanpa menguji kode untuk memahami apakah itu berfungsi atau tidak.
Tidak ada kekacauan di perpustakaan bawaan saat yang satu diperbarui dan yang lainnya jatuh. Karena SDK disediakan dengan bahasa, yang memastikan bahwa semuanya berfungsi setelah peningkatan. Anda tidak perlu menghubungkan satu juta perpustakaan untuk mendapatkan aliran dan aliran - semuanya sudah ada di sana.
Sekarang di dunia ada dua bahasa yang memungkinkan Anda menulis untuk semua platform - untuk seluler, untuk backend, untuk desktop, untuk web. Ini JS dan Dart. Kontra JS tahu berapa banyak. Dan Dart memiliki nilai tambah yang besar.
Karena itu, hanya ada satu bahasa yang diketik keras yang memungkinkan Anda menulis untuk semua platform dengan penyetelan normal. Banyak yang mengutip Kotlin sebagai contoh, tetapi untuk web itu tidak terlalu.
- Sekarang Anda tidak menyesal bahwa, misalnya, TypeScript tidak dipilih?- Tidak sekarang, tapi pada prinsipnya kita tidak menyesal. Saya menyarankan Anda untuk melihat laporan oleh Victor Logov dari JetBrains di konferensi HolyJS [
Pembicara mungkin bingung nama, dan itu adalah laporan oleh Anton Lobov ].
Mereka membuat dukungan TypeScript dalam produk mereka, dan itu hanya menempatkan TS di rak di sana, secara wajar. Dan setelah itu tidak ada keinginan sama sekali untuk mengambilnya. Seseorang mendapatkan perasaan bahwa fitur muncul di dalamnya pada prinsip "Mari kita tambahkan ini? Ayo. "
- Agar saya percaya, katakan apa yang buruk di Dart? Mungkin tidak semuanya sempurna.Dengan mudah. Ada masalah, tetapi tidak dengan bahasa, tetapi dengan Google. Mereka menggunakan banyak alat di dalamnya, yang tidak mencari-cari. Kami sekarang memiliki saluran langsung dengan Google, kami adalah bagian dari sejumlah organisasi internal, dan mereka perlahan-lahan membagikan alat-alat ini.
Tetapi ini hanya relevan bagi kami, untuk basis kode yang sangat besar. Proyek kecil tidak memiliki masalah sama sekali.
- Setelah pengalaman dengan Dart, Anda tidak ingin mengganti Java dengan Go?- Kenapa? Kami memilih Dart sesuai dengan parameter tertentu. Itu adalah keputusan yang seimbang.
- Salah satu pembicara kami mengatakan bahwa ada perusahaan yang menulis ulang semuanya dengan teknologi baru, dan ada perusahaan yang menghasilkan uang. Menulis ulang seharusnya tidak menjadi tujuan itu sendiri. Ada tugas bisnis, dan ada alat yang harus mengimplementasikannya.
- Kami sedang bereksperimen dengan berbagai teknologi. Jika pada titik tertentu kami memahami bahwa Go berfungsi lebih baik, maka kami akan mencoba.
Di ujung depan, kami bergerak menuju aplikasi independen. Ada monorepositori di backend. Ada banyak keuntungan untuk ini, tetapi ada juga kelemahan tertentu - Anda dapat membicarakan hal ini untuk waktu yang lama. Kami melihat ke arah arsitektur layanan-mikro berdasarkan apa yang akan berguna dalam lingkungan kami.
Arsitektur microservice berfungsi dengan baik di mana ada beberapa koneksi. Jika Anda memiliki banyak koneksi, maka layanan microser berubah menjadi rasa sakit. Tidak ada peluru perak. Untuk melakukan ini, kami memiliki seluruh tim yang mengeksplorasi apa yang terbaik digunakan di lingkungan kami.
Mempekerjakan insinyur, bukan ahli bahasa
- Apa yang Anda butuhkan untuk mencapai Anda?- Kami mengajak orang yang tertarik dengan apa yang mereka lakukan. Ini klise - tentang membakar mata. Namun, ini penting. Bahkan jika Anda adalah pengembang yang baik, tetapi Anda tidak peduli apa yang harus dipotong, jika hanya bekerja dari sepuluh hingga enam dan menerima uang - dengan probabilitas tinggi ini tidak akan cocok untuk kami.
- Kami mengajak orang yang ingin belajar, berkembang. Jika Anda berpikir bahwa semuanya telah tercapai dan sekarang raja dunia juga bukan pilihan kita.
- Karena kami memiliki saluran umpan balik yang cukup baik dari pengembang ke bisnis dan sebaliknya, pendekatan "di sini, kerja" tidak begitu cocok. Kami mencoba untuk merekrut orang-orang yang siap menawarkan visi mereka, mereka memiliki pendapat dan pertanyaan.
Ini memajukan proyek lebih cepat daripada jika Anda mempekerjakan tiga super senior yang mengatakan "waktu kerja saya habis dan umumnya Anda membayar saya tidak cukup." Mereka akan melakukan kurang dari orang yang memotong proyek dalam sehari di hackathon, membawanya ke produksi.
- Kami mencari orang yang peduli, yang tertarik untuk bergerak maju.
- Jadi saya datang kepada Anda, mengatakan bahwa saya semua memiliki tujuan, saya memiliki banyak pendapat, mata saya menyala. Aku masih menyodok mereka dengan sesuatu untuk bersinar, kataku, bawa aku. Jadi ambillah?- Wawancara tidak begitu sederhana. Kami menciptakan kondisi yang dekat dengan proses kerja dan menyaksikan bagaimana seseorang menunjukkan dirinya. Jika Anda seorang pengembang, Anda akan menulis kode. Jika eychar - Anda akan mewawancarai.
- Apakah pengembang akan menulis kode saat wawancara?— , , .
, , . , , , , .
: « React-», — . React, ?
, . . , JS. : « Jira Wrike. ?»
, — Go, . , . , , .
— , , « », ?— . , . . , , . — . . , .
, , . , , ? . , … — , « ».
— . ?— .
Wrike , , . , . , , , .
— ?— . Gantt-. Canvas, . , , Google — , Dart . , .
— , - , ?— . . , -. Wrike, . , - , .
— ? , 400 . ?— . — . , . Cultural fit, , .
— . , ?— -5 . — . , . , , ? , .
— , , ?— , - . , , , .
— , , . . . . , , — .
— , ?- Tidak. . - .
— , ?— . , . , , , . .
— . Wrike — safe place. Google , — . , .
, , — .
— , ?- Mengkritik bukanlah kata yang tepat. Pastikan membutuhkan umpan balik. Kami di sini bukan untuk mencari yang bersalah - kami di sini untuk melakukan pekerjaan secara efisien.