İK Liderleri Üretici Olduğunda

Stay on the leading edge of leading with human-centric AI. Create a free account.

Bu İK liderlerinin kendi yapay zekâ araçlarını nasıl geliştirdiğini keşfedin; kullanıma hazır platformların ötesinde İK çözümleri tasarlamaya, test etmeye ve iyileştirmeye ilişkin pratik dersleri ortaya koyuyor.

Key Takeaways

Deney İçgörüsü: İş birliğine dayalı yapay zekâ projeleri, yalnızca araç geliştirme alanının ötesinde İK yetkinliklerine ilişkin derin içgörüler sağladı.

Soruna Odaklanma: Duygu analizinden beceri haritalamaya geçiş, açık ve ulaşılabilir hedefler belirlemenin önemini ortaya koydu.

Yapay Zekâya Şüpheyle Yaklaşım: İK profesyonelleri, mevcut yapay zekâ platformlarında hesap verebilirlik ve şeffaflık konusunda önemli zorluklarla karşılaşıyor.

Araç Yapısı: Yapay zekâ değerlendirme aracı iş birliğini öne çıkardı ve kullanıcıların yapay zekâ tarafından oluşturulan geri bildirimleri onaylamasına veya sorgulamasına olanak tanıdı.

Karşıtlık Testi: Başarılı bir araç geliştirmek, uç durumları etkili biçimde ele almak için çeşitli girdilerle titiz testler yapılmasını gerektirir.

Toplantılar bir saat olarak planlanmıştı. Neredeyse her zaman uzuyorlardı.

Bir grup İK profesyonelini yapay zekâ hakkında konuşmak üzere bir araya getirdiğinizde bu alışılmadık bir durum değildir. Alışılmadık olan, bu konuşmayla ne yapmalarının istendiğiydi. Konuşmayı analiz etmeleri ya da bunun hakkında bir değerlendirme yazısı yayımlamaları değil, gerçekten bir şey inşa etmeleri isteniyordu.

2025 sonbaharında, oluşturucu kohortları olarak adlandırdığım grupları bir araya getirdim: hâlihazırda bu işi yapan ve İK mesleğinin yapay zekâyla neler yapabileceği konusunda sınırları zorlayarak düşünen, belirlediğim küçük İK ve çalışan operasyonları profesyoneli grupları. 

Hipotez basitti. Sorunlara en yakın olan insanlar, çözümleri geliştirmek için en uygun konumdaki kişilerdi. Soru, bunu yapıp yapamayacaklarıydı.

Toplamda dört kohort oluşturacaktım ve bu süreçte bu oturumlar için hedef belirlemenin söylemesi yapmasından daha kolay olduğunu fark edecektim. Sonunda kohortların çoğu, başlangıçtaki vizyonu hayata geçirmekte veya tek bir hedef üzerinde uzlaşmakta zorlanarak sönümlendi. Takvimler, iş yükleri ve asıl işlerimizin talepleri çoğu zaman harika fikirler üreten, ancak bunları hiçbir zaman gerçeğe dönüştürmeyen konuşmalara yol açtı.

Ancak bir kohort bir araya geldi ve elinden geldiğince gerçekten sonuna kadar ilerledi. Gerçek şu ki, kendin inşa et tavşan deliğinde ne kadar derine inerseniz, ortak bir vizyona sadık kalmak ve mühendislik gereksinimini karşılamak da o kadar zorlaşır. 

Bu hikâye, o oturumlardan ortaya çıkanların bir anlatımıdır ve bunu kendi çözümlerinizi geliştirmeye yönelik bir vaka çalışması olarak sunuyorum.

Kohort

Erin Turnmeyer

Erin Turnmeyer

Kohortun gerçekleştiği dönemde Erin, Civis Analytics’te Çalışan Operasyonlarından Sorumlu Başkan Yardımcısıydı. Çalışan el kitabı üzerinde eğitilmiş bir sohbet robotu, iş gücü planlama aracı ve tek kişilik bir İK ekibinin kendini tüketmeden daha fazla iş hacmini yönetmesini sağlayan bir yan haklar öneri motoru gibi kendi kurum içi yapay zekâ araçlarını çoktan geliştirmişti. O zamandan beri yeni bir görev üstlenmek üzere Tri-City Electrical Contractors’ta Stratejik Girişimler Direktörü olarak çalışmaya başladı.

Melina Gillies

Melina Gillies

Kohortun gerçekleştiği dönemde FlexNetworks’te İnsan, Pazarlama ve Müşteri Deneyiminden Sorumlu Direktör. Yapay zekânın çevresel ayak izine ilişkin kurumsal şüphelerle başa çıkarken, yapay zekâ benimsenmesi için insan odaklı değişim yönetimine liderlik etti.​​​​​​​​​​​​​​​​ 

Kelly Satterfield

Kelly Satterfield

İK lideri, danışman ve yapay zekâ girişimlerine danışmanlık yapan kişi. İşe alımların dondurulduğu bir dönemde yetkinlik öz değerlendirmesi geliştirmişti ve o zamandan beri bunun daha kapsamlı bir şeye dönüşüp dönüşemeyeceğini merak ediyordu.

Tim Fisher

Tim Fisher

People Managing People’ın ana şirketi Black and White Zebra’da Yapay Zekâdan Sorumlu Başkanımız. Prototipi gerçekten geliştirebilecek teknik sezgilere sahip olarak dönüşüm ve değişim yönetimi alanındaki kariyerinden kısa süre önce ekibimize katıldı.

Bunlar, ikna edilmesi gereken yapay zekâ şüphecileri değildi. Bu kişiler, bu döneme çoktan yatırım yapmış uygulamacılardı. Kohortun onlara sunduğu şey, danışmanlık yapmayı bırakıp üretmeye başlamak için yapılandırılmış bir alandı.

İlk Dürüst Konuşma

İlk oturum, yayımlanan İK yorumlarına nadiren yansıyan bir şeyi açığa çıkardı: Bu profesyonellerin kullanmaları beklenen araçlardan aslında ne kadar hayal kırıklığına uğradıkları.

