Proje yöneticilerine (ve patron olmayı hayal edenlere) adanmıştır.
Tonlarca kod yazmak zordur ama insanları yönetmek daha da zordur! Yani her ikisini de nasıl yapacağınızı öğrenmek için bu kitaba ihtiyacınız var.
Komik hikayelerle ciddi dersleri birleştirmek mümkün mü? Michael Lopp (dar çevrelerde Rands olarak da bilinir) başarılı oldu. İnanılmaz derecede ödüllendirici (kurgusal da olsa) deneyimlere sahip kurgusal insanlar hakkında kurgusal hikayeler bulacaksınız. Rands, büyük BT şirketlerinde (Apple, Pinterest, Palantir, Netscape, Symantec, vb.) yıllar boyunca çalışarak edindiği çeşitli, bazen tuhaf deneyimlerini bu şekilde paylaşıyor.
Proje yöneticisi misiniz? Yoksa lanet patronunun bütün gün ne yaptığını mı anlamak istiyorsun? Rands size Şişirilmiş Hindilerin Zehirli Dünyasında nasıl hayatta kalacağınızı ve işlevsiz gösterişli insanların genel çılgınlığında nasıl başarılı olacağınızı öğretecek. Manyak beyinlilerden oluşan bu garip toplulukta, mistik bir organizasyon ritüeli aracılığıyla birçok insanın planları, düşünceleri ve banka hesapları üzerinde güç kazanan yöneticiler gibi daha da tuhaf yaratıklar var.
Bu kitap herhangi bir yönetim veya liderlik taslağına benzemez. Michael Lopp hiçbir şeyi gizlemiyor, sadece olduğu gibi anlatıyor (belki de tüm hikayelerin kamuya açıklanması gerekmiyor: P). Ancak ancak bu şekilde böyle bir patronla nasıl hayatta kalacağınızı, inekleri ve inekleri nasıl yöneteceğinizi ve "o lanet projeyi" nasıl mutlu sona ulaştıracağınızı anlayacaksınız!
Alıntı. Mühendislik zihniyeti
Hakkında Düşünceler: Kod Yazmaya Devam Etmeli misiniz?
Rands'ın yöneticiler için kurallar hakkındaki kitabı, modern yönetimsel "zorunluluklar"ın çok kısa bir listesini içeriyor. Bu listenin özlülüğü, "zorunluluk" kavramının bir nevi mutlak olmasından ve konu insanlara gelince mutlak kavramların çok az olmasından kaynaklanmaktadır. Bir çalışan için başarılı bir yönetim yöntemi, bir diğeri için gerçek bir felaket olacaktır. Bu düşünce, yöneticinin "yapılması gerekenler" listesinin ilk maddesidir:
Esnek kalın!
Zaten her şeyi bildiğinizi düşünmek çok kötü bir fikir. Değişmeyen tek gerçeğin dünyanın sürekli değiştiği olduğu bir durumda esneklik tek doğru konum haline geliyor.
Paradoksal olarak listedeki ikinci madde şaşırtıcı derecede esnek değildir. Ancak bu nokta benim kişisel favorim çünkü yönetimsel büyümenin temelini oluşturmaya yardımcı olduğuna inanıyorum. Bu paragraf şöyle:
Kod yazmayı bırakın!
Teorik olarak yönetici olmak istiyorsanız, sizin için çalışanlara güvenmeyi öğrenmeli ve kodlamayı tamamen onlara devretmelisiniz. Bu tavsiyeyi sindirmek genellikle zordur, özellikle de yeni basılmış yöneticiler için. Muhtemelen yönetici olmalarının nedenlerinden biri de geliştirmedeki üretkenlikleridir ve işler ters gittiğinde ilk tepkileri, tamamen güvendikleri becerilere, yani kod yazma becerilerine başvurmak olur.
Yeni atanan bir yöneticinin kod yazmaya "battığını" gördüğümde ona şunu söylüyorum: "Kod yazabildiğini biliyoruz. Soru şu: liderlik edebilir misin? Artık yalnızca kendinizden sorumlu değilsiniz, tüm ekipten sorumlusunuz; ve ekibinizin, kodu kendiniz yazmanıza gerek kalmadan sorunları kendi başlarına çözmesini sağlayabileceğinizden emin olmak istiyorum. İşiniz kendinizi nasıl ölçeklendireceğinizi bulmaktır. Senin sadece bir kişi olmanı istemiyorum, senin gibi birçok kişinin olmasını istiyorum.”
İyi tavsiye, değil mi? Ölçek. Yönetmek. Sorumluluk. Böyle yaygın moda sözcükler. Tavsiyenin yanlış olması üzücü.
Yanlış?
Evet. Tavsiye yanlış! Tamamen yanlış değil ama bazı eski meslektaşlarımı arayıp özür dilemek zorunda kalmamı gerektirecek kadar yanlıştı: "Kod yazmayı nasıl bırakmanız gerektiğine dair en sevdiğim ifadeyi hatırlıyor musunuz? Yanlış! Evet... Programlamaya yeniden başlayın. Python ve Ruby ile başlayın. Evet, ciddiyim! Kariyeriniz buna bağlı!
Borland'da yazılım geliştirici olarak kariyerime başladığımda çok büyük bir ekip olan Paradox Windows ekibinde çalıştım. Yalnızca 13 uygulama geliştiricisi vardı. Bu proje için sürekli olarak temel veritabanı motoru ve temel uygulama hizmetleri gibi önemli teknolojiler üzerinde çalışan diğer ekiplerden kişileri de eklerseniz, bu ürünün geliştirilmesine doğrudan dahil olan 50 mühendis elde edersiniz.
Çalıştığım başka hiçbir takım bu büyüklüğün yanına bile yaklaşamaz. Hatta her geçen yıl çalıştığım ekipteki kişi sayısı giderek azalıyor. Neler oluyor? Biz geliştiriciler hep birlikte giderek daha mı akıllı oluyoruz? Hayır, sadece yükü paylaşıyoruz.
Geliştiriciler son 20 yıldır ne yapıyor? Bu süre zarfında bir sürü kod yazdık. Kod denizi! O kadar çok kod yazdık ki her şeyi basitleştirip açık kaynağa geçmenin iyi bir fikir olacağına karar verdik.
Neyse ki internet sayesinde bu süreç artık olabildiğince basit hale geldi. Eğer yazılımcıysanız hemen şimdi göz atabilirsiniz! Adınızı Google veya Github'da arayın; uzun zamandır unuttuğunuz ancak herkesin bulabileceği kodu göreceksiniz. Korkunç, değil mi? Kodun sonsuza kadar yaşadığını bilmiyor muydun? Evet, sonsuza kadar yaşıyor.
Kod sonsuza kadar yaşar. Ve iyi kod sonsuza kadar yaşamakla kalmaz, büyür çünkü ona değer verenler onun sürekli taze kalmasını sağlar. Bu yüksek kaliteli, iyi korunan kod yığını, ortalama mühendislik ekibi boyutunun azaltılmasına yardımcı olur çünkü yeni kod yazmak yerine mevcut koda odaklanmamıza ve işi daha az kişiyle ve daha kısa bir zaman diliminde halletmemize olanak tanır.
Bu mantık yürütme tarzı iç karartıcı gelebilir, ancak fikir şu ki, hepimiz aynı şeyin biraz farklı bir versiyonunu oluşturmak için mevcut şeylerin farklı parçalarını birbirine bağlamak için koli bandı kullanan bir grup entegrasyon otomatıyız. Bu, dış kaynak kullanmayı seven üst düzey yöneticiler arasında klasik bir düşünce tarzıdır. “Google'ı nasıl kullanacağını bilen ve elinde koli bandı olan herkes bunu yapabilir! O halde neden makinelerimize bu kadar para ödüyoruz?”
Bu yönetim adamlarına gerçekten büyük paralar ödüyoruz ama onlar böyle saçma sapan düşünüyorlar. Bir kez daha vurgulamak istediğim nokta, gezegenimizde pek çok parlak ve çok çalışkan geliştiricinin bulunması; Akredite üniversitelerde bir dakika bile oturmamış olmalarına rağmen gerçekten zeki ve çalışkanlar. Ah evet, artık sayıları giderek artıyor!
Sırf bazı parlak yoldaşlar iddiaya göre orayı arıyor diye yeriniz hakkında endişelenmeye başlamanızı önermiyorum. Bu konuda endişelenmeye başlamanızı öneririm çünkü yazılım geliştirmenin evrimi muhtemelen sizden daha hızlı ilerliyor. Beşi yönetici olmak üzere on yıldır çalışıyorsunuz ve şöyle düşünüyorsunuz: "Yazılımın nasıl geliştirildiğini zaten biliyorum." Evet biliyorsun. Hoşçakal…
Kod yazmayı bırak ama...
Eğer orijinal tavsiyeme uyup kod yazmayı bırakırsanız, oluşturma sürecine katılmayı da gönüllü olarak bırakmış olursunuz. Bu nedenle dış kaynak kullanımını aktif olarak kullanmıyorum. Otomatlar yaratmaz, üretirler. İyi tasarlanmış süreçler çok fazla para tasarrufu sağlar ancak dünyamıza yeni bir şey getirmez.
Az parayla çok şey yapan küçük bir ekibiniz varsa, kod yazmayı bırakma fikri bana kötü bir kariyer kararı gibi görünüyor. Sonsuz düzenlemeleri, süreçleri ve politikaları olan canavar şirketlerde bile yazılımı kendi başınıza nasıl geliştireceğinizi unutmaya hakkınız yok. Ve yazılım geliştirme sürekli değişiyor. Şu anda değişiyor. Ayaklarının altında! Tam bu anda!
İtirazlarınız var. Anlamak. Hadi dinle.
“Rands, yönetmen koltuğuna gidiyorum! Kod yazmaya devam edersem büyüyebileceğime kimse inanmayacak."
Size şunu sormak istiyorum: “CEO olmak üzereyim!” koltuğuna oturduğunuzdan beri, yazılım geliştirme ortamının şirketinizde bile değiştiğini fark ettiniz mi? Cevabınız evet ise size başka bir soru soracağım: Tam olarak nasıl değişiyor ve bu değişikliklerle ilgili ne yapacaksınız? İlk soruma "hayır" cevabını verdiyseniz, o zaman farklı bir sandalyeye geçmeniz gerekiyor, çünkü (bahse girerim!) yazılım geliştirme alanı tam da bu anda değişiyor. Yavaş ama emin adımlarla yazılım geliştirmeyi unutursanız nasıl büyüyeceksiniz?
Benim tavsiyem, bir sonraki ürününüz için tonlarca özelliği uygulamaya kendinizi adamamanızdır. Ekibinizin nasıl yazılım geliştirdiğini takip etmek için sürekli adımlar atmanız gerekir. Bunu hem direktör hem de başkan yardımcısı olarak yapabilirsiniz. Başka bir şey?
“Ah, Rands! Ama birinin hakem olması gerekiyor! Birinin büyük resmi görmesi gerekiyor. Eğer kod yazarsam perspektifimi kaybederim."
Hala hakem olmanız gerekiyor, yine kararları yayınlamanız gerekiyor ve yine de her Pazartesi sabahı mühendislerinizden biriyle birlikte binanın etrafında dört kez dolaşıp onun haftalık "Hepimiz mahkumuz" rantını 30 yıl boyunca dinlemeniz gerekiyor. dakika. ! Ancak tüm bunların ötesinde, mühendislik zihniyetini korumanız gerekir ve bunu yapmak için tam zamanlı bir programcı olmanıza gerek yoktur.
Mühendislik zihniyetini sürdürmek için önerilerim:
- Geliştirme ortamını kullanın. Bu, kod oluşturma sistemi, sürüm kontrolü ve programlama dili dahil olmak üzere ekibinizin araçlarına aşina olmanız gerektiği anlamına gelir. Sonuç olarak, ekibinizin ürün geliştirme hakkında konuşurken kullandığı dilde uzmanlaşacaksınız. Bu aynı zamanda mükemmel çalışan favori metin düzenleyicinizi kullanmaya devam etmenize de olanak tanıyacaktır.
- Ürününüzü anlatan detaylı bir mimari diyagramı istediğiniz zaman istediğiniz yüzeye çizebilmeniz gerekir. Şimdi üç hücreli ve iki oklu basitleştirilmiş versiyonu kastetmiyorum. Ürünün detaylı şemasını bilmelisiniz. En zor olanı. Sadece sevimli bir diyagram değil, aynı zamanda açıklanması zor bir diyagram. Ürünün tam olarak anlaşılmasına uygun bir harita olmalıdır. Sürekli değişiyor ve bazı değişikliklerin neden meydana geldiğini her zaman bilmelisiniz.
- Fonksiyonlardan birinin uygulanmasını devralın. Bunu yazarken kelimenin tam anlamıyla ürküyorum çünkü bu noktanın birçok gizli tehlikesi var, ancak en az bir özelliği uygulamaya karar vermeden 1. ve 2. noktaları başarabileceğinizden gerçekten emin değilim. Özelliklerden birini kendiniz uygulayarak, yalnızca geliştirme sürecine aktif olarak dahil olmakla kalmayacak, aynı zamanda periyodik olarak "Her şeyden sorumlu Yönetici" rolünden "Birinin uygulanmasından sorumlu Adam" rolüne geçmenize de olanak tanıyacaksınız. işlevlerden biridir.” Bu alçakgönüllü ve alçakgönüllü tutum size küçük kararların önemini hatırlatacaktır.
- Hala her yerim titriyor. Görünüşe göre biri bana şimdiden bağırıyor: "İşlevin uygulanmasını üstlenen yönetici mi?!" (Ben de ona katılıyorum!) Evet, sen hala yöneticisin, bu da bunun küçük bir görev olması gerektiği anlamına geliyor, tamam mı? Evet, hâlâ yapacak çok işiniz var. Eğer fonksiyonun uygulanmasını üstlenemiyorsanız, o zaman size bazı yedek tavsiyelerim var: bazı hataları düzeltin. Bu durumda yaratmanın keyfini yaşamayacaksınız ama ürünün nasıl yaratıldığına dair bir anlayışa sahip olacaksınız, bu da hiçbir zaman işsiz kalmayacağınız anlamına geliyor.
- Birim testleri yazın. Bunu hala üretim döngüsünün sonlarında, insanlar çıldırmaya başladığında yapıyorum. Bunu ürününüz için bir sağlık kontrol listesi olarak düşünün. Bunu sık sık yapın.
Yine itiraz mı?
“Rands, eğer kod yazarsam takımımın kafasını karıştırırım. Kim olduğumu, yönetici mi, geliştirici mi olduğumu bilmeyecekler."
Tamam.
Evet, "Tamam!" dedim. Sadece geliştirici havuzunda yüzerek ekibinizin kafasını karıştırabileceğinizi düşünmenize sevindim. Çok basit: yazılım geliştirmedeki farklı roller arasındaki sınırlar şu anda oldukça bulanık. Kullanıcı arayüzü adamları genel olarak JavaScript ve CSS programlama olarak adlandırılabilecek şeyi yaparlar. Geliştiriciler, kullanıcı deneyimi tasarımı hakkında giderek daha fazla şey öğreniyor. İnsanlar birbirleriyle iletişim kurar ve hatalar hakkında, diğer insanların kodlarının çalınması hakkında ve ayrıca bir yöneticinin bu devasa, küresel, çapraz bilgi alışverişine katılmaması için iyi bir neden olmadığı gerçeğini öğrenir.
Üstelik kolaylıkla değiştirilebilen parçalardan oluşan bir ekibin parçası olmak ister misiniz? Bu sadece ekibinizi daha çevik hale getirmekle kalmayacak, aynı zamanda her ekip üyesine ürünü ve şirketi çeşitli açılardan görme fırsatı verecektir. Yapımlardan sorumlu sakin adam Frank'e, yapım senaryolarının sade zarafetini gördükten sonra nasıl saygı duyabilirsin?
Ekibinizin kafasının karışık ve kaotik olmasını istemiyorum. Tam tersine ekibinizin daha etkili iletişim kurmasını istiyorum. Ürünün yaratılmasına ve özellikler üzerinde çalışmaya dahil olursanız ekibinize daha yakın olacağınıza inanıyorum. Ve daha da önemlisi kurumunuzun yazılım geliştirme sürecindeki sürekli değişimlere daha yakın olacaksınız.
Gelişmeyi bırakmayın
Borland'daki bir meslektaşım bir keresinde kendisine "kodlayıcı" dediğim için bana sözlü olarak saldırmıştı.
"Rands, kodlayıcı akılsız bir makinedir! Maymun! Kodlayıcı, işe yaramaz kodlardan oluşan sıkıcı satırlar yazmak dışında önemli bir şey yapmaz. Ben kodlayıcı değilim, yazılım geliştiriciyim!”
Haklıydı, yeni CEO'lara ilk tavsiyemden nefret ederdi: "Kod yazmayı bırakın!" Onların kodlayıcı olduklarını öne sürdüğüm için değil, proaktif olarak işlerinin en önemli kısımlarından biri olan yazılım geliştirmeyi göz ardı etmeye başlamalarını önerdiğim için.
Bu yüzden tavsiyemi güncelledim. İyi bir lider olmak istiyorsanız kod yazmayı bırakabilirsiniz ancak...
Esnek ol. Mühendis olmanın ne demek olduğunu unutmayın ve yazılım geliştirmeyi bırakmayın.
Yazar Hakkında
Michael Lopp, Silikon Vadisi'nden henüz ayrılmamış deneyimli bir yazılım geliştiricisidir. Geçtiğimiz 20 yıl boyunca Michael, aralarında Apple, Netscape, Symantec, Borland, Palantir, Pinterest'in de bulunduğu çeşitli yenilikçi şirketlerde çalıştı ve aynı zamanda yavaş yavaş unutulmaya yüz tutan bir startup'ta da yer aldı.
Michael, iş dışında Rands takma adı altında teknoloji ve yönetim hakkında popüler bir blog işletiyor; burada okuyucularla yönetim alanındaki fikirleri tartışıyor, sürekli nabzını tutma ihtiyacı konusundaki endişelerini dile getiriyor ve bunu, tüm gelişmelere rağmen açıklıyor. Bir ürün yarattığınız için cömert ödüller, başarınız ancak ekibiniz sayesinde mümkündür. Blogu burada bulabilirsiniz .
Michael ailesiyle birlikte Redwood, Kaliforniya'da yaşıyor. Sağlıklı olmak meşgul olmaktan daha önemli olduğundan her zaman dağ bisikletine binmeye, hokey oynamaya ve kırmızı şarap içmeye zaman buluyor.
» Kitapla ilgili daha detaylı bilgiye şu adresten ulaşabilirsiniz:
»
»
Khabrozhiteley için kupon kullanarak %20 indirim - İnsanları yönetmek
Kitabın basılı versiyonu için ödeme yapıldıktan sonra kitabın elektronik versiyonu e-posta ile gönderilecektir.
Not: Kitap fiyatının %7'si yeni bilgisayar kitaplarının çevirisine, kitapların listesi matbaaya teslim edilecek. .
Kaynak: habr.com