Ссылка на OZON
Еще один роман от Голдратта. Другие романы в том же духе: Цель, Цель-2, Цель-3.
Написано в виде романа, то есть читается довольно легко, но... Приходится включать мозг, а это уже сложно ツ
Но полезно!
Введение
Главный герой — учитель программы МВА. Он должен был получить тенуру, а в итоге оказался на грани увольнения. Тенура — постоянный контракт преподавателя. Если ты его получаешь, то можно не волноваться о том, будут деньги или нет. Не надо откладывать на старость итд.
Проблема в том, что набирать людей на МВА стало все сложнее. Это же дорого стоит, вот и плодятся университеты, готовящие таких специалистов. И если раньше получил МВА = получил престижную работу, то теперь уже нет. Берут далеко не всех, а зачем тогда учиться? А еще оказывается, что знания, которые дают на обучении, далеки от реальности. И начальство не горит желанием посылать студентов на курс. В итоге набор небольшой. И поэтому директор университета Ричарда (главный герой) замораживает все тенуры. Платить то нечем.
А Ричард как раз взялся за курс по управлению проектами. А еще один из преподавателей только что вернулся со стажировки в компании Юни Ко, а там ТОС и все такое. В общем, вернулся умный и стал распространять свои идеи.
Обсуждаемые проблемы
На курс записались люди из разных фирм: Генмодем (модемы делают), строительная фирма итд. Причем проблемы у всех одинаковые — проекты не успевают заканчиваться в срок. В итоге мы делаем что? Правильно, или выкидываем функционал, который не успели сделать, или сдвигаем сроки на несколько месяцев / релизов.
Знакомо, не правда ли?
Причины проблем
1. Раздутые сроки
Когда нас спрашивают, сколько времени займет задача, мы сознательно раздумаем срок. Чтобы уж наверняка в него уложиться. Они там, конечно, выводили это чуть ли не весь урок, строили диаграммы Гантта:
Марка попросили отметить на графике точку, как он называет сроки |
Это как когда ты едешь домой на машине. Нельзя сказать четко, сколько времени это займет. Утром минут 45, вечером уже около часа. А совсем утром я как-то доехала чуть ли не за полчаса! И наоборот, когда авария на МКАД-е, можно в пятницу все три пиликать...
В общем, согласно диаграмме, наиболее вероятный исход — посередине кривой. Но это только 50% шанс, что успеете вовремя. Никто в здравом уме такую оценку не даст. Мы будем спокойны за оценку, если будет хотя бы 80% шанс, что мы успеем вовремя. А плюс 30% к уверенности — это чуть ли не 200% подстраховки!
Знаете, это больная тема. Мы не просто знаем о ее существовании, мы сами закладываем времени "побольше, побольше". Если планируем небольшую задачку, то там все просто и оценки такие же. А вот если это будет киллер-фича... То диалог выглядит примерно так:
— Сколько тебе надо?
— Нууууу... Дней 5...
— Ставь ему 7 лучше!
Мне не кажется это правильным, ведь получается, что мы НЕ берем в релиз какие-то задачи на планировании из-за раздутых сроков. А мелкие задачи, которые прилетают в течение релиза, берем. Ведь мы знаем, что есть запас по времени.
2 Синдром студента
Плавно вытекает из предыдущего пункта. Когда мы точно знаем, что времени у нас вагон, то особо не торопимся. И если есть мелкие задачки, разгребаем их.
Об этом пишет Максим Дорофеев в книге «Джедайские техники»: мыслетопливо не бесконечное. Поэтому, если мы беремся с утра за мелкие задачки «Да да, сейчас начну делать большую и сложную, только вот эту мелочь быстренько разгребу», то до «большой и сложной» дело в итоге вообще не доходит. Просто потому, что силы закончились.
Замечали за собой этот синдром? Я не люблю, когда на меня давят сроки, но когда дедлайн проходит, с удивлением отмечаю, как лениво смотрю на задачки. Нуууу, релиз то нескоро, еще все успею!
Или у нас была ситуация — у разработчика есть большая киллер-фича. На митинге обсуждаем, что надо ее делать до экватора, пусть он начнет сегодня. Встречаемся через два дня:
— Так, а ты что делал?
— Ну, я мелкие задачки поразгребал.
— Ээээ, погоди, а киллер-фича?
— А что, надо ее уже делать?
— Мы же на прошлом митинге договаривались, что да.
— Ну... Ладно, сегодня начну.
3. Мерфи
Закон Мерфи — если что-то может произойти, оно произойдет.
С ним ничего нельзя сделать. Собственно, именно из-за него и закладывают большие оценки, никогда не знаешь, что пойдет не так. Начнешь делать задачку. О, тут еще надо проверить. И тут зарефачить, и там... Отсюла и большие оценки. При это ты понимаешь, что можешь справиться быстрее и см пункт 2. Замкнутый круг
Методы решения
Ребята из Генмодема решили построить критический путь — то, без чего проект не закончится. Сократили все оценки, но хитро. Допустим, раньше задача оценивалась в 5 дней. Теперь ее официальная оценка была 3 дня, а еще 2 остались «питающим буфером». На Мерфи.
То есть итоговая дата не сдвинулась, просто появился буфер проекта. Вот мы хотим пройти весь критический путь не за 2 месяца, а за 5 недель. А еще 3 недели — на всякое разное оставим. И после каждой важной задачи поставим небольшой питающий буфер, чтобы защитить следующий элемент. Получилось примерно так:
Потом они столкнулись с проблемой развертывания решения на всю компанию. Оказалось, что построить критический путь недостаточно, потому что есть ресурс Х, который нужен всем. И в итоге всех обсуждений построили критическую цепь. Она длиннее критического пути, так как учитывает конкуренцию за ресурсы. И ставит работы Х последовательно, а не в параллель..
Мои выводы
Это все очень интересно. Потому что в проблемах я узнаю себя. Но всегда сложно применить к себе прочитанное. Знаете, то самое чувство «Ну, это у них получилось, но у нас то совершенно другая ситуация!».
Как раз недавно у нас была ретроспектива и мы решили попробовать построить свою критическую цепь. И отлеживать на митингах именно ее. Не просто "кто что делает и какие проблемы?", а только важное с точки зрения цепи. А то наша комада выросла и митинги стали затягиваться. При этом важная информация теряется. Уже пару раз такое было. Я на митинге машу руками и говорю "я еще не начала делать важную задачу, потому что...", а потом на ретро столько удивления:
— А почему ты поздно начала?
— Я же говорила на митингах!
— Не помню такого.
Что только подтверждает, что надо что-то менять. А то я уж думала, что это только я такая забывчивая.
В общем, посмотрим, к чему это все приведет. Но книга очень интересная. Особенно если вдумчиво ее читать ツ
Правда, в этом есть и своя сложность — вроде как написано в виде романа, а все равно долго не почитаешь. По крайней мере в метро после рабочего дня, когда мыслетопливо почти кончилось.
Но были и забавные моменты! Главный герой же преподаватель. У него есть и «вредные» студенты. На что он и жалуется между делом: «Преподаватель должен любить своих студентов. Но с некоторыми эта миссия невыполнима». Это так смешно читать )))) Но при этом и свои чувства вспоминаешь. Да да, иногда я его так понимаю! ))
В общем, книга более чем достойная! И для ИТ-команд она очень подходит. Попробуйте, почитайте, наложите на свой опыт. И потом попробуйте сделать мир чуточку лучше, начав со своей команды! ツ
PS: добавила книгу в общий список прочитанных мною книг.
Отлично.
ОтветитьУдалитьДобавлю:
1. Посмотрите результат эксперимента "Ошибка планирования" от 1994 года. Там приведена особая ошибка вариаций. Ее можно скомпенсировать.
2. Но еть еще и общая ошибка. Попытка скомпенсировать ее приводит к увеличению разброса. Что наглядно продемонстрировать ДеМарко с Листером.
Сам факт наличия оценки трудоемкости задачи приводит к увеличению времени проекта в полтора-два раза.
А как же планировать без оценки трудоемкости? Просто разгребать беклог?)
Удалить