Jadi, apa kursus itu, apa yang ada dalam 24 pelajaran dan mengapa itu berguna untuk pengembang, dan bukan hanya untuk produk masa depan.
Pelajaran 1. Produk
Was: Inti dari produk. Lingkaran kehidupan. Tugas manajer produk. Produk vs proyek.
Berguna:Sangat penting bagi pengembang untuk mengetahui produk yang ia buat. Untuk ini mereka membayar lebih bodoh. Tentu saja, Anda bisa berpura-pura menjadi teko. Secara ketat mengikuti TK dan tidak melakukan apa pun di luar apa yang tertulis dalam spesifikasi. Bungkus semua keinginan tambahan klien dan jangan mulai bekerja sampai pimpinan teknologi menulis semua detail di tiket, hingga lebar indentasi pada UI. Tapi, kejutan-kejutan, dengan pendekatan ini Anda tidak akan pernah naik di atas tingkat pengembang Tengah. Ada programmer yang bangga pada ketidakmampuan mereka untuk berkomunikasi dengan tim dan klien. Tentu saja ada pengecualian. Tetapi jika Anda bukan Sheldon Cooper di bidang TI, lebih baik menyalakan empati dan memahami cara kerja produk, siapa yang berpartisipasi di dalamnya, apa yang mereka lakukan, apa yang penting bagi mereka, dan mengapa. Dalam salah satu proyek, seorang klien mulai menulis dengan air mendidih dengan kebahagiaan, ketika, pada daftar fitur yang perlu dilakukan, saya bertanya tentang prioritas.Dan kemudian dia menawarkan untuk mengubahnya, tk. beberapa tugas diblokir oleh orang lain. Dan beberapa di antaranya salah kata, yang akan menyebabkan kesalahan dalam proses bisnis. Dan kegagalan terbesar yang saya buat adalah ketika saya melakukan refactoring besar tanpa persetujuan klien, karena klien kami PM dan PM sedang berlibur. Klien menolak untuk membayarnya, karena itu tidak membawa nilai bisnis pada produk.
Pelajaran 2. Hipotesis
Apakah: Definisi hipotesis. Menetapkan sasaran untuk SMART. Siklus HADI.
Berguna: "Siapa yang tidak tahu ke pelabuhan mana untuk berlayar, untuk itu tidak ada angin penarik" - kata Lucius Annei Seneca, mentor Nero, tetapi kami tidak mencintainya sama sekali untuk ini. Hipotesis adalah tentang prioritas. Apa yang harus dilakukan, apa yang nanti, dan apa yang tidak. Prioritas mempengaruhi kecepatan proyek. Kecepatan - untuk mencapai batas waktu. Gaji, bonus, dan barang lainnya tergantung pada tenggat waktu proyek. Ini seperti Tetris. Ada 20 angka yang perlu ditempatkan dalam gelas dalam satu menit. Semua angka berbeda. Area mereka (jumlah kotak di masing-masing) diketahui. Kami meringkas area - mereka harus dengan mudah pas dekat satu sama lain, bahkan tempat itu tetap ada. Tapi ... mereka tidak cocok. Karena, kejutan, mereka akan cocok jika Anda menempatkannya di urutan yang benar. Oleh karena itu, pengembang yang berpengalaman melakukan tugas-tugas sedemikian rupa agar tidak memperlambat kerja kolega sebanyak mungkin. Jika Anda perlu membuat API Web, pertama-tama sepakati antarmuka dan buat bertopik metode sehingga pengembang front-end dapat memanggil API,dan kemudian memodifikasi tubuh metode. Jika dia terlibat dalam database, maka dia memulai tabel sesegera mungkin sehingga mereka dapat digunakan di back-end, dan melakukan view, index dan binding lainnya nanti. Jika dia menulis dokumen, dia mengunggah konsep untuk tinjauan ASAP, dan tidak mempublikasikannya 5 menit sebelum didline, karena menurutnya, 100% dokumen sempurna.
Pelajaran 3. Manajemen tim
Apakah: Membangun tim. Tangkas. Kanban.
Berguna: Ini harus memiliki keterampilan untuk programmer dan tidak hanya. Produk IT modern dibuat oleh tim. Jika Anda tidak tahu cara bekerja dalam tim - selamat datang langsung
Pelajaran 4. Tinjau tugas dan pemilihan proyek
Apakah: Ulasan masalah produk nyata. Presentasi kasus peserta.
Berguna: Tampaknya. Mengapa seorang programmer tahu bagaimana mereka memecahkan masalah konversi iklan yang rendah, peningkatan rata-rata cek atau viralitas akuisisi pelanggan? Jawaban sederhana Keterampilan pemecahan masalah - keterampilan pemecahan masalah. Inilah yang direkrut para perekrut selama 10 tahun terakhir dan apa yang ditemukan di setiap detik lowongan kerja di AS / UE. Pengalaman orang lain tidak pernah berlebihan. Setelah menyuarakan masalahnya, dosen menyarankan untuk mendiskusikan bagaimana peserta kursus akan menyelesaikannya. Tidak pernah berlebihan untuk menggunakan otak Anda dan belajar dari pengalaman orang lain.
Pelajaran 5. Evaluasi produk
Apakah: Penilaian pasar dan analisis pesaing.
Berguna:Pengetahuan tidak jelas bagi programmer. Tabel daftar fitur, analisis SWOT, ukuran pasar TAM / PAM - mengapa demikian? Ya, tampaknya tidak perlu sampai Anda memutuskan pilihan tumpukan teknologi dalam proyek. Atau Anda pikir Anda harus segera beralih ke versi terbaru perpustakaan begitu keluar (tidak). Atau putuskan universitas mana yang akan dikunjungi. Atau dalam bahasa apa untuk menulis proyek pertama Anda. Singkatnya, Anda membuat keputusan strategis yang akan menentukan nasib Anda di tahun-tahun mendatang. C # atau Java? Sudut atau Bereaksi? MSSQL atau Oracle? App store atau Google Play? Mobapps asli atau QT / Xamarin? Visual studio, WebStorm atau kode Visual studio? Saya masih malu dengan satu pelanggan. Dia mencari kontraktor untuk mengembangkan sistem ERP besar dari awal. Perusahaan kami menawarinya tim dan tumpukan - Silverlight. Untuk 1.Selama 5 tahun kami membuat produk dan kemudian Microsoft mengumumkan bahwa itu tidak lagi mendukung Silverlight. Kematian! Sistem yang telah selesai dan didebug dapat dibuang ke tempat sampah. Klien menghabiskan 10 orang * 18 bulan * untuk pengembangan saja * pembayaran bulanan rata-rata termasuk pajak, katakanlah $ 3.000 = $ 540.000. Setengah anjing di ekor! Dan jika kita menambahkan laba yang hilang, dengan mempertimbangkan pengembangan sistem baru (perusahaan menghasilkan ~ 10 miliar euro per tahun), bayangkan kerusakan dari keputusan tersebut. Masalahnya bukan hanya tentang IT. Pirang atau berambut cokelat? Beli apartemen atau sewa? Tinggal di kota atau di pinggiran kota? Haruskah saya memilih atau pergi ke rumah pedesaan? Perusahaan tempat bekerja? Pindah ke ibukota atau tinggal di kota asal Anda?Klien menghabiskan 10 orang * 18 bulan * untuk pengembangan saja * pembayaran bulanan rata-rata termasuk pajak, katakanlah $ 3.000 = $ 540.000. Setengah anjing di ekor! Dan jika kita menambahkan laba yang hilang, dengan mempertimbangkan pengembangan sistem baru (perusahaan menghasilkan ~ 10 miliar euro per tahun), bayangkan kerusakan dari keputusan itu. Masalahnya bukan hanya tentang IT. Pirang atau berambut cokelat? Beli apartemen atau sewa? Tinggal di kota atau di pinggiran kota? Haruskah saya memilih atau pergi ke rumah pedesaan? Perusahaan tempat bekerja? Pindah ke ibukota atau tinggal di kota asal Anda?Klien menghabiskan 10 orang * 18 bulan * untuk pengembangan saja * pembayaran bulanan rata-rata termasuk pajak, katakanlah $ 3.000 = $ 540.000. Setengah anjing di ekor! Dan jika kita menambahkan laba yang hilang, dengan mempertimbangkan pengembangan sistem baru (perusahaan menghasilkan ~ 10 miliar euro per tahun), bayangkan kerusakan dari keputusan tersebut. Masalahnya bukan hanya tentang IT. Pirang atau berambut cokelat? Beli apartemen atau sewa? Tinggal di kota atau di pinggiran kota? Haruskah saya memilih atau pergi ke rumah pedesaan? Perusahaan tempat bekerja? Pindah ke ibukota atau tinggal di kota asal Anda?Pirang atau berambut cokelat? Beli apartemen atau sewa? Tinggal di kota atau di pinggiran kota? Haruskah saya memilih atau pergi ke rumah pedesaan? Perusahaan tempat bekerja? Pindah ke ibukota atau tinggal di kota asal Anda?Pirang atau berambut cokelat? Beli apartemen atau sewa? Tinggal di kota atau di pinggiran kota? Haruskah saya memilih atau pergi ke rumah pedesaan? Perusahaan tempat bekerja? Pindah ke ibukota atau tinggal di kota asal Anda?
Pelajaran 6. Target audiens
Was: Metode untuk menggambarkan audiens target. Segmentasi.
Bermanfaat: Saya akan mengungkapkan rahasia yang mengerikan. Tidak ada satu pun klien di dunia yang membayar seorang programmer hanya untuk menikmati melihatnya menggedor keyboard, google stackoverflows, minum kopi, mendiskusikan prinsip-prinsip polimorfisme dengan rekan-rekannya, dan memberikan isyarat pintar pada panggilan konferensi. Klien membayar untuk menyelesaikan masalahnya. Karena itu, perlu mengetahui dan menghormati klien Anda setidaknya karena dia membayar Anda. Tanpa klien, Anda hanya menulis aplikasi menyenangkan secara gratis. Seperti hobi yang lucu di rumah seperti mengumpulkan perangko atau membakar kayu.
Sesi 7. Penelitian Klien
Apakah: Pengembangan pelanggan (penelitian pelanggan melalui wawancara masalah).
Bermanfaat: Seperti pelajaran sebelumnya adalah tentang klien. Kenapa yang lain? Anda harus Fedya, Anda harus! Di sini kita berbicara tentang sebuah wawancara. Anda perlu berbicara dengan klien. Dan sedikit orang yang tahu bagaimana melakukan ini. Jangan menekan dengan pendapat Anda, jangan menyarankan jawaban, bertanya tentang masa lalu, bukan masa depan, mencari tahu nomor tertentu, bukan keinginan, memperjelas ketidakpastian, memiliki rencana percakapan dan memperbaiki perjanjian, dengarkan lebih banyak, lebih sedikit bicara. Tidak ada yang lebih baik dari buku Rob Fitzpatrick "Ask Mom" yang telah ditulis. Dan saya bahkan sudah memeriksanya . Tiba-tiba, berbicara dalam format castedev tidak hanya mungkin dengan klien, tetapi juga dengan rekan kerja.
Sesi 8. Wawancara praktis
Was: Mencari responden. Perumusan pertanyaan. Pengembangan Pelanggan dalam Praktek.
Berguna:Untuk menjadi pewawancara yang baik, sayangnya, Anda juga perlu melakukan wawancara. Saya berbicara bahasa Inggris dengan sempurna, dengan semua bahasa, saya bisa mengenali bahasa gaul dan meniru aksen apa pun, saya bercanda dengan marah dan memahami nuansa bahasa yang paling halus. Tapi itu ada di kepalaku. Dalam praktiknya terdengar seperti ini: “Ixcuzmi. Veriz eeee niarest shop? Belanja produk visa? Catatan chip, betapa mahal, tapi, pasti, luas! " Teori tidak bekerja tanpa latihan. Pengalaman yang sangat traumatis untuk jiwa setiap programmer cupang adalah menemukan orang yang diwawancarai. Keluar dari gedung dan hal-hal lainnya. Secara fisik sulit untuk memaksa diri Anda untuk memanggil perusahaan yang tidak dikenal dan meminta wawancara atau menawarkan layanan. Atau tanyakan sesuatu di jalan. Tetapi apa yang tidak membunuh membuat kita lebih kuat. Panggilan telepon tidak akan membunuhmu. Hal utama adalah tidak memanggil hujan dan tidak bersembunyi di bawah pohon.
Sesi 9. Penelitian kualitatif dan kuantitatif
Ada: Wawancara, jajak pendapat, kelompok fokus, pakar, webvisor, pembelanja misteri, tes A / B.
Berguna: Anda perlu argumen untuk membuat keputusan. Argumen butuh fakta. Fakta didasarkan pada angka. Angka-angka tersebut berasal dari penelitian. Berbagai jenis penelitian tentang hal yang sama memberikan gambaran yang lebih realistis. Mengapa pengembang membutuhkannya? Kita hidup di dunia yang sangat kejam. Tidak mungkin lagi, seperti pada sekitar tujuh puluhan, untuk pergi ke bos dan meminta $ 152 miliaruntuk mendarat di bulan, lihatlah dengan rapi, meskipun semuanya terlihat jelas melalui teleskop. Jika Anda mengusulkan refactoring, lebih baik untuk menunjukkan keuntungan darinya dalam angka. Misalnya, mempercepat kueri basis data sebanyak X kali, mengurangi duplikasi kode dan mempercepat perubahan atau perbaikan oleh Y-kali. Pembelian penyelamat dibenarkan dengan mempercepat pengkodean dengan faktor Z. Pizza Gratis pada hari Jumat - 100,500+ kali semangat tim yang lebih baik.
Pelajaran 10. Menghasilkan ide
Was: Metode 6 topi, Walt Disney, sapi bodoh, generasi terbalik, objek fokus, TRIZ.
Berguna: Hiburan favorit saya. Seperti yang dikatakan oleh satu orang pintar, "Pemrograman adalah penemuan atas permintaan." Tidak ada tempat di IT tanpanya. Berapa kali saya menghadapi masalah yang tampaknya tidak terpecahkan, dan setelah wawasan saya menemukan solusi yang elegan. Ternyata, orang-orang datang dengan banyak cara untuk merangsang kreativitas. Cara yang berhasil adalah menjelaskan masalahnya kepada kolega, meminta nasihat, dan menemukan beberapa alternatif selama diskusi. Anda perlu lebih banyak berkomunikasi. Adalah baik untuk "tidur" dengan pikiran dan di pagi hari pikiran bawah sadar menemukan solusi atau untuk terlibat dalam aktivitas fisik (berenang) dan dalam proses berpikir tentang ide itu.
Pelajaran 11. Proposisi Nilai
Was: Kompilasi CPU. Kanvas Ramping, Kanvas Proposisi Nilai.
Bermanfaat: Sekali lagi, mereka yang murni teknis akan kecewa. Setiap nama fungsi, pustaka, dan sintaksis bahasa pemrograman. Semua ini, tentu saja, tidak terjadi. Dan ada analisis, merumuskan pertanyaan dan mendapatkan jawaban, mencari informasi, menyusun tabel dan menyusun data. Segala sesuatu yang tanpanya mustahil untuk membayangkan seorang spesialis IT yang baik.
Pelajaran 12. Model Bisnis
Apakah: Jenis dan konstruksi model bisnis. Kanvas Model Bisnis. Monetisasi produk.
Bermanfaat: Mirip dengan pelajaran sebelumnya tentang CPU. Gerak-gerik otak dengan kecepatan penuh. Topik bermanfaat tentang jenis monetisasi, karena itu selalu terbaik untuk membayangkan bagaimana produk Anda menghasilkan uang.
Pelajaran 13. Roadmap Produk
Was: Roadmap. Gantt chart. Strategi. Rencana Rilis. Product Backlog. Backlog pengembangan.
Berguna: Yang ini lebih untuk pemimpin teknologi dan manajer proyek. Melepaskan fungsi, garis pijakan dan tonggak, risiko, akuntansi untuk sumber daya yang tersedia, memuat orang dan rencana untuk menaklukkan dunia.
Pelajaran 14. Merancang MVP
Was: Jenis MVP (Produk yang Layak Minimum). AIDA dan 4U saat membuat halaman arahan.
Berguna: Untuk manajemen produk, MVP adalah tentang membangun produk prototipe untuk menguji permintaan dengan cepat dan murah. Bagaimana hubungannya dengan pembangunan? Faktanya adalah bahwa pemrogram ditugaskan tugas, tetapi seringkali tidak ditentukan dengan tepat bagaimana tugas ini harus diselesaikan. Oleh karena itu, pengembang yang baik mencoba untuk menghemat sumber daya dan membuat tugas dengan usaha minimal, karena prioritas dapat berubah, dan tidak ada yang membatalkan didline. Jika dikatakan membuat tabel data yang dapat diedit, maka Anda tidak boleh membuat kontrol yang akan dapat menampilkan semua jenis data, termasuk mode pivot, fungsionalitas Excel, dan ekspor data dalam format apa pun. Prinsip-prinsip YAGNI , KISS dandosa dari pengoptimalan prematur adalah tentang hal itu. Dan tidak pernah, Anda dengar, tidak pernah melakukan tugas dan refactoring besar dalam satu tiket! (menangis).
Pelajaran 15. TOC
Adalah: Teori Kendala. Tempat yang sempit.
Berguna: Ini adalah TOP langsung ketika mengoptimalkan kecepatan program. Untuk produk, ini tentang mengoptimalkan bagian tersempit dari corong. Untuk seorang spesialis IT, seringkali perlu meningkatkan kecepatan respons - pemuatan halaman, pembuatan laporan, unggah file. SQL memiliki rencana kueri, caching, dan teknik optimasi lainnya. Itu selalu layak meningkatkan hambatan dalam sistem. Dan untuk ini, Anda perlu mengukur tahapan proses, mencatat waktu dan membuat keputusan berdasarkan angka, dan bukan perasaan seperti "Saya akan menulis ulang dari LINQ ke penyimpanan, sepertinya membantu."
Pelajaran 16: Cerita dan Skenario Pengguna
Apakah: Membangun dan menggunakan Peta Perjalanan Pelanggan.
Bermanfaat: Saya mengaku. Pemrograman itu menyenangkan, menulis dokumentasi itu membosankan. Di tengah-tengah terletak desain antarmuka (UX, jangan dikacaukan dengan UI). Ini lebih menyenangkan daripada membosankan. Buat sketsa antarmuka di Visio, pikirkan skenario penggunaan, tulis aturan bisnis. Jika Anda ingin tumbuh dari pengembang menjadi pemimpin, PM, analis, produk atau arsitek, lebih baik untuk menguasai teknik ini. Saya bahkan tidak mengatakan bahwa seringkali persyaratan untuk perangkat lunak diatur agak kabur, atau bahkan tanpa tata letak UI sama sekali. Oleh karena itu, merancang sendiri antarmuka yang layak segera, menyelesaikan inkonsistensi logis dalam logika bisnis secara tepat waktu akan sangat menghemat waktu dan memengaruhi kepuasan Anda dengan pekerjaan Anda.
Pelajaran 17. UX
Apakah: Script. Dasar-dasar UX. Halaman arahan. CJM.
Bermanfaat: Ada latihan UX di sini. Ternyata saya ketinggalan zaman. Orang-orang telah membuat halaman web untuk waktu yang lama di Tilda , Figma dan, Tuhan maafkan aku, Tinkoff . Diagram dan prototipe UX tidak dibuat di Visio, tetapi di Google Drawings , Draw.io dan LucidChart . Untuk dasar-dasar desain yang tepat (indentasi, blok visual, font, aksen) saya menyukai buku karya Vlad V. Golovach "Desain Antarmuka Pengguna: Seni Mencuci Gajah" . Tautannya adalah versi kedua, saya baca dulu, lebih baik.
Pelajaran 18. Metrik
Was: Metrik utama, penyesuaian, koleksi.
Berguna: Membuat keputusan berdasarkan data berguna. Data adalah hitam baru, Pengambilan Keputusan berdasarkan Data dan semua itu. Di perusahaan IT keren, pengembang terbiasa mengukur dan beroperasi dengan banyak data - hasil tes yang berjalan, penggelaran ke server, pemeriksaan kualitas kode, kemajuan penutupan Tugas di Jira, dan sebagainya.
Sesi 19. Unit Ekonomi
Itu: Sebenarnya, Unit-ekonomi.
Berguna: Tema yang sangat berguna untuk produk. Anda harus mendapatkan lebih banyak (3+ kali) dari penjualan satu unit barang daripada yang Anda belanjakan untuk produksi unit yang sama. Apa analog untuk pengembang? Saya tidak tahu. Bagaimanapun, programmer ditugaskan untuk membuat fungsionalitas dalam lingkup kualitas waktu-uang-persegi. Berapa banyak uang yang dihasilkan fitur ini atau itu dibandingkan dengan biaya produksinya ditentukan oleh produk dan prioritas yang ditetapkan olehnya.
Pelajaran 20. Analisis kasus peluncuran produk nyata
Was: Metodologi peluncuran produk. Generasi peningkatan produk.
Berguna: Pengalaman selalu berguna, dan pengalaman dalam perusahaan berdarah dua kali lebih berguna. Ada pendapat bahwa pekerja lepas tidak terlalu suka mempekerjakan perusahaan, terutama untuk sistem warisan yang sarat muatan. Ini bahkan bukan tentang NDA, ketidakmampuan untuk bekerja dalam tim, ketidaknyamanan komunikasi jarak jauh dan apa masalah khas lainnya dengan outsourcing. Hanya saja ada nuansa dalam sistem kehidupan yang mungkin bahkan tidak dipikirkan oleh freelancer. Dari birokrasi hingga interoperabilitas integrasi dan jendela waktu yang nyaman untuk penempatan. Belum lagi masalah memperbarui database secara real time, versi API, dll.
Pelajaran 21. Praktek dalam mengevaluasi solusi produk
Was: Mekanisme untuk mengevaluasi solusi produk.
Berguna:Ini merupakan kelanjutan dari pelajaran sebelumnya. Hanya dengan fokus pada praktik intensif, pembuatan hipotesis, penugasan tugas, dan hasil penelusuran. Singkatnya, sistem operasinya. Akan sangat membantu bagi pengembang yang baik di sini untuk memahami bahwa pekerjaan itu tidak akan lari. Tugas-tugas yang perlu dilakukan kemarin datang dalam beberapa bagian sehari. Salah satunya akan muncul saat Anda meninggalkan kantor dan akhirnya memeriksa email Anda. Keseimbangan kehidupan kerja itu penting. Bahwa ada kalanya Anda hanya perlu mengambil dan melakukannya terlepas dari waktu hari. Tetapi sama pentingnya untuk tidak terjebak dalam rutinitas dan tidak kelelahan dalam beberapa bulan. Anda dapat tetap bekerja selama 4-6 jam di atas norma, tetapi ini berarti bahwa produktivitas tenaga kerja hari berikutnya akan menjadi yang terbaik 50-70%, sehingga lembur yang konstan tidak ada gunanya.
Pelajaran 22. Memprioritaskan tugas-tugas produk
Was: Metode MVP - prioritisasi, ICE / RICE, Biner - prioritisasi, periode pengembalian.
Berguna:Topik bagus karena pengembang terus-menerus harus memberikan perkiraan kompleksitas tugas. Tidak semudah kedengarannya. Berangsur-angsur, Anda bisa bersemangat untuk membuat perkiraan yang kurang lebih memadai agar tidak mengacaukan lebih dari 20%. Tapi biasanya PMU tidak suka angka seperti itu. Itu sulit karena ada tugas yang saling tergantung, faktor keakraban dengan bagian spesifik dari kode dan / atau teknologi, menekan PM untuk mengurangi waktu, karena "Dia dulunya adalah seorang pengembang dan ingat bahwa itu sederhana", spekulasi yang samar-samar (saya suka ketika analis menambahkan poin baru selama proses pengembangan), pendapat subyektif "UI terlihat baik-baik saja atau perlu ditingkatkan", keinginan untuk tidak terlihat bodoh dibandingkan dengan yang lain dan karenanya tajam kurangi penilaian Anda, tekanan dari rekan kerja, rekomendasi yang dikeluarkan dari atas "kami telah menandatangani perjanjian dengan klien untuk jumlah dan ketentuan yang tepat", dll.
Pelajaran 23. Persiapan untuk pertahanan kerja
Apakah: Jenis presentasi. Kiat untuk berbicara. Uji coba laporan.
Bermanfaat: Lagi. Jika Anda tidak berencana untuk tumbuh di atas Pengembang Tengah, lewati titik ini. Selebihnya, dan untuk pengembangan mereka sendiri, tidak akan berlebihan untuk belajar bagaimana menyiapkan laporan, menyalakan audiensi, tidak jatuh dengan pertanyaan rumit, secara konstruktif membahas topik dan mempertahankan sudut pandang mereka atau mengubahnya tanpa pergi ke ekstrem KUHP Federasi Rusia dalam bentuk menimbulkan luka serius pada lawan-lawan ideologis. ...
Pelajaran 24. Pertahanan surat-surat istilah
Itu: Pertempuran kinerja di depan penonton.
Bermanfaat: Ya, sebenarnya, pertunjukan langsung. Anda dapat bersiap untuk waktu yang lama, menjilat preza, mengambil pelajaran berbicara di depan umum dan bertindak. Tapi setelah pukulan pertama ke rahang (naik panggung), semua ini terbang keluar dari kepalaku. Saya tidak tahu mengapa di perusahaan IT besar mereka berbicara di konferensi atau setidaknya menulis artikel untuk publikasi khusus setidaknya beberapa orang. Sementara ini sangat meningkatkan kemampuan untuk merumuskan pemikiran, merek pribadi pembicara, mengembangkan komunitas TI, dan menghemat perusahaan pada biaya PR dan SDM.
Bagaimana lagi bisa seorang pengembang berhenti menjadi pembuat kode-UI untuk mengakses basis data dan diilhami oleh pemikiran produk?
Pertama, ada tren baru untuk organisasi pirus . Ada esai yang sangat baik tentang topik habr . Tentu saja, banyak hal terlihat sedikit utopis. Memberi tanggung jawab tanpa kekuatan nyata dan komitmen finansial bisa sangat berisiko. Dan siapa yang mudah sekarang?
Kedua, atau mungkin ini adalah manifesto untuk poin pertama - " Bisnis funky ". Kutipan yang dipilih dari buku dapat dibaca di sini... Apa yang saya sukai dari lirik-lirik ini adalah bahwa mereka ditulis sebagai wahyu agama. Seburam mungkin, dapat diakses, untuk semua yang baik, melawan semua yang buruk. Ini bukan kerugian, tetapi sebaliknya, martabat. Setiap orang yang membaca akan berpikir dan menarik kesimpulan sendiri.
Akhirnya, ada tren inovasi perusahaan baru-baru ini . Hackathons, pilot pemula, pengembangan kewirausahaan internal, strategi transformasi digital, Lean, pengembangan pelanggan dan Berpikir Desain. Ada skema hebat tentang topik dari Disruptive.vc :
Kesimpulan
Saya yakin saya belum mengungkapkan rahasia apa pun. Semakin banyak Anda tahu, semakin baik. Sekalipun ada banyak pengetahuan, ada banyak kesedihan. Di sebuah tim yang membangun restoran dengan klien dari Inggris, pemimpin teknologi kami menunjukkan sekotak trik pertandingan. Dia meletakkannya di tepi meja, memukulnya dari bawah dan melemparkannya ke udara dan dengan tangan yang sama menyalakan korek api di atasnya. Klien sangat terkesan sehingga dia membayar tagihan untuk seluruh tim, dari bir hingga merayap. Dan salah satu PM bercanda dengan baik sehingga stand-up dan retro berubah menjadi klub komedi di tahun-tahun terbaik. Anda bahkan dapat mengatakan bahwa keterampilan seorang manajer produk tidak hanya akan berlebihan bagi pengembang, tetapi setiap keterampilan secara umum memainkan peran positif dalam pekerjaan, intinya hanya dalam aplikasi yang benar . Karena itu, mari belajar, terus berkembang dan nikmati pekerjaan kita!