Sonsuz teknik tartışmaları durdurmak ve karar vermek

Her zaman, en küçük "teknik şeyler" yüzünden yaşlanmayı seven insanlarla karşılaşıyorum.

Beni yanlış anlama, ben ne yaptığımı seven bir inek programcısıyım, ama konuşma türünü biliyorsun.

• Mac, Windows'tan çok daha iyi
• Her döngü için kullanma, bir döngü kullanmayın
• Intel tabanlı bir PC almayın, AMD tabanlı bir tane edinin.
• Bir IoC kabını diğerine kullanmalıyız.

Bütün bu "şeylerin" her iki taraf için de geçerli profesyonelleri ve dezavantajları vardır ve asla "doğru" bir cevap alamazsınız ve kişi asla bu konuyu kabul etmez. (Tabii ki, cevabın olduğu bir yer olabilir, belki :).

Benim sorum (oraya gidiyorum !!): Bir yazılım ekibinde, yenilikçiliği engellemeden bu uzun tartışmaları nasıl kesiyorsunuz, böylece bir karar verilebilir ve gerçek iş sorunlarını çözebilirsiniz.

Sorun 1. Bazı insanlar kaybetmekten hoşlanmaz. Eğer çekimleri çağırmazlarsa, çekimleri yıpratmadan çağırana kadar tartışacaklar.

Sorun 2. Hiçbir şey gerçekten tehlikede değil, bu yüzden tartışmalar hoş görülüyor.

Hiçbir şey tehlikede değil mi? Evet. Kararların çoğunun neredeyse sıfır dolar etkisi var. “Yaşlar için çarpmak” anlamına gelmesi, her iki seçeneğin de etkili bir şekilde aynı olduğu anlamına gelir.

Ne yapalım?

1. Hiçbir şeyin tehlikede olmadığını fark et.

2. 2 veya 3 yıl içinde, kuruluşun dışındaki bir şey değiştiğinden tüm konunun tekrar açılacağını fark edin.

3. Bozuk para atmak. Ciddi anlamda. Sadece bir şey seç ve devam et. Bazı insanlar tartışmadaki saçmalıkları görecekler. Bazı insanlar daha sonra atılan madalyonun doğasını tartışacaklar. Eğer insanlar bozuk para atmaktan memnun olmazlarsa, ego problemleri vardır ve (a) hiçbir şeyin tehlikede olmadığını ve (b) kararın birkaç yıl içinde değiştirileceğini öğrenmeleri gerekir.

Hiçbir şeyin tehlikede olmadığını bulamazlarsa, tartışmanın her iki tarafının dolar değerini yazmaları gerekir. Bir noktada, birileri analiz için gerçek kararın değerinden daha fazla erkek-saat harcandığını görebilir. Bir madeni para atma düşük bir maliyet için eşit değer üretir.

Düşünmesi gereken birkaç şey:

1. Yalnızca ölçülebilir argümanları kabul edin. Birisi zaman kazanacağını söylerse, onları ölçmelerini ve cevabını tutmalarını isteyin. Bu şekilde, eğer çöplerden bahsediyorlarsa, herkes kendilerine baskın bir floş olduğunu bilmeden önce sadece bir tanesine giderler.

2. İnsanların önerileri için sorumluluk almalarını sağlayın. Yıl sonunda, değerlendirmelerinin bir parçası olacak kötü çağrılar yapıyorlarsa açıkça belirtin. Tartışmalara aldırış etmiyorum ama insanların inançlarını cesaretlendirmelerini istiyorum - eğer bir şey yemin edecekseniz ve benimsememizi beklerseniz, sonuçlarla yaşamanız daha iyi olur.

Bunlar, S.Lott'un iki probleminden kurtulmak için gerçek şeyler - bazı insanlar kaybetmeyi sevmiyor ve hiçbir şeyin tehlikede değil. Cevabım tehlikeye atıldı, bu yüzden tartışmanın iyiliği için tartışma olmaz.

1. Tartışmayı Timebox. - Her iki tarafın davasını belirtmesi 5 dakikadan fazla sürerse, o zaman çok karmaşık olur. Biz aslında bunun için mutfak zamanlayıcılar kullanın . Harika çalışıyorlar ve yaklaşık 5 dolara mal oluyorlar.
2. Katılımcıların veri ve tecrübe ile tartışmalarını zorunlu kılın.
3. Seçenekleri masada tutuyoruz. Her iki tarafın da zamanı geldikten sonra, her bir yaklaşımın sonuçlarını tartışarak 5 dakika daha harcarız. 20 dakika sonra dışarı çıkarız ve yaparız (uygulayın). İşe yaramazsa, diğer yaklaşımla gideriz.

