— Сергей, ты не HR в традиционном смысле. Расскажи про свой опыт, откуда ты набрался идей, как оценивать команды? Как относишься к стартапам и почему решил сделать методологию?
Мой основной опыт работы в IT — работа проектным менеджером. Управление проектом эквивалентно управлению командой, потому что мы работаем с людьми и их компетенциями. Таким образом, работая в этой сфере многие годы я накопил определенную компетенцию и понимание того, как должна быть устроена команда изнутри для достижения успеха.
Если мы берем классические роли по такой методологии как Scrum, то в ней есть три роли:
- Product-owner. Он отвечает за формирование того пути, по которому должен двигаться продукт: составляет техническое задание, детализирует и формулирует бизнес-требования, курирует всё, что связано с продуктом.
- Команда. Технические специалисты, которые имеют экспертизу в реализации нужных задач. Как правило, команда кросс-функциональна, и чем больше в ней компетенций для кросс-функциональности, тем более зрелой и эффективной будет работа такой команды.
- Scrum-мастер. Человек, который находится между product-оунером и командой, помогает product-оунеру реализовывать его идеи с точки зрения эффективного управления командой “в моменте”.
Конечно, управление проектами в IT не заканчивается методологией Scrum: для тяжелых и больших проектов можно вспомнить PRINCE2, RUP, Waterfall, всё, что описывается в книге PMBoK — их очень много. Также есть гибкие: Kanban, Scrum-ban и др.
Но именно Scrum наиболее подходит в IT для проектов,которые созданы в динамично меняющемся окружении: Scrum представляет собой работу без четко прописанного надолго перечня задач и пытается создать процесс, который мог бы в быстро изменяющейся среде максимально быстро менять продукт под потребности меняющегося рынка. Это хорошо подходит стартапу на ранней стадии для поиска своей бизнес-модели. Можно перенести философию Scrum — динамичного поиска решения в нужный момент — на концепцию только что созданного стартапа. И если мы перенесем эти три перечисленные классические для Scrum роли в стартап, очевидно, что стартапу все они будут необходимы.
Когда я стал изучать опыт других акселераторов (в т.ч.и тех, которые присутствуют на белорусском рынке), я понял, что мой подход является довольно общепринятым в индустрии. Новизна моего подхода — в цифровом определении уровня компетентности. Требования к этим определениям выходят за рамки Rocket DAO, потому что проект Rocket DAO стремится уйти от оценочного экспертного суждения за счет внедрения методологий и минимизации человеческого фактора.
Исходя из этих требований, оценка команды происходит по трем направлениям (продукт, бизнес, техническая часть), которые ранжируются по формальным критериям достижений членов команды. Конечно, мы не можем со 100% уверенностью говорить, что человек с теми или иными достижениями обязательно будет успешен в реализации своего стартапа или наоборот, человек без них провалится в разработке и воплощении идеи. Но наличие этих компетенций легко проверить за счет формальных признаков работы человека: его опыта работы, научных работ, уже запущенных проектов, не запущенных (проваленных) проектов. Этот человек может быть студентом и иметь благоприятную социальную среду, если он учится в топовых университетах, которые инновационно открытых и выпускающих перспективные кадры. Или этот человек может быть ученым, который долго работал над какой-то проблемой: в рамках стартапа он будет целиком компетентен в этой проблеме, и закрывает эту потребность. Общее правило лишь одно: чем больше у человека достижений, которые он может документально подтвердить, тем больше опыта он вносит в команду, и команда получает высокую оценку. Соответственно, чем больше человек фантазирует о вещах, в которых не имеет практического опыта, тем больше вероятность, что проект не “взлетит”: техническая реализация проекта подкачает, бизнес-модель, которая не сработает на практике или продуктовое решение не будет решать важных насущных проблем в необходимой области.