Прывітанне сябры. Запар і побач, асабліва ў аўтсорсе, я бачу адну і тую ж карціну. Адсутнасць дакладнага працоўнага працэсу ў камандах на розных праектах.
Самае галоўнае - гэта тое, што праграмісты не разумеюць, як трэба камунікаваць з заказчыкам і адзін з адным. Як пабудаваць бесперапынны працэс распрацоўкі якаснага прадукта. Як спланаваць свой працоўны дзень і спрынты.
І ўсё гэта ў выніку выліваецца ў сарваныя дэдлайны, авертаймы, пастаянныя разборкі, хто вінаваты, і незадаволенасць заказчыкаў - куды і як усё рухаецца. Даволі часта ўсё гэта прыводзіць да змены праграмістаў, а то і цэлых каманд. Страце заказчыка, пагаршэнню рэпутацыі і гэтак далей.
У свой час я якраз і патрапіў на такі праект, дзе былі ўсе гэтыя любаты.
Ніхто не хацеў браць на сябе адказнасць за праект (вялікі сэрвісны маркетплейс), цякучка была страшная, заказчык проста ірваў і кідаў. СЕА неяк падышоў да мяне і сказаў, што ты маеш патрэбны досвед дык вось табе і карты ў рукі. Забірай праект сабе. Аблажаешся, праект закрыем і ўсіх выганім. Атрымаецца, будзе крута, тады вядзі яго і развівай, як лічыш патрэбным. У выніку я стаў тымлідаў на праекце і ўсё лягло на мае плечы.
Першае, што я зрабіў - гэта распрацаваў працоўны працэс з нуля, які адпавядаў на той момант майму бачанню, і напісаў службовую інструкцыю для каманды. Укараняць яго было няпроста. Але дзесьці на працягу месяца ўсё ўстаканіцца, распрацоўшчыкі і кліент прывыклі, і ўсё пайшло ўжо ціха і камфортна. Для таго каб паказаць камандзе, што гэта не проста "бура ў шклянцы", а рэальны выхад з сітуацыі, я ўзяў на сябе максімальны аб'ём абавязкаў, зняўшы непрыемную руціну з каманды.
Ужо прайшло паўтара года, і праект развіваецца без авертаймаў, без пацучыных гонак і разнастайных стрэсаў. Нехта ў старой камандзе не захацеў так працаваць і пайшоў, камусьці наадварот вельмі зайшло, што з'явіліся празрыстыя правілы. Але па выніку ўсе хто ў камандзе, тыя вельмі матываваныя і ведаюць вялізны праект цалкам, пры чым і фронтэнд і бэкэнд. Уключаючы і кодавую базу і ўсю бізнэс логіку. Дайшло ўжо нават да таго, што мы не проста «грэбцы», а самі прыдумляем шматлікія бізнэс працэсы і новыя фічы, якія бізнэсу апынуліся даспадобы.
Дзякуючы такому падыходу з нашага боку, замоўца вырашыў замовіць у нашай кампаніі яшчэ адзін маркетплейс, што не можа не цешыць.
Паколькі на маім праекце гэта працуе, то, можа быць, камусьці гэта таксама зможа дапамагчы. Такім чынам, сам працэс, які дапамог нам выратаваць праект:
Працэс працы каманды на праекце "Мой любімы праект"
a) Унутры камандны працэс (паміж распрацоўшчыкамі)
- Усе задачы ствараюцца ў сістэме Jira
- Кожная задача павінна быць максімальна апісана, і выконваць строга адно дзеянне
- Любая фіча, калі яна дастаткова складаная, разбіваецца на шмат дробных тасок
- Каманда працуе над фічамі, як адзінай нудой. Спачатку які робіцца ўсё разам адну фічу, аддаём яе на тэставанне, затым бярэм наступную.
- Кожная задача маркіруецца, для бэкенда ці фронтэнда яна
- Ёсць тыпы тасок і багаў. Трэба правільна іх указваць.
- Пасля выканання задачы яна перакладаецца ў статут рэўю кода (пры гэтым ствараецца пул рэквест на свайго калегу).
- Той хто выконваў задачу адразу ж трэкае свой час для гэтай задачы
- Пасля праверкі кода, ПР апрувіцца і пасля гэтага, той, хто выконваў гэтую задачу, самастойна мержыць яе ў майстар галінку, пасля чаго змяняе яе статус у гатовая для дэплою на дзеў сервер.
- Усе задачы, гатовыя да дэплою на дзеў сервер, дэплояцца тымлідам (яго зона адказнасці), часам чальцом каманды, калі нешта тэрміновае. Пасля дэплою ўсе цягі з гатова да дэплою на панну пераводзяцца ў статус - гатова да тэставання на панне.
- Усе задачы тэсціруе заказчык
- Калі заказчык пратэставаў задачу на панове, ён перакладае яе ў статус гатовая для дэплою на прад.
- Для дэплою на прад мы маем асобную галінку, куды мержам майстар толькі перад дэплоем
- Калі падчас тэставання замоўца знаходзіць багі, то ён вяртае задачу на дапрацоўку, усталёўваючы ёй статут вернутая на дапрацоўку. Такім чынам мы адлучаем новыя задачы ад тых, якія не прайшлі тэставанне
- У выніку ўсе задачы праходзяць шлях ад стварэння да завяршэння.
- Кожны распрацоўшчык тэстуе свой код самастойна, у тым ліку і як карыстальнік сайта. Не дапушчаецца зліццё галінкі з асноўнай, калі дакладна не вядома, што код працуе.
- Кожная задача мае прыярытэты. Прыярытэты расстаўляе альбо замоўца, альбо тымлід.
- Распрацоўнікі ў першую чаргу выконваюць прыярытэтныя задачы.
- Распрацоўнікі могуць прызначаць задачы сябар на сябра, калі былі знойдзены розныя багі ў сістэме або адна задача складаецца з працы некалькіх адмыслоўцаў.
- Усе задачы, якія стварае заказчык, трапляюць да тымлід, які іх ацэньвае, і альбо просіць заказчыка дапрацаваць, альбо прызначае на аднаго з членаў каманды.
- Усе задачы, якія гатовыя да дэплою на панну або прод, трапляюць таксама да тымліду, які самастойна вызначае, калі і як праводзіць дэплой. Пасля кожнага дэплою тымлід (або член каманды) павінен паведаміць заказчыка аб гэтым. А таксама змяніць статуты для задач, на гатова да тэставання на паннаў/прад.
- Кожны дзень у адзін і той жа час (у нас гэта ў 12.00) мы праводзім мітынг паміж усімі чальцамі каманды
- Кожны на мітынгу дае справаздачу, уключаючы тымліда, што ён зрабіў учора, што плануе рабіць сёння. Што не атрымліваецца і чаму. Такім чынам, уся каманда ў курсе таго, хто чым займаецца і на якім этапе знаходзіцца праект. Гэта дае нам магчымасць спрагназаваць і адкарэктаваць, калі трэба, нашы эстымейты і дэдлайны.
- На мітынгу тымлід таксама агучвае аб усіх зменах у праекце і аб узроўні бягучых багаў, якія былі знойдзены не заказчыкам. Усе багі разбіраюцца і прызначаюцца на кожнага чальца каманды для іх рашэння.
- На мітынгу тымлід прызначае на кожнага задачы, улічваючы бягучую загружанасць распрацоўшчыкаў, узровень іх прафесійнай падрыхтоўкі, а таксама з улікам блізкасці той ці іншай задачы да таго, чым займаецца распрацоўшчык у дадзены момант.
- На мітынгу тымлід выпрацоўвае агульную стратэгію па архітэктуры і бізнес-логіцы. Пасля чаго ўся каманда гэта абмяркоўвае і прымае рашэнне аб унясенні карэктываў або прыняцці дадзенай стратэгіі.
- Кожны распрацоўшчык піша код і будуе алгарытмы самастойна ў рамках адзінай архітэктуры і бізнес логікі. Кожны можа выказаць сваё бачанне рэалізацыі, але сілком ніхто нікога не прымушае рабіць толькі так, а не інакш. Кожнае рашэньне аргумэнтуецца. Калі ёсць лепшае рашэнне, але зараз няма на яго часу, то ствараецца цяга ў тлушчы, на будучы рэфактарынг пэўнай часткі кода.
- Калі распрацоўшчык узяў у працу задачу, ён перакладае яе ў статут распрацоўкі. Уся камунікацыя з нагоды ўдакладнення задачы ў замоўца кладзецца на плечы распрацоўніка. Пытанні тэхнічнага плана можна задаваць тымліду ці калегам.
- Калі распрацоўніку не зразумелая сутнасць задачы, а заказчык не змог тлумачальна яе растлумачыць, то ён прыступае да наступнай задачы. А бягучую забірае тымлід і сам абмяркоўвае яе з замоўцам.
- Кожны дзень распрацоўшчык павінен у чаце кліента пісаць аб тым, над якімі задачамі ён працаваў учора і над якімі задачамі будзе працаваць сёння
- Працоўны працэс адбываецца па скраме. Усё разбіта на спрынты. Кожны спрынт доўжыцца два тыдні.
- Спрынты стварае, напаўняе і закрывае тымлід.
- Калі праект мае строгія дэдлайны, то імкнемся прыкладна заэстымейціць усе цягі. І збіраем з іх спрынт. Калі заказчык спрабуе ў спрынт дадаць яшчэ задачы, то мы тады выстаўляем прыярытэты, і нейкія іншыя задачы пераносім на наступны спрынт.
б) Працэс працы з заказчыкам
- Кожны распрацоўшчык можа і павінен камунікаваць з заказчыкам
- Нельга замоўцу дазваляць навязваць свае правілы гульні. Трэба ў ветлівай і прыязнай манеры даць зразумець замоўцу, што мы адмыслоўцы ў сваёй справе, і толькі мы павінны выбудоўваць працэсы працы і залучаць у іх замоўца
- Неабходна, у ідэале, перш чым прыступаць да рэалізацыі якога-небудзь функцыяналу, стварыць блок-схему ўсяго лагічнага працэсу для фічы (воркфлоў). І адправіць яе на пацверджанне заказчыку. Гэта датычыцца толькі складанага і не відавочнага функцыяналу, напрыклад, плацежная сістэма, сістэма апавяшчэнняў і г.д. Гэта дазволіць больш дакладна зразумець, што менавіта трэба замоўцу, захаваць дакументацыю да фічы, а таксама застрахаваць сябе ад таго, што замоўца можа ў будучыні сказаць, што мы зрабілі не тое, што ён прасіў.
- Усе дыяграмы/блок-схемы/логіку і г.д. мы захоўваем у Канфлюенсе/Жыры, дзе просім заказчыка ў каментарах пацвердзіць правільнасць будучай рэалізацыі.
- Мы стараемся не грузіць заказчыка тэхнічнымі падрабязнасцямі. Калі нам трэба разуменне таго, як заказчык хоча, то малюем прымітыўныя алгарытмы ў выглядзе блок-схемы, якія заказчык можа зразумець і сам усё выправіць/дапрацаваць.
- Калі заказчык знаходзіць баг у праекце, то мы просім вельмі падрабязна распісаць яго ў Тлушчы. Пры якіх абставінах ён адбыўся, калі, якую паслядоўнасць дзеянняў ажыццяўляў заказчык пры тэсціраванні. Просім прымацоўваць скрыншоты.
- Мы стараемся кожны дзень, максімум праз дзень рабіць дэплой на дзеў сервер. Заказчык тады пачынае тэсціраваць функцыянал і праект не прастойвае. Пры гэтым гэта з'яўляецца маркерам для заказчыка, што праект знаходзіцца ў поўнай распрацоўцы і ніхто не расказвае яму казкі.
- Вельмі часта бывае так, што заказчык не да канца разумее, што яму ўвогуле трэба. Бо стварае новы для сябе бізнэс, з яшчэ не адладжанымі працэсамі. Таму вельмі частым выпадкам бывае сітуацыя, калі мы выкідваем у сметнік цэлыя кавалкі кода і перакройваем логіку прыкладання. З гэтага выцякае, што не варта абсалютна ўсё пакрываць цестамі. Ёсць сэнс пакрываць тэстамі толькі крытычна важны функцыянал і тое з агаворкамі.
- Бываюць сітуацыі, калі каманда разумее, што мы не ўпісваемся ў дэдлайн. Тады мы праводзім хуткі аўдыт па задачах, і тут жа паведамляем пра гэта замоўцу. У якасці выхаду з сітуацыі мы прапануем запускаць у тэрмін важны і крытычны функцыянал, а астатняе пакінуць на пострэліз.
- Калі замовец пачынае прыдумляць розныя задачы з галавы, пачынае фантазіраваць і тлумачыць на пальцах, то мы просім яго падаць нам макет старонкі і флоу з логікай, якая павінна цалкам апісаць паводзіны ўсяго макета і яго элементаў.
- Перад тым, як узяць у працу любую задачу, мы павінны пераканацца, што гэтая фіча ўваходзіла ва ўмовы нашай дамовы/кантракту. Калі гэта новая фіча, якая выходзіць за межы нашых першапачатковых дамоўленасцей, то мы абавязкова павінны заэстимейтить гэтую фічу ((прыкладны час выканання + 30%) х 2) і паказаць заказчыку, што ў нас сыдзе столькі часу на яе, плюс дэдлайн ссоўваецца на час эстымейту памножанае на два. Зробім задачу хутчэй - выдатна, усё, што ад гэтага толькі выйграюць. Калі не, то мы падстрахаваліся.
в) Што мы не прымальны ў камандзе:
- Неабавязковасць, нясабранасць, непамятлівасць
- „Кармленне сняданкамі“. Калі не можаш выканаць задачу, не ведаеш як, то пра гэта трэба тут жа апавяшчаць тымліда, а не чакаць да апошняга.
- Бровады і пахвальбы ад чалавека, які не даказаў яшчэ справай свае магчымасці і прафесіяналізм. Калі даказаў, то можна, у рамках прыстойнасці 🙂
- Падман у любых яго праявах. Калі задача не выканана, то не варта мяняць яе статус на выкананую і пісаць у чаце кліента, што яна гатова. Зламаўся кампутар, зляцела сістэма, сабака пагрыз наўтбук - усё гэта недапушчальна. Калі адбываецца рэальны форс-мажор, то тымлід тут жа павінен быць апавешчаны.
- Калі спецыяліст увесь час у афлайне і да яго складана дагрукацца ў працоўны час.
- Таксічнасць у камандзе не дапускаецца! Калі нехта з нечым не згодны, то ўсе разам збіраюцца на мітынг і гэта абмяркоўваюць і вырашаюць.
І яшчэ шэраг пытанняў/тэзісаў, якія я часам задаю свайму замоўцу, каб зняць усе непаразуменні:
- Якія ў вас крытэры якасці?
- Як вы вызначаеце ці ёсць у праекце праблемы ці не?
- Парушаючы ўсе нашы рэкамендацыі і парады па змене/паляпшэнні сістэмы, усе рызыкі нясеце толькі вы
- Любыя мажорныя змены праекту (напрыклад, разнастайныя экста флоу) будуць прыводзіць да магчымага з'яўлення багаў (якія мы будзем, натуральна, фіксаваць).
- Немагчыма на працягу пары хвілін зразумець, што за праблема адбылася на праекце, а тым больш тут жа яе пафіксіць
- Мы працуем па канкрэтным прадукт флоу (Таскі ў Тлушчу - Распрацоўка - Тэставанне - Дэплой). А значыць, мы не можа рэагаваць на ўвесь паток просьбаў і скаргаў у чаце.
- Праграмісты з'яўляюцца менавіта праграмістамі, а не прафесійнымі тэсціроўшчыкамі, і не могуць забяспечыць належную якасць тэсціравання праекта
- Адказнасць за канчатковае тэсціраванне і прыём задач на продзе ляжыць цалкам на вас
- Калі мы ўжо ўзялі ў працу задачу, то не можам адразу ж перамыкацца на іншыя, пакуль не даробім бягучую (інакш гэта прыводзіць да яшчэ большых багаў і павелічэнню часу распрацоўкі)
- Людзей у камандзе стала менш (па прычыне водпускаў ці хвароб), а працы стала больш і мы фізічна не паспеем рэагаваць на ўсё, што вы хочаце
- Просьба з вашага боку зрабіць дэплой на харчаванне без пратэставаных задач на панне - гэта толькі вашыя рызыкі, а не распрацоўнікаў
- Калі вы ставіце невыразныя задачы, без карэктнага флоу, без макетаў дызайну, тое гэта патрабуе ад нас нашмат вялікіх высілкаў і тэрмінаў рэалізацыі, бо нам замест вас прыходзіцца рабіць дадатковы аб'ём працы
- Любыя цягі па багах, без дэталёвага апісання іх узнікнення і скрыншотаў, не даюць нам магчымасці зразумець, што пайшло не так, і як нам семітаваць гэты баг
- Праект патрабуе пастаяннай дапрацоўкі і паляпшэнняў для павышэння прадукцыйнасці і бяспекі. Таму каманда марнуе частку свайго часу на гэтыя паляпшэнні.
- З прычыны таго, што ў нас бываюць перапрацоўкі па гадзінах (тэрміновыя фіксы), то мы павінны іх кампенсаваць у іншыя дні.
Як правіла, замовец адразу разумее, што не так усё проста ў распрацоўцы софту, і аднаго жадання тут відавочна нядосыць.
Увогуле, гэта ўсё. За кадрам пакідаю мноства перамоваў і першапачатковую адладку ўсіх працэсаў, але ў выніку ўсё наладзілася. Магу сказаць, што гэты працэс стаў для нас нейкай "Сярэбранай куляй". Новыя людзі, якія прыходзілі ў праект, маглі ўжо адразу ўпрагацца ў працу з першага дня, бо ўсе працэсы апісаны, а дакументацыя і архітэктура ў выглядзе дыяграм адразу давала ўяўленне аб тым, чым мы тут усё займаемся.
PS Хачу ўдакладніць, што на нашым баку проджект мэнэджара няма. Ён ёсць на баку заказчыка. Зусім не тэхнар. Праект еўрапейскі. Уся камунікацыя толькі на англійскай.
Усім удачы на праектах. Не выгарайце і паспрабуйце паляпшаць свае працэсы.
Зыходнік у маім .
Крыніца: habr.com