ДТР Проекта со сложной судьбой

Главная Форум Теория ограничений: инструменты и практика ДТР Проекта со сложной судьбой

В этой теме 26 ответов, 5 участников, последнее обновление  Filipp Zakharov 1 год, 7 мес. назад.

Просмотр 15 сообщений - с 1 по 15 (из 27 всего)
  • Автор
    Сообщения
  • #9056

    Filipp Zakharov
    Участник

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

    Изучаю ТОС, решил применить на практике, построил дерево, не думал, что это так сложно. Хотелось бы мнения опытных людей услышать.

    Составлялось так:
    1. Попросил причастных людей (разработчики, аналитики, тестировщики, бывшие и нынешние руководители) написать ответ на вопрос: Почему продукт не приносит пользу клиентам? Реально мы еще не довели продукт до такого состояния, чтобы им пользовались.
    2. Выделил НЯ
    3. Построил ДТР

    Вложения:
    You must be logged in to view attached files.
    #9066

    Филипп, добро пожаловать! Интересная тема!

    #9067
    Виктор Вальчук
    Виктор Вальчук
    Хранитель

    Лично я не сторонник строить сначала ДТР. Не пробовали сначала построить тучу?

    #9068

    Filipp Zakharov
    Участник

    Я ориентируюсь на книгу Детмер «Теория ограничений Голдратта». И решил осваивать последовательно инструменты. Тучу планирую в ближайшее время начать строить, т.к. конфликт выглядит очевидным.

    #9069
    Виктор Вальчук
    Виктор Вальчук
    Хранитель

    Да, я понимаю. Это Российская проблема. На русский переведена только книга Детмера, и потому его метод известен большинству. А метод 3 UDE остается малоизвестным в России. Попробуйте все- таки сначала построить 3 тучи для трех разных Нежелательных явлений.

    #9070

    Filipp Zakharov
    Участник

    Спасибо, попробую. Я так понимаю Вы про метод трех туч?
    И еще, не ясно, плохо то, что на русский переведена только книга Детмера или то что это не самая лучшая книга?

    #9071
    Виктор Вальчук
    Виктор Вальчук
    Хранитель

    Плохо и то, и другое. И еще то, что в результате такого стечения обстоятельств в России мнение Детмера преобладает, хотя в мире чаще используется и считается основной именно методика трех туч.

    #9075

    Не совсем понял как логически следует из малого количества ресурсов невозможность планировать. Показалось, что ДТР Вы строили уже «зная» причину. Попробуйте подход предложенный Виктором.

    #9076

    Filipp Zakharov
    Участник

    Имеется ввиду низкое качество планирования из-за очень низкой точности оценки задач.
    Да я хочу попробовать метод 3-х туч, но пока не понял с чего начать. Вот выбрал я скажем 3 НЯ, наиболее весомых. Как строить тучи?
    Инвертировать НЯ и превращать в Задачу, а дальше для этой задачи строить тучу? И так 3 раза.
    И как объединять потом 3 тучи? Ну тут возможно я тороплюсь, надо тучи построить и будет понятно.

    PS А вообще волнует вот что. Я довольно много сил и времени потратил на построение этого ДТР и меня результат устраивает. Я так понимаю есть уверенность, что используя метод 3-х туч я получу другой результат, более качественный? Как бы нет мотивации идти новым путём. Но я попробую, просто сейчас сложнее за это взяться…

    #9077
    Виктор Вальчук
    Виктор Вальчук
    Хранитель

    Давайте сюда одно из своих НЖЯ и мы построим тучу вместе. другие построите сами. ДТР без тучи — это дерево без корней 🙂

    #9082

    Filipp Zakharov
    Участник

    3 НЖЯ:
    1. Ресурсов на работу с техническим долгом выделяется крайне мало
    2. Часто ключевая функциональность не работает на данных пользователей
    3. У команды нет понимания, какую пользу приносит продукт

    Я попробовал построить тучу для 1-го, в котором конфликт кажется очевидным и нужно выявить условия и задачу, получилось то что в атаче

    Вложения:
    You must be logged in to view attached files.
    #9084

    Filipp Zakharov
    Участник

    Еще не много повозился, построил для 2 и 3-го НЖЯ. Путем инвертирования НЖЯ в задачу.

    • Ответ изменён 1 год, 9 мес. назад пользователем  Filipp Zakharov.
    Вложения:
    You must be logged in to view attached files.
    #9094
    Виктор Вальчук
    Виктор Вальчук
    Хранитель

    Чуть — чуть попридираюсь. НЖЯ «Ресурсов на работу с техническим долгом выделяется крайне мало» звучит как предполагаемое решение. Это недопустимо. Нужно переформулировать. Для этого например, можно задать вопрос: «К чему это приведет?». Тогда может быть будет сформулировано правильно.

    По поводу НЖЯ «У команды нет понимания, какую пользу приносит продукт». Не совсем понятно — польза на самом деле есть, или нет? Если есть, то НЖЯ звучит как обвинение персонала, а это недопустимо. К чему приводит то, что у команды нет понимания, какую пользу приносит продукт?

    #9096

    Filipp Zakharov
    Участник

    Согласен, спасибо.
    Тогда возможно такая формулировка:
    НЖЯ: Программный код продукта сложно сопровождать
    На всякий случай поясню, про нашу кухню:
    Дело в том, что в программировании одна из главных проблем — это управление сложностью. Т.е. когда в продукте тысячи строк кода, то важно внутреннее его устройство и организация. Никакой программист не способен его запомнить, а значит важнее становиться «читаемость», т.е. как быстро программист сможет восстановить организацию и алгоритм работы куска кода, в котором ему нужно сделать изменения или дополнения. Также важны стандарты команды, когда код удовлетворяет, некоторым иногда неявным, стандартам, что позволяет программисту гораздо быстрее понимать код другого. Технический долг возникает, когда заставив написанный код выполнять бизнес функцию мы не тратим время на его внутреннее упрощение и приведение к стандартам команды и платим за это потом.

    А по второму я бы так сформулировал, хотя что-то не уверен:
    НЖЯ: Продукт не удовлетворяет нефункциональным требованиям
    Поясню. Когда аналитик ставит задачу, реализовать определенную функцию, зачастую могут быть скрытые требования, которые мы можем выяснить только реально дав пользователю поработать с данной новой функцией. Но некоторые скрытые требования могут выявить программисты и понимание ими задач продукта сильно в этом помогает. К тому же частенько возникают идеи, как сделать решение на порядок более дешевым по времени и сложности, не сильно при этом задев интересы пользователя.

    #9097

    Доброго дня, Филипп!
    В открытых источниках можно найти следующие 10 правил, которые помогают лучше формулировать НЖЯ:
    1) НЖЯ – это постоянная проблема, которая существует в вашей действительности, из-за нее вы не можете достичь лучшего уровня деятельности.
    2) Это описание состояния, а не одноразового случая или действия. (НЖЯ не может содержать глаголы действий типа «взять», «идти» и т.д.)
    3) Это явление находится в вашей области ответственности.
    4) Относительно этого явления возможно что-то предпринять.
    Например, «На улице слишком жарко» – это не НЖЯ.
    Мы не можем изменить то, что на улице жарко. Мы можем изменить только наши действия: то, что мы предпримем, чтобы нам не было жарко.
    5) НЖЯ не должно обвинять кого-либо.
    6) НЖЯ не должно быть предполагаемой причиной.
    «Сотрудники недостаточно обучены» – это не НЖЯ, это предполагаемая причина: «Поскольку сотрудники недостаточно обучены…»
    7) НЖЯ не должно быть завуалированным решением (желанием того, как можно было бы решить проблему).
    8) НЖЯ не должно требовать пояснения того, какой негативный эффект оно вызывает.
    9) НЖЯ не может содержать причинно-следственную связь.
    10) НЖЯ не должно быть субъективным утверждением: не должно содержать оценочных прилагательных и наречий, таких как «сложный / сложно», «хороший / хорошо», «плохой / плохо», «минимальный», «максимальный» и т. п.
    (источник: Одед Коуэн, Елена Федурко «Основы Теории Ограничений»)

    В представленном Вами ДТР есть очень странные, на мой взгляд, вещи: вроде «ключевой функциональности, не работающей на данных пользователей». Белке, бегущей в колесе, порой очень сложно понять, что она на самом деле никуда не бежит.

    Возможно Вашей команде стоит взять паузу в стремительном движении и просто осознать что за продукт вы делаете? Что вы хотите получить? Кто является заказчиком этого продукта, и как этот заказчик связан с теми, кто будет пользоваться продуктом? Прежде всего необходимо определиться с целью создания продукта. Если Ваша задача создавать продукт — это один набор действий, если же задача создать — то совершенно другой. Не так и важно, что уже было создано на текущий момент. Затраченные усилия безусловно очень ценны для тех кто их совершал, но вовсе не обязательно ценны для итога этих усилий.

    Есть ли у Вас список требований к функциональности проекта упорядоченный по степени важности? Есть ли понимание по каким критериям эта упорядоченность создана?

    "Никакие тактические успехи не могут компенсировать стратегические просчеты" (с) Карл фон Клаузевиц

Просмотр 15 сообщений - с 1 по 15 (из 27 всего)

Для ответа в этой теме необходимо авторизоваться.