Управление на развитието и производството в Asana

Здравейте всички, казвам се Константин Кузнецов, аз съм главен изпълнителен директор и основател на RocketSales. В ИТ сферата има доста често срещана история, когато отделът за развитие живее в своя собствена вселена. В тази вселена има овлажнители на въздуха на всеки работен плот, куп джаджи и почистващи препарати за монитори и клавиатури и най-вероятно собствена система за управление на задачи и проекти.

Каква е голямата работа?

Може би за някои това е нищо. Но се натъкнахме на проблем. Изграждаме и автоматизираме системи за продажби, внедряваме CRM и създаваме облачна инфраструктура за бизнеса. В допълнение към отделите за развитие и производство клиентските проекти често включват търговци, продавачи, счетоводители и други служители. И започнахме да мислим как да организираме ефективен процес на управление на проекти.

Ако процесът на разработка и производство е организиран в платформа като Jira или GitLab, тогава никой освен развитието не разбира какво е какво. За да включите служител на трета страна в проект, трябва да се срещнете с него, да обясните контекста, да запишете задачата някъде, след това да наблюдавате степента на готовност в работни чатове, да получите резултата чрез чата и да го въведете в Jira. И така всеки път.

Развитието е откъснато от другите отдели на компанията, те не знаят как да ни включат и ние не знаем дали имат нужда от нашето участие.

Преди няколко години открихме платформата Asana. В този материал искам да ви разкажа как организирахме процеса на разработване и управление на производството, за да:

• цялата компания работи в една екосистема,
• всеки имаше достатъчно функционалност,
• беше възможно да се оцени цената на всеки проект в часове и пари,
• работата с клиенти беше дългосрочна: не в рамките на една задача, а в рамките на цял проект с постоянно изоставане от идеи.

Малко за опознаването на Асана

Прекарах 10 години в търсене на удобен софтуер за управление на проекти. Trello, Jira, Planfix, Megaplan, Bitrix24 и десетки други програми за проследяване на задачи не преминаха теста за здравина. Тогава намерих Асана. И всичко се получи.

Според нас това е най-добрата и бързо развиваща се платформа за управление на задачи и проекти. Днес Asana е световен лидер по популярност и удовлетвореност на потребителите. Това се доказва от таблицата с рейтинг g2.

Ние сме фенове на Asana, дори се сертифицирахме, за да можем да я прилагаме за нашите клиенти.

Ще опиша накратко процеса от продажбата до реализирането на проекта

Тъй като продаваме ИТ услуги, фунията ни е доста дълга и към края навлиза в производствения, а понякога и в развойния отдел.

Търговският отдел извършва стандартни манипулации: одит, одобрение на CP, подписване на споразумение, прехвърляне на сделката в производство. Производството може да не приеме договора: той трябва да посочи бюджета, датата на прехвърляне към производството и прогнозния фонд за време за изпълнение на проекта.

Благодарение на комбинацията amoCRM + Asana, при прехвърляне на транзакция от отдел продажби към производство и обратно, работата не се прекъсва никъде. Синьото показва зоната на отговорност на отдела по продажбите, оранжевото показва производствения отдел, а розовото показва отдела за развитие.

Важно е отделът за развитие, за разлика от отдела за дизайн, да не участва във всеки проект. Понякога настройката на система не изисква персонализирани решения.

И така, когато мениджърът прие проекта за производство, мениджърът по продажбите отива в Asana с 1 щракване (екранна снимка). От amoCRM проектът се създава автоматично в Asana.

Задача (задача) с карта на проекта и търговски предложения се създава автоматично на общата клиентска дъска на проекта. Тук се показват всички клиенти, които в момента са в производство. Тук се назначава отговорен ръководител, определят се срокове, избира се вида работа и се променят статусите на задачите.

Мениджърът може да стартира всеки от предложените автоматични бизнес процеси в задачата:

1. Намерете/Създайте клиентски проект + Прикачете задача там
2. Попълнете задачата с информация за транзакцията
3. Създайте сделка от текущата задача