Kural basit. Bir kez ne seçeceğinizi bilmiyorsanız - şirket için neyin daha iyi olduğunu düşünün.

Evet, Intel v AMD seçimi o kadar kolay değil. Ama şirketiniz için hangisi daha iyi? Örneğin, bir şeyler sipariş etmekten sorumlu olan bir kişi varsa ve AMD işlemci tabanlı bir PC'yi sipariş etmesi yıllar alır, ancak Intel tabanlı bir dakika içinde sipariş edilebilir ve ne olacağı umrunda değil - Intel tabanlı bir şirket siparişi verin, çünkü bu şirket için daha iyidir.

Genellikle bu tartışmalar gerçekten sadece bisiklete bürünüyor . Hangi aktarım biçimini veya hangi veri deposunu kullanacağını ve tüm bileşenlere gerçekten saydam olması gereken, ancak çok ayrıntıyı uygulayan diğer tonlarca insanı savundukları. Bileşen tasarım sözleşmesini yerine getirdiği sürece ve hiç kimsenin umrunda değildir ve sorumlu kişiler sözleşme değişikliklerine makul bir sürede cevap verebileceklerdir.

Yazılım geliştirmede karşılaştığınız tüm teknik sorunların büyük çoğunluğu bisikletle ilgili sorunlardır. Basitçe onlar zaten çözümleri var ve tek soru, hangi çözümü seçmek istediğiniz.
Kendinizi bu tür kararlara kilitlememelisiniz. Bu tür kararları , başvurunuzu bu detaylardan ayıran bir soyutlama katmanına kilitlemelisiniz .
Yazılım geliştirmedeki en önemli problemler özellik ve sistem düzeyinde tasarım problemleridir. Geri kalan her şey ikincildir.

Öyleyse, gerçekten böyle tartışmalara başlamayın. Projenizi bağımsız parçalara bölmek için enerjinize odaklanın. Bu, daha sağlam ve esnek bir yazılım sağlar. Ve net dezavantajları olan teknik kararları (yalnızca bir kez çalıştıran bir yazılımı kullandıktan sonra yapabileceğiniz bir şeyi) belirleyebiliyorsanız, sistemin geri kalanını etkilemeden farklı bir karar verebilirsiniz.

Standardizasyon bir yaklaşımdır

Ekibiniz, geliştirme için standart olarak neleri benimseyecekleri konusunda bir fikir birliğine varmalı ve daha sonra makul bir süre kendisine bağlı kalmalıdır (ekip tarafından kararlaştırılmalıdır). Standart başarısız olursa, o zaman yeni bir olasılıkla muhtemel çözüm çerçevelerinden yeni bir grup kabul edilir.

“Hey, bu bilgisayarlar sonunda işe yaramazdı, hadi Macleri deneyelim!”

veya

“Sana söylemiştim! Bahar EJB'den çok daha iyi.”

Ve bunun gibi.

Standart olması, kodun daha verimli bir çevreye yol açan bir takımda birlikte çalışmanın daha kolay olduğu anlamına gelir.

Şu anda test yaklaşımı, "Papalık conclave" adlı kod ve oldukça ümit verici. Papalık seçimlerinden birinde “kilitlenme” olduğu ve kardinallerin bir seçim yapamadığı bir hikayeye dayanıyor. Bir seçime ev sahipliği yapan kuruluş (büyük olasılıkla bazı şehir büyükleri için) önce bir binada kardinalleri kilitledi, ardından gıda tedarikini büyük ölçüde azalttı ve daha sonra tartışmayı daha da rahat hale getirmek için binanın çatısını kaldırdı. Beklendiği gibi kardinaller çatı kaldırıldıktan sonra seçim yaptı ve üç yıllık bir kilitlenme sona erdi.

Bu yüzden benim yaklaşımım, insanlar bazı şeyler konusunda anlaşamadıkları zaman, bir seçim yapana kadar tartışmaya zorlandıklarıdır. Başka bir rahatsızlık vermiyorum, zaman kısıtlaması bile yok ve tabii ki çatıda hiçbir şey yapmıyorum :). Tek yaptığım her gün sürekli sorunu gündeme getirmek. Biri giderse "Biz karar veremiyoruz" ile cevap veriyorum "Şey ... zorundasın". Şimdiye kadar bu kadar ufak teknolojik detaylara bu kadar umutsuzca bağımlı bir insanla tanışmadım. Bir sürü toplantıdan sonra, tıpkı kardinaller gibi bir uzlaşma arayışına giriyorlar.

