Üç Başlı WooCommerce Projesi: Ajansınız, Serbest Çalışan ve Müşterinizin Geliştiricisi

Online alışverişin önümüzdeki on yılda perakende satış mağazalarını aşamalı olarak kaldıracağına ilişkin tahminlerle birlikte, insanlar giderek daha fazla çevrimiçi mağazanın kervanına atlıyorlar. Bir WooCommerce projesi geliştirmek, bazen ihtiyacınız olduğunda ajansınızda bulunmayabilecek zaman ve uzmanlık gerektirir ve sizi serbest geliştiriciler gibi başka yerlerde yardım aramaya zorlar.

Uzman çağırmanız gereken aşamaya geldiyseniz nelere dikkat etmelisiniz? Yeni "eklemeleri" mümkün olduğunca sorunsuz hale nasıl getirirsiniz? Ama ayrıca: ya müşterinizde halihazırda mevcut bazı şirket içi geliştiriciler varsa?

İşler çok kapsamlı bir şekilde planlanıp yürütülmezse, bu kadar çok insanın dahil olması gerçek bir karışıklık olabilir.

Gelin böyle zorlu bir çalışma senaryosunu nasıl yönetebileceğinizi ve bunu kendi avantajınıza nasıl dönüştürebileceğinizi birlikte inceleyelim!

İyi bir iletişiminiz olmalı, yoksa iyi bir şey başarılamaz

Herhangi bir çalışma ilişkisinin temel taşı ve başarılı proje yürütmenin anahtarı her zaman kapsamlı iletişimdir. Hem gereksinimlerinin tam olarak ne olduğuna dair net bir resim geliştirmek için önemli olan müşterilerinizle, hem de onları doğrudan projeye dahil ediyor olsanız da, müşterinizden gelmiş olsalar da dahil olan tüm geliştiricilerle.

Bunu başarmak için birçok ajans ve geliştirici, birçok özelliği nedeniyle grup tartışmaları için Slack'i kullanır. İlgili tüm taraflar arasında iletişimin ileri ve geri gittiği ortak bir zemine sahip olmanın önemi, WooExpert ve SAU/CAL'den Codeable uzmanı Mitchell Callahan tarafından daha da detaylandırılmıştır:

Bu oldukça fazla olan bir şeydir: müşteriler sizi WooCommerce uzmanlığı istedikleri için işe alırlar, ancak daha sonra şirket içinde bir geliştirici veya genellikle birlikte çalıştıkları bir serbest çalışan gibi olabilirler. Bu nedenle, bir proje üzerinde çalışan tüm geliştiricilerin ve müşterinin şirketinin iletişim noktasının hepsinin aynı Slack kanalında olduğundan emin olmanız gerekir. Bu sayede projede yer alan tüm denekler birbirleriyle daha etkin bir şekilde iletişim kurabilir.

İletişim araçları kurulduktan sonra sıra bir sonrakine odaklanmaya gelir: kod deposu.

Kod için sağlam bir sürece sahip olmalısınız

Farklı geliştiriciler aynı proje üzerinde çalışırken, kimin neyi nerede yaptığını bulmak için yüzlerce kod, dosya ve dizini araştırmak istemezsiniz. Bu nedenle, koddaki herhangi bir değişikliği takip edebilmeniz için Github veya Bitbucket gibi araçlar doğru şekilde kurulmalıdır.

Mitchell'i açıklıyor:

İşletmeniz dışındaki diğer geliştiricilerle çalışacağınız zaman, değişiklikleri izleyebilmeniz için bir Git deposuna sahip olmanız gerekir. Siteye herhangi bir şey eklenirse, onu kimin eklediğini ve ne zaman eklediğini öğrenebileceksiniz, böylece sorun çıkarsa yalıtabilirsiniz.
Buradaki en önemli şey, sağlam bir sürecin yerinde olmasıdır: bu nedenle, canlı sunucuya herhangi bir şey gönderilmeden önce, her zaman bir çekme isteği yapmamız gerekir ve ardından birisi bir kod incelemesi yapar.

Araçlar, daha verimli bir çalışma ortamı için sadece bir araçtır. Eksik parça, gördüğünüz gibi, tüm hareketli parçaların mümkün olduğunca sürtünmesiz çalışmasını sağlayacak net bir sürece sahip. Ve bir sonraki noktamız bu.

Herkes neyin sorumlu olduğunu bilmeli