Turnmeyer ortamın tonunu belirledi. BambooHR, Paycom ve Gusto içinde duygu analizinin nasıl çalıştığına ilişkin teknik belgeleri edinmeye çalışmıştı; amacı araçları göz ardı etmek değil, hukuk ekibinin kullanımlarını onaylamadan önce bu araçları anlamasını sağlamaktı. 

Ne satış ekipleri ne de hukuk temsilcileri sorularını yanıtlayabildi. Yapay zekâ özellikleri mevcuttu. Nasıl çalıştıklarına ilişkin hesap verebilirlik ise mevcut değildi.

Gillies de benzer bir gerilimle başa çıkıyordu. Kurum içinden bazı kişiler yapay zekânın çevresel etkisiyle ilgili endişelerini dile getirmiş, bazı çalışma arkadaşları ise yalnızca çalışanların yapay zekâ kullanımını yasaklamak istemişti. Gillies buna karşı çıktı.​​​​​​​​​​​​​​​​

Yapay zekâyı tamamen yasaklamak, gizli kullanıma ve artan riske yol açar. Yapay zekâyı koruyucu önlemlerle benimsemek daha iyi bir yaklaşımdır.

Melina Gillies  ·  İnsan ve Kültür Başkanı, Flex Networks

İlk saatin sonunda ortaya çıkan şey, grubun üzerinde uzlaşabildiği bir teşhisti. Gillies'in ifadesiyle, kurumsal İK platformlarının yerleşik yapay zekâ özellikleri "çoğu zaman temel düzeyde ve işlevsellikten yoksun"du. 

Gerçekten işe yarayan araçlar genellikle belirli sorunlar, belirli bağlamlar ve belirli şirketler için geliştirilmiş, özel çözümler olma eğilimindedir. İnsan ve operasyon liderlerinden sık sık duyduğum bir görüş olan Turnmeyer, daha fazla araç değil, daha az araç istiyordu. Doğru belgelerle beslenen yetkin bir yapay zekânın İKYS'yi gereksiz kılabileceği bir gelecek hayal edebiliyordu.

Ayrıca nadiren bu kadar doğrudan ele alınan bir konuyla da yüzleştiler: davranış takibinin etiği. Toplantı reddetme oranlarının, sisteme girişler arasındaki boşlukların veya olağandışı çalışma saatlerinin bağlılık kopmasının göstergeleri olarak kullanılması fikri erkenden gündeme geldi. 

Bu yaklaşımın sınırları da tartışıldı. Satterfield, her bağlılık aracının er ya da geç karşılaştığı bir risk olan eylemsizlik yorgunluğuna dikkat çekti. Veri toplar ve bunu görünür biçimde eyleme dönüştürmezseniz çalışanlar sisteme güvenmeyi bırakır. Veriler gürültüye dönüşür ve araç yapay zekâ tiyatrosuna dönüşür.

Henüz duygu analizi aracı geliştirmeye hazır değillerdi. Konu çok genişti, etik ikilemlerle fazlasıyla yüklüydü ve feci biçimde yanlış sonuçlara ulaşmak çok kolaydı. Bu yüzden yön değiştirdiler.

Doğru Sorunu Bulmak

İkinci oturum, başlangıçtaki yönelimin fazla iddialı ve fazla belirsiz olduğuna dair dürüst bir kabulle başladı. 

Turnmeyer, "Bunun bağlılığı mı ölçtüğünü bilmiyorum," dedi, "yoksa sadece bir konuşmayı gerektiren bir şeyi mi ölçtüğünü bilmiyorum."

Bu ayrım, ilk bakışta göründüğünden daha önemli. Pek çok İK teknolojisi, veriyi konuşmanın yerine koyma hatasına düşüyor. Grup, bir konuşmanın yapılması gereken anları ortaya çıkarmak ve ardından bu konuşmayı daha iyi hâle getirmek için yapay zekâyı kullanmaya çalışıyordu.

Satterfield, projenin geri kalanına yön verecek fikri ortaya attı. Önceki işverenlerinden birinde işe alım dondurması sırasında, yetenek kazanımı ekibi için bir beceri öz değerlendirmesi oluşturmuştu. Bu, insanların neleri yapabildiğini aslında neleri yapmak istedikleriyle karşılaştırarak haritalandırmanın bir yoluydu ve yeniden görevlendirme kararlarını daha insancıl ve stratejik hâle getiren bir ısı haritası oluşturuyordu. 

Yapay zekâ destekli değildi. Bir Microsoft Form'uydu. Ancak altında yatan mantık sağlamdı, kullanım alanı gerçekti ve işe yaradığını görmüştü.

"Büyük tedarikçiler bunu yapmaya çalışıyor, ancak henüz hiç kimse bunu gerçekten iyi yapamıyor ve pek çok şirketin temel İKYS'lerine ek olarak bu tür bir teknoloji için ayrılmış bir bütçesi yok," dedi.

Grup fırsatı gördü. Ya yapay zekâ odaklı bir sürüm geliştirselerdi? Klinik olmak yerine sohbet odaklı, uyumluluk güdümlü olmak yerine geleceğe dönük ve kurumsal sözleşmelerin arkasına kilitlenmek yerine bireysel İK liderlerinin bütçesine uygun fiyatlandırılmış bir sürüm?

İK'nın İK hakkında İK ile konuşma biçimi dinamik olarak farklıdır. Bu gerçek bir değer yaratabilir ve çoğu araç bunu tamamen gözden kaçırır.

Melina Gillies  ·  İnsan ve Kültür Başkanı, Flex Networks

Grup olasılıkları değerlendirirken dinleyen Fisher, projenin potansiyelini yeniden çerçeveleyen bir gözlemde bulundu. İK yelpazesinin her iki ucunu da deneyimlemişti: uyumluluğu ve çerçeveyi önceleyen, işlemsel yaklaşımı ve daha nadir görülen, kendisiyle "yanımda olduğunu hisseden biri gibi" konuşan insanı önceleyen uygulamacıyı.

"İkinci türün dili," dedi, "hiçbir zaman onlarca yıl önce yazılmış bir çerçeveden çıkmış gibi hissettirmedi. Sadece iyi hissettirdi."