Bunun, onu kesmek yerine daha fazla kalıcı bir tartışma olduğuna katılıyorum. Bununla birlikte, tartışmalar sınırsız değildir ve artı olarak, böyle bir "uzlaşmadan" sonra bazı insanlar küçük teknolojik tartışmalardan kaçınma eğilimindedir;

Nereye gideceğinize ve ne yapacağınıza karar vermeniz gerekiyorsa, fikir birliğine varamayacağınızdan, 6'dan fazla seyahat etmemelisiniz.

Bu, neden belirleyici güçlere sahip bir kişinin olması gerektiğinin en önemli örneğidir. Bu özel örnekte, söz konusu kişinin bir karar vermesi ve "böyle olması gerektiği" demesi, diğerlerinin de gerçek karar vermesi için bu karara saygı duyması gerekir.

Kararın daha sonra kötü olduğunu kanıtlarsa, en azından kesin olarak biliyorsunuz ve ondan öğrenebilirsiniz.

Bir yaklaşım oy kullanmak ve daha küçük ölçekli takımlarda iyi çalışıyor.

İki kişi sohbet ediyor olabilirken; açık bir foruma taşı ... N süre tartış, sonra da ellerini kaldırarak oy ver.

Basit ama demokratik ve ilerlemenizi sağlar.

Benzer bir soru olabilir:

Forumlarda dini / alev savaşları nasıl durdurulur?

Sanırım @ S.Lott, yorumunda haklı, tek nokta "tartışma", "çekip gitmek" ya da başka türlü görmezden gelmek, tek cevap olabilir. Bu tekniği geçmişte kullandım.

