Коллеги, внимание!
Форум переехал в Facebook в нашу группу «Фокусировка на главном».
Прошу задавать свои вопросы и открывать новые темы в группе, там вы сможете оперативно получить ответы.
Перейти в группу
- В этой теме 26 ответов, 5 участников, последнее обновление 8 лет назад сделано
.
-
Сообщения
-
Достался проект со сложной судьбой (больше года писала большая команда), но не смотря на прошедшее время, еще почти год, так и не удается кардинально переломить ситуацию. Лишь улучшить и стабилизировать.
Изучаю ТОС, решил применить на практике, построил дерево, не думал, что это так сложно. Хотелось бы мнения опытных людей услышать.
Составлялось так:
1. Попросил причастных людей (разработчики, аналитики, тестировщики, бывшие и нынешние руководители) написать ответ на вопрос: Почему продукт не приносит пользу клиентам? Реально мы еще не довели продукт до такого состояния, чтобы им пользовались.
2. Выделил НЯ
3. Построил ДТРЯ ориентируюсь на книгу Детмер «Теория ограничений Голдратта». И решил осваивать последовательно инструменты. Тучу планирую в ближайшее время начать строить, т.к. конфликт выглядит очевидным.
Да, я понимаю. Это Российская проблема. На русский переведена только книга Детмера, и потому его метод известен большинству. А метод 3 UDE остается малоизвестным в России. Попробуйте все- таки сначала построить 3 тучи для трех разных Нежелательных явлений.
Спасибо, попробую. Я так понимаю Вы про метод трех туч?
И еще, не ясно, плохо то, что на русский переведена только книга Детмера или то что это не самая лучшая книга?Плохо и то, и другое. И еще то, что в результате такого стечения обстоятельств в России мнение Детмера преобладает, хотя в мире чаще используется и считается основной именно методика трех туч.
Не совсем понял как логически следует из малого количества ресурсов невозможность планировать. Показалось, что ДТР Вы строили уже «зная» причину. Попробуйте подход предложенный Виктором.
Имеется ввиду низкое качество планирования из-за очень низкой точности оценки задач.
Да я хочу попробовать метод 3-х туч, но пока не понял с чего начать. Вот выбрал я скажем 3 НЯ, наиболее весомых. Как строить тучи?
Инвертировать НЯ и превращать в Задачу, а дальше для этой задачи строить тучу? И так 3 раза.
И как объединять потом 3 тучи? Ну тут возможно я тороплюсь, надо тучи построить и будет понятно.PS А вообще волнует вот что. Я довольно много сил и времени потратил на построение этого ДТР и меня результат устраивает. Я так понимаю есть уверенность, что используя метод 3-х туч я получу другой результат, более качественный? Как бы нет мотивации идти новым путём. Но я попробую, просто сейчас сложнее за это взяться…
Давайте сюда одно из своих НЖЯ и мы построим тучу вместе. другие построите сами. ДТР без тучи — это дерево без корней 🙂
3 НЖЯ:
1. Ресурсов на работу с техническим долгом выделяется крайне мало
2. Часто ключевая функциональность не работает на данных пользователей
3. У команды нет понимания, какую пользу приносит продуктЯ попробовал построить тучу для 1-го, в котором конфликт кажется очевидным и нужно выявить условия и задачу, получилось то что в атаче
Чуть — чуть попридираюсь. НЖЯ «Ресурсов на работу с техническим долгом выделяется крайне мало» звучит как предполагаемое решение. Это недопустимо. Нужно переформулировать. Для этого например, можно задать вопрос: «К чему это приведет?». Тогда может быть будет сформулировано правильно.
По поводу НЖЯ «У команды нет понимания, какую пользу приносит продукт». Не совсем понятно — польза на самом деле есть, или нет? Если есть, то НЖЯ звучит как обвинение персонала, а это недопустимо. К чему приводит то, что у команды нет понимания, какую пользу приносит продукт?
Согласен, спасибо.
Тогда возможно такая формулировка:
НЖЯ: Программный код продукта сложно сопровождать
На всякий случай поясню, про нашу кухню:
Дело в том, что в программировании одна из главных проблем — это управление сложностью. Т.е. когда в продукте тысячи строк кода, то важно внутреннее его устройство и организация. Никакой программист не способен его запомнить, а значит важнее становиться «читаемость», т.е. как быстро программист сможет восстановить организацию и алгоритм работы куска кода, в котором ему нужно сделать изменения или дополнения. Также важны стандарты команды, когда код удовлетворяет, некоторым иногда неявным, стандартам, что позволяет программисту гораздо быстрее понимать код другого. Технический долг возникает, когда заставив написанный код выполнять бизнес функцию мы не тратим время на его внутреннее упрощение и приведение к стандартам команды и платим за это потом.А по второму я бы так сформулировал, хотя что-то не уверен:
НЖЯ: Продукт не удовлетворяет нефункциональным требованиям
Поясню. Когда аналитик ставит задачу, реализовать определенную функцию, зачастую могут быть скрытые требования, которые мы можем выяснить только реально дав пользователю поработать с данной новой функцией. Но некоторые скрытые требования могут выявить программисты и понимание ими задач продукта сильно в этом помогает. К тому же частенько возникают идеи, как сделать решение на порядок более дешевым по времени и сложности, не сильно при этом задев интересы пользователя.Доброго дня, Филипп!
В открытых источниках можно найти следующие 10 правил, которые помогают лучше формулировать НЖЯ:
1) НЖЯ – это постоянная проблема, которая существует в вашей действительности, из-за нее вы не можете достичь лучшего уровня деятельности.
2) Это описание состояния, а не одноразового случая или действия. (НЖЯ не может содержать глаголы действий типа «взять», «идти» и т.д.)
3) Это явление находится в вашей области ответственности.
4) Относительно этого явления возможно что-то предпринять.
Например, «На улице слишком жарко» – это не НЖЯ.
Мы не можем изменить то, что на улице жарко. Мы можем изменить только наши действия: то, что мы предпримем, чтобы нам не было жарко.
5) НЖЯ не должно обвинять кого-либо.
6) НЖЯ не должно быть предполагаемой причиной.
«Сотрудники недостаточно обучены» – это не НЖЯ, это предполагаемая причина: «Поскольку сотрудники недостаточно обучены…»
7) НЖЯ не должно быть завуалированным решением (желанием того, как можно было бы решить проблему).
8) НЖЯ не должно требовать пояснения того, какой негативный эффект оно вызывает.
9) НЖЯ не может содержать причинно-следственную связь.
10) НЖЯ не должно быть субъективным утверждением: не должно содержать оценочных прилагательных и наречий, таких как «сложный / сложно», «хороший / хорошо», «плохой / плохо», «минимальный», «максимальный» и т. п.
(источник: Одед Коуэн, Елена Федурко «Основы Теории Ограничений»)В представленном Вами ДТР есть очень странные, на мой взгляд, вещи: вроде «ключевой функциональности, не работающей на данных пользователей». Белке, бегущей в колесе, порой очень сложно понять, что она на самом деле никуда не бежит.
Возможно Вашей команде стоит взять паузу в стремительном движении и просто осознать что за продукт вы делаете? Что вы хотите получить? Кто является заказчиком этого продукта, и как этот заказчик связан с теми, кто будет пользоваться продуктом? Прежде всего необходимо определиться с целью создания продукта. Если Ваша задача создавать продукт — это один набор действий, если же задача создать — то совершенно другой. Не так и важно, что уже было создано на текущий момент. Затраченные усилия безусловно очень ценны для тех кто их совершал, но вовсе не обязательно ценны для итога этих усилий.
Есть ли у Вас список требований к функциональности проекта упорядоченный по степени важности? Есть ли понимание по каким критериям эта упорядоченность создана?
- Форум «Теория ограничений: инструменты и практика» закрыт для новых тем и ответов.