Herhangi bir geliştirme sürecinin sonucu, her bir konunun uyması gereken talimatların ve rollerin açıklığına dayanır. Spesifik olarak, verimli bir sürece sahip olmak istiyorsanız, Mitchell'in altını çizdiği gibi, komut akışı için iyi tanımlanmış bir yapıya sahip olmanız gerekir:

Diğer geliştiricilerle çalışıyorsanız, tavsiyem bir hiyerarşiye sahip olmanızdır. Aslında, her zaman CTO'muzun çekme taleplerinden sorumlu olduğunu savunuyoruz. Bu, her bir kod parçasının yapılandırılmış bir şekilde gözden geçirildiğinden, birleştirildiğinden ve planlandığından emin olabilmemiz için birleştirme yeteneğine sahip tek kişi olmasını sağlayacaktır. Büyük kuruluşlarda bu bir darboğaz olabilir ve bununla mücadele eden birden fazla kişi olabilir.

Bu, proje üzerinde herhangi bir yetki çatışmasının olmamasını ve tabii ki sürecin sorunsuz bir şekilde yürütülmesini sağlar.

Proje yönetimi araçları: birini seçin ve herkes arasında paylaşın

Tuzakları azaltmak için her şeyi yapıyorsanız, proje yönetimi araçlarının etrafındaki havayı temizlemek için zaman ayırmayı kaçıramazsınız. Bunlardan en önemlisi, aynı anda birden fazla PM aracının çalıştırılmasından uzak durmaktır. Bu, dakikalar içinde özensizleşecek, dolayısıyla projeye hiçbir değer katmadan iş yükünüzü artıracak bir şey.

Projelerinizden birinde serbest geliştiriciler ve müşterinizin kurum içi geliştiricileri ile çalışırken amacınız, tüm tarafların en rahat olduğunuz PM aracına dahil olmasını sağlamaktır. Biliyorum, başarılması oldukça zor bir şey çünkü herkesin kendi tercih ettiği araçları var. Ancak Mitchell ve SAUCAL'daki adamlar, müşterileri ve geliştiricileri şu şekilde kazanabilirler:

Pek çok insan Jira'yı kullanır, örneğin bizim onun yerine Breeze adını verdiğimiz yerde. Bazı insanlar, ilk gördüklerinde bize 'Ah, bu çok güçlü görünmüyor' diyorlar. İşte burada eğitim bileşeni devreye giriyor. Onlara bunu yıllardır aynı amaçla (WooCommerce siteleri oluşturmak) yaptığımızı açıklıyoruz. Ve gerçekten kalın, ince ve sürecin bir parçası olmak isteyenler için - genellikle geliştiricilerdir - onları sistemimizi nasıl kullanacakları konusunda eğitmek için zaman harcayacağız, bu şekilde hepimiz uyumlu, paylaşımlı bir şekilde çalışıyoruz. yol.

Farklı taraflar arasında farklı proje yönetimi araçlarına sahip olmak, örneğin siz, müşterinin şirket içi ekibi ve bazı serbest geliştiriciler, proje zaman dilimlerini gereksiz yere uzatabilir. Bu nedenle, yinelenen araçlardan kurtulmak ve tüm çabaları ortak bir araçta toplamak, proje (ve zihinsel akıl sağlığınız) için büyük ölçüde faydalıdır.

toparlamak

Slack kanalları, paylaşılan depolar ve dahil olan tüm tarafların kullanmayı kabul ettiği bir Proje Yönetim aracı, akıcı bir proje tamamlamanın temel unsurlarından bazılarıdır. Ancak, hayattaki çoğu şeyde olduğu gibi, her şey tüm taraflar arasında etkili iletişime bağlıdır. Bu boşluğu doldurmak çok önemlidir çünkü Mitchell'in dediği gibi:

En zayıf iletişimciye sahip olan, en zayıf halka olacaktır.

Matteo Duo, birinci sınıf WordPress geliştiricilerini kaliteli çalışmaya ihtiyaç duyan işletmelerle eşleştiren 1 numaralı WordPress odaklı dış kaynak platformu Codeable.io'da İçerik Strateji Uzmanıdır . Müşteriler ve geliştiricilerle, ilişkilerinin farklı inceliklerini belgelemek ve WordPress'ten etkili bir ticari varlık olarak nasıl yararlanılacağına dair rehberlik sağlamak için yıllardır aktif olarak çalışıyor.