Проектът е попълнен с всички данни, посочени в amoCRM. В зависимост от вида на услугата незабавно се създава набор от подзадачи за изпълнение на действителните работни блокове. Ръководителят на проекта остава да разложи детайлни задачи, да разпредели отговорности и срокове.

Тази дъска помага за поемането на нови проекти. Но следенето на текущите състояния и наличието на рискови проекти върху него е неудобно.

Как групираме задачите и проектите на клиентите

От общото табло на всички проекти мениджърът добавя проекта към още 3 табла:

1. лично табло на клиента;
2. портфолио от активни клиенти;
3. портфолио на мениджъра.

Нека да разберем защо имаме нужда от всяко едно от образуванията.

На екранната снимка, която виждате лично табло на клиента.

Защо тази дъска?

Преди мислехме от гледна точка на задачите. Изпълних задачата и отидох да направя друга. Оказа се, че вършим за клиента точно толкова работа, колкото поиска. Но ние искахме да изградим дългосрочни отношения, така че се преместихме от работа със задачи към работа с клиенти.

Задължително записваме всички идеи за подобрения за клиента. Дори да е случайно хвърлена във въздуха мисъл от клиента, ние я поправяме и довършваме. Така се формира изоставане от задачи, работата с клиента не свършва.

Какво има на тази дъска?

Нашата асана е свързана с няколко услуги:

• CRM система (за взаимодействие с търговския отдел),
• TimeDoctor (за проследяване на времето),
• ERP система (за агрегиране на всички данни в един интерфейс).

Въведохме панел за бърз контрол на ресурсите в Asana. Посочвате табелата над задачата и виждате кой е работил по задачата и колко време, и какъв бонус е спечелил.

Работата на производствения отдел се изчислява на час, така че за нас беше важно да следим стриктно колко време отделя всеки служител за решаване на клиентски проблеми.

Какви са ползите от използването на дъска?

В резултат на това в ERP системата виждаме Доклад по проекта. Състояние на сделката, участници в проекта, бюджет на проекта, брой отработени часове и срокове.

Можем да предвидим цената на подобни проекти за разработка, изчисленията на KPI стават абсолютно прозрачни и няма място за илюзии, че разработката отнема само няколко часа. При необходимост винаги разполагаме с интерфейс, който можем да покажем на клиента за отчитане.

Асана Куфарчета

Тази функционалност е внедрена в Asana от дълго време. Но не го оценихме веднага. Първоначално просто събрахме всички проекти на нашите мениджъри в портфейли. Оказа се, че за времето си в компанията Денис Киселев е работил с 61 клиента.

Готино е да се знае, но не достатъчно, за да оправдае времето, прекарано в събирането му. И вкарахме на куфарчета. Всичко се промени, когато приравнихме проект в Asana към една транзакция в CRM системата.

Преди това мениджърът се абонира за всички проекти и получава известия за всички промени във входящата кутия (емисия за известия). Всяка актуализация на състоянието и нов коментар се показват в емисията, като се започне с най-новия. В понеделник мениджърът седна и завърши последователно задачи от входящата кутия. Не се говореше за приоритети, а понякога не се достигаше до важни задачи.

Сега има портфолио на служителите и портфолио на проектния отдел. При първия мениджърът управлява своите проекти, вторият дава на мениджъра контролна функционалност по отношение на текущото натоварване на всички служители.

Портфолио на дизайнерския отдел

На екранната снимка можете да видите проекти, сортирани по служител.

Веднъж седмично ръководителят на проекта актуализира статуса на всеки проект. Пише какво е направено миналата седмица и какво е планирано за следващата седмица. Задава един от три етикета: под контрол, в риск, има проблеми.

Мениджърът може бързо да прецени:

• текущ брой клиенти в дизайнерския отдел,
• брой проекти в работа за всеки мениджър,
• брой просрочени задачи по проекти,
• наличие на проблеми и необходимост от участие в проекти,
• крайни срокове на проекта, изразходвано време, етап на фунията и приоритет на проекта.

Портфейлите също ни помагат при отчитането. След актуализиране на статуса на проекта, отчет за извършената и планирана работа автоматично се изпраща в чата на клиента.

Портфолио на служител

Дори ръководителят на дизайнерския отдел има собствено портфолио. Ако, па-па-па, той премахне властта си, новият човек ще види всички проекти под негов контрол, които трябва да продължи да наблюдава.

Служителите на линията също оцениха удобството на планирането на натоварването в портфолиото. В раздела „Зареждане“ Asana анализира обема на задачите, като взема предвид крайните срокове и предупреждава, ако служителят е планирал прекомерен обем задачи. Можете да промените крайните срокове и да коригирате подробности, без да напускате този раздел.

Разрешаване на грешки и персонализирана разработка

Имаме отделен екип, който отговаря за развитието. Като част от бизнес процес, той получава задачи от два типа:

1. буболечка,
2. ново развитие.

Грешките се проверяват, оценяват за критичност и се прехвърлят на работа от службата за техническа поддръжка.
Задачите за разработка идват или от вътрешното продуктово изоставяне на компанията, или от ръководителя на проекта, ако има съответно искане от клиента.

Процесът на разработка като цяло изглежда така.

Задачите падат върху таблото за развитие в Asana. Ето я.

Директорът на задачата избира типа „Бъг“ или „Характеристика“, задава степента на критичност, посочва клиента и вътрешните отдели на компанията, които задачата засяга. Когато задачата отговаря на всички изисквания на вътрешния правилник, директорът кликва върху иконата със светкавица в горната лента над задачата и стартира автоматичния бизнес процес „Оценка в разработка“.

Ръководителят на отдела за развитие получава известие за нова задача за оценка, а самата задача се премества в отделна дъска със същото име за времето на оценката.

След оценка мениджърът премества задачата към спринт, съответстващ на месеца на планираното завършване. Задачите винаги са на няколко дъски едновременно:

• на личното табло на ръководителя на проекта,
• на борда за техническа поддръжка,
• на таблото за разработка.

Всички участници и служители, наблюдаващи задачата, виждат напредъка на задачата, получават известия и водят дискусии директно в коментарите към задачата. Когато дадена задача е изпълнена, ръководителят на проекта или отговорният специалист по техническа поддръжка я „взема“ на своя страна, за да продължи работата по проекта.

Какво се случи, когато върнахме отделите за разработка и производство в една среда с екипа?

На първо място, клиентските проекти станаха по-дългосрочни. Поради постоянно попълваното изоставане, средната сметка се увеличи.

На второ място, качеството на проектите се подобри значително, тъй като отделът за развитие можеше да задава въпроси на маркетинг, продажби, счетоводство и т.н. по всяко време. Успяхме своевременно да свържем необходимите компетенции на екипа и да предложим решения от съвсем различно ниво.

На трето място, служители, мениджъри и клиенти получиха пълна прозрачност на планираните и изпълнени задачи. Научихме се как да УПРАВЛЯВАМЕ проекти и разбрахме, че това е абсолютно технически процес, от който човешкият фактор може да бъде почти напълно елиминиран.

Четвърто, екипът стана по-сплотен. Преди това служителите нямаха много представа какво правят митичните отдели за развитие и производство.

Сега, виждайки процеса на разработка и техническа конфигурация на системите:

• отделът по продажбите намира в него идеи и вдъхновение как да продава,
• търговците редовно вземат полезно съдържание за публикации, статии, позициониране и рекламни текстове,
• мениджърите анализират нуждите и поведението на клиентите, коригирайки стратегията.

Резултатът беше печеливша и печеливша трансформация, от която ние, нашите клиенти и нашите партньори се възползвахме. Ще се радвам, ако споделите мнението си в коментарите: имаше ли нещо полезно в моята статия и какви методи за управление на проекти използвате в разработката!

Източник: www.habr.com