Gillies bu fikri benimsedi. Ona göre araçlarının fark yaratan yönü ton ve yapıydı. Araç, İK profesyonellerinin bir konferansta oturumlar arasında, kayıt dışı olarak birbirleriyle gerçekte nasıl konuştuklarını taklit edebilseydi ne olurdu? "Politik açıdan becerikli" olmayı bir onay kutusu olarak değil, deneyimli uygulamacıların kendi aralarında tartıştığı, yüklü, tartışmalı ve duruma göre karmaşık bir konu olarak anlayabilseydi ne olurdu?

Yön buydu: işe almadan önce işe alım uzmanı adaylarını değerlendirmek için daha iyi bir yönteme ihtiyaç duyan İK ve yetenek kazanımı liderleri için tasarlanmış bir işe alım öncesi değerlendirme aracı. Bir kişilik testi veya özgeçmiş taraması değil; işe alım yöneticisine karşısındaki kişinin işi nasıl yapacağını gerçekten bilip bilmediğini söyleyebilecek yapılandırılmış, sohbet odaklı bir teşhis aracı. Bir performans değerlendirmesinden çok, işe alımı içeriden anlayan biriyle yapılan bir sohbet gibi hissettiren bir araç.

It starts with one signal.
Each week, AI Signal takes one meaningful shift in AI and helps people leaders understand what changed, why it matters, and what to consider next.
Get Free Access

Have an account? Log In

Aydınlanma Anı

Üçüncü oturumda grup, aracın mimarisine derinlemesine girmişti: hangi yetkinliklerin değerlendirileceği, bunların seviyeler arasında nasıl yapılandırılacağı ve insanların yapabileceklerini söyledikleri şeylerle gerçekten yapabildikleri arasındaki farkın nasıl hesaba katılacağı.

Mevcut çerçevelere yönelik eleştiri, SHRM yetkinlik modelini bazı yönlerden "çok geleneksel ve geçmişe fazlasıyla dönük" olarak tanımlayan Gillies'ten geldi. Onun ifadesiyle meslek hâlâ "sanayi sonrası bir rehavet" içindeydi: uyumluluk temelli, hiyerarşik ve artık gerilemekte olan bir dünya için tasarlanmıştı. 

Araçlarının yönelmesi gereken şey, İK liderlerinin bilmesi gerekenler değil, yapabilmeleri gerekenlerdi.

CEO ile performansı hakkında konuşmaya istekli misiniz? İstekli değilseniz, zor konuşmalar konusunda uzman değilsiniz.

Erin Turnmeyer  ·  İnsan Operasyonlarından Sorumlu Başkan Yardımcısı

Turnmeyer'in açıklayıcı bir örneği vardı. Kısa süre önce SPHR sınavına girmişti. Bilmesi gereken şeyler—yasa hükümleri, usule ilişkin tanımlar, sınıflandırma kuralları—yetkin herhangi bir İK profesyonelinin basitçe araştırıp bulabileceği şeylerdi. 

Zor beceriler sertifika sınavının içeriğinde yer almıyordu. Bunlar şunlar gibi şeylerdi: Bir CEO'nun karşısına oturup duymak istemediği bir şeyi ona söyleyebilir misiniz? İş gerekçesi belirsiz olduğunda bir çalışanı savunabilir misiniz? İş kanunlarını ezberlemek bu soruların yanıtını vermez.

Fisher konuyu daha da ileri götürdü. Yıllarını değişim yönetiminde geçirmişti ve bir kuruluşun dönüşüm sürecini yönetme becerisini en iyi öngören değişkenin belirli bir beceri olmadığını görmüştü. Bu, kişinin belirsizlikle olan ilişkisiydi.

Birinin rahatsızlık vermeyen bir durum içinde ne kadar rahat olduğunu—ya da genel olarak değişim hızına ne kadar uyum sağladığını—öğrenmek, bu yeni dünyada işlev görme becerinizin çok önemli bir göstergesidir.

Tim Fisher  · Black and White Zebra Yapay Zekâ Başkanı

Ardından grubun daha sonra gizli formül olarak adlandıracağı şey ortaya çıktı.

Gillies bir soru ortaya attı. Ya araç bir çapraz kontrol mekanizması içerirse? Bir kişi kendisini çatışma yönetiminde uzman olarak değerlendiriyor, ancak ardından bir takip sorusuna verdiği doğal dil yanıtında uzmanlıktan çok uzak görünen durumları anlatıyorsa, yapay zekâ bunu işaretleyebilir miydi? Burada bir boşluk olabileceğini nazikçe söyleyebilir miydi?

"İşte bu, ampulün yandığı andı," dedi Turnmeyer.

Beceri envanterleri ile çalışmış herkesin aynı sorunun farklı örneklerini gördüğünü belirtti Satterfield. İnsanlar çoğu zaman kendilerini, gerçek deneyimlerinin veya davranışlarının göstereceğinden çok farklı değerlendirir.

Aracın değeri, insanların kendileri hakkındaki inançlarını kaydetmesinden gelmeyecekti. Değeri, öz algı ile kanıtlanmış yetkinlik arasındaki nazik, veriye dayalı sürtüşme olan kalibrasyondan gelecekti.

Değerlendirme yalnızca bir ayna olmayacaktı. İş yeri değerlendirmelerinde çoğu insanın alışık olduğundan daha çok “duvardaki ayna, ayna” olacaktı. 

Geliştirmenin Gerçekleri

Bunların hiçbiri kolay değildi. Grup da işe başlarken bunu biliyordu.

En kalıcı zorluk teknik değildi. Kapsamdı. Her oturum, her biri gerçekten değerli ve projenin tamamını yutabilecek on yeni yön ortaya çıkarıyordu. Turnmeyer bunu erkenden ve sık sık dile getirdi. 

"İlk işi doğru yaptığından emin olun; böylece kapsam kontrolden çıkıp onu oluşturamayacağınız bir noktaya gelmez," dedi.

Satterfield grup için yol gösterici bir ilke ortaya koydu: Minimum Uygulanabilir Ürün ile Minimum Değerli Ürün arasındaki fark. Uygulanabilir bir ürün çalışır. Değerli bir ürün, insanların geri dönmek istemesini sağlar. 

Değerlendirme araçlarıyla doymuş bir pazarda, ilk etkileşimde anlamlı bir şey sunmayan bir arayüzün gelişmesi için ikinci bir şansı olmaz. Ölçüt işlevsellik değildir. Değerdir.

