Bu yazıda her bilim dalı gibi dijitalleşen Arkeoloji alanında nasıl dijital-arkeoloji veya Arkeo-enformatik projeleri yönetebileceğimizi tartışacağız. Mesleki tecrübeler ve Bilgi İşlem (IT) proje yönetim metotlarını harmanlayarak kısa bir doküman oluşturmayı amaçladık.

Arkeo-enformatik projeler:​
– Disiplinler arası​
– Ancak bir ekip ile yürütülebilen​
– Yaşayan veri setlerine sahip projelerdir.​

Bu açıdan projeleri “Proje Öncesi”, “Proje Süreci” ve “Proje Sonrası” diye üç temel aşamada düşünürüz. Ancak bu genel yaklaşım bir Arkeo-enformatik projeyi planlamada yeterli değildir. Öncelikle bu tip projelerin yaşam döngülerine yakından bakalım.

Geleneksel ve yaygın bir proje yaşam döngüsü (Waterfall):

Proje Döngüsü, projenin fikir aşamasından tamamlanmasına kadar geçen sürede kaliteyi, kaynakları, verimliliği ve etkinliği en iyi şekilde uygulamayı amaçlayan süreçlerin tamamıdır. Proje döngüsü yönetimi de bu süreçlerde tüm kaynakların en etkin şekilde kullanılması için izlenen yönetim sistemidir.​

Waterfall modeli, bizim projemiz gibi genel ilerleyişi planlı ve doğrusal projelerde iyi bir yöntemdir. Ancak projenin merkezinde bulunan Tasarım, Yapım ve Test aşamaları için “bir aşama tamamlanmadan diğer aşamaya geçemeyiz” tarzı bir yaklaşımda bulunamayız. Bu basamaklar, tıpkı yazılım geliştirme projeleri gibi kendi içinde sürekli güncellenen ve tekrar eden bir yaşa döngüsüne (Agile) sahiptir.

Yazılım geliştime projelerinde görülen bir proje yaşam döngüsü (Agile):

Yazılım projelerinin doğası gereği, projedeki temel aşamalar sürekli olarak güncellenecek bir dinamiğe oturtulmalıdır. İşte bu aşamada geleneksel Arkeoloji projelerinin adım adım ilerleyen yapısına alışkın araştırmacılar zorluk yaşayabilmektedirler.

Böyle bir karma yaşam döngüsü ilk bakışta projeyi “yap-boz tahtasına” çeviriyor gibi gelebilir. Ancak tasarım ve gereksinimlerin analizi süreçleri ne kadar başarılı olursa projenin kurgulanması ve bu esaslara göre yürütülmesi bir o kadar kolay olacaktır. Bu bağlamda mevcut ve gelecekte ortaya çıkabilecek sorunların dokümante edilmesi büyük fayda sağlayacaktır.

“Karmaşık bir problemi tahtaya yazmak, sorunun yarısının çözülmesi demektir.”

Anonim

Proje Öncesi (Hazırlık ve Başvuru)

Proje öneri metnini yazarken kendinize aşağıdaki soruları sorabilirsiniz. İster TÜBİTAK, ister uluslararası bir proje başvuru portalı olsun, şu ya da bu şekilde aşağıdaki konularda açıklamalar arayacaklardır:

• Neden bu projeyi yapıyorum? Bu proje hangi bilimsel sorulara/sorunlara cevap arayacak?​
• Projemin özgün değeri nedir? ​
• Hangi yöntemleri kullanacağım? Hangi yöntemler ne işime yarayacak?​
• Elimde hangi imkanlar var ve nelere ihtiyacım var?​
• Projeyi etkileyecek ne gibi sorunlar ortaya çıkabilir? (Risk Yönetimi için) ​
• Proje çıktıları neler olacak?​
• Projeden kalan veri setleri ne olacak? (Veri Yönetim Planı için)​

Veri Yönetim Planı (Data Management Plan – DMP)

 

Veri Yönetim Planı, proje sürecinde ve sonrasında elimizdeki neredeyse bütün veriye ne olacağını açıkladığımız bir formdur. Aynı zamanda bu form, bütçe ve zamandan sonra elimizdeki en kıymetli değeri yani veriyi nasıl yöneteceğimizi sorgular. Yukarıdaki görselde görüldüğü gibi; veri toplama ve dokümantasyon, etik, yasal ve güvenlik konuları, veri depolama/koruma ile veri paylaşımı ve yeniden kullanım konularında açıklamalar yazmamız gerekir. Bu işlem daha proje başlamadan yapılır ve Arkeo-enformatik projeler için oldukça öne çıkan bir konudur.

Proje Süreci

Tebrikler! Umarım sorunsuz bir şekilde projeniz kabul edilmiştir. Esas serüvene başlamadan önce özlü bir söze değinelim:

“Ölçemediğiniz şeyi yönetemezsiniz…”​

Peter F. Drucker

 Proje kapsamında, proje yöneticisi, araştırmacılar, bursiyerler ve hizmet alımı yapılacak dış kaynaklar (outsource) olacaktır. Tüm bu kalabalığı yönetmek için öncelikle proje başvuru raporunda hazırladığınız zaman tablosunu kişilere bölebileceğiniz bir uygulamaya ihtiyacınız olacaktır. ERP çözümleri olarak isimlendirilen ücretli ve ücretsiz bir çok uygulama bulunmaktadır.

