Endüstriyel yazılım geliştirmenin mevcut gelişim aşamasında, çeşitli üretim rolleri gözlemlenebilir. Sayıları artıyor, sınıflandırma her geçen yıl daha karmaşık hale geliyor ve doğal olarak uzman seçme ve insan kaynaklarıyla çalışma süreçleri daha da karmaşıklaşıyor. Bilgi teknolojisi (BT), yüksek nitelikli işgücü kaynaklarının ve personel sıkıntısının olduğu bir alandır. Burada personel geliştirme süreci ve personel potansiyeli ile sistematik çalışma ihtiyacı, internet kaynaklarını kullanarak doğrudan seçimden çok daha etkilidir.
Makale, BT şirketlerindeki İK uzmanlarını ilgilendiren konuları tartışıyor: üretim rollerinin gelişiminde neden-sonuç ilişkileri, genel olarak İK çalışması için rollerin içeriğinin yanlış yorumlanmasının sonuçları ve ayrıca iş yükünü artırmak için olası seçenekler. Uzmanların işe alınmasının verimliliği.
Deneyimsiz olanlar için BT üretimi
BT'de kim kimdir çeşitli platformlarda tartışılan bir konudur. Tüm BT endüstrisi kadar uzun bir süredir, yani ilk yazılım geliştirme şirketlerinin geçen yüzyılın 90'lı yıllarının başında tüketici pazarında ortaya çıkmasından bu yana var olmuştur. Aynı süre boyunca bu konuda ortak bir görüş de oluşmadı, bu da zorluklar yaratıyor ve personel çalışmasının verimliliğini azaltıyor. Hadi anlamaya çalışalım.
Benim için BT sektöründeki üretim rolleri konusu, BT şirketine katıldığımdan beri alakalı ve ilginç hale geldi. Üretim sürecini anlamaya çalışırken çok zaman ve enerji harcadım. Bu maliyetler beklentilerimi ve diğer alanlardaki süreçlere uyum sağlama maliyetlerini aştı: eğitim, malzeme üretimi, küçük işletme. Genel olarak bir kişi sanal dünyadan çok maddi dünyaya daha fazla adapte olduğundan süreçlerin karmaşık ve olağandışı olduğuna dair bir anlayışa sahiptim. Ancak sezgisel bir direnç vardı: Sanki burada bir şeyler ters gidiyormuş gibi görünüyordu, bu şekilde olmamalıydı. Adaptasyon süreci muhtemelen bir yıl sürdü ve benim anlayışıma göre bu sadece kozmik bir süreç. Sonuç olarak BT üretimindeki kilit roller hakkında oldukça net bir anlayışa sahip oldum.
Şu anda bu konu üzerinde çalışmaya devam ediyorum, ancak farklı bir düzeyde. Bir BT şirketinin geliştirme merkezi başkanı olarak, işveren markasını işgücü piyasasında tanıtmak için sık sık öğrencilerle, üniversite öğretmenleriyle, başvuru sahipleriyle, okul çocuklarıyla ve bir BT ürününün oluşturulmasına katılmak isteyen diğer kişilerle iletişim kurmak zorunda kalıyorum yeni bir bölgenin (Yaroslavl). Muhatapların yazılım geliştirme sürecinin nasıl organize edildiğine dair farkındalıklarının düşük olması ve bunun sonucunda da konuşma konusunu anlayamamaları nedeniyle bu iletişim kolay olmuyor. 5-10 dakikalık bir diyalogdan sonra geri bildirim almayı bırakırsınız ve kendinizi konuşması tercüme gerektiren bir yabancı gibi hissetmeye başlarsınız. Kural olarak, muhataplar arasında diyalogda bir çizgi çizen ve 90'lardan kalma bir halk efsanesini dile getiren biri var: "Neyse, tüm BT uzmanları programcıdır." Efsanenin kökenleri şunlardır:
- Bilişim sektörü hızla gelişiyor, bu koşullarda tüm temel anlamlar ve ilkeler oluşma aşamasında;
- Belirsizlik koşullarında var olmak zordur, bu nedenle kişi mitler yaratarak bilinmeyeni anlamasını kendisinin kolaylaştırmaya çalışır;
- Kişi maddi dünyanın algısına sanal olandan daha alışkındır ve bu nedenle algısının ötesindeki kavramları tanımlaması onun için zordur.
Sorunun ele alınması gereken çeşitli yönleri olduğundan, bu efsaneyle mücadele etmeye çalışmak bazen yel değirmenlerine saldırmak gibi gelebilir. Bir İK uzmanının öncelikle bir BT şirketindeki üretim rollerinin ideal ve gerçek bir düzenlemesinde net bir resmine sahip olması, ikinci olarak şirketin iç kaynaklarının en etkili şekilde nasıl ve ne zaman kullanılabileceğini ve üçüncü olarak hangi gerçek yöntemlerin kullanılacağını anlaması gerekir. İşgücü piyasası katılımcılarının farkındalığının artmasına yardımcı olacak ve işveren markasının gelişimine katkı sağlayacaktır. Bu yönlere daha yakından bakalım.
Üretim rollerinin temeli olarak yazılım yaşam döngüsü
Genel olarak herhangi bir BT şirketindeki tüm üretim rollerinin kaynağının yazılım yaşam döngüsü olduğu bir sır değildir. Bu nedenle, bu konuya ilişkin tüm BT endüstrisi genelinde birleşik bir algı üzerinde anlaşmaya varmak gibi kavramsal bir görev belirlersek, özellikle yazılım yaşam döngüsüne, herkes tarafından kabul edilen ve açıkça anlaşılan anlamsal bir temel olarak güvenmemiz gerekir. Üretim rolleri konusunu uygulamaya yönelik belirli seçeneklerin tartışılması, yazılım yaşam döngüsüne yönelik yaratıcı tavrımızın düzleminde yatmaktadır.
Şimdi RUP metodolojisini örnek alarak yazılım yaşam döngüsünün içerdiği aşamalara bakalım. İçerik ve terminoloji açısından oldukça olgun bağlantılardır. Üretim süreci her zaman ve her yerde iş modelleme ve gereksinimlerin oluşturulmasıyla başlar ve (tabii ki şartlı olarak) kullanıcılara danışmak ve kullanıcıların "isteklerine" göre yazılımı değiştirmekle sona erer.
Geçen yüzyılın sonuna doğru tarihi bir gezi yaparsanız (bildiğiniz gibi bu “ada otomasyonu” dönemiydi), yazılım oluşturma sürecinin tamamının bir programcı-geliştirici tarafından yürütüldüğünü görebilirsiniz. İşte her BT uzmanının bir programcı olduğu efsanesinin kökleri.
Üretim süreçlerinin artan karmaşıklığı, entegre platformların ortaya çıkışı ve konu alanlarının karmaşık otomasyonuna geçişle birlikte, iş süreçlerinin yeniden yapılandırılmasıyla birlikte yaşam döngüsü aşamalarına bağlı uzmanlaşmış rollerin ortaya çıkması kaçınılmaz hale geliyor. Bir analist, testçi ve teknik destek uzmanı bu şekilde ortaya çıkar.
Analistin rolü örneğini kullanarak pozisyon çeşitliliği
Bir analist (aka bir analitik mühendis, diğer bir deyişle bir direktör, metodolog, iş analisti, sistem analisti vb.), bunların uygulanması için iş görevleri ve teknolojileriyle "arkadaşlık kurmaya" yardımcı olur. Geliştirici için problem tanımının açıklaması - soyut bir analistin ana işlevi bu şekilde karakterize edilebilir. Gereksinimlerin oluşturulması, analizi ve yazılım tasarımı süreçlerinde müşteri ile geliştirici arasında bir bağlantı görevi görür. Gerçek üretim koşullarında analist işlevlerinin listesi, üretimi organize etme yöntemine, uzmanın niteliklerine ve modellenen konu alanının özelliklerine göre belirlenir.
Bazı analistler müşteriye daha yakın konumdadır. Bunlar iş analistleridir (İş Analisti). Konu alanının iş süreçlerini derinlemesine anlıyorlar ve kendileri de otomatik süreçler konusunda uzmandırlar. Özellikle metodolojik olarak karmaşık konu alanlarının otomatikleştirilmesinde, bir işletmenin kadrosunda bu tür uzmanların bulunması çok önemlidir. Özellikle devlet bütçesi sürecini otomatize eden bizler için, analistler arasında konunun uzmanlarının bulunması şarttır. Bunlar, iyi bir mali ve ekonomik eğitime sahip ve mali otoritelerde, tercihen önde gelen uzmanlar rolünde çalışan deneyime sahip, yüksek nitelikli çalışanlardır. Bilişim alanında değil, özellikle konu alanında deneyim son derece önemlidir.
Analistlerin diğer kısmı ise geliştiricilere daha yakın. Bunlar sistem analistleridir (Sistem Analisti). Ana görevleri, müşteri gereksinimlerini karşılama olasılığı açısından belirlemek, sistematik hale getirmek ve analiz etmek, teknik spesifikasyonları hazırlamak ve sorun açıklamalarını tanımlamaktır. Yalnızca iş süreçlerini değil aynı zamanda bilgi teknolojilerini de anlıyorlar, müşteriye sağlanan yazılımın yeteneklerini iyi anlıyorlar, tasarım becerilerine sahipler ve buna göre müşterinin çıkarlarını geliştiriciye en iyi şekilde nasıl aktaracaklarını anlıyorlar. Bu çalışanların BİT alanında eğitim sahibi olmaları ve mühendislik ve teknik zihniyete sahip olmaları, tercihen BT alanında deneyime sahip olmaları gerekmektedir. Bu tür uzmanları seçerken, modern araçları kullanarak tasarım becerisine sahip olmak açık bir avantaj olacaktır.
Diğer bir analist türü ise teknik yazarlardır. Yazılım geliştirme süreçlerinin bir parçası olarak dokümantasyon, kullanıcı ve yönetici kılavuzları, teknolojik talimatlar, eğitim videoları vb. hazırlamakla meşgul olurlar. Ana görevleri, programın çalışmasıyla ilgili bilgileri kullanıcılara ve diğer ilgili taraflara aktarabilmek, teknik açıdan karmaşık şeyleri kısa ve net bir şekilde tanımlayabilmektir. Teknik yazarların çoğu, Rus diline mükemmel derecede hakimdir ve aynı zamanda teknik eğitime ve analitik bir zihne sahiptir. Bu tür uzmanlar için, standartlara uygun, anlaşılır, yetkin, ayrıntılı teknik metinler derleme becerisinin yanı sıra dokümantasyon araçlarına ilişkin bilgi ve ustalık da büyük önem taşımaktadır.
Böylece, aynı rolü (ve bu arada, personel tablosundaki pozisyonu) - analist olarak görüyoruz, ancak farklı spesifik uygulama enkarnasyonlarında. Her biri için uzman arayışının kendine has özellikleri vardır. Bu tür analistlerin genellikle tek bir kişiyle bağdaşmayan beceri ve bilgilere sahip olması gerektiğini bilmek önemlidir. Biri hümanist, büyük hacimli metin belgeleriyle analitik çalışmaya yatkın, gelişmiş konuşma ve iletişim becerilerine sahip, diğeri ise mühendislik düşüncesine ve BT alanına ilgi duyan bir "teknisyen".
Dışarıdan mı alıyoruz yoksa büyütüyor muyuz?
BT sektörünün büyük bir temsilcisi için, İnternet kaynaklarından doğrudan seçimin etkinliği, projeler büyüdükçe azalıyor. Bu, özellikle aşağıdaki nedenlerden dolayı gerçekleşir: Şirket içindeki karmaşık süreçlere hızlı adaptasyon imkansızdır, belirli araçlara hakim olma hızı, proje geliştirme hızından daha düşüktür. Bu nedenle, bir İK uzmanının yalnızca dışarıdan kimi arayacağını değil, aynı zamanda şirketin iç kaynaklarını nasıl kullanacağını, kimden ve nasıl bir uzman geliştireceğini de bilmesi önemlidir.
İş analistleri için konu ile ilgili gerçek süreçlerde çalışma deneyimi çok önemlidir, dolayısıyla onları “dışarıdan” işe almak, onları şirket içinde büyütmekten daha etkilidir. Aynı zamanda bir İK uzmanının bu insan kaynağına kaynak olabilecek kuruluşların listesini bilmesi ve seçim yaparken onlardan özgeçmiş aramaya odaklanması da önemlidir.
Sistem analisti, yazılım mimarı gibi açık pozisyonları doldurmak için ise tam tersine şirket içi eğitim süreci büyük önem taşıyor. Bu uzmanlar mevcut üretim ortamında ve belirli bir organizasyonun özelliklerinde oluşturulmalıdır. Sistem Analistleri, İş Analistlerinden, Teknik Yazarlardan ve Teknik Destek Mühendislerinden gelişir. Yazılım Mimarları - deneyim kazandıkça ve ufuklarını genişlettikçe tasarımcılardan (Sistem Tasarımcısı) ve yazılım geliştiricilerden (Yazılım Geliştirici) oluşur. Bu durum, bir İK uzmanının şirketin iç kaynaklarını etkin bir şekilde kullanmasını sağlar.
Üretim rollerinin kesişimi, entegrasyonu ve gelişimi
Üretim sürecinde uygulama açısından zor bir konu daha var - roller arasında net sınırlar oluşturmak. İlk bakışta her şey açık gibi görünebilir: Uygulama tamamlandı, yazılımın ticari işletmeye alınmasına ilişkin belgeler imzalandı ve her şey teknik desteğe devredildi. Doğru, ancak, sistemin zaten uygulanmış olmasına rağmen, müşterinin alışkanlık dışında, analistle yakın temas halinde olması ve onu "sihirli bir değnek" olarak görmesi, onunla aktif olarak iletişim kurmaya devam ettiği durumlar sıklıkla ortaya çıkar. ve resmi destek aşaması devam ediyor. Ancak müşterinin bakış açısına göre, sistemle çalışmayla ilgili soruları onunla birlikte görevlendiren analistten daha iyi ve daha hızlı kim cevaplayacaktır. Ve burada teknik destek mühendisi ve analistin rollerinin kısmen kopyalanmasıyla ilgili soru ortaya çıkıyor. Zamanla her şey daha iyi hale gelir, müşteri teknik destek servisiyle iletişime alışır, ancak yazılımı kullanmaya başladığınızda böyle bir "dahili geçiş" her zaman her iki tarafta da stres olmadan gerçekleştirilemez.
Analist ve teknik destek mühendisinin rollerinin kesişmesi, destek aşamasının bir parçası olarak geliştirme gereksinimleri akışının gerçekleşmesi durumunda da ortaya çıkar. Yazılım yaşam döngüsüne geri döndüğümüzde, gerçek üretim koşulları ile gereksinim analizinin ve problem formülasyonunun yalnızca bir analist tarafından gerçekleştirilebileceği şeklindeki resmi tutumlar arasında bir tutarsızlık görüyoruz. Bir İK uzmanının elbette yazılım yaşam döngüsü içindeki rollerin ideal resmini anlaması gerekir; bunların net sınırları vardır. Ancak aynı zamanda kesişmenin mümkün olduğunu da mutlaka aklınızda bulundurmalısınız. Başvuru sahibinin bilgi ve becerilerini değerlendirirken ilgili deneyimin varlığına dikkat etmelisiniz; yani, teknik destek mühendisleri ararken analist deneyimine sahip adaylar da dikkate alınabilir veya bunun tersi de geçerlidir.
Örtüşmeye ek olarak, sıklıkla üretim rollerinin birleştirilmesi de söz konusudur. Örneğin bir iş analisti ve teknik yazar tek bir kişi olarak var olabilir. Büyük endüstriyel gelişimde bir yazılım mimarının (Yazılım Mimarı) varlığı zorunludur, ancak çok küçük projeler bu rol olmadan da yapılabilir: burada mimarın işlevleri geliştiriciler (Yazılım Geliştirici) tarafından gerçekleştirilir.
Geliştirme yaklaşımlarının ve teknolojilerinin tarihsel dönemlerde değişmesi, kaçınılmaz olarak yazılım yaşam döngüsünün de değişmesine yol açmaktadır. Küresel olarak elbette ana aşamaları değişmeden kalıyor, ancak daha ayrıntılı hale geliyorlar. Örneğin, Web tabanlı çözümlere geçiş ve uzaktan yapılandırma yeteneklerinin artmasıyla birlikte yazılım yapılandırma uzmanının rolü ortaya çıktı. Tarihin erken bir aşamasında bunlar uygulayıcılardı, yani çalışma zamanlarının çoğunu müşterilerin işyerlerinde geçiren mühendislerdi. Yazılımın artan hacmi ve karmaşıklığı, Yazılım Mimarı rolünün ortaya çıkmasına neden olmuştur. Sürüm sürümlerini hızlandırmaya ve yazılım kalitesini iyileştirmeye yönelik gereksinimler, otomatik testlerin geliştirilmesine ve yeni bir rolün (QA mühendisi (Kalite Güvence Mühendisi) vb.) ortaya çıkmasına katkıda bulundu. Üretim sürecinin her aşamasında rollerin evrimi, yöntemlerin, teknolojilerin ve araçların geliştirilmesiyle önemli ölçüde ilişkilidir.
Şu ana kadar bir yazılım şirketi içindeki üretim rollerinin yazılım yaşam döngüsü bağlamında dağılımına ilişkin bazı ilginç noktalara baktık. Açıkçası bu, her şirkete özel, içeriden birinin görüşüdür. BT sektörü işgücü piyasasının katılımcıları ve işveren markasını tanıtmaktan sorumlu olanlar olarak hepimiz için dışarıdan bakış özellikle önemli olacaktır. Ve burada sadece anlam bulmada değil, bu bilgiyi hedef kitleye aktarmada da büyük bir sorun var.
BT pozisyonlarının "hayvanat bahçesi"nin nesi yanlış?
İK uzmanlarının, üretim yöneticilerinin kafasındaki karışıklık ve yaklaşımların çeşitliliği, çok çeşitliliğe, gerçek bir BT pozisyonları "hayvanat bahçesine" yol açmaktadır. Mülakatlar ve sadece profesyonel temaslar deneyimi, insanların çoğu zaman iş unvanlarından çıkması gereken anlam konusunda net bir anlayışa sahip olmadıklarını göstermektedir. Örneğin bizim organizasyonumuzda “analitik mühendisi” terimini içeren pozisyonlar, bunun görev belirleyici olduğunu varsayar. Ancak durumun her yerde böyle olmadığı ortaya çıktı: analitik mühendisin uygulayıcı olduğu geliştirme organizasyonları var. Tamamen farklı bir anlayış, katılıyor musunuz?
İlk olarak, BT pozisyonlarının “hayvanat bahçesi” şüphesiz işe alım etkinliğini azaltmaktadır. Her işveren, markasını geliştirirken ve tanıtırken, üretiminde var olan tüm anlamları kısa ve öz bir biçimde aktarmak ister. Ve eğer kendisi çoğu zaman kimin kim olduğunu açıkça söyleyemiyorsa, dış çevreye belirsizlik yayması doğaldır.
İkincisi, BT pozisyonlarının “hayvanat bahçesi”, BT personelinin eğitimi ve geliştirilmesinde çok büyük sorunlar yaratıyor. Sadece çalışma sahalarını "sağmak" değil, insan kaynaklarını oluşturmayı ve geliştirmeyi amaçlayan her ciddi BT şirketi, er ya da geç eğitim kurumlarıyla etkileşim kurma ihtiyacıyla karşılaşır. Yüksek vasıflı BT personeli için bu, üniversitelerin bir bölümüdür ve bu alanda en iyi olanlar, en azından TOP-100 sıralamasında olanlar.
Sürekli bir BT uzmanı yetiştirme süreci oluştururken üniversitelerle entegrasyon sorunu, üniversitelerin BT şirketi içinde kimin kim olduğunu anlama konusundaki eksikliğinin yaklaşık yarısı kadardır. Bu konuda çok yüzeysel bir anlayışa sahipler. Kural olarak, üniversitelerin adlarında "bilgisayar bilimi" kelimesi geçen çeşitli uzmanlık alanları vardır ve çoğu zaman bir kabul kampanyası yürüttüklerinde tüm uzmanlıkların temelde aynı şey olduğu tezine güvenirler. Görünüşe göre tüm BT uzmanlarının programcı olduğu şeklindeki popüler efsaneye güveniyoruz.
Üniversitelerle yakın işbirliğimizin deneyimi, “Uygulamalı Bilişim (endüstri bazında)” uzmanlığının bize metodoloji ve teknik destek departmanları için personel sağladığını, ancak geliştirme için personel sağlamadığını göstermektedir. “Temel Bilişim”, “Yazılım Mühendisliği” ise geliştiricilere mükemmel bir insan kaynağı hazırlıyor. Başvuranı başlangıçta kendisine uygun olmayan bir yola yönlendirmemek için BT üretimini çevreleyen "sisleri dağıtmak" gerekir.
Her şeyi ortak bir paydada buluşturmak mümkün mü?
Üretim rollerini birleştirmek ve şirket içinde ve dışında ortak bir anlayışa varmak mümkün mü?
Elbette mümkün ve gereklidir, çünkü tüm kalkınma işletmelerinin birikmiş kolektif deneyimi, üretim sürecini organize etmek için ortak, birleştirici kavramların varlığını göstermektedir. Bu, yazılım yaşam döngüsüne ilişkin hala benzersiz şekilde yorumlanmış bir kavramın bulunmasının bir sonucudur ve yeni ortaya çıkan üretim rolleri (Veri Bilimcisi, Kalite Güvence Mühendisi, Makine Öğrenimi Mühendisi, vb.), Yazılım yaşam döngüsü, teknolojilerin ve araçların iyileştirilmesinin yanı sıra iş görevlerinin geliştirilmesi ve genişletilmesiyle ortaya çıkar.
Aynı zamanda üretim rollerini birleştirmek zordur çünkü BT ekonominin en genç ve en hızlı büyüyen sektörlerinden biridir. Bu bir bakıma evrenin ortaya çıktığı kaostur. Burada net bir organizasyon yapısı imkansızdır ve uygun değildir çünkü BT entelektüel ama oldukça yaratıcı bir alandır. Bir BT uzmanı bir yandan gelişmiş algoritmik ve matematiksel düşünceye sahip bir "fizikçi" entelektüeldir, diğer yandan fikirlerin yaratıcısı, taşıyıcısı ve destekçisi olan bir "söz yazarıdır". Tıpkı sanatçı gibi onun da resim yapmak için net bir planı yok, görüntüyü parçalara ayıramıyor çünkü ikincisi var olmayacak. Kendisi soyut, soyut, ölçülmesi zor ama hızlı olan bilgi süreçlerinin hükümdarıdır.
BT üretiminde etkili personel çalışması oluşturmanın yolları
Peki, bir İK uzmanının BT üretim rollerinin çeşitliliği bağlamında etkili İK çalışmaları oluşturmak için bilmesi gerekenler nelerdir?
İlk olarak, bir BT şirketindeki herhangi bir İK uzmanının, özellikle kendi işletmesi için tipik olan durum hakkında bir fikre sahip olması gerekir: kim ne yapar, kime ne denir ve en önemlisi, bu rollerin koşullarında bu rollerin anlamı nedir? özel bir yapım.
İkinci olarak, İK profesyonelinin üretim rolleri konusunda esnek bir anlayışa sahip olması gerekir. Yani başlangıçta onlar hakkında ideal bir anlayış oluşturur ve bu onun her şeyi kendi başına çözmesine olanak tanır. O halde üretimin gerçek bir resmi olmalıdır: rollerin nerede ve hangi yollarla kesiştiği ve birleştiği, üretim yöneticileri arasında bu rollere ilişkin nasıl bir algının olduğu. Bir personel uzmanı için zorluk, gerçek ve ideal durumları zihninde birleştirmektir; ideal anlayışlarına uyacak şekilde süreçleri zorla yeniden inşa etmeye çalışmak değil, üretimin kaynak ihtiyacını karşılamasına yardımcı olmaktır.
Üçüncüsü, belirli uzmanların olası gelişim yörüngeleri hakkında kesinlikle bir fikre sahip olmalısınız: hangi durumlarda dış seçim etkili olabilir ve ekibinizde bir çalışanı büyütmek, ona gelişim fırsatları sağlamak, hangi niteliklere sahip olmak ne zaman daha iyidir? Adayların sayısı, onların belirli bir yönde gelişmelerine olanak tanıyacak ve bu nitelikler bir kişide uyumlu olamayacak ve bu, başlangıçta bir gelişim yörüngesinin seçilmesi için önemlidir.
Dördüncü olarak, BT'nin yüksek vasıflı personel alanı olduğu ve daha etkili personel çalışması için üniversite eğitim ortamıyla erken entegrasyonun kaçınılmaz olduğu tezine dönelim. Bu durumda, her İK uzmanı yalnızca doğrudan arama, anketlerle çalışma ve görüşme becerilerini geliştirmekle kalmamalı, aynı zamanda üniversitedeki uzmanların eğitimi ortamında da gezindiğinden emin olmalıdır: hangi üniversiteler şirket için personel hazırlıyor, belirli üniversitelerde hangi uzmanlıklar var? Bunun arkasında kimin olduğu, üniversitelerde uzmanları kimin yönettiği ve yetiştirdiği önemli.
Dolayısıyla, tüm BT uzmanlarının programcı olduğu efsanesini kasıtlı olarak çürütürsek, bu yönde bir dizi adım atmak ve geleceğin mesleği algısının temellerinin atıldığı üniversitelerimize özel önem vermek gerekiyor. Başka bir deyişle, eğitim ortamıyla sürekli etkileşime ihtiyacımız var; örneğin ortak çalışma merkezlerinde modern işbirliği formatını, "kaynama noktalarını" ve yoğun eğitim etkinliklerine katılımı kullanmaya ihtiyacımız var. Bu, BT kuruluşu hakkındaki yanlış anlamaların ortadan kaldırılmasına, personel çalışmasının verimliliğinin artırılmasına ve sektörümüzdeki çeşitli uzmanların eğitiminde ortak faaliyetler için koşullar yaratılmasına yardımcı olacaktır.
Bu makalenin hazırlanmasında ve konuyla ilgili olarak desteklenmesinde görev alan meslektaşlarıma şükranlarımı sunuyorum: Valentina Vershinina ve Yuri Krupin.
Kaynak: habr.com