Ürün ilk girişte yeterli değer sağlamazsa, kullanıcıların daha sonra iyileşip iyileşmediğini görmek için geri dönmesi pek olası değildir.

Kelly Satterfield  ·  İK Lideri ve Danışman

Ayrıca bir geliştirme ekibinin dışında bir şeyler oluşturmaya çalışan herkesin yakından bildiği pratik kısıtlar da vardı: dağıtım, ödeme altyapısı, mevcut sistemlerle entegrasyon, oturumun ortasında kapanarak saatlerce süren verimli çalışmayı silen bağlam pencereleri. 

İlk geliştirme, aracın temel akışını yansıtıyordu. Bir işe alım uzmanı, rol adayı özgeçmişini yükler; araç ön beceri profilini çıkarır ve ardından bu ilk değerlendirmeyi kalibre edip ona bağlam ve derinlik kazandırmak üzere tasarlanmış bir dizi sohbet biçimli soruda adaya rehberlik eder.

Sonunda işe alım lideri, adayın belirlenmiş bir yetkinlik çerçevesi karşısında gerçekte nerede durduğuna dair bir tablo elde eder. 

Fisher, belirli bir LLM'e bağımlı bırakmadan sohbet yoluyla kamuya açık araçlar oluşturan kodsuz bir yapay zekâ geliştiricisi olan Lovable'da temel geliştirme ortamını kurdu; böylece teknik mimari, grubun düşünce hızına ayak uydurabilir ve kendi başına bir darboğaza dönüşmezdi.

Taslak Plandan Geliştirmeye

Dördüncü oturuma gelindiğinde grup artık soyut bir araç tasarlamıyordu. Bir araç geliştiriyorlardı ve geliştiricilerin her zaman yaptığı gibi, fikir ile uygulama arasındaki mesafenin gerçek öğrenmenin tam olarak gerçekleştiği yer olduğunu keşfediyorlardı.

Fisher, görüşme yüklenmeden önce talimatlar, ön yeterlilik çerçevesi ve önceki oturumlarda haritasını çıkardıkları konuşma mantığının başlangıç aşamalarını içeren temel düzeyde özel bir GPT oluşturmuştu. Plan, herkesin buna erişmesi, birlikte istemler vermesi ve sesini ve davranışını gerçek zamanlı olarak kalibre etmeye başlamasıydı. Plan hemen gerçeklerle karşılaştı.

Paylaşılan bağlantı benden başka hiç kimse için çalışmadı. Çalışma alanı izinleri, platformun kendine özgü sorunları ve ChatGPT'nin dış erişimi ele alış biçimi, oturumun ilk çeyreğini tüketti. 

Bu, tam da bir ürün duyurusunda asla yer almayacak türden küçük bir hayal kırıklığıydı ve öğreticiydi. Uygulayıcıların gerçekten bir şeyler oluşturmak için kullandıkları araçlar, demolar gibi davranmaz.

Karşılama ekranının sonunda nasıl görüneceğini gösteren bir ekran görüntüsü.

Bu ekran görüntüsü, grubun oluşturduğu ve Talent Scout adını verdiği aracın karşılama ekranının nasıl görüneceğini gösteriyor.

Herkes aynı ekrana bakmaya başladığında daha ilginç bir şey oldu. Grup hâlâ yeterlilik tanımlarının hangi biçimde olması gerektiğini tartışırken Gillies, ayrı bir pencerede Claude'u açtı ve puanlama tablosunu görüşme sırasında canlı olarak yapılandırılmış JSON'a dönüştürdü. 

"Bunun için Claude kullanıyorum çünkü bu konuda ChatGPT'den daha iyi," dedi, bunu herhangi bir törene dönüştürmeden. Biçimlendirilmiş dosyayı birkaç dakika sonra grup sohbetine bıraktı. Kimse bunu kabul etmek için durmadı. Sadece ilerlemeye devam ettiler.

Hareket hâlindeyken sorun çözme—bir darboğazı, onu toplantının ana gündemine dönüştürmeden çözüme kavuşturma—bu araçları gerçekten içselleştirmiş uygulayıcıları hâlâ bu araçlarda yolunu bulmayı öğrenenlerden ayıran şeydir.

Son Sözü Kim Söyler?

Satterfield, hem aracın mimarisi hem de nihai olarak nasıl karşılanacağı açısından önemli sonuçlar doğuracak bir soru ortaya attı: Nihai değerlendirmeyi yapay zekâ mı sunmalı, yoksa kullanıcı mı onaylamalı?

Bu ayrım sadece kozmetik değildir. Araç, "Yanıtlarınıza göre aday odaklılık alanında 2. seviyedesiniz" gibi bir hüküm verirse, yapay zekâyı otorite konumuna yerleştirir. Bunun yerine geçici bir değerlendirme sunup kullanıcıyı itiraz etmeye davet ederse dinamik tamamen değişir. Değerlendirme, hüküm verici olmaktan çıkar ve iş birliğine dayalı hâle gelir. Kullanıcı sürecin nesnesi değil, katılımcısıdır.

"Bu geri bildirimi kabul ediyor musunuz?" dedi Turnmeyer, fikir ortaya çıktığında. "Buna bayıldım."

Gillies mantığı geliştirdi. Kullanıcı değerlendirmeyi kabul etmezse araç, neyin yanlış hissettirdiğini soruyor ve ardından yanıtı, değerlendirmesini yeniden kalibre etmek ya da kanıtları adım adım ele alarak değerlendirmesini nazikçe yeniden doğrulamak için kullanıyor.

Bu konuşmaya dayalı karşılıklı alışveriş, aracın gerçekten yararlı olabilmesi için ihtiyaç duyduğu psikolojik güvenliği yaratır. İnsanlar güvenmedikleri geri bildirimlere dayanarak değişmez. Kabul sağlamak yumuşak bir özellik değil, mekanizmanın kendisidir.

İlk Gerçek Sınama

Prototipi canlı olarak test etmeye karar verdiler. Turnmeyer, değerlendirme sorularından birine kasıtlı olarak yüzeysel bir yanıt vermeyi gönüllü olarak üstlendi—ilgisiz bir adayın ya da dikkati dağılmış bir çalışanın verebileceği türden bir yanıt. 

