Как стать автором
Обновить

Комментарии 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, но тогда это будет явная замена желаемого на действительное.

Ладно, по больше части уже начался переход в полемику, проедем. Суммарно, мой посыл был в двух пунктах:

  1. Модель TOTE - это поведенческая модель (в т.ч. человека), т.е. по сути - формализация и описание того, что уже и так существует в подсознательном, что уже и так применяется на практике. Использовать ее для построения логики работы ПО и оборудования - вполне, но накладывать ее на модель управления проектами все равно что мешать синее с тёплым.

  2. Даже если и мешать, то модель TOTE базируется на петле обратной связи, т.е. на цикле, который по определению не может соотноситься с тезисом "реализации проектов в срок" (с чего статья и началась). Конечно возможно, как ты писал, вернуться с Т2 на Т1 и изменить "чёткое описание цели", но тогда получится "Мы сделали не то, что требовалось, потому мы изменили требования, и теперь мы имеем то, что соответствует требованиям. Профит". Вообще да, удобно. =) Если бы речь шла про эти аджайловские сектантские подходы - вопросов бы не было, вполне применимая модель постоянного улучшения (которая не лучше и, возможно, не хуже цикла Деминга), но с реализацией проектов "в срок" - взаимосвязи точно нет.

В любом случае - спасибо за ответы.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий