На прошедшей в конце 2018 года Russian Tech Week руководитель школы аналитиков Order Skills Татьяна Крутова предложила пять «потемкинских деревень» — кейсов, которые наглядно показывают ошибочность применения best practices, — и составила пять вопросов, на которые нужно ответить себе, прежде чем ввязываться в применение того или иного новаторского решения в собственном бизнесе.
Татьяна Крутова, руководитель школы аналитиков Order Skills:
Сейчас у каждого есть два состояния. Одно – в медийных профилях – Instagram, Facebookи и др., где ваши друзья отслеживают вас именно по этому профилю. Второе – реальное. У бизнесов происходит то же самое.
Есть информационное пространство, где вы существуете как информационная модель, а есть реальная компания со своими реальными проблемами. Бывает, что компания так уверена, что у нее все классно («У нас замечательно, у нас лучшие процессы!»), что не в состоянии понять, что же у нее действительно болит.
Виной тому подход, который можно назвать «потемкинские деревни»: компания стремится развивать свой информационный профиль, она хочет выглядеть успешной и современной, и в результате начинает верить тому образу, который сама и создала.
Когда компании, начинают внедрять Best practices, они тоже зачастую строят «потемкинские деревни». Менеджеры говорят: «Мы внедряем Agile!» Внедрять гибкие методологии очень модно, но на самом деле очень часто такие заявления делаются для «продажи статусности».
1. «Мы лучшие на рынке»
Если вы зайдете на сайт любой компании, не важно насколько она крупная, вы узнаете, что она – самая лучшая, что она занимает ведущую позицию в каком-нибудь рейтинге или списке. Это симптом того, что компания пытается занять места больше, чем нужно.
Когда компании, которая занимается обучением, советуют «пора лить лидов на лендинг», «пора брать больше учеников», «пора расширяться», «пора масштабироваться» – это тоже советы занять больше места, чем нужно. В реальности такие действия нужны только тогда, когда компания к ним готова.
Можно набрать кучу учеников но, например, будет недостаточное количество преподавателей. Может быть другая проблема: слушатели будут сидеть в аудитории, но ученики на задних рядах будут мало вовлечены в процесс. В результате качество обучения будет теряться. Вместо того, чтобы «позиционировать себя в качестве крупной компании», задайте себе вопрос: «что хорошее и полезное сделать вы можете сделать для целевой аудитории?»
Ресурсы и компании, как и ресурсы человека, ограничены, и вы всегда можете выбрать – создавать какой-то бомбически крутой профиль в Instagram и жить «инстаграмной» жизнью, то есть создавать видимость, что вы очень уважаемая и успешная персона, либо реально делать действительно полезные какие-то вещи. Вы не можете делать и то и другое одновременно, потому что в один момент можно выполнять всего одну задачу.
2. «Программа решает проблемы»
Типичный пример из практики консалтинга. Компания- клиент говорит: «У нас есть компания-конкурент, они недавно внедрили программу N, и у них стало все хорошо. Было плохо, стало отлично. Нам нужно так же».
На самом деле причины у такого запроса две:
- Поиск волшебной таблетки. Всем нам хочется, чтобы – раз! – и жизнь стала прекрасной.
- Стыд признаться, что волшебная таблетка не сработала, а деньги потрачены.
Тот самый конкурент, у которого «все стало хорошо», на самом деле может очень страдать от того, что потратил деньги и ничего не получил, но будет говорить с умным видом, что у него все замечательно – процессы заработали, показатели вышли на новый уровень. Компания отправит пару человек отправит на конференцию и расскажет об этом рынку.
Так происходит развитие мифа, что программа решает проблемы. Программа, конечно, и даже самая крутая, проблем не решает.
Однажды компания-клиент потребовала: «Нам надо поставить классную программу для отслеживания задач». Вводные такие: компания занимается деятельностью с большим количеством задач, и нужен постоянный контроль исполнителей, расчет KPI.
Они решили сразу замахнуться на очень крупное решение, на мощную ERP-систему, но не знали, с какой стороны подойти к этой покупке. На вопрос «А что вы хотите от ERP-системы?» представители компании отвечают: «Ну, хотим размечать время, смотреть, кто какие задачи выполнял, контролировать качество выполнения». Однако для этого могут подойти самые простые инструменты, например, Гугл-диск. На самом деле, задача была, чуть сложнее, конечно, но тем не менее… Когда компания видит проблему, почему-то кажется, что:
- с этой проблемой столкнулась только она одна,
- для решения проблемы нужно что-то серьезное, потому что «Мы же крупная компания, нам нужно какое-то большое решение, которое сразу покроет весь функционал».
В этом кейсе все закончилось тем, что мы рассмотрели бесплатные средства автоматизации задач. Потому что проблема компании состояла в том, что учет задач там не велся в принципе. Один сотрудник мог выполнять выполнять 40-50 задач в неделю, другой – две. Но уважали в компании больше того, кто сидел с более напряженным лицом.
Резюмируя можно сказать, что любая программа решает проблему только в том случае, если люди подстроены под эту программу. Иногда, внедрение какой-то программы, особенно, если это большая ERP-система, происходит методом «прижать сверху». Кто-то из руководства подумал, что это очень круто, и начинает прессовать низы. Когда все доходит до конечного исполнителя, хороший эффект от внедрения программы, конечно, сильно уменьшается.
3. «Модное дизайн-мышление»
Очень многие компании, особенно – которые разрабатывают продукты, любят говорить, что они используют методы дизайн-мышления. Что мы имеем по факту?
Очень часто это дизайн-мышление похоже на старую добрую методику ТРИЗ – теорию решения изобретательских задач. Это не что-то новое, это, по сути – просто здравый смысл. Когда этот здравый смысл начинает мешать? Когда мы выполняем эти методики формально.
Компания Х разработала некое веб-приложение. Они обвешали его всеми видами метрик, статистик. Они знали про пользователя все, вплоть до количества чихов, которые тот совершает, когда открывает ту или иную форму.
Однако они не удосужились пообщаться вживую с пользователями. На вопрос «А где те люди, которые пользуются вашим приложением? Вы с ними общались, вы к ним ездили?» компания отвечала: «Нет, но есть специальный человек, он знает, как им надо».
Метрики не могут быть заменой общения с пользователем. Это катастрофа, когда внедряется куча методик, а по факту получается, что есть один замечательный человек, который решает, куда же пойдет продукт, просто потому что его опыт говорит, что обычно люди ходят туда.
4. «Проблемы Scrum»
Что есть Scrum? Что нам обещает Scrum? «Нет» жесткому планированию. «У вас больше не будет жестких графиков с четкими сроками, вы будете гибкими, вы будете водой, вы будете выполнять требования заказчика, и все будут счастливы». Но что на самом деле?
- Ежедневное совещание по Scrum должно занимать 15-30 минут. Оно же ежедневное, быстрое: посовещались и побежали работать. Что происходит на деле? Поскольку есть менеджер, который занимается общим руководством процессом, он начинает расспрашивать каждого участника Scrum-митинга, что же за проблемы у него возникли, а еще хуже, когда начинает эти проблемы решать. И в итоге – это не 15 минут, не полчаса, а час-два.
- Мы делаем функции, которые полезны клиенту. Звучит классно. Но как вы думаете, насколько клиенту полезно и интересно, как вы будете рефакторить ваше приложение? Конечно, вы будете говорить, что продукт станет быстрее, станет лучше, будет круче работать, но пройдет, например, две-три недели и ваш клиент, приученный к тому, что каждый раз он получает новую функцию, получит все то же самое и спросит: «Что такое? Где мои деньги? Что вы сделали за этот период?». В другой компании все задачи, которые не давали видимого клиенту, наглядного результата вообще отодвигали. В итоге вырос такой технический долг, что восполнять его пришлось в течение трех-четырех спринтов.
- Командная ответственность. Тоже звучит классно. В одном известном мне случае команда пришла к выводу: «Что-то не так, давайте запланируем задачу и все это исправим». Но при этом не провела анализ проблемы. В итоге прошла пара спринтов, команда наткнулась на ту же проблему и пришла к выводу: «Это влияние предметной области». Самое удобное, кстати, решение – списывать на предметную область – и опять продолжила работу без анализа. В конечном счете, эта командная ответственность привела к тому, что в команде появился отдельный человек, который вроде как был продакт-менеджером, то есть занимался тем, что определял, как будет развиваться продукт, но по факту на любой вопрос от директоров спрашивал в чатике команды: «Что вы думаете по этому поводу?» А если спросишь что-то у него, отвечал: «А какие ты тут видишь варианты?»
- Вовлечение заказчика. Вы когда-нибудь пробовали вовлечь заказчика, который не хочет вовлекаться в процесс? Далеко не каждый заказчик готов к тому, что его будут постоянно теребить. Причем, иногда заказчику задают вопросы, на которые не то, что у заказчика нет отетов, на эти вопросы никто не знает ответа! Но очень удобно спрашивать у заказчика. Ну, мы же для него делаем, в конце концов, он же должен знать, как ему надо.
- Кросс-функциональность. Точнее – миф о кросс-функциональности. В Scrum считается, что вся команда работает по спринту. Как было на самом деле? Для того, чтобы разработчик начал делать задачу, он должен понимать, что он делает. Для этого аналитик должен проработать задачу до момента ее реализации. То есть до момента старта спринта.
По факту получалось, что аналитики всегда работали на спринт раньше, тестировщики работали практически на спринт позже. То есть никакой командной работы внутри спринта не было. Но, самое интересное не в этом, самое интересное в том, что пока аналитик готовил требования под следующий спринт, они уже успевали устаревать к его началу. И где-то накануне спринта аналитик пару раз переписывал все заново.
Поэтому, когда вы используете Scrum, понимайте, зачем он вам нужен и нужен ли он вам вообще. Потому что есть ряд проектов, особенно, если сроки жесткие и заказчики обвязаны регламентами, которые не очень хорошо сочетаются со Scrum. В таких случаях гибкости особой-то и нет. И, если гибкости нет, не надо делать вид, что она есть и заявлять: «Ооо! Мы тоже используем Scrum! Мы умудрились использовать его в проектной разработке и у нас все получилось!»
Хорошо, что получилось, но это не тренд.
5. «Монетка или machine learning?»
Очень часто теперь можно услышать фразы, вроде: «У нас в компании используется machine learning. И вообще мы теперь очень близки к передовому краю новых технологий». Что по факту происходит?
У компании Y есть некоторая форма заявки, которая проходит процесс проверки, которая причем, обвязана кучей всяких регламентов и субъективным трактованием законов Российской Федерации. Сотрудники компании прикрутили «интеллектуальную систему», как они ее назвали, и сказали, что интеллектуальная система скажет, корректно или некорректно заполнена ваша заявка.
И она действительно говорит, корректно или некорректно заполнена заявка. Ведь исхода всего два: корректно или некорректно!
На вопрос, насколько велика точность таких прогнозов, разработчики ответили – 60%. Впрочем, раз исходов всего два, берем волшебный железный кружочек – монетку, подкидываем и получаем 50% вероятности, что всего на 10% меньше дорогостоящей технологии!
То есть по факту очень много компаний, которые делают вид, что они что-то внедрили, для того, чтобы накрутить ценник на свой продукт. Ведь теперь там есть машинное обучение, а значит, продукт стоит чуть ли не в два раза дороже. И вроде как оно даже применяется.
5 вопросов для проверки мифов
Любая технология требует адаптации под конкретную компанию, конкретную задачу. И чаще всего мы экономим именно на первой фазе, когда нужно просто провести анализ: оно мне надо? Оно точно мне надо? И когда я получу хоть какую-то прибыль?
Что можно сделать, для того чтобы понять, точно ли стоит внедрять что-то новое? На самом деле список банальный, но тем не менее эти вопросы важно задать себе, просто чтобы понять, нужно ли в это ввязываться.
- Что это даст бизнесу? Но ответ на этот вопрос вы чаще всего находите на сайтах продуктов, которые собираетесь купить.
- Когда? Потому что если мы говорим про какие-то долгоиграющие технологии, все таки должен быть какой-то срок, где мы должны сравнить пользу от вложенных денег и от какой-то полученной прибыли с этого.
- Сколько ресурсов будет потрачено? Потому что иногда внедрение каких-то новых программ, технологий или систем сопряжено с таким количеством расходов на процессы, что в целом не очень-то и понятно, стоит внедрять какие-то новые системы и тратить много денег, не понимая при этом, что же в итоге получится.
- Насколько предсказуем и, что важнее, устойчив результат? Некоторые продукты работают очень интересным образом. Вначале вы получаете вроде бы большой результат, но потом он потихоньку начинает сходить на нет, потому что первый эффект основан на эффекте новизны. То есть вы увидели, внедрили, классно. А потом понимаете, что оно не работает в большой перспективе. Поэтому лучше заранее подумать, насколько велика вероятность, что что-то изменится и эта технология или какой-то сервис вам перестанет подходить. Может быть и не стоит вкладываться.
- Готовы ли процессы компании к изменениям? Чаще всего ответ – «Нет». То есть мало кто начинает рассмотрение новых технологий и вообще какие-то новые процессы с того, что спрашивает своих сотрудников о том, как они сейчас работают и какие проблемы у них реально есть.
Часто компания считает, что ее проблему находятся в одном сегменте, тогда как в реальности они расположены в другой стороне. Часто топы бывают не в курсе того, что делают реально сотрудники. В этих условиях браться за реформы, в том числе за применение «модных технологий» –противопоказано. Технологические решения могут принести положительный эффект, когда они правильно нацелены на решение задач, и когда люди готовы к переменам.
Ура! К нам присоединился специалист по Scrum!
Укажите где и как не прав автор статьи?
В чем он приврал или приукрасил что-то для красного словца?
А самое главное, расскажите тогда, КАК на самом деле должен работать Scrum?
Интересно, когда-нибудь станет понятно, что для внедрения любой новомодной управленческой технологии нужна удобренная почва в виде отстроенного системного менеджмента. Наверное, да. Но мы это вряд ли увидим)
очень точно
Зачем? С помощью скрам вы можете минуя этап систематизации автоматизировать сложившийся бардак, тем самым сократив время внедрения нового решения в РАЗЫ! И далее худо бедно существовать, что подтверждают тысячи компаний не только в России, но и во всем мире. Вы же предлагаете плодить и кормить это ненасытное племя системных аналитиков, которые только и могут пить кофе с булочкой и критиковать все вокруг.
Это только терять время в конкурентной борьбе с более прагматичными соперниками, которые в короткой перспективе сожрут вас с вашими сыроватыми прототипами. А потом закажут статью у копирайтера, в которой объявят свой бизнес системным, при этом не теряя ни рубля на его реальную систематизацию.
Ничего не поняла
уж лучше тогда бардак неавтоматизированный, скорость разрухи меньше)
Ничего подобного я никогда не предлагала, не предлагаю и даже не собираюсь)
понравилось. как правило все знают что надо купить ERP внедрить агил и все будет пучком.
как правильно замечено топы иногда вообще не представляют что творится в трюмах и машинном...
а 50% народу внедряя новые технологии управления или развивая новые направления - тупо жрут бабки.
любые пилюли хороши когда собственник заинтересован, процессы прописаны и испытаны и все знают что хотят. и кадры при этом учат, проверяют, дерут и кормят не так чтоб не сдохли, а чтобы хоть чуть чуть заинтересовать денежной:)))
> Укажите где и как не прав автор статьи?
1. Daily Scrum - строго не более 15 минут. Это НЕ совещание, это синхронизация прогресса работы над целью спринта. На нем - как и вообще в Скраме - нет менеджера.
2. В течение спринта создается новая бизнес ценность, а не "делают то, что полезно клиенту" - массаж и припарки очень полезны, но делают именно бизнес ценности.
3. Нет никакой командной ответственности, есть самоорганизация. В команде может быть лид который отвечает за производительность команды, но этому лиду никто не может сказать "пусть Вася делает фичу А, а Петя - Б" - команда сама знает как лучше организовать работу.
4. Полный бред. В Скраме вообще нет "заказчика". Есть Владелец продукта и Заинтересованные лица. "Заказчик" (кто это вообще? - непонятно) может не участвовать в процессе, ему достаточно платить деньги и интересоваться у ВП как идут дела.
5. Опять полнейший бред. Кросс-функциональность означает что команда может достичь цели спринта самостоятельно, исключительно силами членов команды. Чтобы разработчик понимал что он делает есть Product Backlog Refinement событие, на котором обсуждается будущий функционал.
Вообщем по Scrum все из разряда "сам, конечно, не видел, но слышал от человека, который слышал от человека".
КАК на самом деле должен работать скрам подробно рассказано в Scrum Guide. Это всего 19 страниц текста, на одной из которых черным по белому написано что Скрам "Simple to understand • Difficult to master".
Или вы хотите в одном комментарии услышать ответ на главный вопрос жизни, вселенной и всего такого? Это вам к автору статьи.
Спасибо за информативный ответ.
Признаюсь, я не специалист по Scrum, но немного понимаю в организации бизнес-процессов. Законов сохранения материи никто не отменял. Поэтому при возникновении проблем их нужно КОМУ-ТО и КОГДА-ТО решать. Если не во время Daily Scrum, то значит после. Но ВРЕМЯ на решение проблемы так или иначе нужно потратить. Или я не прав?
По возможности расскажите:
Я просил не то, что в книжках написано, а то, что в реальной жизни происходит. Если конечно Вы с Scrum работаете на практике.