Здравейте, казвам се Константин Кузнецов, аз съм главен изпълнителен директор и основател на компанията RocketSales. В ИТ сферата доста често се среща историята, когато отделът за разработка живее в собствената си вселена. В тази вселена има овлажнители на въздуха на всяко работно място, купчинa джаджи и почистващи средства за монитори и клавиатури и, най-вероятно, собствена система за управление на задачи и проекти.
Какво толкова?
Може би за някого — нищо. Но ние се сблъскахме с проблем. Занимаваме се с изграждане и автоматизация на продажбени системи, внедряваме CRM, създаваме облачна инфраструктура за бизнеса. В клиентските проекти, освен отделите за разработка и производство, често участват маркетолози, търговци, счетоводители и други служители. И започнахме да мислим как да организираме ефективен процес на управление на проектите.
Ако процесът на разработка и производство е организиран в платформа като Jira или GitLab, то никой освен разработките не разбира какво се случва там. За да се включи външен служител в проекта, трябва да се срещне с него, да му обясни контекста, да запише задачата някъде, след това да контролира степента на готовност в работните чатове, чрез чата да получи резултата и да го въведе в Jira. И така всеки път.
Разработката е изолирана от другите отдели на компанията, те не знаят как да ни включат, а ние не знаем дали им е нужно нашето участие.
Преди две години открихме платформата Asana. В този материал искам да разкажа как организирахме процеса на управление на разработката и производството, за да:
- цялата компания работи в единна екосистема,
- на всички стига функционалност,
- може да се оценява разходът на всеки проект в часове и пари,
- работата с клиентите да бъде дългосрочна: не в рамките на една задача, а в рамките на цял проект с постоянно течение на идеи в бэклога.
Няколко думи за запознанството с Asana
На търсенето на удобен софтуер за управление на проекти ми отне 10 години. Trello, Jira, Планфикс, Мегаплан, Битрикс24 и десетки други таск-трекера не издържаха теста за устойчивост. После намерих Asana. И всичко се нареди.
Според нас, това е най-добрата и най-бързо развиваща се платформа за управление на задачи и проекти. Днес Asana е световен лидер по популярност и удовлетвореност на потребителите. За това свидетелства графикът на рейтинга g2.
Ние сме фенове на Asana, дори преминахме сертификация, за да можем да я внедряваме на нашите клиенти.
Кратко ще опиша процеса от продажба до изпълнение на проекта
Тъй като продаваме IT услуги, воронката ни е доста дълга и, към края, преминава през производствения отдел и, понякога, отдела за разработка.
Отделът за продажби извършва стандартни манипулации: одит, съгласуване на КП, подписване на договора, предаване на сделката на производството. Производството може да не приеме договора: в него задължително трябва да бъдат посочени бюджет, дата на предаване за производство, изчислителен фонд време за изпълнение на проекта.
Благодарение на комбинацията amoCRM + Asana, при прехвърляне на сделката от отдела за продажби в производството и обратно, работата не прекъсва никъде. В синьо е обозначена зоната на отговорност на отдела за продажби, в оранжево — на производствения отдел, в розово — на отдела за разработка.
Важно е, че отделът за разработка, за разлика от проектния отдел, не участва във всеки проект. Понякога настройката на системата не изисква персонализирани решения.
И така, когато ръководителят приеме проекта за производство, мениджърът по продажби с едно щракване преминава в Asana (екранна снимка). От amoCRM проектът автоматично се създава в Asana.
Таск (задача) с картата на проекта, търговските предложения автоматично се създават на общата дъска на проектите на клиентите. Тук се показват всички клиенти, които в момента са в производство. Тук се назначава отговорен мениджър, определят се крайни срокове, избира се тип работа и се променят статусите на задачите.
Мениджърът може да стартира в задачата всеки от предложените автоматични бизнес процеси:
- Намери/Създай проект на клиента + Прикачи там задача
- Попълни задачата с информация относно сделката
- Създай сделка от текущата задача
Проектът се попълва с всички данни, посочени в amoCRM. В зависимост от типа услуги, незабавно се създава набор от подзадачи за изпълнение на актуалните блокове работи. На мениджъра на проекта остава да декомпозира детайлните задачи, да разпредели отговорни и крайни срокове.
Тази дъска помага за приемането на нови проекти за работа. Но е неудобно да се контролира актуалният статус и наличието на проекти в риск на нея.
Как групираме задачите и проектите на клиентите
От общата дъска на всички проекти мениджърът добавя проекта на още 3 дъски:
- персонална дъска на клиента;
- портфейл на активни клиенти;
- портфейл на мениджър.
Нека разберем, за какво ни е всяка от субектите.
На екрана виждате персонална дъска на клиента.
Защо е тази дъска?
По-рано мислехме в задачи. Направих задача, продължих с друга. Оказваше се, че работим за клиента точно на онези обеми, които той е поискал. Но искахме да изградим дългосрочни отношения, затова се отказахме от работа с задачи и преминахме на работа с клиенти.
Задължително записваме всички идеи за подобрения за клиента. Дори и ако това е мисъл, случайно подхвърлена от клиента, я записваме и реализираме. Така се формира беклог на задачи, работата с клиента не свършва.
Какво има на тази дъска?
Нашата Asana е свързана с няколко услуги:
- CRM система (за взаимодействие с отдела по продажби),
- TimeDoctor (за отчитане на времето),
- ERP система (за агрегиране на всички данни в един интерфейс).
В Asana изведохме панел за бърз контрол на ресурсите. Навеждате курсора върху панела над задачата и виждате кой и колко време е работил по задачата, каква премия е спечелил.
Работата на производствения отдел се оценява по часове, затова беше важно да следим стриктно колко време е похарчил всеки служител за решаване на задачите на клиента.
Какво получаваме от използването на дъската?
В крайна сметка в ERP системата виждаме Отчет по проектите. Статус на сделката, участниците в проекта, бюджетът на проекта, броят на отработените часове и сроковете.
Можем да прогнозираме цената на аналогични проекти по разработка, изчисляването на KPI става абсолютно прозрачно и няма място за илюзии, че разработката е само няколко часа. При необходимост, винаги имаме интерфейс, който можем да покажем на клиента за отчетност.
Портфейли в Asana
Тази функционалност е реализирана в Asana отдавна. Но ние не я оценихме веднага. Първоначално просто събрахме в портфейли всички проекти на нашите мениджъри. Оказа се, че за времето на работа в компанията Денис Киселев е работил с 61 клиента.
Да знаеш това е готино, но не е достатъчно, за да оправдае времето, прекарано в събиране. И ние загубихме интерес към портфейлите. Всичко се промени, когато свързахме проект в Asana с една сделка в CRM системата.
По-рано ръководителят подписваше на всички проекти и получаваше уведомления за всички изменения в Inbox (потока от известия). Всяка актуализация на статуса, нов коментар се показваше в потока, започвайки от най-новите. В понеделник ръководителят седеше и последователно изпълняваше задачите от инбокса. За приоритетите не се говореше, понякога не достигаше време дори за важните задачи.
Сега има портфейл на служителя и портфейл на проектния отдел. В първия мениджърът управлява своите проекти, вторият дава на ръководителя контролната функционалност за текущото натоварване на всички служители.
Портфейл на проектния отдел
На екрана виждате проектите, сортирани по служители.
Веднъж седмично проектният мениджър актуализира статуса на всеки проект. Пише какво е направено за изминалата седмица и какво се планира за следващата. Установява един от трите тагове: под контрол, в риск, има проблеми.
Ръководителят бързо може да оцени:
- текущия обем клиенти в проектния отдел,
- броя на проектите в работа при всеки мениджър,
- числото на просрочените задачи по проектите,
- наличието на проблеми и нуждата от включване в проекти,
- дедлайните на проектите, изразходваното време, етапа на воронката и приоритетността на проекта.
Портфейлите също така ни помагат да съставяме отчети. След обновяване на статуса на проекта, отчетът за извършената и планираната работа автоматично се изпраща в чата с клиента.
Портфейл на служителя
Собствен портфейл има дори и ръководителят на проектния отдел. Ако, чук-чук-чук, той свали от себе си пълномощията, новият човек ще види всички проекти под контрол, които трябва да продължи да следи.
Линейните служители също оцениха удобството на планирането на натоварването в портфейла. В таба "Натоварване" Asana анализира обема на задачите с оглед на дедлайните и предупреди, ако служителят е планирал непосилен обем задачи. Промяната на дедлайните и коригиране на детайлите може да става без да напускате тази вкладка.
Решаване на бъгове и кастомна разработка
Отделен екип отговаря за разработката. Към него в рамките на бизнес процеса постъпват задачи от два типа:
- бъг,
- нова разработка.
Бъговете се проверяват, оценяват за критичност и се предават за работа на техническите специалисти.
Задачите за разработка постъпват или от беклога на вътрешните продукти на компанията, или от проектния мениджър при наличие на съответстваща заявка от клиента.
Процесът на разработка изглежда така.
Задачите попадат на дъската за разработка в Asana. Ето я.
Постановчикът на задачата избира тип “Баг” или “Фичa”, определя степента на критичност, посочва клиента и вътрешните отдели на компанията, които засягат задачата. Когато задачата отговаря на всички изисквания на вътрешния регламент, постановчикът натиска иконата на мълнията в горната част на задачата и стартира автоматизирания бизнес процес “Оценка в разработка”.
Ръководителят на отдела за разработка получава известие за нова задача за оценка, а самата задача временно се премества на отделна дъска с името “Оценка”.
След оценката ръководителят премества задачата в спринт, съответстващ на месецa на планирано завършване. Задачите винаги се намират на няколко дъски наведнъж:
- на личната дъска на проектния мениджър,
- на дъската за техническа поддръжка,
- на дъската за разработка.
Всички участници и контролиращите задачата служители виждат напредъка в изпълнението, получават известия, водят обсъждане директно в коментарите на задачата. Когато задачата е изпълнена — проектният мениджър или отговорният специалист по техническа поддръжка “прибира” задачата на своя страна, за да продължи работата по проекта.
Какво се случи, когато върнахме отделите за разработка и производство в единна среда с екипа?
Първо, клиентските проекти станаха по-дългосрочни. Поради постоянно обновявания беклог средният чек нарасна.
На второ място, качеството на проектите значително се подобри, тъй като отделът за разработка по всяко време можеше да зададе въпрос на маркетинга, продажбите, счетоводството и т.н. Получихме възможност навреме да включваме нужните компетенции на екипа и да предлагаме решения на съвсем различно ниво.
На трето място, и служителите, и ръководителите, и клиентите получиха пълна прозрачност в планираните и изпълнени задачи. Научихме се да УПРАВЛЯВАНЕ проектите, осъзнахме, че това е абсолютно технически процес, от който практически изцяло може да се изключи човешкият фактор.
На четвърто място, екипът стана по-сработен. По-рано служителите слабо разбираха какво правят митичните отдели за разработка и производство.
Сега, виждайки процеса на разработка и техническа настройка на системите:
- отделът по продажбите намира идеи и вдъхновение за продажба,
- маркетолозите редовно извличат полезно съдържание за публикации, статии, позициониране и рекламни текстове,
- мениджърите анализират нуждите и поведението на клиентите, коригирайки стратегията.
Станахме свидетели на win-win-win трансформация, в която спечелиха и ние, и клиентите, и нашите партньори. Ще се радвам, ако споделите своето мнение в коментарите: имаше ли нещо полезно в моята статия и какви методи за управление на проекти използвате в разработката!
Източник: habr.com