Maaşındaki bir tutarsızlık nedeniyle yöneticisiyle tartıştığını, adayı kaybettiğini ve sonucun ne olduğu hakkında hiçbir fikri olmadığını anlattı. Bu, neden İK'da çalışmak istediğiniz sorulduğunda "İnsanları gerçekten çok seviyorum" diye yanıt vermenin İK'daki karşılığıydı.

Araç bunu hemen değerlendirdi. Bir seviye atadı. Teşvik ediciydi. Aynı zamanda yanlış olmasa da erkenciydi. Yanıtın ne anlama geldiği konusunda varsayımlarda bulunmuş, doğru bir değerlendirme yapmak için ihtiyaç duyacağı ek bağlamı sormamıştı.

Birine 'beklentileri karşılıyor' dışında bir değerlendirme verecekseniz ayrıntılı örnekler sunmalısınız. Yapay zekâ da kendisinden aynı standardı beklemeli.

Erin Turnmeyer  ·  İnsan Operasyonları Başkan Yardımcısı

Turnmeyer bu paralelliği doğrudan performans değerlendirme uygulamasından kurdu. Uzun zamandır yöneticilerin herhangi birini "beklentileri karşılıyor" düzeyinin üstünde ya da altında değerlendirmeden önce somut kanıt sunmasını şart koşuyordu.

Aynı disiplin araca da uygulanmalı. Bir seviye atamadan önce, değerlendirmeyi savunulabilir kılacak soruları sorarak bunu yapma hakkını kazan. Bir kez daha odadaki İK uzmanlığı yapay zekâyı daha iyi hâle getiriyordu; tersi değil.

Satterfield, aracın gözden kaçırdığı bir karmaşıklık ekledi. Yüzeysel yanıt beceriden ziyade politikayı yansıtıyor olabilirdi. 

Yönetici gerçekten sabit bir ücret tavanı belirlemişse daha güçlü savunma yapmak sonucu değiştirmezdi. Araç, durum hakkında soru sorması gerekirken kişiyi değerlendirmişti. Açıklayıcı sorular sonradan eklenecek bir cilalama unsuru değildi. Yararlı bir değerlendirmeyi varsayıma dayalı bir değerlendirmeden ayıracak şey onlardı.

Turnmeyer talimat yazma görevini ödev olarak aldı: Her etkileşimi bir sorguya çekme gibi hissettirmeden, bir araca doğru anlarda açıklayıcı sorular sormasını nasıl telkin edersiniz? 

Bu ekran görüntüsü, nihai ürünün açıklayıcı sorular sorarak ve adayı daha derinlemesine düşünmeye yönlendirerek ne yapacağına dair bir örnek göstermektedir.

Kulağa geldiğinden daha zor bir problemdi ve çıtanın alışılmadık derecede yüksek olduğunun fazlasıyla farkındaydı. 

"Bir insandan daha iyi olması gerekiyor," dedi. "Standart bu."

Bir Disiplin Olarak Test

Oturum, tüm grubun ortaya koyduğu en pratik açıdan yararlı metodolojik içgörülerden birini de sağladı. Satterfield, grubun genellikle bunun gibi araçları nasıl test ettiğini sorduğunda Turnmeyer ve Gillies'in her ikisi de, titiz testlerin pratikte gerçekte nasıl göründüğüne dair önemli bir şeyi açığa çıkaran yanıtlar verdi.

Düşünce Çeşitliliği Önemlidir

Düşünce Çeşitliliği Önemlidir

“Farklı düşünme ve etkileşim tarzlarına sahip kişileri işe alın, onları serbest bırakın ve nerelerde bozulduğuna dair not almalarını sağlayın. Sonrasında değerlendirme yapın. Doğru bir çıktının nasıl göründüğünü bilen kullanıcılara ihtiyacınız var; böylece çıktının doğru olmadığını anlayabilirler.” – Melina Gillies

Anlamlı Geri Bildirim Tek Yararlı Geri Bildirimdir

Anlamlı Geri Bildirim Tek Yararlı Geri Bildirimdir

“Bana ‘hayır’ diyeceğini ve ‘bu kötü’ diyeceğini bildiğim insanlar var; önce onların test yapmasını sağlıyorum—çünkü bazı insanlar sadece çok nazik davranıp ‘bu harika, geri bildirim yok, teşekkürler’ diyor.” – Erin Turnmeyer

Belirli ilaçların şirketin sağlık planı kapsamında olup olmadığını doğru şekilde ortaya çıkarması gereken yan hak öneri aracı için Turnmeyer özellikle uç durumları test etti. Modelin eğitim sırasında tekrar tekrar karşılaşmış olacağı bariz ilaçları, popüler olanları değil. Güvenle halüsinasyon üretme olasılığı en yüksek kategorilerdeki, nadir kullanılan ilaçları test etti. 

"Gidip popüler olmayan ilaçları test ettim," dedi, "çünkü Claude, onu oluştururken ne yaptığını bana gösterdi."

Testlerdeki bu düzeyde karşıtlık arayan bilinçli yaklaşım, mühendislik bağlamı dışından gelen geliştiriciler arasında nadirdir. Aynı zamanda güven kazanan araçları, utandırıcı bir başarısızlıktan sonra sessizce terk edilen araçlardan ayıran şey de tam olarak budur.

Zaten Oluşturduklarınızı Kesmek

Tatil öncesindeki bir yeniden toparlanma oturumu, kulağa geldiğinden daha zor bir soruyla başladı: özgeçmiş yükleme özelliği aslında ne işe yarıyor?

Bu soruyu Gillies gündeme getirdi. Değerlendirme, kullanıcılardan kendi yetenekleri hakkında dikkatlice düşünmelerini istiyordu. Kullanıcı yalnızca soruları yanıtlayarak daha doğrudan sağlayamayacağı hangi bilgiyi özgeçmiş ekliyordu? Gruptaki hiç kimse bunun böyle olduğundan emin değildi. Başlangıçtaki amaç, bir özgeçmiş ayrıştırıcısı gibi zaman kazandırmaktı; ancak artık bunun gerçekten bu amaca hizmet ettiğine ikna olmuş değildik.

Bu özelliği kaldırmayı kabul ettiler.

Ürün geliştirmede bu, kulağa geldiğinden daha nadir görülür. Grup, yükleme özelliği üzerinde ciddi zaman harcamıştı—özelliği oluşturmuş, test etmiş, Satterfield'ın özgeçmişinin ayrıştırılıp yanlış puanlandığını izlemişti. Bu özelliği kaldırmak, ekipleri daha önce yatırım yaptıkları şeylere ekleme yapmaya iten batık maliyet mantığını geçersiz kılmayı gerektiriyordu. 

Sonu zihninizde canlandırarak başlayın ve sonuç açısından iyinin nasıl göründüğünü tanımlayın. Bir özelliğin ne amaçla var olduğunu açıklayamıyorsanız, onu savunamazsınız.

Turnmeyer metodolojiyle ilgili bir argüman daha ortaya koydu. Geriye dönüp baktığında, tek bir istem yazmadan önce aracın davranışını tamamen tanımlamış olsalardı daha hızlı ilerleyebileceklerini düşünüyordu. Çevik bir modele benzeyen bir süreç yürütmüşlerdi—oluştur, test et, ayarla—oysa oluşturdukları şeyin karmaşıklığı daha çok şelale yaklaşımı gerektirmiş olabilirdi: önce spesifikasyonu doğru şekilde oluştur, ardından buna göre geliştir. 

Bu ders ona, oluşturduğu farklı bir araçtan kalan 130 sayfalık bir tasarım belgesi sayesinde öğretilmişti. Eksiksiz bir spesifikasyon yalnızca ne oluşturacağınızı söylemez. Ne oluşturmadığınızı da söyler ve bunun en az diğer bilgi kadar yararlı olduğu ortaya çıkar.

Gillies, ürünün temel sorununu daha net hâle getirdi. Araç ekranda ne gösterirse göstersin, bunun daha ileri gitmesi gerekiyordu. Verileri ortaya çıkaran bir değerlendirme, size bu verilerle ne yapmanız gerektiğini söyleyen bir araçla aynı şey değildir. Çıktı ile eylem arasındaki bu boşluk, tanı araçlarının sessizce yararsız hâle geldiği yerdir ve çoğunun hiçbir zaman kapatamadığı boşluk da budur.

Tek Başına Geliştirmek

Ocak ayına gelindiğinde Satterfield, grubun geri kalanı 9-5 işlerinin çekimine fazla kapıldığı ve projeye ayıracak zaman bulamadığı için geliştirme işinin çoğunu kendisi yapıyordu. Ne de olsa bu iş için kimseye ödeme yapılmıyordu. 

Grubun üzerinde anlaşmaya vardığı gibi özgeçmiş yükleme özelliğini kaldırmıştı. Sesli girdi eklemişti—kullanıcılar artık değerlendirme sorularını yazmak yerine konuşarak yanıtlayabiliyordu; bu da bir metin alanını manipüle etmeye kıyasla daha zor olan, daha sohbet odaklı bir yanıt biçiminin önünü açıyordu. 

Sentetik test yanıtları oluşturmak için ChatGPT'yi kullanıyordu ("Bu konuda güçlü, şu konuda zayıf bir genç işe alım uzmanıyım, bana yanıtlar ver"); ardından bu yanıtları araca aktarmak ve aracın bunlara nasıl puan verdiğini gözlemlemek için Lovable'a geçiyordu.

Lider panosu, aracın mantığının diğer yarısıydı—bir TA direktörünün veya CHRO'nun bir adayın nasıl puan aldığını, boşlukların nerede olduğunu ve yetkinliklerinin mevcut bir ekibin güçlü yönlerini ve ihtiyaçlarını nasıl tamamlayabileceğini görmek için kullanacağı görünüm.

Bu durum, organizasyon yapısını gerçek bir sorun hâline getiriyordu çünkü aracın kimin kimi değerlendirdiğini ve sonuçları görme yetkisine kimin sahip olduğunu bilmesi gerekiyordu. 

Satterfield, veri entegrasyonunun olmadığı durumda kullanıcılardan adlarını, iş unvanlarını ve yöneticilerinin adını girmelerini isteyerek bunu çözmeye çalışmıştı. Ancak bu mantık, yaygın bir senaryoda yetersiz kaldı: hem doğrudan hem de dolaylı raporlama ilişkilerini içeren daha geniş bir işe alım organizasyonuna değerlendirmeyi göndermek isteyen bir yetenek kazanımı direktörü. Organizasyon eşleştirme mantığı, bu yapıyı hesaba katacak kadar incelikli değildi.

Teoride bu bilgiler, araca değerlendirmeyi alan kişinin rolü hakkında daha fazla bağlam sağlayacaktı, ancak daha fazla veri toplamak işleri karmaşıklaştırdı.

Turnmeyer bu sorunun bir versiyonunu farklı bir bağlamda zaten çözmüştü. Kendi şirketi için geliştirdiği performans yönetimi aracı, Google E-Tablolar, Slack ve Claude üzerinde çalışıyordu. Google E-Tablolar verileri depoluyordu. Slack, çalışanların etkileşim kurduğu arayüzdü. Claude ise analiz ve geri bildirim oluşturma işini yürütüyordu. 

Mimari, kulağa geldiğinden daha basitti: ad, e-posta, iş seviyesi ve iş unvanının yer aldığı bir elektronik tablo. İş seviyesini yetkinliklerle çapraz referanslayan ayrı bir sekme. 

"Şirketimdeki güvenlik ekibi aracımı incelemek istedi," dedi gruba. "Google Dokümanlar'da depolandığını söyledim. Onlar da 'Aa, bu kadar basitmiş,' dediler."

Basitti, ancak Turnmeyer bunu yalnızca geliştirerek öğrenmişti. Üç hafta önce bilmediği şey, günlük kaydının mevcut olduğuydu—a bir kullanıcının ilerlemesini kaydeden ve biri uzaklaşıp geri döndüğünde aracın sıfırlanmasını önleyen bir işlev. 

"Claude'a söylenip duruyordum," dedi, "ta ki bana günlük kaydının mevcut olduğunu söyleyene kadar. 

