Большинство владельцев бизнеса знакомы с менеджментом и управлением сотрудниками, хотя бы частично, либо на подсознании. Но что если я скажу Вам, что руководитель может всего лишь поставить перед своими сотрудниками большую задачу, а команда уже сама воплотит всё в жизнь без опазданий и даже самостоятельно устранит все “косяки”, выявленные в ходе действия. А что если такое будет постоянно? Классненько же? Тогда поговорим о Scrum.

Отвечая на Ваш немой вопрос о невозможности такого подхода, ведь мы же в России живем и люди тут так не работают, их только и нужно “пинать”. С уверенностью могу Вам сказать, что такое возможно (далее расскажу подробнее), но для этого в Вашей компании должно быть внедрено всего одно условие. 

Та самая agile-методология (методология гибкого управления проектами), по которой должны работать сотрудники в Вашей организации. Для примера, вспомните Сбербанк всего 5 лет назад. Хамство, ужас и постоянная ругань с бабушками. И всего 5 лет по прошествию и внедрению Германом Грефом идеологии аджайл. Сейчас Сбербанк не узнать. Конечно, осталось еще это “Где карту получали туда и идите”, но… все совершенно по-другому. Однако вернемся к методологии скрам.

Важно. Вначале статьи мы разберём в целом что такое методика Scrum, преимущества и недостатки, а уже потом поговорим о том как его внедрить в обычный микро и малый бизнес. Наш блог всё показывает с практической стороны, и эта статья не исключение.

И снова программисты

Методика Scrum — это технология гибкого управления проектами. Поскольку само понятие довольно сложное, я нашел несколько расшифровывающих его определений, наиболее подходящих для нашего блога (объясняющие сложное простым, человеческим языком). Они же несут в себе основные принципы scrum. Итак:

  1. Scrum — процесс реализации проекта, используя который сотрудники могут решать проблемы, появляющиеся в ходе самой работы над проектом.
  2. Scrum — методология управления, которая позволяет правильно формировать имеющиеся в компании ресурсы и максимально использовать потенциал команды, для получения результата.

От себя хочу еще раз напомнить про аджайл. Если Вы помните, то agile — это не методология, это философия, придуманная 12-ю программистами. То есть общие правила, как должна работать команда и компания для получения результатов. 

Scrum же это именно методология (тоже придуманная программистами, только 2-мя). То есть набор конкретных инструкций (или если называть по-модному — мануал), действуя на основании которых Ваша компания и команда сможет развиться неимоверно.

Почему везде одни программисты? Потому что изначально agile и scrum были придуманы при создании IT-решений (разработка программ). Ведь там процессы сложные и очень долгосрочные, просто так, через “устные приказы” всё не реализовать и система не будет работать как часы. Именно поэтому и сама философия, и прочие методологии (помимо Scrum, есть еще XP или каскадно-водопадные) были заложенны именно ими.

Интересно. Само слово “scrum” было взято из регби. Это когда спортсмены разыгрывают мяч, уперевшись головами друг в друга, направив взгляд вниз. Командная игра, где важен каждый. 
scrum-bolshe-chem-prosto-upravlenie-proektami-regbi

Разберем на части

В методологии скрам разработка проекта разбивается на части, на каждый из которых выделяются определенные временные рамки (все это называется спринтом), по завершении которых, команда, ответственная за свою часть, должна завершить свой подпроект и отчитаться за него. Но не всё так просто, рассмотрим каждый этап.

Спринт

Спринт (у программистов это называется итерация) — это срок, в течении которого команда работает над проектом. Перед началом работы над задачей, все сразу договариваются какой продолжительности будут спринты. Обычно этот срок составляет от одной до 4-х недель. В дальнейшем срок спринта не меняется, пока не будет готов финальный продут.

К примеру, в компании Nokia, ныне почившей, срок спринтов ставился 6 месяцев. У Apple срок спринта редко превышает 3 недели. Может именно в этом успех этой компании.

Чем короче спринт, тем более гибкий процесс разработки проекта, тем быстрее получается обратная связь и тем быстрее можно найти недостатки и внести улучшения.

Перед началом каждого спринта ставится цель, которую должна достичь команда по окончании спринта. В идеале эта цель должна стать мотивирующим фактором для дальнейших спринтов и завершения всего проекта в целом. В течении каждого “забега” проводятся ежедневные совещания (дневные спринты), на которых каждый член команды должен ответить на следующие вопросы:

  1. Что было сделано вчера?
  2. Что я должен сделать сегодня?
  3. Какие у меня были препятствия в работе надо проектом и как их устранить?

Главная задача дневного спринта — это понять в какой ситуации находится команда сейчас и как она близка к завершению работы над проектом в рамках отпущенных им сроков. Длится он не более 15 минут и проводится ежедневно в одно и то же время.

После завершения спринта команда проводит спринт-митинг (совещание по итогам), это аналог большой планёрки в обычной жизни. В результате такой встречи должны появится ответы на два вопроса:

  1. Что мы можем сделать лучше в следующий раз/в следующем “забеге”?
  2. Какие были проблемы в этом спринте?

