Apa yang bisa dilakukan ketika "dipimpin oleh contoh" tidak berhasil? [Tutup]

40

Saya telah bekerja untuk sebuah perusahaan besar (8000+ karyawan) selama hampir 2 tahun sekarang, dan dipekerjakan tepat setelah saya menyelesaikan studi saya.

Setiap orang di sini harus berurusan setiap hari dengan kode lama yang seringkali dirancang dengan sangat buruk dan penuh peretasan. Pada awalnya, saya tidak menonjolkan diri, berusaha tidak terlalu banyak mengkritik. Tetapi situasinya, sebagaimana adanya, telah menjadi sangat sulit untuk dijalani dan tampaknya tidak ada yang mau memperbaiki / mengganti alat yang kita gunakan.

Untuk lebih eksplisit kami memiliki:

Alat kontrol sumber usang (Visual SourceSafe)
Makefiles tua polos yang hanya mendukung pembangunan kembali penuh
.def file yang harus dikelola secara manual dan terpisah untuk semua arsitektur yang ada
file header monolitik dan proyek dengan sangat sedikit file yang berbeda (tetapi masing-masing memiliki sekitar 3000 baris kode, yang terkadang menangani tugas yang sangat berbeda)
tidak ada penggunaan fasilitas bahasa "baru" (yah std::stringbukan yang baru tapi tidak seorang pun kecuali saya menggunakannya)

Saya memutuskan, beberapa bulan yang lalu untuk melakukan sesuatu tentang hal itu, dengan merancang lingkungan kompilasi yang baru. Saya bisa mendapatkan build tambahan untuk bekerja dengan andal, waktu kompilasi yang lebih cepat, proyek terstruktur yang lebih baik, .defpembuatan file otomatis . Saya bahkan membuat jembatan dari / ke Git ke / dari Visual SourceSafe.

Saya menunjukkan prestasi saya kepada beberapa kolega dan bos kami tetapi rasanya tidak ada yang peduli. Mereka semua seperti, "Yah ... orang sudah terbiasa melakukannya seperti itu sekarang. Mengapa kita mengubah banyak hal?"

Perubahan yang saya sarankan dirancang agar kami dapat memiliki transisi yang lunak dari sistem yang lama ke yang baru. Setiap peningkatan dapat diterapkan secara terpisah dan aman.

Saya bahkan mencoba melibatkan beberapa rekan kerja saya dalam perubahan. Namun sejauh ini, tidak berhasil.

Apakah Anda sudah menghadapi situasi yang sama? Apa yang bisa dilakukan ketika "dipimpin oleh contoh" tidak berhasil?

architecture productivity changes

— sebelum
sumber

10

"Saya memutuskan, beberapa bulan yang lalu untuk melakukan sesuatu tentang itu," ... "Saya menunjukkan hasilnya kepada bos saya". Sepertinya Anda salah memesan di sana.

3

@ ThorbjørnRavnAndersen: Tidak yakin untuk mendapatkannya: Bagaimana saya bisa menunjukkan sesuatu yang belum saya lakukan? Atau mungkin Anda maksudkan bahwa saya seharusnya bertanya sebelum melakukannya?

— sebelum

21

Saya pernah ke sana, dan IMO, Anda harus keluar dari sana, karena, seperti kata pepatah, "seorang idiot akan selalu mengalahkan Anda - pertama dia akan membodohi Anda sampai ke levelnya dan kemudian mengalahkan Anda dengan pengalamannya. ". Jika orang gagal mengenali kebutuhan untuk meningkatkan, itu stagnasi profesional, dan stagnasi di bidang kita adalah kematian. Anda dapat memasukkan hal-hal yang telah Anda lakukan pada CV Anda dan jika Anda baik, Anda mungkin akan mendapatkan pekerjaan yang baik dalam sebulan.

— TC1

8

Sapi suci, 8000 pengembang? Untuk siapa Anda bekerja, Facebook? Google? Microsoft?

— Kyralessa

5

@ Kirralessa: saya tidak berpikir facebook atau google menggunakan VSS.

— Jake Berger

46

Bertujuan untuk kepala : "Memimpin dengan contoh" harus memiliki peningkatan dalam pikiran, tetapi harus ditargetkan pada orang yang bukan pada teknologi. Mungkin Anda telah menginvestasikan terlalu banyak waktu untuk meningkatkan teknologi, tetapi tidak cukup waktu dalam apa yang terjadi di kepala mereka. Pikirkan faktor pendorong mengapa ada pertentangan untuk hal-hal baru. Dalam banyak kasus mereka hanya takut risiko. Identifikasi risiko-risiko itu dan temukan tandingannya.

Ambil daging segar : Lebih mudah untuk memenangkan karyawan yang ingin mengubah keadaan. Anda segera melihatnya saat melihatnya.

Hindari daging busuk : Beberapa tidak akan pernah bersimpati dengan ide-ide Anda. Tinggalkan mereka.

Tumbuhkan ke massa kritis : Temukan orang yang bersimpati dengan ide-ide Anda. Menangkan lebih dari satu per satu. Pada titik tertentu jika massa kritis tercapai, semakin banyak orang akan mengikuti contoh Anda secara sukarela.

Kosakata manajemen : Manajer tidak tertarik dengan desain yang lebih baik. Bahasa mereka adalah uang dan waktu. Jelaskan berapa banyak jam kerja yang terbuang untuk bug. Jelaskan bahwa pelanggan yang tidak puas yang menemukan bug tidak menguntungkan. Tunjukkan seberapa cepat Anda dapat mengimplementasikan fitur baru. Anda perlu memilih kosakata lain untuk manajer.

Ini semua tentang proses : Teknologi yang lebih baik tidak membuat programmer dan program yang lebih baik. Jika Anda memiliki proses yang berjalan dengan baik, bahkan teknologi yang ketinggalan zaman menghasilkan hasil yang baik. Pikirkan tentang usaha dan waktu yang terbuang. Mungkin bukan teknologinya, tetapi sesuatu dalam prosesnya sangat salah. Dalam kebanyakan kasus itu adalah kurangnya komunikasi.

Temukan perusahaan baru : Anda sudah melakukan banyak hal. Anda masih dapat mencoba untuk meningkatkan hal-hal, tetapi terserah Anda untuk memutuskan berapa lama Anda ingin mencobanya dan berapa banyak energi yang ingin Anda investasikan. Perlu diingat: Sekalipun Anda tidak dapat mencapai banyak peningkatan, Anda akan belajar banyak dari usaha Anda. Pada titik tertentu Anda harus pindah.

— Theo Lenndorff
sumber

3

Terkait dengan "tumbuh massa kritis": youtube.com/watch?v=V74AxCqOTvg

— back2dos

2

@Farmor jika Anda tidak dapat meyakinkan mereka tanpa mengatakan "bacalah halaman web", mungkin Andalah yang perlu memoles keterampilan komunikasi.

1

Maksud saya jika mereka keras kepala dan tidak mendengarkan yang muda. Anda dapat menyampaikan maksud Anda dengan merujuk pada dokumentasi. Misalnya jika mereka mengatakan poin Anda tidak benar dan hampir semua pakar versi menulis poin Anda, mereka akan dipaksa untuk mengirimkan. Dan saya suka menggoda arogan, Misalnya jika mereka suka Torvalds, Anda bisa mengatakan Torvals mengatakan, "Jika Anda menyukai SVN, Anda bodoh dan jelek" seperti yang ia lakukan dalam pidato google-nya. Saya tidak mengerti mengapa merujuk pada dokumentasi ketika orang yang keras kepala tidak akan percaya Anda adalah hal yang salah. Anda bahkan dapat melakukannya di ponsel dan menunjukkannya segera.

— Petani

6

-1 untuk umur. Terkadang Anda perlu mendengarkan "ahli fosil" dengan hati-hati dan membiarkan diri Anda sedikit rendah hati. Kemudian dengan pengetahuan yang Anda peroleh membuat ide Anda menjadi lebih baik. Meminggirkan orang lain hanya karena mereka sudah tua adalah cara yang pasti untuk kehilangan pengetahuan yang berharga dan dukungan dari para senior yang berpengaruh.

— Doug T.

1

@Lundin: Manajer harus memiliki keahlian teknis, tetapi semakin tinggi Anda menaiki tangga, semakin banyak uang dan waktu menjadi penting. Tidak ada yang salah dengan itu, karena seseorang perlu melacak aspek komersial perusahaan. Sangat penting untuk memberikan manajer argumen yang tepat ke tangan mereka sehingga mereka dapat membenarkan keputusan mereka kepada manajer mereka. Sebagai pengembang, Anda dapat memenangkan seorang manajer jika Anda memberikan argumen yang tepat kepadanya.

— Theo Lenndorff

30

Pernahkah Anda berhenti untuk mempertimbangkan bahwa Anda mungkin salah?

Jadi Anda membaca beberapa buku desain dan pola di sekolah dan Anda kehilangan haknya dengan apa yang tampak seperti praktik kuno yang relatif ketinggalan zaman di tempat Anda bekerja. Tidak diragukan lagi itu mungkin ide yang lebih baik dan proyek baru harus dimulai dengan ini dalam pikiran, tetapi sepertinya Anda berada pada level yang sama sekali berbeda.

Pengembang menggembalakan seperti mencoba menggembalakan kucing, mereka secara inheren memiliki pikiran mereka sendiri, dan cara yang disukai untuk melakukan sesuatu, apakah benar atau tidak. Saya memiliki waktu yang cukup sulit menegakkan praktik terbaik dan mengelola tim yang terdiri dari 2 pengembang, tetapi Anda bekerja untuk perusahaan yang memiliki 8000.

Itu jumlah yang sangat besar. Bahkan perubahan proses sederhana yang menyatakan semua pengembang harus menjadwalkan pertemuan dan keluar dari kantor pada kalender publik menjadi kebijakan yang sangat kompleks dan sulit untuk diterapkan di seluruh papan. Ini juga akan memerlukan dorongan signifikan dari manajemen untuk memastikan kebijakan diterima dan diadopsi secara keseluruhan.

Anda mungkin tidak memikirkannya, tetapi sesuatu yang sederhana seperti pindah dari file header monolitik ke banyak file, atau memindahkan kontrol versi dari SourceSafe ke Git memerlukan upaya dan investasi yang sangat besar dari pihak semua orang yang terlibat. Itu akan membutuhkan:

Dukungan manajemen yang signifikan
Penerimaan perusahaan yang luas
Investasi jam pertemuan untuk semua pengembang untuk memberi tahu mereka tentang prakarsa baru (Rapat membutuhkan jam kerja, biaya jam kerja)
Pelatihan perlu direncanakan dan ditetapkan untuk memastikan bahwa pengembang yang paling bodoh pun tahu apa yang mereka lakukan
Bahkan dengan asumsi satu jam pelatihan, di 8000 pengembang x € 50 / jam = € 400.000 biaya pelatihan. Ini lebih banyak uang daripada yang dianggarkan oleh tim pengembangan perangkat lunak saya satu tahun penuh untuk gaji, perangkat lunak, dan perangkat keras. Itu adalah investasi luar biasa yang Anda usulkan.

Tetapi Anda mengatakan, "Pikirkan semua waktu yang dapat dihemat melalui peningkatan produktivitas." Memang benar, tetapi investasi yang signifikan adalah risiko yang signifikan, jadi saya lebih baik yakin bahwa Anda benar tentang ini sebelum saya menandatanganinya. Jika tidak ada orang senior yang mendukung Anda, maka saya tidak bisa membenarkan biayanya. Pada akhirnya kami mungkin tidak efisien, tetapi kami konsisten dan dengan 8000 pengembang di seluruh perusahaan, konsistensi adalah yang paling penting.

Untuk melakukan ini, Anda perlu keluar dari beberapa orang tingkat senior, dan Anda perlu menemukan secara akurat dan obyektif cara untuk mengukur waktu pengembang yang hilang menjadi tidak efisien. Waktu itu setara dengan dolar dan hanya dolar dan politik akan membantu Anda memenangkan pertempuran ini.

— maple_shaft
sumber

4

Terima kasih. Sejujurnya, pada awalnya, ketika saya datang, selama beberapa minggu saya semua: "Apa-apaan, orang-orang ini tidak punya petunjuk!" kemudian menyadari betapa salahnya saya dalam banyak hal. Tetapi setelah dua tahun di sana, saya cukup yakin beberapa proses dapat ditingkatkan, dan dapat menyelesaikan banyak keluhan yang saya dengar. Saya mengerti itu juga masalah pendapat tetapi jika seseorang datang kepada saya dengan bukti bahwa saya melakukan sesuatu yang tidak efisien, saya setidaknya akan mendengarkan pria itu karena dia membantu saya. Departemen saya hanya terdiri dari 40 orang, dan hanya kami yang melakukan pengembangan seperti ini.

— sebelum

1

Saya yakin mereka dapat meningkat, tetapi seperti yang saya katakan, berbeda bagi saya untuk mengubah perilaku dan praktik saya untuk meningkat, daripada melatih dan memaksa 40 pengembang untuk melakukan ini. Seorang manajer non-teknis tidak akan mendengarkan Anda tanpa orang-orang senior yang secara politis penting mendukung gagasan itu.

— maple_shaft

Bukan hanya "bisakah hal dilakukan dengan lebih baik?". Mengganti repositori sumber adalah perubahan besar. ada biaya besar untuk melakukan peralihan, yang paling penting adalah melatih kembali semua staf. Lalu ada risikonya. Apakah Anda 100% yakin bahwa tidak akan ada kemampuan yang dibutuhkan repositori kode sumber lama, yang tidak Anda sadari, dan yang baru tidak akan memilikinya?

— DJClayworth

@DJClayworth: Repositori VSS hanya digunakan sebagai sistem penyimpanan dasar. Tidak ada yang pernah melihat sejarah dan mereka biasanya menghapus semuanya sebelum menyalin seluruh direktori lagi.

— sebelum

1

@ereOn Harap ingat Anda bekerja untuk bisnis, dan bisnis adalah menghasilkan uang, bukan kode. Kecuali itu bukan untuk keuntungan. Bagaimanapun, nilai utama Anda kepada pelanggan Anda mungkin bukan "kami akan mengirimkan kode kepada Anda dengan makefile kompilasi tercepat di industri". Anda harus menentukan apa yang penting bagi bos Anda (mis. Memangkas biaya) dan kemudian menghitung biayanya. Faktor pada orang, dan biaya alat.

— jasonk

7

Apa yang Anda jelaskan tidak terdengar seperti "teladan" bagi saya, sepertinya Anda membuat proposal dan ditolak. Untuk memimpin dengan memberi contoh, Anda harus menunjukkan kepada orang lain bahwa jalan Anda lebih baik. Dari masalah yang Anda daftarkan, saya melihat tiga bahwa Anda dapat mulai menggunakan perubahan Anda sendiri.

Makefiles tua polos yang hanya mendukung pembangunan kembali penuh.

Buat makefile Anda sendiri secara lokal dan tunjukkan seberapa efisien Anda dapat bekerja dengannya.

file header monolitik dan proyek dengan sangat sedikit file yang berbeda (tetapi masing-masing memiliki sekitar 3000 baris kode, yang terkadang menangani tugas yang sangat berbeda)

Baik memecah yang sudah ada saat Anda menyentuhnya (tanpa merusak build) atau memperkenalkan file header yang lebih kecil saat Anda menulis kode baru. Ketika orang mulai bekerja dengan mereka, mereka akan menyadari bahwa mereka tidak membutuhkan duplikasi.

tidak ada penggunaan fasilitas bahasa "baru" (well std :: string tidak begitu baru tetapi tidak seorang pun kecuali saya menggunakannya)

Lanjutkan memperkenalkan fasilitas bahasa baru setiap kali Anda menyentuh kode lama atau memperkenalkan kode baru. Pastikan Anda menyederhanakan hal-hal. Jangan berkecil hati dari yang ini. Kebanyakan dari kita malas. Jika kami melihat bahwa fitur bahasa baru memudahkan, kami akan mengadopsinya.

Setelah beberapa bulan, jika pengembang lain mulai mengadopsi peningkatan Anda, maka Anda dapat mendekati atasan Anda lagi tentang perubahan yang lebih radikal seperti meningkatkan sistem kontrol sumber Anda. Anda perlu memastikan pengembang lain melihat manfaatnya, atau itu tidak akan pernah terjadi. Salah satu cara untuk mendekati itu mungkin dengan menyarankan mencoba Git pada proyek kecil yang hanya beberapa pengembang aktif. Dengan begitu Anda dapat mempromosikannya sebagai evaluasi, bukan transisi skala penuh ke sistem yang tidak dikenal.

Akhirnya, jika setelah beberapa bulan mencoba, tak seorang pun tampaknya tertarik untuk meningkatkan bagaimana hal-hal dilakukan di perusahaan Anda, Anda harus benar-benar mempertimbangkan apakah itu cocok untuk Anda.

— Bill the Lizard
sumber

5

Selain Lionel Barret (yang sebagian besar saya setuju), pertimbangkan juga kemungkinan motivasi untuk perlawanan.

Mengevaluasi biaya proses yang sebenarnya
Mengevaluasi biaya proses karena akan menjadi seperti milik Anda

Tetapi juga:

Mengevaluasi biaya perubahan dalam hal
- Uang yang dihabiskan untuk menyiapkan lingkungan baru bagi siapa pun
- Waktu yang dihabiskan untuk melatih semua orang agar terbiasa dengan mode baru (mungkin mudah bagi Anda, tetapi tidak mudah bagi orang yang tidak menyadari apa yang Anda lakukan)
- Waktu yang berlalu diperlukan untuk mengelola perubahan dengan cara yang tidak mengganggu.

Saya memiliki tersangka: Berapa banyak di perusahaan Anda orang-orang seperti Anda dalam hal usia dan budaya (saya laki-laki "sekolah" dan "jenis sekolah")? Berapa banyak orang seperti Anda yang akan dipekerjakan dalam 2/3 tahun ke depan dan berapa banyak yang akan pensiun atau mengubah peran mereka dalam organisasi?

Tersangka saya adalah Anda berada dalam posisi dengan kekuatan yang tidak cukup untuk mengubah perusahaan. Dalam situasi itu, perusahaan akan mengubah Anda atau akan "mengeluarkan" Anda (dalam arti itu akan menjadi keinginan Anda sendiri untuk pergi), jika Anda tidak dapat menunggu lebih lama.

Tetapi mungkin perusahaan sedang mengevaluasi bahwa biaya tambahan yang saya katakan dapat dihemat memungkinkan proses perubahan terjadi secara spontan dengan menunggu penggantian alami orang-orang untuk terjadi. Anda baru saja berada di awal proses yang tidak dapat Anda lihat karena tidak ada apa-apa di belakang Anda.

— Emilio Garavaglia
sumber

1

Tebakan Anda tepat: Saya memang salah satu yang termuda di departemen saya. Beberapa dari mereka tampaknya menyadari bahwa meskipun saya masih muda, saya memiliki pengetahuan yang berharga. Saya tahu dan mengerti bahwa saya masih harus banyak belajar (dan saya percaya itu akan terjadi sampai hari kematian saya), tetapi banyak dari mereka yang tampaknya tersinggung oleh hal-hal yang tidak mereka ketahui. Saya tidak ingin mendorong mereka pergi atau mencuri pekerjaan mereka atau apa pun: Saya hanya ingin meningkatkan hal-hal sehingga semua orang dapat bekerja / hidup lebih baik. Apakah saya harus menunggu untuk menjadi lebih tua untuk menambah berat badan?

— sebelum

1

@ eOn: mengemudi Anda sangat mulia, setiap orang waras ingin bekerja sama dengan Anda.

— o0 '.

@ereOn: "Apakah saya harus menunggu lebih tua untuk menambah berat badan?" Belum tentu. Usia adalah nilai dalam hal pengalaman dalam mengelola kompleksitas. Bukan nilai dalam memahami hal-hal baru (mereka baru bagi siapa saja, dan tidak memiliki jaminan simpanan bisa menjadi keuntungan). Itu bukan masalah "pribadi". Ini masalah "massa kritis". Sampai orang yang menginginkan perubahan kurang dari 20% mereka akan mati lemas. Jika mereka lebih, kepemimpinan menjadi terlihat (dan bukan masalah usia). Jika seorang pemimpin dapat mencapai 40% dari populasi, "hal baru" akan memiliki kewarganegaraan yang tepat. Dari 60% perubahan bersifat spontan.

— Emilio Garavaglia

3

Pada titik ini saya hanya dapat menambahkan referensi ke Artikel Joel yang Mendapatkan Hal-Hal yang Dilakukan Ketika Anda Hanya Mendengus . Bagian tersebut meliputi:

Strategi 1 Lakukan Saja

Strategi 2 Memanfaatkan Kekuatan Pemasaran Viral

Strategi 3 Buat Saku Keunggulan

Strategi 4 Menetralkan Bozos

Strategi 5 Menjauh Dari Gangguan

Strategi 6 Menjadi Sangat Berharga

Saya akan meringkas artikel sebagai "Perubahan harus dimulai dari Anda."

— Joshua Drake
sumber

2

Saya menemukan GTDWYOG tidak terlalu membantu. Menurut pendapat saya, setidaknya gelar itu menyesatkan: seseorang yang "tidak terlibat dalam perekrutan" atau memiliki kebebasan untuk mengabaikan bagian dunia lainnya saat bekerja di kafetaria bukanlah sebuah keluhan. Grunt adalah seseorang yang harus melakukan apa yang diperintahkan, dengan sedikit atau tanpa kendali atas keadaannya. Dalam pengalaman saya, meskipun gambar idealistik dilukis di sini di stackexchange, itulah yang terjadi pada sebagian besar pengembang. Dan bagi mereka, GTDWYOG lebih merupakan resep untuk dipecat karena ketidakpatuhan.

— keppla

1

Sedihnya orang terjebak dalam suatu kebiasaan dan mengembangkan mentalitas bahwa 'itu bekerja, semua orang menggunakannya dengan baik, mengapa mengubahnya' Dan itu menjadi menyebalkan.

Anda telah melakukannya dengan cara yang benar dengan tidak hanya mengeluh tetapi dengan mengembangkan solusi yang bisa diterapkan sebagai pengganti, sekarang Anda hanya perlu menerima.

Tampilkan manajer lini langsung Anda (atau pimpinan teknis). Jika mereka tidak tertarik, apakah Anda memiliki orang yang bertanggung jawab atas kontrol perubahan atau inovasi?

Namun secara potensial, ide dan pekerjaan Anda dapat diabaikan dan situasinya akan tetap seperti semula.

— Amy
sumber

2

ah tetapi beberapa kali saya pernah mendengar "mari menulis ulang, itu akan jauh lebih baik dan lebih keren dalam teknologi baru x" hanya untuk menemukan bahwa yang baru tidak lebih baik dari yang lama (dan dalam banyak kasus lebih buruk). Cukup sering, sampai ada kebutuhan , yang terbaik adalah tidak merusak sesuatu yang berfungsi.

— gbjbaanb

1

Anda perlu menyatakan kasus Anda dengan cara yang membuat atasan Anda berada di pihak Anda. BTW, Perubahan semacam ini diusulkan oleh direktur teknis atau manajer proyek, jadi Anda harus berkomitmen pada proyek. (Sebagai rute alternatif, Anda dapat mengusulkan audit teknis, orang luar cenderung mengatakan hal yang sama dengan Anda tetapi akan lebih berbobot.)

Sejauh ini, dia tidak melihat kebutuhan untuk berubah, sepertinya kosmetik berubah padanya: Mahal tanpa manfaat yang jelas kecuali untuk memuaskan kesukaan seorang dev. Hanya ada dua hal yang penting baginya: aliran uang dan tim yang stabil. Teknologinya adalah kotak hitam, jika berhasil, itu sudah cukup.

Uang pertama, Anda perlu membuktikan bahwa pengaturan saat ini adalah biaya uangnya. Berapa biaya / jam seorang dev dan berapa jam waktu kompilasi yang lebih cepat akan menyelamatkannya? Lakukan perhitungan. Juga, kompilasi artikel atau kesaksian tentang risiko pipa kode saat ini dan tunjukkan padanya angka-angka menakutkan: "karena SourceSafe / Praktik Pengkodean Buruk, perusahaan kami kehilangan $ XXXK".

Kedua tim, bos Anda mungkin terjebak dengan coders pemarah tua yang tidak ingin mengubah cara mereka. Jika poin pertama ditetapkan, Anda juga perlu mengusulkan solusi untuk masalah ini. Berapa banyak kamu Mungkin menarik untuk menggarisbawahi bahwa akan sulit untuk mengganti seseorang karena pipa pengkodean saat ini adalah bizantine. Anda perlu mengusulkan rencana untuk memperbarui tim. Pelajari mereka praktik terbaik industri dan periksa mereka mengikuti aturan baru.

Akhirnya, Anda perlu mengusulkan rencana untuk mengubah basis kode, dibagi menjadi proyek-proyek kecil, dengan tonggak dan alokasi sumber daya. Bahkan, Anda menjual diri Anda sebagai manajer proyek dan perubahan itu wajib untuk memiliki pipa kode yang solid.

— Lionel Barret
sumber

Terima kasih atas saran Anda. Masalahnya adalah orang yang bertanggung jawab tampaknya sangat menyukai semua pengembang lama (karena pada akhirnya, mereka menyelesaikan pekerjaan dan tidak menghitung jam). Saya merasa berat saya sangat sedikit karena saya masih muda. Beberapa orang di departemen saya datang untuk menanyakan hal-hal tentang praktik yang baik tetapi meskipun saya menjelaskannya dengan sangat rendah hati, pada titik tertentu mereka tidak ingin menunjukkan bahwa mereka tidak tahu banyak tentang hal itu dan berusaha mempertahankan cara lama mereka.

— sebelum

1

Apakah Anda bekerja di organisasi yang meyakini melakukan sesuatu dengan baik, efisiensi dan inovasi mengarah pada kesuksesan dan profitabilitas; atau bahwa mengejar pendapatan, dan berkonsentrasi pada mempertahankan penjualan adalah penyewa kesuksesan?

Perusahaan yang berperilaku seperti yang Anda gambarkan memiliki teknologi yang kuat. Dalam pasar yang kompetitif mereka tidak akan mampu bersaing dengan perusahaan yang berfokus pada individu dan inovasi.

Jika Anda adalah orang yang Anda katakan, maka kerjakanlah suatu tempat yang menghormati dan menghargai semangat Anda. Akhirnya, setelah bertahun-tahun menyelesaikan Anda akan mulai berkompromi untuk filosofi yang sama dengan yang dianut atasan Anda. Pergi bekerja di tempat lain (mungkin organisasi yang lebih kecil) yang menghargai kerja keras, inspirasi, kreativitas, dan kemajuan.

Jika Anda tidak mengambil risiko dan melakukan ini segera, pada akhirnya Anda akan puas dan Anda tidak akan dapat terus memberi makan rasa ingin tahu dan kreativitas Anda karena secara filosofis ditentang dalam kelompok teman sebaya Anda saat ini.

Keunggulan adalah sikap dan pandangan dunia.

Ketahuilah bahwa pengalaman ini memberi Anda wawasan untuk tahu apa yang harus dihindari, jaga mata Anda untuk berpuas diri dan proteksionisme sehingga Anda dapat mendeteksinya sejak dini.

Dalam wawancara berikutnya, ajukan pertanyaan seperti "Inovasi apa yang datang dari karyawan Anda", "Apa saja perubahan yang datang dari kreativitas individu?", "Apa bakat individu yang dapat saya bawa ke tim ini?", "Apa yang mendorong kesuksesan organisasi Anda? ? "," Bagaimana organisasi Anda terus merangkul inovasi teknologi? "... Jawaban untuk pertanyaan seperti ini sangat jelas. Banyak organisasi tidak memiliki visi, atau mereka yang menciptakan visi hilang, dan organisasi dijalankan oleh akuntan. Jika Anda mewawancarai Direktur Teknologi - tanyakan padanya apakah ia melihat organisasi sebagai perusahaan teknologi.

— Ben DeMott
sumber

-1

Jika Anda tidak menyukai lingkungan tempat Anda bekerja maka Anda merugikan diri sendiri. Anda perlu dikelilingi oleh orang-orang yang memiliki minat dan tujuan yang sama seperti yang Anda lakukan secara profesional. Saya tahu kadang-kadang itu lebih mudah diucapkan daripada dilakukan, tetapi perasaan melihat ke belakang beberapa tahun dan merasa seolah-olah Anda telah menyia-nyiakan waktu Anda lebih buruk daripada takut mengambil risiko.

Sebagai alternatif, jika Anda ingin mengembangkan dalam suatu sistem atau lingkungan yang menggunakan teknologi dan / atau metodologi tertentu, maka saya sarankan Anda mencari proyek di luar pekerjaan yang dapat Anda berkontribusi. Paling tidak variasi dari bekerja pada kedua sistem akan memuaskan kebutuhan akan sesuatu yang berbeda saat Anda menemukan di mana Anda berada.

Menurut saya Anda adalah ikan dari air. Pergi dan temukan tubuh samudra Anda dan berenang!

— wavedrop
sumber