Geliştirme yapmak aslında bunu öğretir. Öğrenmeyi planladığınız şeyi değil, bilmeniz gerektiğini bilmediğiniz şeyi.

More Articles

Altta Yatan Soru

Ocak ayındaki oturumun bir noktasında, konuşma aylardır etrafında dolaştığı soruya ulaştı.

Grup mimariyi, izinleri, depolamayı ve panoları tartışmayı sürdürdü—bunların hepsi gerçek sorunlardı. Ancak bunların altında daha temel bir soru yatıyordu. Aslında ne inşa etmeye çalışıyorlardı ve kimin için?

Araç, başlangıçta tasarlandığı hâliyle bir seçim tanılama aracıydı—bir TA liderinin bir adaya veya şirket içindeki bir çalışana göndererek gerçek yetkinliklerinin özgeçmişlerinde yer alanlarla örtüşüp örtüşmediğini değerlendirebileceği ve bu tabloyu bir seçim kararı verilmeden önce ortaya çıkarabileceği bir araç. 

Burada gördüğünüz, aracın mülakata katılan kişi için ürettiği rapor türüne ait ekran görüntülerinden bir seçkidir. Değerlendirici için mevcut ekip güçlü yönlerini gösteren bir pano, mülakata katılan kişiyi TA ekibindeki zayıflıkları giderip gidermediğini görmek üzere hangi alanlarda değerlendireceğine odaklanmasına yardımcı olur.

Bu temel değişmemişti. Ancak aldıkları her pratik karar—bir lider panosu eklemek, abonelik modellerini düşünmek, oturum açma akışını oluşturmak—onları daha karmaşık bir şeye doğru çekiyordu. 

Gerçek zamanlı panolar sürekli erişim anlamına geliyordu; bu da abonelik ücretleri, dolayısıyla birçok kuruluşun karşılamakta veya etkili bir şekilde işletime almakta zorlandığı kurumsal araç türüne giderek yaklaşmak anlamına geliyordu.

"Bir HCM tedarikçisi olmaya çalışmıyoruz," dedi Satterfield.

Turnmeyer nerede durduğu konusunda dürüsttü. 

"Niyetim yalnızca yeni bir şey öğrenmekti."

Bu, projeden geri çekilmek değildi. Deneyin onun için zaten ortaya çıkardığı şeyin doğru bir ifadesiydi. Bazı yeni şeyler öğrenmişti ve kohorttan öğrendiklerini uygulayarak yeni bir performans yönetimi aracı geliştirme sürecine zaten başlamıştı. 

Grubun aracını ürünleştirmesine gerek yoktu; bundan gerçek bir değer elde etmişti.

Bu aşamada benim ilgim öncelikle editoryaldi. Anlatacak bir hikâye ve insanların inceleyebileceği bir şey istiyordum; bir abonelik ürünü değil, İK profesyonellerinin üzerine düşünebileceği ve belki de bunun gibi bir araç geliştirebileceği bir gösterim. 

Bu makaleyi yazmak da bunun bir parçasıydı. İndirilebilir bir rehber hazırlayabilir miydim? Sonunda grubun yaptıklarını tartışabileceği, bir kitlenin araçla etkileşime girmesine olanak tanıyacak ve konuşmayı bir podcast olarak kaydedebileceğimiz canlı bir etkinlik düzenleyebilir miydim? Pek çok fikrim vardı, ancak yeni yılın hedefleri hepimizin önünde birikmeye başladıkça bunları hayata geçirmek için kalan süre kısalıyordu. 

Satterfield'ın ilgisi ticari açıdan en fazla yönelim gösteren ilgiydi ve bu konuda netti. Sonunda bunu ürünleştirmekle ilgileniyordu. Bunu tek başına yapmayacaktı. Ancak bir gün satılabilecek bir şeye doğru geliştirmeye devam etmeye istekliydi.

Niyetin bu üç yönlü ayrışması—öğrenme, hikâye anlatımı, ürün—muhtemelen bunun gibi herhangi bir grup için kaçınılmazdır. Ocak ayında bu konu hakkında dürüstçe konuşmak, herkesin en başından beri aynı şeyi istediğini varsaymaktan daha faydalı oldu.

Yanıt Olarak Demo

İnsanların aracı denemesine nasıl olanak tanınacağı sorusu, özgeçmiş yükleme özelliğinin kullanıma açılmasından beri çözümsüz bir şekilde bekliyordu. Gerçek kullanıcılarla test yapmak değerliydi, ancak kendi sorunlarını da beraberinde getiriyordu. Aracın tutarlı bir şekilde çalışması, kullanıcıların ne yaptıklarını bilmeleri için yeterli bağlama sahip olması gerekiyordu ve kötü bir ilk deneyimin telafisi zordu.

Turnmeyer, grubun değerlendirdiği en basit çözümü sundu.

Demo kayıtlarını izliyordu—bir aracın nasıl çalıştığını, izleyenin aracı gerçekten kullanmasını gerektirmeden gösteren, bir ya da iki dakikalık kısa anlatımlar. Bunun yeterli olabileceğini öne sürdü. İnsanlar aracı iş başında görebilir, ne yaptığını ve neden yaptığını anlayabilir ve bunun mümkün olduğu duygusuyla ayrılabilirdi. 

Bir giriş ekranında yol bulmaları, bir organizasyon şeması sunmaları ya da bir değerlendirme sorusu kendi durumlarına uymadığında takılıp kalmaları gerekmeyecekti.

Yazdığım birçok blogdan aldığım geri bildirim, insanların gerçekten aynı şeyi birebir kopyalayıp yapıştırmak istemediği yönünde. Sadece bunu yapabileceklerini bilmek istiyorlar.

Erin Turnmeyer  ·  VP, İnsan Operasyonları

Bu gözlem, İK profesyonellerinin şu anda yapay zekâ araçlarıyla nasıl ilişki kurduğuna dair gerçek bir noktaya işaret ediyor. Birçoğunun aşmaya çalıştığı boşluk, bir şeyin var olduğunu bilmekle onu kullanmak arasındaki boşluk değil. Bu boşluk, böyle bir şeyi yapabilecek kapasiteye sahip olduklarına inanmakla ilgili. 