Именно ответы на эти вопросы сильно помогают улучшить эффективность работы над проектом в последующем. Так как деятельность бизнеса не подразумевает выполнение одноразовых задач по Scrum. Обычно это повторяющиеся процессы, хотя бы близко. Но если Вы хотите делать всё по скраму, даже одноразовые задачи, то спринт-митинг Вам скорее всего уже не нужен.

Команда

Команда, работающая над частью проекта, состоит из семи участников (плюс-минус два человека) разноплановой направленности. То есть в команде могут быть дизайнеры, программисты и даже продажники. Таким образом можно получить гораздо более широкий взгляд на проект и гораздо лучше применить знания каждого.

Количество связано прежде всего с тем, что для работы с большим числом участников требуются большие временные ресурсы, а меньшее количество несет опасность того, что команда (за счет меньшего количества умений) не сможет справится со своей частью проекта за спринт.

Кроме основного плюса, который можно назвать “коллективный разум”, подобная команда обладает дополнительными плюсами и их легко выделить:

  • Функциональность. Как я уже писал, в команде собраны в основном люди различных специальностей. Это могут быть программисты, дизайнеры, продажники и даже бухгалтеры (если проект требует их вмешательства). Это способствует аккумулированию большого числа знаний в команде.
  • Мотивация. Работа в команде влияет на скорость и эффективность достижения высоких целей. Ведь каждый подтягивает друга друга и в какой-то степени вырастает, хоть и дружественная, но конкуренция.
  • Автономность. У проекта нет формального лидера, который всем руководит. Руководитель лишь ставит задачу, а команда (или команды, если их несколько) уже сама решает как лучше ее выполнить, чтобы прийти к желаемому результату.

Работа в команде даёт свои плоды. Но как Вы уже заметили, не у многих представителей малого бизнеса есть такое количество людей, и к тому же не многие бизнесы могут так легко выделить время людей на такого рода задачи. Ведь у нас у всех и так всё под завязку, а тут ещё дополнительные встречи. Но об этом чуть позже.

Роли

А теперь самое необычное, что есть в методологии скрам, что ее отличает от многих. Это роли. Так как в scrum нет руководителей и явных лидеров (это собственно главный принцип agile-методологии), то кто-то должен модерировать работу команды и работу над проектом в целом. И для этого в методе скрам бывают следующие роли:

  1. Владелец продукта;
  2. Скрам-мастер;
  3. Команда-разработки.

Если честно, когда я впервые встретил реализацию аджайл в компаниях и писал статью про аджайл, то она мне очень понравилось тем, что команда общается неформально, в ней нет лидеров и организационной структуры. Однако, есть функции, которые должны выполняться в независимости от панибратства, у нас в России иначе никак. Поэтому давайте поговорим о каждой роли более подробно.

Владелец продукта. Важно, это не заказчик. Это человек из команды, который берет на себя его роль. Его ключевые задачи в проекте:

  • Видение со стороны конечного пользователя итогового продукта;
  • Решения о любых изменениях в проекте;
  • Связь команды и заказчика.

Скрам-мастер. Как и в любом проекте, в скрам есть люди, которые руководят всем проектом. В нашем подходе это скрам-мастер. Его главные задачи в проекте:

  • Контролирование хода всего проекта;
  • Организация спринтов и совещаний;
  • Выявление затыков и их устранение;
  • Доработка продукта до идеального состояния.

О команде-разработки мы уже говорили выше. Напомню, это разношёрстные члены компании, которые помогают выполнять и улучшать проект во время своего спринта. Больше добавить тут нечего.

Инь и Янь

Если задуматься, то каждый подход управления проектами является своеобразным аккумулятором, в котором есть положительная и отрицательная клемма, то есть плюс и минус. И скрам не исключение. Есть преимущества scrum перед, например, каскадно-водопадной методологией управления проектами, но есть и свои недостатки.

Разберем их, чтобы уже точно понимать, стоит ли Вам переходить на такой вид управления проектами (и не побоюсь этой фразы, Вашими сотрудниками) или же оставить это большим компаниям, а Вам поискать что-то попроще, например, Канбан.

Преимущества

Отсутствие бюрократии и довольные сотрудники. Я не покривлю душой, если скажу, что мы одна из самых бюрократичных стран в мире. Этой бюрократией также страдает бизнес и его владельцы. Они ставят на вершину пирамиды бизнес-процессов бумажки и документацию. Но что если поставить на вершину сотрудников. И тогда вместо злых и недовольных, которые вынуждены заполнять бумаги, Вы получите сотрудников, которые рады работать в организации, ценящей их мнение. Скрам позволяет получить таких сотрудников с легкостью.

Готовый идеальный продукт. Помните старый советский анекдот про “тебе шашечки или ехать?”. Если для Вас важнее получить идеальный продукт, чем документацию по его использованию, то это скрам. Apрle до сих пор, начиная с 2007 года, работает именно в таком ключе. Им важнее выпустить совершенный новый гаджет, чем правильную инструкцию к нему. Открою Вам секрет, но у первого iPhone, на момент его презентации Стивом Джобсом в 2007 году, не было полной инструкции и готовой технической документации. Зато был телефон, который перевернул мир. А технические инструкции доделывали уже потом в диком темпе. Но об этом никому, я обещал молчать 😉

Получение обратной связи и продукта, который купят (вытекает из премущества “готовый идеальный продукт”). Я даже не представляю какое должно быть разочарование в душе у клиента, который через 3 года создания проекта не смог стать успешным (хотя бы окупиться). А все потому, что было слепое следование планам, без получения обратной связи в ходе действий. То есть планы просто не меняли всё это время, потому что была цель создать продукт, который все видели в начале пути, без поправок в процессе.

Внутренняя обстановка. Представьте, что у Ваших сотрудников нет начальника, который ежечасно проверяет их работу, кричит на них за малейшие недочеты и постоянно их контролирует. А все это время они занимаются тем, что по-настоящему любят. Их главная задача — не работа “для галочки”, а реализация наилучшим образом задачи. Естественно, их работоспособность и вовлеченность в общий процесс/создание продукта/развитие компании (то, о чем мечтают все собственники) будет в разы выше, чем при стандартном подходе с руководителями и классической организационной структурой.

Экономия. Метод скрам легок в использовании и его, несмотря на заблуждения, могут использовать маленькие компании, в частности стартапы (не только IT характера), у которых нет средств на поиск и найм дорогих и высоко профессиональных руководителей. Ведь всё, что Вам нужно, это понимание как всё устроено и как это реализовать именно у Вас. Дорогостоящее программное обеспечение для этого не обязательно, хотя и желательно.

Недостатки

Звучит это все, конечно, круто и наверное даже фантастически. Столько плюсов. Вы поставили проект и в дальнейшем команда сама работает при минимальном контроле. Но не все так хорошо. Методология скрам имеет и свои минусы.

Команда. Наверное, один из самых главных плюсов и в то же время минусов. Подобрать команду  — самое сложное. Они должны не только сочетаться между собой как профессионалы, но и как обычные люди. Если нет руководителя, то это не говорит о том, что команда будет работать на 146% своего КПД. Требуются затраты (финансовые, временные и моральные) на их сыгранность, обучение и мотивацию. А это крайне непросто и может загубить всю идею на корню.

Планирование. Это хорошо, если компания опытная и есть понимание, что будет на выходе и в процессе. Однако, если это делается в первый раз, то практически всегда команда ошибается в планировании, закладывая либо очень маленькие временные промежутки в спринты, либо слишком большие. То же касается и других необходимых ресурсов, ошибки есть во всём.

Время. Помните, что в спринтах постоянно проводятся спичи (мини-планерки)? А теперь посчитайте сколько это времени занимает в целом проекте. Немного напоминает ситуацию, что мы уходили-уходили от бюрократии и планерок, но в результате пришли к уменьшению их по времени, но увеличению по количеству. Итог — очень много времени уходит на обсуждения.

Жесткость. Она же структура методологии скрам. То есть любой проект разбивается на подчасти, которые делаются в  несколько спринтов. Всё это реализует команды, которыми руководит скрам-мастер. Иначе никак! Нет отдельных игроков, нет нарушения структуры, нет увеличения длительности спринтов в середине процесса. Всё жёстко и по плану.

Коротко о главном для малого бизнеса

Первое мнение, которое у меня сложилось, метод скрам — это только для IT-компаний. Частично это верно. Но сколько таких компаний в числе наших читателей? Наверное 0,001%. Поэтому подведём итог, основываясь на малом бизнесе, а именно на рознице, услугах, опте и производстве.

В каких из вышеперечисленных бизнесов есть сложные и длительные проекты, для которых требуется команда из 7 человек? Скорее всего Вы скажите, что в НИ-КА-КИХ. В этом и весь смысл. Скрам подходит только в тех случаях, когда Вы создаёте что-то неопределённое, что сами до конца не понимаете. А значит и планировать дальше 2-3 месяцев не можете.

В малом бизнесе нужно использовать обычный каскадный подход (последовательный переход от одного этапа к другому). Единственное, когда можно рассмотреть Scrum в классическом бизнесе, это когда требуется создать новый продукт, вот тогда в этом есть смысл. А во всём остальном оставьте эту идею для IT-сфер, старт-апов и очень-очень-очень сложных проектов.

Вердикт. Считаю, что для малого и среднего бизнеса шумиха над этой методологией (в том числе про agile) создана только чтобы Вас поразить, а не чтобы увеличить результат Вам в продажах или оптимизировать работу. Всё это модное слово, которые используют все, кто хочет отличаться. Но нам же деньги нужны, а не просто отличия, верно?!