Eğer nokta bir çözüme ulaşmaksa, söz konusu alan için artıları / eksileri tartın, bir süre limiti ayarlayın ve (Nike'a başını sallar) hemen yapın.

İdeal olarak - IMO - teknik lider veya otorite figürü, "tamam, puanlarınız için teşekkür ederiz, biz ..." zar atmanın sesi "diyoruz . ve herkes gider ve oturur.

Minik noktaların üzerindeki geekery, toplantı zamanımın çok büyük bir kısmını boşa harcadı ve artık duymak istemiyorum. : - /

Sohbeti, hangi alternatifin doğru olduğuna değil, yanlış olanı seçmenin sonuçlarının ne olduğuna odaklandığınızda çok fazla tıkanma eğiliminde olmadığınızı anlıyorum. Biz bir doğru olsa bile, B bizi öldürmek olmayacak bir fikir birliğine varmaya Eğer biz ise biz B ile gidiş sonunda, kimse de butthurt alır olamaz o fikir birliğine varmaya gerçek bir sorun var, çünkü genellikle bulunuyor, ele almamız gerek.

Asıl mesele şu ki, olgun olmak zorundayız ve her zaman birbirimize hemfikir olamayacağımızı anlayın, büyük ve olgun olan şey birbirimizden öğrenmek, neden sahip olduğumuz pozisyonlara sahip olduğumuzu ve belki de kendi kendime soru, neyin yaşandığını ve nedenini öğrenmek. Sonra kendi bilgilendirilmiş görüşümüzü oluşturabilir ve lanetlenebilir veya edilmeyebiliriz.

Şahsen, diğer insanların benimle aynı fikirde olmalarına ihtiyacım yok veya beklemiyorum, iyi olurdu, ama önemli değil. Ve bu noktaya Voltaire'den alıntı yapıyorum.

“Söylediklerinize katılmıyorum, ama bunu söyleme hakkınızı ölümüne savunacağım.” -Voltaire, 5. Yüzyıl Filozofu

Her toplantıda gündemden ve düzenden sorumlu bir başkan bulunmalıdır (ve toplantı her şeyle başa çıkamayacak kadar büyükse, bu görevi başkasına devredebilir). Başkanın görevi, birisine tartışmayı bırakmasını söylemek (şirket konuşmasında "beyler, lütfen çevrimdışı olun").

Toplantı bir başkan atamaya değmiyorsa, toplantıya değmez. Su soğutucusunda da sohbet edebilirsiniz.

Biri "söylenenden daha kolay söylenir, quant_dev" diyebilir. Şey ... doğal bir başkan, bir ekip lideri, bir proje yöneticisi, bir ekip yöneticisidir. Gerekli yetkiye sahip olmalılar. Hiç kimsenin toplantıları gerçekten kimin yönlendirdiğini bilmediği toplantılar, organizasyondaki kaosun işaretidir, çözülmesi gereken daha derin bir problemdir.

Önce genel sorunları çözün: bir web sunucusuna, uygulama sunucusuna, DB'ye vb. İhtiyacımız var.

Hangi DB veya sunucunun kullanılacağı konusundaki tartışmalar için bu öğeleri başka bir toplantı için park edin.

Müteakip toplantılar sırasında, MySQl, MS SQL Server, Postgres, vb.

Ekip üyelerinin görüşlerini dile getirmelerine izin verin, ancak görüşlerini gerçeklerle desteklemelerini isteyin. Ürün X berbat! Kesmiyor, Ürün Y ölçeklenmiyor! Çok belirsiz. Vb.

Tüm detaylar ortaya çıktığında ve masada bir oy vermeye ya da takım lideri olarak bir yürütme kararı vermeniz gerekir.

Açıkça kazananı kazanmanız veya bir özellik / konsept için destek / eksiklik olduğunu onaylamanız gerekiyorsa, POC (Konseptin Kanıtı) yapmak için biraz zaman ayırmaktan çekinmeyin ancak bunun zaman alacağını ve geliştiricilere yönelik bir eğilim olduğunu fark edin. Başladıkları her neyse onunla koşmak istiyorum ... POC'ye gitmeden önce barikatlar / teknik kaygılarını doğruladığınızdan emin olun.

Bir takım lideri olarak ben karar eğer bağlıdır hissetmek gerekir burada ve şimdi yapılacaktır.

Gerekirse, en düşük geri dönüş maliyetine sahip olanı ararım. Bir geliştirme ekibi olarak, kararınızın yanlış olabileceğini bilmek, topal seçim yapmak ve fikrinizi değiştirmek zorunda kalabilirsiniz. Bunu yapmanın maliyeti her zaman en aza indirilmelidir.

Eğer bekleyebilirse, o zaman tarafların hiçbirine katılmamasının tüm gerçeklere sahip olmadığını düşünün. Ayrılmalarını ve daha fazla araştırma yapmalarını ve kendi araştırmalarınızı yapmalarını isteyin.

Bunu hep savaşın sıcağında mı yapıyoruz? Hayır, özellikle de hararetli düşüncelere sahip biriyken (mükemmel olduğunu iddia etmiyorum). Ancak bunun böyle durumlara yaklaşmanın yolu olduğunu düşünüyorum. Zaman boks hiç bir zaman herkesin aynı fikirde olmasına yol açmaz, sadece sonuçsuz bir tartışmaya yol açar.

Zorlu bir takım üyeniz olmadığı sürece, her iki yaklaşımın da net bir avantajı olmadığı sürece genellikle sonsuz bir tartışmanız olmaz. Aşağıdakiler kravat kırmada bazı iyi yaklaşımlardır:

• Gerçekten uygulamak zorunda olan kişinin karar vermesine izin verin.
• Kullanıcı Arabirimi sorunları için, kişinin müşteri gereksinimlerinden en çok haberdar olmasına izin verin.
• Konuyla veya kod tabanının bir kısmı ile ilgili en fazla deneyime sahip olan kişinin karar vermesine izin verin.
• Kesin programı kısıtlamaları olan insanlara ya da insan gücü ve kaynak sınırlamalarına karar vermesine izin verin.
• Kişinin teorik itirazlardan ziyade kimin daha somut olduğuna karar vermesine izin verin.
• Yaklaşımlar arasında bir uzlaşma bulun.
• Son toplantıdan bu yana araştırmaları biraz zaman harcayan insanlara daha fazla ağırlık vererek daha fazla bilgi toplayın ve bir sonraki toplantıya karar verin.

Bildiğim kadarıyla nasıl bir karar açıklayacak, sadece "Tamam, gideceksin, demek bu çünkü bu ." İnsanlar kendilerine adil bir duruşma yapmış gibi hissediyorlarsa ve lider olarak kibar olmak istemiyorsanız, kararınızla devam edeceklerdir. Özellikle inatçı için, belirli bir miktarda uygulama yapıldıktan sonra yeniden değerlendirme sözü verebilirsiniz, ancak çoğu kişi bu noktaya kadar düşecek.

İyi bir toplantı kolaylaştırıcısı, bu tür tartışmaları ele geçirmelerine izin vermeden kolaylaştırabilir.