Усім прывітанне, мяне клічуць Канстанцін Кузняцоў, я – генеральны дырэктар і заснавальнік кампаніі RocketSales. У IT-сферы даволі часта сустракаецца гісторыя, калі аддзел распрацоўкі жыве ў сваім сусвеце. У гэтым сусвеце ёсць увільгатняльнікі паветра на кожным працоўным стале, куча гаджэтаў і клінераў для манітораў і клавіятур і, хутчэй за ўсё, свая сістэма кіравання задачамі і праектамі.
Што ў гэтым такога?
Магчыма, для кагосьці - нічога. Але мы сутыкнуліся з праблемай. Мы займаемся пабудовай і аўтаматызацыяй сістэм продажаў, укараняем CRM, ствараем хмарную інфраструктуру для бізнесу. У кліенцкія праекты апроч аддзелаў распрацоўкі і вытворчасці часта ўключаюцца маркетолагі, прадаўцы, бухгалтар, іншыя супрацоўнікі. І мы пачалі думаць, як арганізаваць эфектыўны працэс кіравання праектамі.
Калі працэс распрацоўкі і вытворчасці арганізаваны ў платформе тыпу Jira ці GitLab, то ніхто, акрамя распрацоўкі, не разумее, што там да чаго. Каб падключыць да праекту іншага супрацоўніка, з ім трэба сустрэцца, растлумачыць кантэкст, недзе зафіксаваць задачу, потым кантраляваць ступень гатоўнасці ў працоўных чатах, праз чат жа атрымаць вынік, унесці ў Jira. І так кожны раз.
Распрацоўка адрэзана ад іншых аддзелаў кампаніі, яны не ведаюць, як прыцягнуць нас, а мы не ведаем, ці патрэбны ім наш удзел.
Пару гадоў таму мы адкрылі для сябе платформу Asana. У гэтым матэрыяле я хачу расказаць, як мы арганізавалі працэс кіравання распрацоўкай і вытворчасцю, каб:
- уся кампанія працавала ў адзінай экасістэме,
- усім хапала функцыяналу,
- можна было ацэньваць кошт кожнага праекту ў гадзінах і грошах,
- праца з кліентамі была доўгатэрміновай: не ў рамках адной задачы, а ў рамках цэлага праекта з пастаянным бэклогам ідэй.
Трохі аб знаёмстве з Asana
На пошук зручнага софту для праектнага кіравання я патраціў 10 гадоў. Trello, Jira, Планфікс, Мегаплан, Битрикс24 і дзясяткі іншых таск-трэкераў не прайшлі тэст на трываласць. Потым я знайшоў Asana. І ўсё склалася.
На наш погляд, гэта лепшая і самая хутка якая развіваецца платформа для кіравання задачамі і праектамі. Сёння Asana з'яўляецца сусветным лідэрам па папулярнасці і задаволенасці карыстальнікаў. Пра гэта сведчыць графік рэйтынгу g2.
Мы фанаты Asana, нават прайшлі сертыфікацыю, каб мець магчымасць укараняць яе кліентам.
Коратка апішу працэс ад продажу да рэалізацыі праекту
Так як мы прадаем IT-паслугі, варонка ў нас даволі доўгая і, бліжэй да канца, яна заходзіць у аддзел вытворчасці і, часам, распрацоўкі.
Аддзел продажаў праводзіць стандартныя маніпуляцыі: аўдыт, узгадненне КП, падпісанне дамовы, перадача ўгоды ў вытворчасць. Вытворчасць можа не прыняць дамову: у ёй абавязкова павінны быць указаны бюджэт, дата перадачы ў вытворчасць, разліковы фонд часу на рэалізацыю праекта.
Дзякуючы звязку amoCRM + Asana, пры перадачы здзелкі з аддзела продажаў у вытворчасць і назад, праца нідзе не перарываецца. Блакітным колерам пазначана зона адказнасці аддзела продажаў, аранжавым - аддзела вытворчасці, ружовым - аддзела распрацоўкі.
Важна, што аддзел распрацоўкі, у адрозненне ад праектнага аддзела, удзельнічае не ў кожным праекце. Часам настройка сістэмы не патрабуе кастамных рашэнняў.
Такім чынам, калі кіраўнік прыняў праект у вытворчасць, мэнэджар па продажах у 1 клік пераходзіць у Asana (скрыншот). З amoCRM праект аўтаматычна ствараецца ў Asana.
Таск (задача) з картай праекта, камерцыйнымі прапановамі аўтаматычна ствараецца на агульнай дошцы праектаў кліентаў. Тут адлюстроўваюцца ўсе кліенты, якія зараз знаходзяцца ў вытворчасці. Тут прызначаецца адказны мэнэджар, ставяцца дэдлайны, выбіраецца тып працы і змяняюцца статуты задач.
Мэнэджар можа запусціць у задачы любы з прапанаваных аўтаматычных бізнес-працэсаў:
- Знайсці/Стварыць праект Кліента + Прымацаваць туды задачу
- Запоўніць задачу інфармацыяй па здзелцы
- Стварыць здзелку з бягучай задачы
Праект запаўняецца ўсімі дадзенымі, указанымі ў amoCRM. У залежнасці ад тыпу паслуг адразу ствараецца набор падзадач для рэалізацыі актуальных блокаў прац. Мэнэджару праекту застаецца дэкампазіраваць дэталёвыя задачы, расставіць адказных і дэдлайны.
Гэтая дошка дапамагае прымаць новыя праекты ў працу. Але кантраляваць на ёй актуальныя статусы і наяўнасць праектаў у зоне рызыкі - няёмка.
Як мы групуем задачы і праекты кліентаў
З агульнай дошкі ўсіх праектаў менеджэр дадае праект яшчэ на 3 дошкі:
- персанальная дошка кліента;
- партфель актыўных кліентаў;
- партфель мэнэджэра.
Разбярэмся, для чаго нам кожная з сутнасцяў.
На скрыншоце вы бачыце персанальную дошку кліента.
Нашто гэтая дошка?
Раней мы думалі задачамі. Зрабіў задачу, пайшоў рабіць іншую. Атрымлівалася, што мы робім для кліента роўна той аб'ём работ, які ён папрасіў. Але мы хацелі будаваць доўгатэрміновыя адносіны, таму адышлі ад працы з задачамі ў працу з кліентамі.
Мы абавязкова запісваем усе ідэі па дапрацоўкам для кліента. Нават калі гэта думка, выпадкова кінутая кліентам у паветра, фіксуем і дабіваем. Так фарміруецца бэклог задач, праца з кліентам не заканчваецца.
Што ёсць на гэтай дошцы?
Наша Asana звязана з некалькімі сэрвісамі:
- CRM-сістэма (для ўзаемадзеяння з аддзелам продажаў),
- TimeDoctor (для ўліку часу),
- ERP-сістэма (для агрэгацыі ўсіх дадзеных у адзіным інтэрфейсе).
Мы вывелі ў Asana панэль хуткага кантролю рэсурсаў. Наводзіш на плашачку над задачай і бачыш, хто і колькі працаваў над задачай, якую прэмію зарабіў.
Праца аддзела вытворчасці ацэньваецца па гадзінах, таму нам было важна строга адсочваць, колькі часу пайшло ў кожнага супрацоўніка на вырашэнне задач кліента.
Што дае выкарыстанне дошкі?
У выніку ў ERP-сістэме мы бачым Справаздача па праектах. Статус здзелкі, удзельнікі праекта, бюджэт на праект, колькасць адпрацаваных гадзін і тэрміны.
Мы можам прагназаваць кошт аналагічных праектаў па распрацоўцы, падлік KPI становіцца абсалютна празрыстым і не застаецца месца ілюзіям, што распрацоўка - гэта ўсяго пару гадзін. Пры неабходнасці ў нас заўсёды ёсць інтэрфейс, які мы можам паказаць кліенту для справаздачнасці.
Партфелі Asana
Гэтая функцыянальнасць рэалізаваная ў Asana ужо даўно. Але мы не адразу яе ацанілі. Спачатку мы проста сабралі ў партфелі ўсе праекты нашых мэнэджэраў. Аказалася, што за час працы ў кампаніі Дзяніс Кісялёў папрацаваў з 61 кліентам.
Ведаць гэта прыкольна, але нядосыць, каб апраўдваць выдаткаваны на збор час. І мы забілі на партфелі. Усё змянілася, калі мы прыраўнялі праект у Asana да адной угоды ў CRM-сістэме.
Раней кіраўнік падпісваўся на ўсе праекты і атрымліваў апавяшчэнні па ўсіх зменах у Inbox (стужку апавяшчэнняў). Кожнае абнаўленне статусу, новы каментар адлюстроўваліся ў стужцы, пачынаючы з самага новага. У панядзелак кіраўнік садзіўся і выконваў задачы з інбокса паслядоўна. Аб прыярытэтах гаворкі не ішло, да важных задач часам не даходзілі рукі.
Цяпер ёсць партфель супрацоўніка і партфель праектнага аддзела. У першым мэнэджар кіруе сваімі праектамі, другі дае кіраўніку кантралюючы функцыянал па бягучай загружанасці ўсіх супрацоўнікаў.
Партфель праектнага аддзела
На скрыншоце вы бачыце адсартаваныя па супрацоўніках праекты.
Раз на тыдзень праектны мэнэджар абнаўляе статут кожнага праекту. Піша, што было зроблена за мінулы тыдзень і што плянуецца на наступным. Усталёўвае адзін з трох тэгаў: пад кантролем, у зоне рызыкі, ёсць праблемы.
Кіраўнік хутка можа ацаніць:
- бягучы аб'ём кліентаў у праектным аддзеле,
- колькасць праектаў у працы ў кожнага мэнэджэра,
- колькасць пратэрмінаваных задач па праектах,
- наяўнасць праблем і запатрабаванні ўключыцца ў праекты,
- дэдлайны праектаў, затрачаны час, этап варонкі і прыярытэтнасць праекта.
Партфелі таксама дапамагаюць нам складаць справаздачнасць. Пасля абнаўлення статуту праекту, справаздача аб праведзенай і запланаванай працы аўтаматычна адпраўляецца ў чат з кліентам.
Партфель супрацоўніка
Уласны партфель ёсць нават у кіраўніка праектнага аддзела. Калі, цьфу-цьфу-цьфу, ён здыме з сябе паўнамоцтвы, новы чалавек убачыць усе падкантрольныя праекты, якія ён павінен працягваць адсочваць.
Лінейныя супрацоўнікі таксама ацанілі зручнасць планавання нагрузкі ў партфелі. У табе "Нагрузка" Asana аналізуе аб'ём задач з улікам дэдлайнаў і папярэджвае, калі супрацоўнік запланаваў непад'ёмны аб'ём задач. Змяняць дэдлайн і карэктаваць дэталі можна не сыходзячы з гэтай укладкі.
Рашэнне багаў і кастамная распрацоўка
Асобная каманда адказвае ў нас за распрацоўку. Да яе ў рамках бізнэс-працэсу паступаюць задачы двух тыпаў:
- баг,
- новая распрацоўка.
Багі правярае, ацэньвае на крытычнасць і перадае ў працу служба тэхпадтрымкі.
Задачы на распрацоўку паступаюць альбо з бэклогу па ўнутраных прадуктах кампаніі, альбо ад праектнага мэнэджара пры наяўнасці адпаведнага запыту ад кліента.
Працэс распрацоўкі, у цэлым, выглядае так.
Задачы падаюць на дошку распрацоўкі ў Asana. Вось яна.
Пастаноўшчык задачы выбірае тып "Баг" ці "Фіча", устанаўлівае ступень крытычнасці, паказвае заказчыка, унутраныя аддзелы кампаніі, якія закранае задача. Калі задача адпавядае ўсім патрабаванням унутранага рэгламенту, пастаноўшчык націскае на значок маланкі ў верхняй панэлі над задачай і запускае аўтаматычны бізнес-працэс "Ацаніць у распрацоўцы".
Кіраўнік аддзела распрацоўкі атрымлівае апавяшчэнне аб новай задачы на адзнаку, сама задача на час адзнакі перамяшчаецца на асобную аднайменную дошку.
Пасля ацэнкі кіраўнік перамяшчае задачу ў спрынт, які адпавядае месяцу запланаванага завяршэння. Задачы заўсёды знаходзяцца на некалькіх дошках адначасова:
- на асабістай дошцы праектнага менеджэра,
- на дошцы тэхпадтрымкі,
- на дошцы распрацоўкі.
Усе ўдзельнікі і кантралюючыя задачу супрацоўнікі бачаць прагрэс выканання, атрымліваюць апавяшчэнні, вядуць абмеркаванне прама ў каментарах да задачы. Калі задача выканана - праектны менеджэр або адказны спецыяліст тэхпадтрымкі "забіраюць" яе на свой бок, каб працягнуць працу ў праекце.
Што атрымалася, калі мы вярнулі аддзелы распрацоўкі і вытворчасці ў адзіную сераду з камандай?
Па-першае, кліенцкія праекты сталі больш доўгатэрміновымі. За кошт пастаянна папаўняецца бэклог вырас сярэдні чэк.
Па-другое, якасць праектаў моцна палепшылася, бо аддзел распрацоўкі ў любым момант мог задаць пытанне маркетынгу, продажам, акаўнтынгу і г.д. Мы атрымалі магчымасць у час падключаць патрэбныя кампетэнцыі каманды і прапаноўваць рашэнні зусім іншага ўзроўню.
Па-трэцяе, і супрацоўнікі, і кіраўнікі, і кліенты атрымалі поўную празрыстасць у запланаваных і выкананых задачах. Мы навучыліся КІРАВАЦЬ праектамі, усвядомілі, што гэта абсалютна тэхнічны працэс, з якога можна амаль цалкам выключыць чалавечы фактар.
Па-чацвёртае, каманда стала больш згуртаванай. Раней супрацоўнікі слаба ўяўлялі, чым займаюцца міфічныя аддзелы распрацоўкі і вытворчасці.
Зараз, бачачы працэс распрацоўкі і тэхнічнай наладкі сістэм:
- аддзел продажаў знаходзіць у ім ідэі і натхненне, як прадаваць,
- маркетолагі рэгулярна бяруць карысны кантэнт для пастоў, артыкулаў, пазіцыянавання і рэкламных тэкстаў,
- кіраўнікі аналізуюць патрэбнасці і паводзіны кліентаў, карэктуючы стратэгію.
Атрымалася win-win-win трансфармацыя, у якой выйгралі і мы, і кліенты, і нашыя партнёры. Буду рады, калі вы падзеліцеся меркаваннем у каментарах: ці было нешта карыснае ў маім артыкуле і якія метады кіравання праектамі вы выкарыстоўваеце ў распрацоўцы!
Крыніца: habr.com