Як мы пілоцім Doika. Анатомія каманды

Апублікавана

by — Posted in пра майстэрню, праекты, праца каманды

Працягваю серыю зацемак (частка 1) пра тое, як, чаму развіваецца праект Doika. На гэты раз расповяд пра логіку арганізацыі ўдзельнікаў. Гэта не значыць, што я выключаю эмоцыі: прывязанасць, сімпатыю, імкненне дасягнуць мэты і атрымаць асалоду калектыўнай творчасці. Нарэшце.

Што такое “каманда”?

Часта ў размовах праектных мэнэджэраў чую тэрмін “каманда”. Што яно значыць насамрэч? У гэтым пасце паспрабую даць сваё вызначэнне і паразважаць, якія інструменты на шляху да добрай каманды можна прытрымлівацца.

Каманды бываюць спартыўныя, вытворчыя, творчыя, палітычныя, грамадскіх арганізацый.

Маё вызначэнне:
Каманда – гэта група людзей, аб’яднаная пэўнай мэтай і каштоўнасцямі, якая падзяляе адзіны або агульна прыняты спосаб вырашэння пастаўленай задачы, а таксама мае абазначаныя ролі і адказнасці.

Нягледзяцы на тое, што ў маім вызначэнні каманды ёсць слова “мэта”, пастаянна ўзнікаюць пытанні. Ці могуць існаваць каманды без мэты? Ці могуць існаваць каманды, якія не прытрымліваюцца агульных каштоўнасцяў, але бачаць агульную мэту? Ці могуць існаваць каманды, удзельнікі якой бачаць розныя спосабы вырашэння праблемы? Якое лідэрства ў валанцёрскай камандзе павінна быць? Як прымаць новых удзельнікаў у каманду?

Падчас працы каманды

Насамрэч гэтыя пытанні я часта падымаю падчас працы праекта Doika, але вельмі рэдка атрымліваю адказы, якія задаволяць мяне. Чаму так здараецца?

Якія якасці ў камандзе патрэбны?

Зараз разбярэмся, якія якасці неабходна мець камандзе. У дадзеным выпадку камандзе, якая працуе над стварэннем вэб-прыкладання на валанцёрскіх падставах.

Першая якасць – гэта падзяляць мэту, дзеля якой ствараецца прадукт. Гэта мэта павінна быць разам прагаворана і прынята кансэнсусам. Мэта павінна мець не толькі натхняючыя рэчы, але метрыкі. Метрыкі патрэбны, каб каманда магла вымераць свой поспех.

Другая не менш важная якасць – гэта ўменне дамаўляцца пра інстытут лідэрства ў камандзе, іншымі словамі, як прымаць рашэнні, размяркоўваць час і прыярытэт. Будзе гэта абмеркаванне з кансэнсусам, дэлегаванне праектнаму мэнэджэру ці каманднаму ліду рашэнняў датычна прыярытэтаў развіцця праекта, або каманда вызначае сваё дзеянне згодна дэталізаваным правілам?

Далей, важна ўменне вучыцца, у тым ліку не толькі профільным накірункам. У камандзе з 3х чалавек не можа быць выключна тры вузкія ролі: спецыяліста па дызайну, фронт кадзіраванню і ручному тэставанню. Хутчэй за ўсё ўдзельнікам неабходна будзе засвоіць навыкі праектавання праграм, бэкэнд распрацоўкі, UX-дызайна і даследвання, разгортвання і аўтаматычнага тэставання, сумаўленне з карыстальнікамі і іншымі спецыялістамі па-за камандай. Іншымі словамі, без умення выконваць 2-3 функцыі, каманда ўвесь час будзе сутыкацца з так званым bottle neck, калі адны задачы выконваюцца добра, але іншыя правісаюць і праект стопарыцца.

Нарэшце, апошняя са спісу якасць – гэта ўменне прыслухоўвацца да меркаванняў спажыўцоў. Тут усё проста. Маркетынгавага аддзелу ў камандзе з 3х чалавек няма, але гэта не выключае неабходнасць працаваць з людзьмі. Таксама, калі каманда базуе свой код у адкрытых рэпазіторыях варта, каб яна была гатова выслухваць крытыкі іншых распрацоўшчыкаў.

Як развівалася каманда Doika

Усяго прайшло дзве ітэрацыі, зараз мы падступілі да трэцяй.

Развіццё каманды пачалося з афармлення ідэі. Мы правялі не адну сустрэчу, афармляючы першы набор функцыянала з бізнэс-аналітыкамі, адзін з якіх пазней пряднаўся да каманды. Пасля далучылася некалькі валанцёраў (праектны мэнэджэр і бэкэнд распрацоўшчык) і пачалася праца над кодам. Далей у каманду прыйшоў тэставальшчык. Такімі сіламі была скончана першая ітэрацыя. У канцы першай ітэрацыі мы правялі фокус-групу з патэнцыйнымі карыстачамі (грамадскімі арганізацыямі), дзе атрымалі спіс пажаданняў да развіцця прадукта.

У гэтай ітэрацыі людзі толькі прывыкалі адзін да аднаго. Адбываліся рэгулярныя сустрэчы анлайн (skype, trello), часам афлайн (некалькі сустрэч). Усе правілы прагаворваліся у гутарцы, некаторыя канспектаваліся.

На другой ітэрацыі каманда папоўнілася фронтэнд распрацоўшчыкам, які неўзабаве замяніўся іншым. Такія хуткія замены вельмі балюча адбіваюцца на камандзе, бо механізм перадачы ведаў больш факусаваўся на вуснай гаворцы падчас чатаў і толькі невялікім удзелам вікі. Каманда была больш прыцёртая, але на гэтым этапе ўзніклі два іншых выкліка: недахоп кампетэнцый і перагаранне удзельнікаў.

Зацемка: Вікі праекта – гэта сховішча неабходных для ўстойлівага развіцця праекта ведаў, якія можа дапаўняць кожны ўдзельнік самастойна.

Пачнем з другога выкліка. Усе людзі, якія інтэнсіўна працуюць у праектах маюць уласцівасць перагараць, у тым ліку валанцёры. Гэта ў сваю чаргу прыводзіць да рэзкага змяншэння прадуктыўнасці каманды: пагаршаецца код, тэсты, дызайн, дакументацыя. Іншымі словамі, траціцца шмат часу толькі на размовы і рэанімацыю удзельнікаў, чаканне, паўторнае узгадненне тэрмінаў, рэальнага руху ў няма. Але камандзе гэта складана прызнаць.

Недахоп кампетэнцый – гэта толькі палова выкліка, бо іншая – гэта неабходнасць хутка вучыцца. Калі гэтай якасці ў каманды няма, праца можа стаць на палове і патрабаваць хутчэй за ўсё:

  • іншых удзельнікаў з дастатковымі кампетэнцыямі або
  • працяглага адпачынку і факусавання на павышэнні кваліфікацыі існуючых удзельнікаў.

Падкрэслю, што гэта вельмі затратныя актыўнасці і першая і другая, якія як мінімум уводзяць праект у бок.

Усё ж такі на другой ітэрацыі ў каманды былі лепей апісаны правілы працы, зроблена першая структура вікі (на гіт-хаб), мы абнавілі агульную праектную прастору, больш часу прысвяцілі апісанню архітэктуры. Такім чынам, каманда зрабіла сур’ёзны крок наперад па кіраванні кодам і сваімі ведамі.

Галоўнае, каб на стале была свежая гардніна

На сёння каманда складаецца з працягла актыўных і адказных удзельнікаў (ядра) і рэзерву. Ядро на сёння выглядае так:

  • UI/UX дызайнер,
  • Вэб-распрацоўшчык і дэвопс (пакуль больш па фронт-энд часцы),
  • Праектны мэнэджэр і камандны лід у адной асобе,
  • Таксама SMM і графічны дызайнер.

На сёння ў камандзе добра прадстаўлены дызайнерскі і мэнэджэрскі бакі. Недастае высокага ўзроўню архітэктуры кода і тэставання, а таксама працы па прасоўванню.

Каманда мае валанцёраў-дапаможнікаў. Гэта пачынаючыя распрацоўшчыкі, як фронтэнд, так і бэкэнд, якія далучаюцца да некаторых задач: паляпшаюць або тэстуюць існуючы інтэрфейс.

Праца каманды (багі і прапановы) больш перанакіроўваецца на гітхаб, дзе да ўнёску кода могуць далучаца любыя жадаючыя. Размовы і гукавы чаты адбываюцца праз slack, падрыхтоўка праекту ідзе на realtimeboard і trello. Працоўныя дошкі спрынтоў на trello. Большасць працэсаў інтэгравана і мае магчымасць паведамляць аб зменах у розных асяродках.

Якія складанасці ў валанцёрскай камандзе

У валанцёрскіх камандах пастаянна паўстае пытанне колькасці ўдзельнікаў каманды. Ці дастатковая колькасць удзельнікаў, ці неабходна яшчэ далучаць? У валанцёрскіх вымярэннях вялікая каманда – гэта 7-10 чалавек актыўна працяглы час (больш за 3-6 месяцаў) працуюць з кодам і людзьмі.

 

