На прошедшей в конце 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 вопросов для проверки мифов
Любая технология требует адаптации под конкретную компанию, конкретную задачу. И чаще всего мы экономим именно на первой фазе, когда нужно просто провести анализ: оно мне надо? Оно точно мне надо? И когда я получу хоть какую-то прибыль?
Что можно сделать, для того чтобы понять, точно ли стоит внедрять что-то новое? На самом деле список банальный, но тем не менее эти вопросы важно задать себе, просто чтобы понять, нужно ли в это ввязываться.
- Что это даст бизнесу? Но ответ на этот вопрос вы чаще всего находите на сайтах продуктов, которые собираетесь купить.
- Когда? Потому что если мы говорим про какие-то долгоиграющие технологии, все таки должен быть какой-то срок, где мы должны сравнить пользу от вложенных денег и от какой-то полученной прибыли с этого.
- Сколько ресурсов будет потрачено? Потому что иногда внедрение каких-то новых программ, технологий или систем сопряжено с таким количеством расходов на процессы, что в целом не очень-то и понятно, стоит внедрять какие-то новые системы и тратить много денег, не понимая при этом, что же в итоге получится.
- Насколько предсказуем и, что важнее, устойчив результат? Некоторые продукты работают очень интересным образом. Вначале вы получаете вроде бы большой результат, но потом он потихоньку начинает сходить на нет, потому что первый эффект основан на эффекте новизны. То есть вы увидели, внедрили, классно. А потом понимаете, что оно не работает в большой перспективе. Поэтому лучше заранее подумать, насколько велика вероятность, что что-то изменится и эта технология или какой-то сервис вам перестанет подходить. Может быть и не стоит вкладываться.
- Готовы ли процессы компании к изменениям? Чаще всего ответ – «Нет». То есть мало кто начинает рассмотрение новых технологий и вообще какие-то новые процессы с того, что спрашивает своих сотрудников о том, как они сейчас работают и какие проблемы у них реально есть.
Часто компания считает, что ее проблему находятся в одном сегменте, тогда как в реальности они расположены в другой стороне. Часто топы бывают не в курсе того, что делают реально сотрудники. В этих условиях браться за реформы, в том числе за применение «модных технологий» –противопоказано. Технологические решения могут принести положительный эффект, когда они правильно нацелены на решение задач, и когда люди готовы к переменам.
5 баллов!!!!
http://www.repiev.ru/articles/Anti-TRIZ.htm
Очень интересная статья про ТРИЗ развод.
Вопрос был задан не мне, но так часто обсуждается на разных форумах, что добавлю свои «пять копеек».
Называть любую задачу проблемой — неконструктивно.
Задачи — это вопросы с принципиально-известными способами решения. (Называть их проблемами — значит просто увиливать от ответственности.) Основные инструменты решения задач — декомпозиция, аппроксимация и другие обычно хорошо известны специалистам. Поэтому любые задачи прекрасно решаются именно во время Daily Scrum, а также в последующей работе по спринту.
Что касается проблем, то технология Scrum сама по себе именно ПРОБЛЕМ не решает. Для решение проблем нужны другие технологии. Для научных — научно-исследовательские, для технических или организационных — техническая или бизнесТРИЗ соответственно. А теперь чуть подробнее.
Начнём с определения слова «проблема».
Назовём проблемой насущный вопрос с заведомо НЕИЗВЕСТНЫМ способом решения. ТРИЗ полагает, что причина любой проблемы — явное или скрытое противоречие. Которое может быть нескольких видов/уровней:
0. Противоречие между желаемым и известным современной науке. Этот уровень противоречий лежит за пределами ТРИЗ и относится к сфере научных исследований (хотя ТРИЗ применяется и в них, но эта сфера — наименее разработанная).
В технической сфере выделяют три уровня противоречий:
1. Противоречие между желаемым и действительным. А также между известным и доступным (но лежащим в пределах научного знания!) способом достижения. Такие противоречия регулярно возникают в административной практике, поэтому называются в классической ТРИЗ административными.
Этот уровень указывает на первичное, «сырое», едва осознанное и не проанализированное противоречие (обычно — целый их «клубок»).
2. Техническое противоречие — это противоречия между отдельными элементами технической системы и/или их техническими требованиями. Его по теории требуется обострить до физического.
3. Физическое противоречие — это противоречие требований, предъявляемых к ОДНОМУ элементу. (Должен быть и отсутствовать, быть горячим и холодным одновременно и т.д.) По факту, физическое противоречие — это попытка совмещения в сознании логически-несовместимых моделей ситуации и решается их перестройкой с помощью приёмов, стандартов и других инструментов ТРИЗ.
В организационной же сфере, имеющей дело с человеком, выделяют четыре уровня противоречий:
1. Административное (общее),
2. Организационное (между частями структуры),
3. Коммуникативное (межличностное)
4. Личностное (внутреннее).
Снимаются они также с помощью инструментов ТРИЗ (в стуктура), а физически в сочетании с известными организационно-психологическими техниками.
В общем, не надо требовать от SCRUM того, чего этот подход принципиально обеспечить не может. Для каждой сферы — свои инструменты.
Я так понимаю - в ТРИЗ АП - это просто что-то плохо (?)
А что Вы понимаете под АП в организационной сфере, не ясно из текста?
По прошлым вопросам пример Вы не привели (?)
Здесь хотя бы можно пример, это же не коммерческая тайна?
В целом глубоко уважаю Репьева и его здравый маркетинговый подход, учился у него копирайтингу. Также согласен с его мнением о том, что «ТРИЗ-Шанс» перенесла инструменты ТРИЗ в маркетинг слишком грубо, прямолинейно и местами некорректно.
С отдельными мыслями Александра Павловича о методологических ошибка «ТРИЗ-Шанс» я согласен. Например, принципы, лежащий в основе софтов Headliner/Заголовщик и ряда других программ, действительно порочны.
(Разбору этого могу посвятить отдельную статью.)
Однако, в этой статье Репьев сделал грубую логическую и методологическую ошибку, расширив мнение о частных заблуждениях «ТРИЗ-Шанс» до полной неприменимости ТРИЗ в рекламе и маркетинге.
В защиту «ТРИЗ-Шанс» могу сказать, что их (Викентьева и Сычёва) оправдывает то, что это была ПЕРВАЯ (а местами вполне удачная) попытка применения ТРИЗ в маркетинге и рекламе.
Однако, с тех пор прошло уже много лет, и успешная практика подтверждает эффективность использования ТРИЗ в бизнесе (рекламе, маркетинге и бизнес-управлении).
Не просто «плохо», а «надо менять (обычно — срочно), но не известно как». В этом противоречие — между желаемым (необходимым) и субъективно-возможным.
>А что Вы понимаете под АП в организационной сфере, не ясно из текста?
Административное противоречие в организационной сфере примерно совпадает с таким же в сфере технической. Поэтому отдельно не описывал. То есть, тоже «надо что-то делать, но что, неизвестно».
>По прошлым вопросам пример Вы не привели (?)
По каким конкретно? Напишите. Пока же приведу пример конкретного административного противоречия из практики:
При создании инновационной продукции (антропоморфные — человекоподобные роботы) в НПО (тогда ещё) «Андроидная техника» сразу было обнаружено противоречие между потребностью (желанием) в создании такой продукции у гендиректора и отсутствием явной потребности в ней у человечества. (Стандартное противоречие для любых прорывных инноваций.)
При этом, ни времени, ни ресурсов на «метод проб и ошибок» у стартапа не было.
Требовалось точно обнаружить скрытые потребности и найти возможно больше конкретных сфер применения этой продукции. А на основе этого — создать её проектным методом, попутно решая уже многочисленные технические противоречия.
Все эти проблемы были с помощью ТРИЗ быстро и успешно решены. Что вылилось в поэтапное создание ряда линеек/поколений продукции «Андроидной техники» и обеспечило итоговый вывод компании с «гаражного» этапа на уровень «Роскосмоса», НПО «Энергия» и т.д. меньше, чем за пятилетку.
О чём-то могу рассказать детальнее, о чём-то — нет (NDA и незнание деталей последних трёх лет).
Константин Куликов пишет:
Мой вопрос был - Интересная информация, ее можно продемонстрировать простым примером?
Тогда следует поправить Вашу классификацию - убрать п. 1 (он относится к АРИЗ).
А пункты 2,3 и 4 отнести к областям применения АРИЗ в организации, но не к видам противоречий в организации.
Поскольку иначе, используя одно и то же слово - противоречие, Вы нас скорее запутаете, а не поясните.
в данном случае, насколько я понял речь идет исключительно о разработке ПО, а вопрос стоял несколько шире, об применении методики scrum в бизнесе
Да, конечно, многими. Вот простейший — один из первых в моей практике.
В начале 2000-х всех предпринимателей Магнитогорска ОБЯЗАЛИ при открытии офисов выполнять так называемое «благоустройство территории». Среди прочих было обязательное требование заменить асфальт на прилегающих участках тротуарной плиткой. (Почему оно возникло знаю, но распространяться не буду.)
Разумеется, для предпринимателей это — прямые потери. Однако, по ТРИЗ любой ресурс со знаком «минус» легко превратить в «плюс».
Поэтому, когда один из друзей озвучил эту проблему, решение было найдено приёмом «инверсия» (обратить вред в пользу) моментально. Было предложено часть серой тротуарной плитки заменить цветной (для прочности — глазуированной) и выложить из неё парковочные зоны, надписи, другие рекламные элементы. Заодно в тротуар дополнительно был врезан круглый фирменный знак.
Такая необычная реклама прекрасно работает, как минимум, полгода (если снег чистят плохо) и 365 дней в году, там, где тротуары убирают.
Таких рекламных локальных «микроизобретений» было сделано в первый же год практики несколько сотен (обычно, со скоростью постановки задачи).