Uzaktan işbirliği sorununun üstesinden nasıl gelinir? Tower'ın 72 aylık uzaktan çalışma uygulamasına bakın
9 Aralık'ta TGO Kunpeng Kulübü Wuhan Şubesi ilk grup etkinliğini başarıyla düzenledi. Bu grup etkinliğinde, Tower kurucu ortağı ve TGO Kunpeng Club Wuhan şubesi üyesi Xu Zheng, "Tower Team 72 Months Remote Collaboration Practice" in harika bir paylaşımını getirdi.
Paylaşım süreci boyunca Xu Zheng, Tower'ın büyüme deneyimini ve uzaktan çalışmadaki 72 aylık başarılı pratik deneyimini paylaştı. Aşağıdakiler, Xu Zheng tarafından sitede, Enjoy tarafından paylaşılan içeriktir:
Bugün, sizinle paylaşmak üzere sunduğum tema, Tower ekibinin 72 aylık uzaktan çalışmasının başarılı uygulamasıdır.
Yeni bir oyuncu olduğum için, Tower ekibinin şu ana kadarki büyüme geçmişini tanıtmak istiyorum, bunun uzaktan işbirliğimizle harika bir ilişkisi var.
Aslında, Caicheng Design oldukça erken kuruldu. Caicheng Design 2008 yılında kuruldu. Şirketin CEO'su Shen Xueliang ve hepimiz ona "Eski Shen" diyoruz.
İlk başladığımızda Esas olarak yaptığımız şey, kullanıcı deneyimi tasarımını dış kaynak olarak kullanmaktır. O zamanlar, birkaç yerli şirket "kullanıcı deneyimi", "UCD" ve "UX" gibi kavramlara sahipti, bu yüzden o sırada listelenen şirketin kalçalarını, AsiaInfo Lianchuang'ı tutarak ve bazı operatör iş sistemlerinin kullanıcısı olmalarına yardımcı olarak başladık. Tasarım optimizasyonunu deneyimleyin.
Sistemleri uzun süredir kullanıldığı için sistemin kullanımı çok zor hale geldi. Aslında, o zamanlar zaten Web çağındaydı, ancak yazılımlarının çoğu hala CS mimarisini kullanıyor.
O zamanlar, esas olarak Sichuan, Liaoning ve Pekin'deki 10086 çevrimiçi iş salonundan, müşteri hizmetleri sisteminden, ağ yönetim sisteminden, AsiaInfo Overseas faturalandırma sisteminden vb. Sorumluyduk. Tasarım süreci boyunca, ekibimiz ürün tasarımında çok fazla deneyim biriktirdi.
2011 yılında, mobil İnternet'in yükselişiyle birlikte ekibimiz, Chengdu'daki yerel Gudong sporları, kullanımı kolay arabalar vb. Dahil olmak üzere bazı mobil uygulamalar için bazı tasarım dış kaynak kullanımı yapmaya başladı.
Birkaç yıl kullanıcı deneyimi tasarımı dış kaynak kullanımı yaptıktan sonra, yavaş yavaş kendimize ait bir ürün yaratmak istemeye başladık. Böylece, 2011'den itibaren ekibimiz, biri TeamCola ve diğeri DesignBoard adında iki küçük ürün yapmaya başladı.
Aslında bu iki ürün ekibimizin ihtiyaçlarına dayanmaktadır.
TeamCola, çalışma saatlerini kaydetmek için kullanılan bir üründür; DesignBoard, kullanıcıların PSD tasarımları hakkında iletişim kurmasını ve yorum yapmasını sağlayan bir üründür.
İki ürünün piyasaya sürülmesinden sonra, İnternette ilk ağızdan ağza iletişim dalgasını biriktirdik ve ayrıca, herkesin Chengdu'nun bir renk programı tasarımına sahip olduğunu ve bazı yararlı araçlar yarattığını bildiren bir dizi fan kullanıcısı kazandık.
2012 civarında, daha genel bir araç yapıp yapamayacağımızı düşünmeye başladık.
Böylece içten tartışmaya başladık. O zamanlar Çin'de basit ve hafif ekip işbirliği araçları olmadığından ve proje ve görev işbirliği için kendi ekip içeriğimiz Basecamp aracıydı, bu nedenle Basecamp aracını Çin'e tanıtmamız ve proje işbirliği ürününün yerel bir sürümünü yapmamız gerekip gerekmediğini merak ettik. Ne?
Sadece yapın ve 2012'nin ikinci yarısında Tower'ın ilk versiyonunu piyasaya sürdük.
Tower piyasaya sürüldükten sonra performansı beklentilerimizi aştı, çünkü çevrimiçi olduğu ilk günkü kayıtlı kullanıcı sayısı TeamCola ve DesignBoard'ın toplam kullanıcı sayısını çok aştı. Ardından bir ay içinde Sequoia'nın Seri A yatırımını aldık.
Daha sonra bazı ortaklarımız tüm enerjilerini Tower inşa etmek için kullanıp kullanmamayı tartıştı. Sonunda, bunu düşündükten sonra, tüm dış kaynak kullanımını durdurmaya ve ToB SaaS alanına geçmeye karar verdik.
Şimdiye kadar, Tower'ın 800.000 kayıtlı ekibi ve 10 milyon kayıtlı kullanıcısı var ve uzun süredir Alexa'da ülkede ilk sırada yer alıyor.
Bu sonuçlar tüm ekibimiz tarafından uzaktan çalışma modunda yapılır. Ardından, son yıllarda uzaktan çalışma ile ilgili bazı düşüncelerimi sizinle paylaşacağım.
Neden uzaktan çalışmalı
2013 yılında uzaktan çalışmaya karar verdik.
O zaman asıl niyetimiz şuydu: Tower ürününü daha iyi oluşturmayı umuyorum . Kulağa garip gelebilir.İyi bir ürün geliştirmek istiyorsanız, neden birlikte fazla mesai yapmayasınız ve uzaktan işbirliği yapalım?
İlk neden, cesur bir vizyona sahip olmamızdır - Tower, uzaktaki bir ekibin günlük işbirliğini tam olarak destekleyebiliyorsa, bu, her gün bir arada kalan ekipler için fazlasıyla yeterlidir.
Aynı zamanda, 37signals'ın Basecamp'ına dayandığımız ve 37signals'ın kendisi de uzaktan çalışan bir ekip olduğu için, bu şekilde daha iyi ürünler üretmenin mümkün olduğunu düşünüyoruz.
İkinci sebep, İşe gidip gelirken zaman kaybetmek istemiyoruz .
2008'den 2013'e kadar ekibimiz neredeyse 4-5 yıldır birlikteydi. Bu süreçte ekibimiz bir çok ofis yerini değiştirdi, bu da ekip arkadaşlarımızın yolda çok fazla zaman geçirmemesi ümididir. Ancak nerede işe gidersek gidelim, arkadaşlarımızın yaklaşık yarısı günde ortalama 2 saatini işe gidip gelmek için harcıyor.
Hesaplayabiliriz, ortalama 1,5 saat alırsak, her üye haftada 7,5 saat işe gidecek Tatil ve tatilleri düştükten sonra her yıl 300-400 saat yolumuz olacak.
Bu zaman kurtarılabilirse, herkesin bu zamanı çok şey öğrenmek veya daha anlamlı şeyler yapmak için kullanabileceğini düşünüyoruz. Üstelik günümüz şehir içi trafik koşulları gittikçe kötüleşiyor ... İster toplu taşıma kullanıyor olun, ister araba kullanıyor olun, büyük şehirlerde sabah ve akşam zirveleri insanı depresyonda hissettiriyor.
Üçüncü neden, tüm çekirdek ekibin yaklaşık 5 yıldır birlikte çalışıyor olmasıdır. Herkes ofise geldiğinde, elindeki konuyla da ilgilenir. .
Başkalarını rahatsız etmekten kaçınmak için iletişim kurma ihtiyacı varsa, kasıtlı olarak şirketin alt katındaki tartışma yerini veya nispeten uzak bir toplantı odasını kuracağız. Bu aynı zamanda herkesin bir Kule inşa etmek için bir araya gelmesinin gerekli olup olmadığını düşünmemize olanak tanır.
2013 Bahar Şenliği'nin ardından ekibi dağıttık ve uzaktan çalışmaya başladık.
Uzaktan çalışmanın faydaları
Uzaktan çalışmanın birçok fayda sağladığını itiraf etmeliyim.
İlk fayda ve bence en büyük fayda- Kişisel yaşam kalitesi büyük ölçüde artacaktır .
Uzaktan çalışmanın ilk birkaç yılında, temelde her gün bir makine gibi davrandım. Her sabah saat 7: 00'de kalkın, sonra yüzmek için evin karşısındaki spor salonuna yürüyün; 8: 30'dan 12: 00'ye kadar işe başlayın, ardından öğle yemeği yiyin ve kestirin; 14: 00-19: 00'da çalışmaya devam edin, sonra tekrar eve gidin Yakındaki bir topluluk kütüphanesinde bir kitap okuyun; 20: 30'da eve gidin ve sonunda yıkayın ve uyuyun.
Her sabah, spor salonundan eve giderken, sabahın yoğun saatlerinde aceleyle insanlara bakıyorum, artık otobüs veya metroyu sıkmak zorunda olmadığım zaman çok mutlu olduğumu düşünüyorum.
İkinci avantaj şudur: Ekibi daha odaklı tutabilir .
Genelde ofisteyken, etrafınızdaki konuşma ve buluşma seslerinden sık sık rahatsız olabilirsiniz. Aynı zamanda rapora göre uzun süre aynı ortamda çalışırken, kendi iş veriminizi etkileyecek kendi estetik yorgunluğunuz nedeniyle dikkatinizi kaybedeceksiniz.
Bu nedenle, uzaktan çalışmayı savunduğumuzda, evden çalışmayı veya seyahat etmeyi asla savunmadık, ancak en verimli yeri koruyabildiğiniz sürece hangi ortamda olursanız olun.
2014 yılında, bir zamanlar küçük ve iyi bilinen bir açık kaynak projesi olan Github'da 4.5k yıldıza sahip Simditor adında bir metin editörü açtık. Bu küçük şey, ekibimizdeki bir arayüz mühendisi.İki aylığına Lijiang'a gitti ve onu tek başına geliştirdi.
Ek olarak, uzaklaştıktan sonra 4 kişiden fazlası için toplantı süresinin önemli ölçüde kısalacağını ve sıklığın azalacağını keşfettik.
Geçmişte, bir toplantıya bilinçsizce katılmanız ve ardından toplantıyı daha uzun süre yapmanız kolaydı; uzaktan çalışmaya başladığınızda, insanlar bir arada olmadığından, konuşma maliyeti çok yüksek olur, bu nedenle her konferans görüşmesinden önce , Herkes önce fikirlerini Tower'a yazacak, sonra herkesle iletişime geçecek, bu da uzaktan kumandadan sonra kalan iyi bir alışkanlık.
Üçüncü fayda, İşe almak daha uygun olacak .
Küçük girişimci bir ekip olduğumuz için, maaş açısından kesinlikle büyük bir şirket kadar iyi değiliz, öyleyse daha fazla yeteneği katılmaya nasıl çekebiliriz?
Uzun mesafe, girişimci ekibimizin cazibesi haline gelebilir.
Aynı zamanda, uzaktan çalışmayı seçmeye cesaret eden küçük ortakların çoğunun oldukça yetenekli ve cesur insanlar olduğuna ve nispeten güçlü olmaları gerektiğine inanıyorum, bu yüzden daha zor bir yol seçmeye cesaret etti. Remote, adayları gizli bir biçimde taramamıza yardımcı oluyor, böylece işe alınan ortaklar genellikle nispeten yüksek bir seviyede oluyor.
Son olarak, uzak olduğu için sadece Wuhan veya Chengdu ile sınırlı değil, ülkenin her yerinden yetenekleri işe alabiliyoruz. Attığınız ağ yeterince büyük olduğunda, balığınız artacaktır.
Yukarıdaki üç nokta, uzaktan çalışmanın getirdiğini düşündüğüm en büyük faydalar.
Uzaktan çalışmanın kalitesi ve verimliliği nasıl sağlanır
Sonra, herkesin en çok endişelendiği nokta olabilir Uzaktan çalışma ekipleri kalite ve verimliliği nasıl sağlayabilir?
Yıllardır sürdürdüğümüz uygulama sonuçlarına göre, iki temel noktadan fazlası yoktur:
- Doğru kişileri işe alın;
- Ekibin iş sürecini sürekli olarak optimize edin.
### Doğru kişileri işe alın
Daniel Pinker'ın şu kitabını okuyup okumadığınızı merak ediyorum: "Sürüş Gücü"?
Daniel Pinker kitapta bahsetti, Yaratıcı çalışma alanında, çalışanları motive etmek istiyorsanız, tek güvenilir yol onları sevdikleri ve önemsedikleri şeyi yapmaya teşvik etmektir. Startuplardaki "havuçlar" ve "çubuklar" çalışanları motive etmede etkili değildir.
Bu nedenle, ekibimiz için, uzaktan çalışmak istiyorsanız, kendi kendine yeten, uzmanlaşan ve eşyalarımızı seven insanları bulmak çok önemlidir.
Bir iş kurmanın farklı aşamalarında, farklı işe alma yöntemlerimiz var.
2008 yılında işimize başlamak için Chengdu'ya ilk döndüğümüzde, önceliğimiz ekibi genişletmekti.
O zamanlar ekibimizin ne itibarı ne de parası vardı.Eğer işe alım web sitelerinde çeşitli reklamlar yapmak veya işe alım ilanları yayınlamak için acele ederseniz, etkinin çok zayıf olduğunu hayal edebilirsiniz.
Bu nedenle, şu anda en iyi yol Bir tanıdıktan başlayın .
O sırada Caicheng'in çalışanlarının yarısı, Chengdu Elektronik Bilim ve Teknoloji Üniversitesi'ndeki "Dongli Unlimited" öğrenci kulübünün üyeleriydi, çünkü Lao Shen (Shen Xueliang, Caicheng CEO) kulübün başlatıcısıydı. "Dongli Unlimited" öğrenci kulübünde staj ve alıştırma yapmak isteyen öğrenciler bulacağız.
Yukarıdaki resimdeki küçük ortak, o sırada aradığımız sınıf arkadaşı ve şu anda ekibimizin CTO'su.
O sırada, Chengdu Elektronik Bilim ve Teknoloji Üniversitesi'nde izinli olarak son sınıftaydı. Askıya alma sırasında, denetlemek için Hong Kong Üniversitesi'ne gitti. Umarım daha fazla öğrenerek, gelecekteki uzun yaşamda gerçekten ne istediğini anlayabilirim.
Onun deneyimini öğrendiğinizde, güçlü bağımsız düşünme yeteneğine sahip bir kişi olduğunu göreceksiniz, bu yüzden artık şirket ortağımız oldu. Aynı zamanda, iki yıl önce beni CTO pozisyonundan "attı".
Bu, işimizin en başında insanları bulmamızın bir yoludur. Şirket yavaş yavaş büyüdükçe yerel bir "UCD Kitap Kulübü" aktivite.
Her ay sabit bir hafta sonu, bazı arkadaşları ve şirketin küçük ortaklarını tasarım ve ürünlerle ilgilenen meslektaşlarımızla iletişim kurmak için bir öğleden sonra geçirmeye davet edeceğiz. Bu tür faaliyetler, sadece Chengdu'daki yerel ağ kaynaklarını genişletmemize yardımcı olmakla kalmadı, aynı zamanda pek popüler olmayan "Kullanıcı Deneyimi Tasarımı" ile ilgilenen pek çok kişinin bizim gözümüze girmesine izin verdi.
Bu dönemde artık Tower için etkileşim tasarımcısı olan arkadaşlarımızla tanıştık. O sıralarda Southwest University for Nationalities'in kıdemli okulu bırakan öğrencisiydi. Tibet'e tek başına bisikletle gidiyordu.Hobisi karting. Şimdi Sichuan Eyaletindeki amatör grubun şampiyonu.
O da böyle bir insan, görelim ki bir insan bir şeyi çok sevdiğinde, kendisini tamamlamaya kendini adamıştır.
Yukarıdaki resim onun kıdemli el yazması El çizimi prototip tasarımına baktığımızda, aradığımız küçük ortak olduğunu biliyorduk.
Bu bizim ikinci aşamamız, Ekibiniz biraz büyüyen bir aşamadayken işe almanın sırrı budur. .
Tower'ı piyasaya sürdükten sonra ekip yavaş yavaş itibar kazandı. Şu anda, ülkenin her yerinden bazı özgeçmişler alabiliyoruz.
Bununla birlikte, adayları doğrudan özgeçmişinizden yargılamak sizin için hala zor. Bu nedenle, uygun ortakları işe almak için iki temel ilke belirledik. Bu, Trello'nun kurucusu Joel Spolsky'nin "Mülakat Kılavuzu" makalesinde belirttiği şeydir. Bahsetti: Akıllı ve işi zamanında tamamlayabilen.
Aslında bunlar çok basit iki ilkedir.Başvurana, görevi tamamlama sürecinde hızını ve kalitesini gözlemleyerek ve başvuranın görevi nasıl tamamladığını görerek gerçekleştirmesi için Tower'da sadece bazı özel görevler vermemiz gerekir. Süreç boyunca, Kule'yi düşündü ve bu aşamada ihtiyacımız olan yetenek olup olmadığına karar verdi.
Kısa süre önce işe aldığımız bir tasarımcı örneğini ele alalım, o sırada ona Tower'ın görev ayrıntıları sayfasını yeniden tasarlaması için bir görev verdik.
Tasarımcı, çalışmasını hızlı bir şekilde sunmakla kalmadı, aynı zamanda 18 sayfalık bir rapor da sundu:
Tower'ı kullanma konusundaki önceki deneyimine ve etrafındaki bazı arkadaşlarının kullanılabilirlik testine dayanarak, Tower görev ayrıntıları sayfasının eksiksiz bir yeniden inşa planını yaptı. Bu şekilde hedef üyelerimizin tüm temel niteliklerine sahip olduğunu hissedebilirsiniz.
Belki de her zaman bu kadar iyi arkadaşlar edinebileceğimizi söyleyemeyiz, ancak açıkçası, şirketimizin üyeleri takımda en büyük değeri oynayabilir.
Bu nedenle, Netflix Kültür El Kitabı'nda da belirtildiği gibi, şirkette en temel şeyleri yapmak istiyorsak, şirketin yetenek yoğunluğunun yüksek olması gerektiğini düşünüyorum.
Hayatımızın en değerli yıllarının neredeyse yarısı iş başında olduğundan, seçkin insanlarla çalışmayı ve birlikte olağanüstü ürünler yapmayı umuyoruz. Caicheng için bu, şirketi ne kadar büyütebileceğimizden daha önemli.
İşbirliği sürecini sürekli olarak optimize edin
Doğru kişiyi bulmak yalnızca ilk adımdır ve ikinci adım, uzaktan ekip işbirliğinin verimliliğini artırmamızı gerektirir. Bu nedenle, ürün geliştirme sürecimizi optimize etmeye devam ediyoruz.
Şu anda, Tower (ürün) oluşturmanın ana süreci 6 adımda özetlenmektedir: geri bildirim toplama, gereksinim sıralama, şema tasarımı, yinelemeli geliştirme, işlevsel test ve işlevsel sürüm.
Tower, kullanıcıların etrafında dönen bir ürün olduğu için, hepimiz kullanıcılardan başlıyoruz ve kullanıcılar, çeşitli kanallar aracılığıyla kullanım sırasında karşılaşılan sorunları bize geri bildirecekler. Bu sorunlar öncelikle kullanıcılara yardımcı olmaya ve mevcut sorunlarını çözmeye çalışacak olan müşteri hizmetleri ekibimize özetlenir.
Müşteri hizmetleri sorunu çözemediğinde, sorunu iki türe ayıracağız, biri kullanıcının bir hatayla karşılaşması, diğeri de kullanıcının bize potansiyel bir yeni talep önermesidir.
İki farklı ses türü için, müşteri hizmetleri farklı projelerde görevler oluşturacak ve ardından bunları ürün departmanındaki meslektaşlarına devredecektir.
Hata görevleri için, mühendislik ekibi bunları hızla düzeltecek ve çevrimiçi olacak; yeni gereksinimler için, ürün yöneticisi bazı yargılardan sonra bunları uygulayıp uygulamayacağına karar verecektir. Uygulanması gerektiği belirlenirse, ürün yöneticisi tüm problem arka planını, çözümünü ve uygulama yöntemini yazacak ve ardından talep havuzuna koyacak ve mühendislik ekibinin geliştirmesini bekleyecektir.
Mühendislik ekibi, sabit bir döngüde yinelemeli geliştirme gerçekleştirecektir. Yinelemeye başlamadan önce mühendis, talep havuzundan gelen önceliğe göre her görevin ölçeğini değerlendirecek ve yineleme döngüsünün kaynakları tahsis edilene kadar ilgili yineleme görevini oluşturacaktır.
İşlevsel yineleme geliştirme bittikten sonra, ürün sahibi bir test yapacak; test geçildikten sonra ekip bir çevrimiçi plan ayarlayacak, bazı işlevler iç test için bazı kullanıcılara açık olacak ve bazı işlevler doğrudan tam olarak piyasaya sürülecek.
Her proje yineleme döngüsü bittikten sonra, bu yinelemede karşılaşılan sorunları ve iyileştirme yöntemlerini özetlemek için bir toplantı yapacağız.
Yeni işlevler kullanıcıların eline teslim edilir ve yeni bir döngü yeniden başlar: geri bildirim toplama, gereksinimleri sıralama, planlar tasarlama, yinelemeli geliştirme, test etme ve başlatma vb.
Yukarıdaki sürece karşılık gelen ekibimiz aşağıdaki temel projeleri kullanacaktır:
"VOICE 2019" projesi esas olarak yeni kullanıcı ihtiyaçlarını toplamak için kullanılır. Bu projenin adından da anlaşılacağı gibi, o yıldan itibaren kullanıcı geri bildirimleri için her yıl yeni bir proje inşa edeceğiz ve her yıl yepyeni bir başlangıç.
Kullanıcı geri bildirimi oluştururken, müşteri hizmetinin, kullanıcının takım boyutu, ilgili platform, geri bildirimin ait olduğu işlevsel modül vb. Gibi kullanıcının probleminin arka planını anlaması ve ilgili görevi oluşturması gerekir.
Tower'ın müşteri hizmetleri özeldir, çünkü Tower'ın müşteri hizmetleri temelde mühendislerimizdir, müşteri hizmetlerinde uzmanlaşmak için haftada bir gün dönüşümlü olarak çalışacaklar, böylece ürünlerini daha iyi anlarlar ve kullanıcıların ihtiyaçlarını anlarlar.
Daha sonra, ürün yöneticisi "VOICE 2019" da kullanıcı geri bildirimlerini kontrol etmek için her gün sabit bir zaman harcıyor, neyin yapılmaması gerektiğini, ne yapılması gerektiğini ve hangilerinin bir karar vermeden önce sahneyi derinlemesine anlaması gerektiğini ayırt ediyor.
Ürün yöneticisi, kullanıcının ihtiyaçlarını net bir şekilde anladıktan sonra, "Sırada Ne Var" projesinde belirli talep görevleri oluşturacak, görev önceliklerini belirleyecek ve planları tasarlayacaktır.
Tüm "Sırada Ne Var?" Projesinin birkaç aşaması vardır: orijinal gereksinimler, tasarım, değerlendirilecek noktalar, yineleme ve yayınlama.
Değerlendirmeyi geçen kullanıcı geri bildirimleri ilk önce orijinal gereksinimlere yerleştirilecek, ürün yöneticisi bir öncelik tahmin edecek ve ardından yüksek öncelikli gereksinimler için bir plan tasarlayacaktır. Ön ürün planının tasarım gereksinimleri konusunda daha dikkatliyiz.Genel olarak, her gereksinim sabit bir plan belgesi oluşturacaktır:
Örneğin, çevrimiçi düzenleyiciyi güncellemek için, ürün yöneticisinin kullanıcının kullanım senaryosu, her bir terminalin altındaki ürün planı, proje ekibinin tahmini kaynak girdisi ve çıktı hedefleri hakkında net bir şekilde yazacağını katalogdan görebiliriz. Bu belge, takip ekibi tartışmalarının temeli olduğundan, ürün müdürünün bunu olabildiğince ayrıntılı yazmasını umuyoruz.
Ürün yöneticisi plan tasarımını tamamladıktan sonra, bu görevi değerlendirme aşamasına koyacak ve bir sonraki yineleme başladığında değerlendirmeyi bekleyecektir.
Mühendislik ekibimiz eskiden her 3 haftada bir yinelemelerle ilgileniyordu, ancak şimdi her 6 haftada bir yinelemeyle değiştiriliyor.
Her yinelemenin başlamasından önce, önceki yinelemenin tam miktarını özetlemek ve serbest bırakmak için bir hafta kullanacağız ve ardından bir sonraki yinelemede yapılması gereken görevleri tartışacağız. Yinelemeli başlangıç toplantısında, ürün yöneticisi ve mühendis, "Sırada Ne Var?" Projesinin "Değerlendirilecek" listesindeki gereksinimleri önceliklerine göre inceleyecek:
Ürün yöneticisi talebin arka planını ve tasarım planını açıklayacaktır.Bu süreçte mühendis, tekrar tekrar kullanıcının talep senaryosunu soracak, potansiyel çukurlar hakkında net bir şekilde sorular soracak ve ardından görev tahminini yürütecektir.
Daha sonra, mühendislik ekibi yinelemeli "Fox RS" projesinde işbirliği yapacak. Projenin adı bir yarış arabası modelidir ve "Fox" odaklanmayı temsil eder ve "RS" hızı temsil eder. Mühendislerin yineleme döngüsündeki en hızlı hızda kendi ihtiyaçlarını karşılamaya odaklanabileceklerini umuyoruz.
İlk olarak bu projeyi dört aşamaya ayırdık: beklemede, yürütülüyor, test ediliyor ve tamamlandı:
Mühendislik yineleme sürecinde, "işlenecek" listesinde "yürütülecek" yeni görevler olup olmadığını belirlemek için her gün video konferanslar düzenleyeceğiz; tamamlanan görevler "test" aşamasına taşınır ve ürüne teslim edilir. Yönetici testi yürütür.
Yineleme döngüsünde, mühendislerden işlevi bir an önce "tatma" aşamasına ilerletmelerini isteyeceğiz Bu aşamaya ulaştıktan sonra, sorumlu kişi görev kartını "yürütme" listesinden "test" aşamasına sürükleyecektir. Ve farklı ekipler tarafından dahili test için ürün işlevlerini dahili test sunucusuna dağıtın.
Dahili test aşamasında, elde etmek için gri tonlama mekanizmasını kullanacağız. İlk günlerde, dahili test ortamını oluşturmak için bazı bağımsız sunucular kullanacağız. Bu yöntemi kullanmanın en büyük sorunu, bu bağımsız sunucuda resmi bir veri olmadığı için gerçek üretim ortamından izole edilmiş olmasıdır. Bu nedenle, takımdaki meslektaşlar genellikle "oynamak" ve testi bitirmek için sahadan geçerler. Bu bizim amacımız değil, bu yüzden dahili test yöntemini geliştirdik.
Üretim ortamı veritabanına doğrudan bağlı bir web sunucumuz var Bu web sunucusu dahili test şubesini devreye alacak. Arka planda kendi ekibimize dahili test için bir çerez bayrağı ekleyeceğiz, böylece Nginx her HTTP isteğini aldığında, isteğin bu bayrağa göre belirli bir dahili test sunucusuna iletilip iletilmeyeceğini belirleyecektir.
Ürün yöneticisi ve ekibin diğer üyeleri ürün işlevini gerçek bir ortamda test ettiğinde ve ürün işleviyle ilgili bir sorun olmadığını hissettiğinde, test için bazı kullanıcılara yayınlayacağız.
Aslında burada belli bir risk var - çünkü Tower'da zaten binlerce ödeme yapan kullanıcı var, bazı özellikler önemli ölçüde değiştiğinde, doğrudan kullanıcılara açılmanın ne gibi sonuçlara yol açacağını belirlemek bizim için zor, bu yüzden özellikleri koyacağız "Labs" adlı bir sütunda, kullanıcılara deneme için başvuruda bulunabilir:
Böylelikle öncelikle kullanıcıların hangi fonksiyonel gereksinimleri istediğini belirleyebiliyoruz.Başvuran sayısı çok az ise ihtiyaçların kaynağı ile ilgili bir sorun var demektir ve devam etmek için zaman kaybetmeye gerek yoktur; ikincisi başvuran kullanıcılar genellikle haklıdır Bu özellikler çok heveslidir. Bu kullanıcılar, özelliğin ilk sürümündeki bazı kusurları tolere etmeye isteklidir ve ayrıca deneme sürecinde bize daha fazla geri bildirim vermeye isteklidir. Bu kullanıcıların ihtiyaçları doğrultusunda iyileştirmeler yaparsak, sonraki başarı oranı daha yüksek olacaktır.
Temel olarak, küçük ekibimizin yanlış gitmemesini sağlamak için yayınlamak için yukarıdaki iki yöntemi kullanacağız.
Aynı zamanda, üç haftalık yineleme bittikten sonra, yinelemeli inceleme yapmak ve bu yinelemeye karşılık gelen işlevleri serbest bırakmak için bir hafta kullanacağız.
Yineleme incelemesi ile ilgili olarak, yineleme döngüsü ekibinin çıktı verimliliğini hesaplamak için Tower'ın bilgi tabanına buna benzer bir belge yazacağız:
Bu iterasyon periyodundaki her üyenin yüküne ve sonunda serbest bırakılabilecek görevlere karşılık gelen puan sayısına göre, bu iterasyon periyodunda her üyenin çıktı verimini hesaplayabiliriz. Düşük çıktı verimliliğine sahip üyeler için, gözden geçirme haftasında karşılaşılan sorunları ve iyileştirme planlarını bireysel olarak analiz edebiliriz Her yinelemeden sonra ekibin çıktı verimliliğinin iyileştirilebileceğini umuyoruz.
Yukarıdakiler, Tower'ı inşa eden ekibimizin ana süreçleridir.
Ekip küçük olsa da, süreç hala sürekli olarak optimize ediliyor, ancak bu şekilde uzaktan çalışırken iş verimliliğimizi sağlayabiliriz.
TGO Kunpeng Club, Geekbang Technology altında üst düzey teknik kişilerin bir araya gelme ve iletişim organizasyonudur.Üyelerine özel hizmetler sunmak için çevrimiçi ve çevrimdışı olarak teknoloji liderleri için dünyanın en etkili sosyal ağını oluşturmayı amaçlamaktadır. Şu anda TGO Kunpeng Club, Pekin, Şanghay, Hangzhou, Guangzhou, Shenzhen, Chengdu, Silikon Vadisi, Tayvan, Nanjing, Xiamen, Wuhan ve Suzhou'da 12 şehirde şubeler kurdu. Şu anda dünya çapında 800'den fazla kayıtlı üye var ve bunların% 60'ı CTO'lar, teknik VP'ler ve teknik ortaklar.
Üyelik, BATJ gibi İnternet devlerinin teknik liderlerini kapsamaktadır.Aynı zamanda, Alibaba'dan Dr. Wang Jian, Tongcheng Yilong'un teknik komitesi yöneticisi Zhang Hailong ve Suning.com'un BT genel müdür yardımcısı Qiao Xinliang, TGO Kunpeng Club'ın fahri danışmanları olmaya davet edildi.
