воскресенье, 6 августа 2017 г.

Критическая цепь. Элия Голдратт


Ссылка на OZON

Еще один роман от Голдратта. Другие романы в том же духе: Цель, Цель-2, Цель-3.
Написано в виде романа, то есть читается довольно легко, но... Приходится включать мозг, а это уже сложно ツ 

Но полезно!


Введение


Главный герой — учитель программы МВА. Он должен был получить тенуру, а в итоге оказался на грани увольнения. Тенура — постоянный контракт преподавателя. Если ты его получаешь, то можно не волноваться о том, будут деньги или нет. Не надо откладывать на старость итд.

Проблема в том, что набирать людей на МВА стало все сложнее. Это же дорого стоит, вот и плодятся университеты, готовящие таких специалистов. И если раньше получил МВА = получил престижную работу, то теперь уже нет. Берут далеко не всех, а зачем тогда учиться? А еще оказывается, что знания, которые дают на обучении, далеки от реальности. И начальство не горит желанием посылать студентов на курс. В итоге набор небольшой. И поэтому директор университета Ричарда (главный герой) замораживает все тенуры. Платить то нечем.

А Ричард как раз взялся за курс по управлению проектами. А еще один из преподавателей только что вернулся со стажировки в компании Юни Ко, а там ТОС и все такое. В общем, вернулся умный и стал распространять свои идеи.

Обсуждаемые проблемы


На курс записались люди из разных фирм: Генмодем (модемы делают), строительная фирма итд. Причем проблемы у всех одинаковые — проекты не успевают заканчиваться в срок. В итоге мы делаем что? Правильно, или выкидываем функционал, который не успели сделать, или сдвигаем сроки на несколько месяцев / релизов.

Знакомо, не правда ли? Wink ;)

Причины проблем 




1. Раздутые сроки



Когда нас спрашивают, сколько времени займет задача, мы сознательно раздумаем срок. Чтобы уж наверняка в него уложиться.  Они там, конечно, выводили это чуть ли не весь урок, строили диаграммы Гантта:

Марка попросили отметить на графике точку,
как он называет сроки

Это как когда ты едешь домой на машине. Нельзя сказать четко, сколько времени это займет. Утром минут 45, вечером уже около часа. А совсем утром я как-то доехала чуть ли не за полчаса! И наоборот, когда авария на МКАД-е, можно в пятницу все три пиликать...

В общем, согласно диаграмме, наиболее вероятный исход — посередине кривой. Но это только 50% шанс, что успеете вовремя. Никто в здравом уме такую оценку не даст. Мы будем спокойны за оценку, если будет хотя бы 80% шанс, что мы успеем вовремя. А плюс 30% к уверенности — это чуть ли не 200% подстраховки!

Знаете, это больная тема. Мы не просто знаем о ее существовании, мы сами закладываем времени "побольше, побольше". Если планируем небольшую задачку, то там все просто и оценки такие же. А вот если это будет киллер-фича... То диалог выглядит примерно так:
— Сколько тебе надо?
— Нууууу... Дней 5...
— Ставь ему 7 лучше!

Мне не кажется это правильным, ведь получается, что мы НЕ берем в релиз какие-то задачи на планировании из-за раздутых сроков. А мелкие задачи, которые прилетают в течение релиза, берем. Ведь мы знаем, что есть запас по времени.


2 Синдром студента


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

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

Замечали за собой этот синдром? Я не люблю, когда на меня давят сроки, но когда дедлайн проходит, с удивлением отмечаю, как лениво смотрю на задачки. Нуууу, релиз то нескоро, еще все успею!

Или у нас была ситуация — у разработчика есть большая киллер-фича. На митинге обсуждаем, что надо ее делать до экватора, пусть он начнет сегодня. Встречаемся через два дня:

— Так, а ты что делал?
— Ну, я мелкие задачки поразгребал.
— Ээээ, погоди, а киллер-фича?
— А что, надо ее уже делать?
— Мы же на прошлом митинге договаривались, что да.
— Ну... Ладно, сегодня начну.


3. Мерфи


Закон Мерфи — если что-то может произойти, оно произойдет.

С ним ничего нельзя сделать. Собственно, именно из-за него и закладывают большие оценки, никогда не знаешь, что пойдет не так. Начнешь делать задачку. О, тут еще надо проверить. И тут зарефачить, и там... Отсюла и большие оценки. При это ты понимаешь, что можешь справиться быстрее и см пункт 2. Замкнутый круг Smile :)


Методы решения


Ребята из Генмодема решили построить критический путь — то, без чего проект не закончится. Сократили все оценки, но хитро. Допустим, раньше задача оценивалась в 5 дней. Теперь ее официальная оценка была 3 дня, а еще 2 остались «питающим буфером». На Мерфи.

То есть итоговая дата не сдвинулась, просто появился буфер проекта. Вот мы хотим пройти весь критический путь не за 2 месяца, а за 5 недель. А еще 3 недели — на всякое разное оставим. И после каждой важной задачи поставим небольшой питающий буфер, чтобы защитить следующий элемент. Получилось примерно так:



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


Мои выводы


Это все очень интересно. Потому что в проблемах я узнаю себя. Но всегда сложно применить к себе прочитанное. Знаете, то самое чувство «Ну, это у них получилось, но у нас то совершенно другая ситуация!».

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

— А почему ты поздно начала?
— Я же говорила на митингах!
— Не помню такого.

Что только подтверждает, что надо что-то менять. А то я уж думала, что это только я такая забывчивая. 

В общем, посмотрим, к чему это все приведет. Но книга очень интересная. Особенно если вдумчиво ее читать 

Правда, в этом есть и своя сложность — вроде как написано в виде романа, а все равно долго не почитаешь. По крайней мере в метро после рабочего дня, когда мыслетопливо почти кончилось. 

Но были и забавные моменты! Главный герой же преподаватель. У него есть и «вредные» студенты. На что он и жалуется между делом: «Преподаватель должен любить своих студентов. Но с некоторыми эта миссия невыполнима». Это так смешно читать )))) Но при этом и свои чувства вспоминаешь. Да да, иногда я его так понимаю! ))

В общем, книга более чем достойная! И для ИТ-команд она очень подходит. Попробуйте, почитайте, наложите на свой опыт. И потом попробуйте сделать мир чуточку лучше, начав со своей команды! 

2 комментария:

  1. Отлично.

    Добавлю:
    1. Посмотрите результат эксперимента "Ошибка планирования" от 1994 года. Там приведена особая ошибка вариаций. Ее можно скомпенсировать.
    2. Но еть еще и общая ошибка. Попытка скомпенсировать ее приводит к увеличению разброса. Что наглядно продемонстрировать ДеМарко с Листером.

    Сам факт наличия оценки трудоемкости задачи приводит к увеличению времени проекта в полтора-два раза.

    ОтветитьУдалить
    Ответы
    1. А как же планировать без оценки трудоемкости? Просто разгребать беклог?)

      Удалить