Şimdi bu tip uygulamalarda yapılacakları nasıl organize edeceğimize ilişkin iki yaygın yönteme bakalım:

İş-Zaman Çizelgesi (GANTT)

Elbette proje öncesinde belirlenen (muhtemelen GANTT şeması tarzında gösterilen) iş zaman çizelgeleri, proje sürecinde bir miktar değişecektir. İşte bu yüzden dinamik bir uygulamada, yapılacak iş paketlerini ve alt kırılımları görebileceğiniz, gerçek kişilere atayabileceğiniz bir sisteme ihtiyacınız olacaktır. ClickUp ve JIRA gibi çözümler oldukça yaygın ve kullanışlı araçlardır.

Görev Listesi (Kanban)

GANTT şemasında bütün işler genel iş paketleri ve alt kırılımları olarak görülecektir. Daha alt görevler için oldukça basit Kanban yöntemini kullanabilirsiniz. Bu yöntemde işleri “Yapılacak”, “Yapılıyor”, “Test Ediliyor/Revizyonda” ve “Tamamlandı” olarak dört ana başlığa ayırarak çalışabilirsiniz. Ayrıca işleri kendi içinde “Normal”, “Acil” ve “Çok Acil” olarak önem sırasına koyabilirsiniz.

Ancak unutmayınız; neredeyse tüm işleri “Çok Acil” veya “Çok Önemli” olan birinin iş akışında aslında önem sırası diye bir şey kalmamıştır.

Raporlamalar

Neredeyse bütün projeler, dönemlik (aylık, 6 aylık veya yıllık) ilerleyiş raporuna ihtiyaç duymaktadır. Raporlama en güzel yöntem, düzenli olarak yapılan işlerde her proje çalışanının belli merkezi bir yere notlar tutması olacaktır. Böylece bu notlar birleşerek kısa ama detaylı raporlara dönüştürülebilir.

Risk ve Süreç Yönetimi

Arkeo-enformatik projelerde sıkça karşılaşılabilen bir takım risklerden ve çözüm önerilerinden bahsedelim:

Yukarıda sayılan iki hususa açıklık getirelim. Yedekleme stratejisi olarak projenizdeki veri setlerinin bir kopyasının zaten kullanılan veri seti olması ve düzenli olarak yedeklenen bir aktif yedeğinin olması önerilir. Ancak üçüncü bir yedeğin de kazı evi veya iş alanının dışında bir yerde, hatta mümkünse bulut ortamında korunması tavsiye edilir.

Bir projeyi eğer 1 yıl içinde bitirmeyi planlıyorsanız muhtemelen dış etmenlerle beraber bu süre 1 buçuk yıla kadar uzayabilecektir. Bu 1,5 katı formülü tıpkı Murphy yasası gibi proje yönetimindeki talihsizliklere göre yapılan esprili ama gerçeklik payı olan bir önlemdir.

Proje Sonrası

Bir projenin daha sonuna geldiniz. Nitekim Arkeo-enformatik projeler için her şey burada bitmiyor. Veri Yönetim Planı’nda belirttiğimiz açıklamalara uygun olarak veri setlerimizi uzun vadeli saklamanın bir yolunu arayacağız. Bu veri setlerini saklarken FAIR Prensipleri denen Findable (Bulunabilir), Accesible (Erişilebilir), Interoperable (Birlikte çalışılabilir) ve Reusable (Yeniden kullanılabilir) standartları takip etmemiz gerekecektir. Aksi takdirde bizim bile anlayamadığımız veri yığınları ortaya çıkacaktır.

Nerelerde Depolayabiliriz?

• Özel veri merkezleri (düzenli ücret ödenmesi gerekir)​
• Akademik Kurumlara ait sunucular/bilgi merkezleri​
• TÜBİTAK ULAKBİM​
• Diğer akademik açık veri portalları​
• NAS veya SAN gibi yerel veri depolama cihazları (6 yılda bir bakım/değişim gerekir)​

Ancak kişisel bilgisayarda depolayamayız.

Ne kadar alana ihtiyacımız olabilir?

Normal şartlar altında yaşayan veri setleri her yıl ortalama %20 gibi bir oranda büyümektedir. Ancak Arkeolojik çalışmalarda toplanan görüntü verilerinde aşırı yüksek çözünürlüklü fotoğraflama ve üç boyutlu veri üretimi trendi sebebiyle her yıl veri boyutunun iki katına çıktığını savunabiliriz.

Esasen bu kural, donanım teknolojilerinin düzenli aralıklarla iki katına çıkabileceğini savunan Moore Yasası ile benzerlik göstermektedir. Kısa bir örnekle, 2018 yılında 25 MB alan kaplayan bir klasörünüz, yeni teknolojik araçlarlarla her yıl iki katına çıkarak (25 -> 50 -> 100 -> 200….) 5 yıl sonra 800 MB boyuta ulaşabilir.

Elbette böyle bir tahmin her veri seti için geçerli değildir. Ancak bu tahmin için aşağıdaki formülü kullanabilirsiniz:

Kalan veri setleri güncellenecek ise kaç yıl boyunca bu şekilde saklanacağı hesaplanmalıdır.

Proje sonunda veri (Vo), her yıl (n) yaklaşık iki katı büyüklüğe erişebilmektedir:

Kalan veri setleri güncellenmeyecek ise mevcut veri büyüklüğünün 1,5 katı bir alan yeterli olacaktır.