Profesyonellerin kendi araçlarını oluşturduğunu gösteren bir demo, tamamlanmış bir üründen farklı bir soruyu yanıtlar—“bu araç iyi mi?” sorusunu değil, “benim gibi biri bunu yapmış olabilir mi?” sorusunu.

Fikir olumlu karşılandı. Testle ilgili endişeleri giderdi, üretime hazır olmayan bir şeyi paylaşmanın karmaşıklığını azalttı ve vurguyu, grubun en başından beri amaçladığı yere, yalnızca çıktıya değil, sürece ve düşünme biçimine yöneltti.

Deneyin Öğrettikleri: İK Araç Geliştiricileri İçin Bir Rehber

  • Teknolojiyle değil, problemle başlayın. Grubun duygu analizi konusundaki ilk heyecanı gerçekti ve onları daha uygulanabilir, daha değerli bir problemden uzaklaştırdı. Yetkinlik haritalamaya geçiş işe yaradı çünkü sahada daha önce test edilmiş gerçek bir kullanım alanıyla başladı.
  • Özel çözümler geneli yener. Her katılımcı, kurumsal İK platformlarının sınırlarıyla karşılaşmıştı. Belirli bağlamlar için oluşturulan araçlar—Turnmeyer'in yan haklar önericisi, Satterfield'ın ısı haritası—hazır çözümlerden daha iyi performans gösterdi. Kendi aracınızı oluşturmanın gerekçesi hiç olmadığı kadar güçlü ve önündeki engeller hiç olmadığı kadar düşük.
  • Çapraz kontrol, işin tamamıdır. Öz değerlendirmeler, insanların kendilerini ne kadar iyi tanıdığı kadar iyidir ve bunun güvenilmez olduğu herkesçe bilinir. Bir aracın gerçek değeri, insanların kendileri hakkında inandıklarını yalnızca kaydetmesinde değil; bunları sorgulama, onlara meydan okuma ve nazikçe yeniden ayarlama becerisinde yatar.
  • Asgari Uygulanabilir değil, Asgari Değerli. İlk sürüm, kullanıcının geri dönmek istemesini sağlayacak bir şey sunmuyorsa yol haritasının önemi yoktur. Beşinci izlenim için değil, ilk izlenim için tasarlayın.
  • Benimseme, yumuşak değil yapısal bir konudur. Yapay zekânın nihai puanı vermesi ya da kullanıcının bunu onaylaması meselesi bir kullanıcı deneyimi ayrıntısı değildir. Bu, aracın bir otorite mi yoksa bir işbirlikçi mi olduğunu belirler ve bu ayrım, aracın nasıl karşılanıp kullanılacağına dair her şeyi şekillendirir.
  • Zaten oluşturduğunuz özellikleri çıkarın. Battı maliyet mantığı, ekiplerin yatırım yaptıkları şeylere, bunlar değerlerini yitirdikten çok sonra bile eklemeler yapmayı sürdürmesine neden olur. Bir özelliğin ne işe yaradığını açıklayamıyorsanız, yanıtınız budur. Onu çıkarmak başarısızlık değil, ürün disiplinidir.
  • Çekişmeli ve erken test edin. Size aracın kötü olduğunu söyleyecek insanlar bulun. Aklınıza gelebilecek en kötü makul girdiyi verin ve ne yaptığını görün. Yaygın durumları iyileştirmeden önce uç durumları oluşturun. Aracın güvenilirliği, tasarlanmadığı anları nasıl ele aldığına bağlıdır.
  • Araç, değerlendirme yapma hakkını kazanmalı. Yeterli soru sormadan puanlamaya geçmek verimlilik değil, varsayımdır. Açıklayıcı sorular, değerlendirmeyi savunulabilir kılan şeydir ve geri bildirimin kalıcı olmasını sağlayan da savunulabilirliktir.
  • Herkesin orada bulunma amacı konusunda dürüst olun. Bir grup içindeki farklı niyetler yönetilmesi gereken bir sorun değil, bilgidir. Bunları erkenden açıkça ortaya koymak, herkesi yalnızca bazılarının gerçekten paylaştığı bir hedef doğrultusunda çalışmaktan kurtarır.
  • En zor konuşmalar, en önemli olanlardır. Grup, İK becerilerini değerlendirmek için bir araç geliştirdi ve bunu yaparken, İK'nın sınırlılıkları hakkında hatırlayabildikleri en dürüst konuşmalardan birini gerçekleştirdi. Geriye dönük çerçeveler, sınav bilgisi ile durumsal muhakeme arasındaki boşluk hakkındaki bu konuşma, araç kadar ürünün de kendisiydi.

Dört görüşmelik bir taahhüt olarak başlayan oturumlar kışa, ardından yeni yıla uzandı. Prototip hâlâ gelişiyordu. Onu oluşturan insanların niyetleri, kolayca çözülemeyecek biçimlerde netleşmişti.

Satterfield hâlâ geliştirme yapıyordu. Turnmeyer öğrendiklerini alıp başka yerlerde uygulamıştı. Gillies, grubun aracın aslında ne yapması gerektiği konusunda daha disiplinli olmasını sağlamıştı. Ben de tüm bunların öyküsünü yazıyordum.

Turnmeyer sürecin başlarında, doğruluğunu koruyan bir şey söylemişti: Birisinden istendiği için değil, anlaması gerektiği için geliştiriyordu.

Yapay zekâ araçlarının gerçekte ne yaptığını, nerelerde hata yaptığını ve onları kullanışlı hâle getirmenin ne gerektirdiğini anlamak, herhangi bir konferans oturumunda ya da tedarikçi demosunda edinilebilecek bir şey değildi. Bu anlayış, grubun aldığı kararlardan, çıkardığı özelliklerden, aracın birini yanlış değerlendirdiği ve nedenini anlamaları gereken anlardan doğmuştu.

Katılımcı grubunun ürettiği en faydalı şeyler prototipte değildi. Bunlar, prototipin ardındaki akıl yürütmede saklıydı.

David Rice
David Rice is a long time journalist and editor who specializes in covering human resources and leadership topics. His career has seen him focus on a variety of industries for both print and digital publications in the United States and UK.
Follow the author: