Комментарии 5
Про качество. Как то читал, что "качество должно быть встроено в продукт". Контроль качества не выходе не приводит к росту качества. Что вы об этом думаете?
Добрый день! Спасибо за комментарий.
Вы абсолютно правы, для этого и есть этапы теста 1 и теста 2:
В рамках теста первого мы еще до старта определяем то качество, которое должно быть встроено в продукт (критерии).
А в рамках теста второго мы в рамках процесса создания замеряем метрики (на фокус-группах, исследованиях и других источниках обратной связи) и сравниваем их с установленными критериями (достаточно или нет).
Однако, при создании нового продукта не всегда возможно отследить все метрики в процессе. Автор может полагаться на мнение выпускающего редактора, однако далеко не факт, что книга соберет тираж и станет бестселлером.
Конструкторское бюро при создании нового автомобиля может закладывать определенные характеристики (технические, эстетические, надежность и т.д.), но может только формировать гипотезы о его будущих продажах.
Андрей, честно - это прям сова, натянутая на глобус и заваренная в кашу. Некорректное трактование как самой модели TOTE, так и смысла этапов в ее составе. Да и вообще непонятно, как эта модель связана с «достигаторами» и реализацией проектов (тем более в яблочко и в срок).
Модель TOTE из книги «Планы и структура поведения» - это действительно Test-Operate-Test-Exit. Только там нет Test1 и Test2, есть только Test. Т.е. еще до начала работы должен быть определен желаемый результат и его критерии, и далее начинается цикл:
Test - проверка соответствия текущего состояния желаемому, если нет, то
Operate - действие
Test - проверка соответствия текущего состояния желаемому, если нет, то
Operate - действие
И далее до бесконечности, пока ответ не будет «да». Самый примитивный пример (как в книге) - с забиванием гвоздя. С приготовлением яичницы это будет выглядеть как:
«Хочу яичницу средней прожарки, поэтому:
проверяем - яичницы нет на столе;
жарим;
проверяем - пережарилась, выкидываем;
жарим снова;
проверяем - недожарилась;
дожариваем;
проверяем - пережарилась, выкидываем;
жарим снова;
и т.д. по кругу, пока
проверяем - то, что надо.»
Да, результат достигнут, но совсем не эффективно.
Поэтому модель TOTE к реализации проектов в бюджет и в срок не относится никак. Совсем никак. Более того, она даже к этой статье не относится, т.к. весь лонгрид, на самом деле, о простой комбинации понятий «MVP» (minimum viable product) и «DoD» (definition of done), т.е.:
определяем что есть сейчас и критерии того, что должно быть в итоге;
исключаем избыточные критерии и соответствующие действия;
действуем, учитывая риски и придерживаясь плана;
убеждаемся, что результат соответствие желаемым критериям;
завершаем работы.
В общем, все просто и понятно без четырех волшебных букв.
Антон, привет! Спасибо за подробный комментарий и свое мнение! Постараюсь ответить по тезисам:
1. Про неправильную трактовку T.O.T.E. Ну слава Богу, знания, да и трактовки знаний не статичны и меняются с течением в времени и различны у разных людей, и в наше время не сжигают на костре за иное трактование. Благо, это не абсолютное знание вроде 2*2=4.
Я изучал эту модель с test 1 и test 2, да и википедия выделяет такие этапы (хотя я согласен, не идеальный источник).
2. В части T-O-T-O. Все-таки мое мнение, что ты выкидываешь этапы инициация действия и выхода. Если посмотреть мою схему модели T.O.T.E., то тогда уж правильнее T1-O-T2-O-T2-O-T2-E. Иногда даже возможно из T2 переход в T1 для изменения критериев.
По сути ты переходишь в более простую модель "стимул-реакция".
3. По поводу твоего примера с яичницей.
Во-первых, если так часть пережаривается яичница, значит время проведения T2 и петля обратной связи (возвращение к операциям) наступает не в нужное время. Как пишу в статье, частотность тут - хороший способ как раз сэкономить ресурсы.
Во-вторых, ты прям из общего тоута взял маленький кусочек (о чем я пишу в части тоут в тоуте). То есть у тебя уже есть плита, сковорода, яйца и т.д. Но можно с этой моделью взглянуть и на весь процесс в целом. Потому что жарить (а в отдельных случаях выкидывать) - это всего лишь одна операция из плана.
А дальше у каждого свое: у меня модель T.O.T.E. относится к снижению бюджета и достижению результата в срок, у тебя нет. Тут мы, наверное, оба правы, так как руководствуемся своим опытом, своей картиной мира.
4. Про MVP и DoD. Да, хорошие модели, хотя и у них есть критики (впрочем, как и всего на свете). Но это не отменяет применение других моделей теми, кому они удобны и помогают достигать результат.
5. В части порядка действий мы с тобой сходимся. И это наверное самое главное. А как и за счет чего мы получаем такой порядок и можем его применять - это уже наше с тобой право)))
Моя картина мира говорит о том, что модель применима (но не ограничивается этим списком) для:
1. ведения проектов;
2. постановки стратегических целей на 5-10 лет;
3. быстрого усвоения новых навыков посредством моделирования экспертов;
4. анализа и повышения эффективности своего поведения.
Ты имеешь полное право ее не использовать для этих целей.
Спасибо тебе за возможность обсудить)
Как раз про пункт:
2. В части T-O-T-O. Все-таки мое мнение, что ты выкидываешь этапы инициация действия и выхода. Если посмотреть мою схему модели T.O.T.E., то тогда уж правильнее T1-O-T2-O-T2-O-T2-E. Иногда даже возможно из T2 переход в T1 для изменения критериев.
Опять же, нет взаимосвязи модели с достижением результатов в срок, если процесс крутится в цикле ...-О-Т2-О-Т2-О-Т2-..., т.к. тут нет (и по модели не может быть) ограничений. Да, для выхода из цикла необходим, как раз ты пишешь, переход из Т2 в Т1, но тогда это будет явная замена желаемого на действительное.
Ладно, по больше части уже начался переход в полемику, проедем. Суммарно, мой посыл был в двух пунктах:
Модель TOTE - это поведенческая модель (в т.ч. человека), т.е. по сути - формализация и описание того, что уже и так существует в подсознательном, что уже и так применяется на практике. Использовать ее для построения логики работы ПО и оборудования - вполне, но накладывать ее на модель управления проектами все равно что мешать синее с тёплым.
Даже если и мешать, то модель TOTE базируется на петле обратной связи, т.е. на цикле, который по определению не может соотноситься с тезисом "реализации проектов в срок" (с чего статья и началась). Конечно возможно, как ты писал, вернуться с Т2 на Т1 и изменить "чёткое описание цели", но тогда получится "Мы сделали не то, что требовалось, потому мы изменили требования, и теперь мы имеем то, что соответствует требованиям. Профит". Вообще да, удобно. =) Если бы речь шла про эти аджайловские сектантские подходы - вопросов бы не было, вполне применимая модель постоянного улучшения (которая не лучше и, возможно, не хуже цикла Деминга), но с реализацией проектов "в срок" - взаимосвязи точно нет.
В любом случае - спасибо за ответы.
Точно в яблочко или как запускать проекты