Мы розныя. Ёсць эмацыянальныя, ёсць лагічныя

Найбольш выразныя плюсы вялікай валанцёрскай каманды:

  1. Спецыялізацыя дае магчымасць прафесійна выканаць частку задачы і тым самым палепшыць якасць усяго прадукта, а ў некаторых выпадках хуткасць.
  2. У вялікай камандзе прасцей знайсці замену ўдзельнікам, якія выбываюць. Выбыццё ў валанцёрскіх камандах – звычайная з’ява. Прычын шмат: губляецца цікавасць, псіхалагічная несумяшчальнасць, выгаранне, пераключэнне на больш прыярытэтныя справы і інш.
  3. У вялікай камандзе ёсць больш магчымасцяў абраць больш надзейны накірунак развіцця праекта, улічыўшы шмат меркаванняў і рознапрофільных хібаў.

Зараз пра мінусы:

  • Каардынацыйныя выдаткі. Перш за ўсё вялікія каманды вымагаюць вялікіх каардынацыйных выдаткаў, у тым ліку, як агульна камандныя, так і пазадачныя. Таму такія каманды не жывуць без персаніфікаванага лідэрства і праектнага мэнэджмэнта. А гэта значыць, валанцёрская каманда павінна мець удзельніка, які будзе пастаянна каардынаваць, што часта з фінансавага боку непад’ёмна для каманды.
  • Рызыка часу. Вялікія каманды патрабуюць вельмі шмат часу траціць на псіхалагічнае прыціранне і ўвод новых удзельнікаў у справы. Гэты “непрадуктыўны” час у іншым выпадку мог быць накіраваны на развіццё прадукта, але выдаткоўваецца на ўвядзенне ў справу, без гарантыі, што гэты час акупіцца пасля прадуктыўным выкананнем.
  • Розніца ведаў. У вялікіх камандах можа ўзнікаць розніца ведаў паміж сталымі і новымі ўдзельнікамі. Гэты бар’ер часта не так проста прадухіліць, але з іншага боку ён парабуе сумяшчэння падыходаў і звыш гнуткасці ў кіраванні. З улікам абмежаванасці рэсурса якасных ведаў, навучальны працэс можа забіраць занадта вялікую колькасць часу. Як вынік можа ўзнікаць цэлыя залежы неякаснага коду і яшчэ больш непрадказальнай архітэктуры рашэння.

Ці патрэбна вялікая каманда ў Doika?

Найбольш актуальны застаюцца два пытанні:

  • Як кіраваць аптымальнай колькасцю каманды, захоўваючы яе прадуктыўнасць, устойлівасць і рост ведаў.
  • Якія крытэры павінны быць для ўдзельнікаў, якія хочуць далучыцца да ядра?

Так зараз мы дасягнулі мяжы магчымасцяў валанцёрскай – гэта значыць бясплатнай у прамым сэнсе – працы, але вельмі дарагой у сэнсе часа, які пры канвертацыі можа паказваць большыя выдаткі.

Магчымыя сцэнары

  • Камбінацыя прафесіяналаў і валанцёраў. Прафесіяналы, робяць задачы, якія патрабуюць большай кампэтэнцыі і кансультуюць каманду Doika.
  • Прафесіяналізацыя самой каманды Doika, якая выконвае праект за грошы, каардынуючы далучыўшыхся ўдзельнікаў-валанцёраў. Гэта значыць ведаў ўдзельнікаў даволі для якаснага развіцця прадукта.
  • Пры знаходжанні рэсурсаў перадача выканання працы трэцім асобам (на аўтсорс), пераключэнне каманды на маркетынг і тэх. падтрымку рашэння. Іншымі словамі, выкананне функцый прадуктовага мэнэджмэнта.

Наогул кожны з гэтых сцэнароў мае свае плюсы. Як вы думаеце яки сцэнар будзе найбольш выніковым з доўгатэрміновай перспектывы опенсорснага праекта?

Чыстая логіка , мэта і эмоцыі даюць неверагодны кайф ад сумеснай творчасці

…..

У наступным допісе распавяду нарэшце, чаму мы назваліся Doika.

Калі вы знайшлі памылкі, калі ласка паведамьце нам гэты тэкст, націснуўшы Ctrl+Enter.

Дзяліся:


ryzomych
рухавік і заснавальнік Фаланстэра. Цікаўлюся сацыятэхнікай, лічбавымі правамі і роварамі.

2 думак пра “Як мы пілоцім Doika. Анатомія каманды

Пакінуць адказ

Ваш адрас электроннай пошты не будзе апублікаваны. Неабходныя палі пазначаны як *