Теория ограничений или как измерить качество?

Я не люблю Теорию ограничений - скука смертная. Если бы не художественное изложение ряда книг - ничего бы не осилил. У меня все еще теплится надежда попробовать эти диаграммы для решения проблем, но пока не могу найти случая и команды для этого. Наверное нужны желающие чтобы можно было это делать совместно - просто впихивать это своим сотрудникам можно их сразу отпугнуть от ТОС и они даже не захотят потом читать про него.

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

Опишу то малое что я взял и хочу использовать.
В производстве есть 3 показателя, которыми можно описать нашу деятельность

• Выпуск - то что мы выпускаем и продаем, то есть наш доход от продажи продукции
• Операционные расходы - наши затраты на осуществление деятельности, которые нельзя вернуть
• Инвестиции - наши инвестиции в производство, которые мы можем в будущем обналичить и вернуть

В результате все НАША деятельность направлена на достижение простой Цели

• Увеличивать выпуск
• Уменьшать операционные расходы и инвестиции

Теперь что это относится к ИТ.

• Выпуск - это тот продукт что мы разрабатываем. Чтобы его померить не хочется оперировать деньгами, сделаем упрощение и будем измерять его в кол-ве фич, которые мы выпускаем, или Velocity (да, это неправильно. Я знаю. Это упрощение). То есть мы выпускаем фичи - нам за них ПЛАТЯТ. При этом мне сразу хочется здесь выделить из всего Выпуска его часть и назвать его Value. Это те фичи, которые реально нужны заказчика. То есть платит он нам за все фичи, но его реально нужны лишь ЧАСТЬ из них
• Трудозатраты - все трудозатраты, которые списываются на проект. В часах. Легко переводится в деньги.
• Инвестиции - тут сложнее. Нет у меня станков или роботов, которые потом можно будет продать. Можно попробовать переделать это в знания, которые в дальнейшем помогают нам выпускать лучше, и тогда стратегия меняется на их увеличение. НО лучше упростить - инвестиций нет.

То есть вся моя деятельность как менеджера направлена на увеличение выпуска и уменьшение трудозатрат. Это было интуитивно понятно и до ТОС.

Но далее появляется следующее утверждение. Любое улучшение должно быть измерено относительно этих показателей. И мы делаем переход в нашу реальность.

Ко мне приходят аналитики Маша и Катя и говорят что они сильно постарались и перевели процесс поставки требований в Use Cases на User Stories. И теперь этот процесс занимает в 2 раза меньше времени. Я узнаю увеличилась ли скорость разработки, то есть Выпуск. Он не увеличился (предположим).  Я увольняю Машу. Так как Выпуск не увеличился, то для Общей Цели это ничего не дает. Зато теперь я могу снизить трудозатраты. После этого никто никаких "инноваций" мне не предлагает.

Конечно же я считаю что практика User Story полезна. Она должна заставить команду меньше общаться через документы и больше общаться в живую. В результате процесс передачи знаний должен улучшится, снизится время на переработку фич в результате непонимания, и должен увеличится Выпуск.
А снижение трудозатрат аналитиков мы используем чтобы перенести часть работ со Спринта на предспринтовую деятельность. Например, более детальную проработку UI прототипов, что так же должно увеличить Выпуск. Используйте User Stories.

Потому можно утверждать что любая практика, которую вы решите внедрить, должна увеличивать Выпуск. То есть TDD, BDD, CI, Code Review и тп должны "драйвить” разработку вперед. Если новая практики оптимизирует только какую-то ЧАСТЬ процессов и не увеличивает Выпуск, то это Wastes. Можно выкидывать.

Давай поставим новую Jira. Выпуск увеличится? Waste.
Давай перейдем на Jenkins. Waste.
Давай будем описывать в Confluence How-To, которые нам возможно потом помогут. Waste.

Трудозатраты чаще всего мы не можем уменьшить. На практике мы не увольняем людей из команды. Если аналитики стали работать меньше, а вы не можете никак это превратить в Выпуск - Вам это ничего не дает.

Как измерить Качество?

Мы пишем unit-тесты - мы увеличели Качество. Хм, а как проверить?
Фактически Качество так же заложено в вашем Выпуске и Трудозатратах.

Вы используете CI чтобы быстро находить баги и исправлять их. В результате баг исправляется за 2 минуты сейчас, а не за N часов или M дней завтра с использованием поддержки 1, 2 и 3 уровней. Это не стопает разработку, значит “драйвит” Выпуск.

Или качество это увеличение соотношения Value / Выпуск, то есть больше поставки того что бизнесу надо, а не то что написано в ТЗ. НО вам еще нужно постараться превратить это деньги. Если вы не можете превратить это в деньги, то такое качество Вам не нужно. Именно так и происходит в заказной разработке. Платят за фичи в ТЗ, а не за то что процент ПОЛЕЗНЫХ для бизнеса фич будет выше.

Книга "Switch: How to Change Things When Change Is Hard"

Книга о том как внедрять изменения в жизни. В свой жизни, в команде, в компании, в обществе. Такое обобщение всех практик и методов в одну стройную модель. 

Это сама модель в кратком виде. 

• Направляйте всадника. Всадник абсолютно логичен, быстро меняет направление. И для него нужно знать направление, знать путь (шаги до цели) и успешные примеры.
• Мотивируйте слона. Слон действует исходя из привычек и ощущений. Его сложно свернуть с пути. Потому нужно искать нужные ощущения для внедрения изменений. Разбивать весь путь на мелкие шаги и двигаться постепенно, праздную маленькие победы. Изменять мышление людей, чтобы они идентифицировали себя с теми кто уже изменился.
• Очищайте путь. То есть изменяйте окружение чтобы поддержать изменение. Вырабатывайте правильные привычки. Управляйте поведением окружающий (толпы).

И в книге очень много примеров изменений из разных сфер жизни. Есть даже про изменение механизмов госзакупок в USA. Мужик много смог изменить без ресурсов и власти.

Эту модель можно использовать везде. Причем она хорошо описывает что есть много разных причин для fails во внедрении изменений.

Я хочу похудеть но этого не происходит. Я понимаю что у меня нет достаточной мотивации для этого. Вес 92, рост 192. Идеально совпадает с формулой. И вроде бы всадник хочет, но слон не имеет ощущений, достаточных для перем.

У кого-то огромная мотивация похудеть, но он не знает Как.

Кто-то знает Как, но окружение и привычки не позволяют. 

Same с желанием бросить курить.

В общем, это полезно не только для менеджмента, но и для личного роста и личных перемен.

Всем советую. 

Ссылка на mindmap

Как обычно - у меня можно попросить электронную версию.

Состав задач спринта

Закрывали релиз.
Было большое желание сделать все задачи по функционалу данного релиза перед тем как закрыть его. В результате мы набирали кучу всяких beefups из разных фич. Хотели - еще чуть-чуть и все. Так мы закрывали релиз 3 спринта. Набирали много несвязных задач - цель спринта было не определить.
Главное - было ощущение что нет никакого движения "вперед".

В результате решили следующее:

1. Чиним все основные баги (бесплатно, оценка 0)
2. Более половины спринта берем основной функционал, который сильно двигает продукт вперед. Это составляет цель спринта.
3. Набираем мелкие фичи (при необходимости)
4. Из всего множества beefups набираем только самые важные сверху.

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

Lean №12 - Заряжать команду

Профессионалы лучше менеджеров знают как выполнять свою работу. Необходима смена мышления с управления на помощь.

1. Сотрудники говорят менеджерам как нужно работать, а не наоборот. 

Выглядит круто, но не помню ни одного случая чтобы кто-то сам признал что есть проблемы и предложил улучшить процессы, культуры или что-то подобное. Обычно коллеги любят улучшать инструменты, фреймворки и тп. Что не сильно влияет на производительность, а просто переводит их на новый уровень комфорта.
И общая цель и мотивация на нее не меняют такой mindset, и видимо не будут. Наверное в этом роль менеджера - видеть чуть больше, направлять, учить.

2. Мотивация.

У команды должен быть не просто список задач в виде беклога, например. Нужна цель чтобы заряжать их. Как этого можно достичь:

• Начните со понятной и озвученной цели
• Убедитесь что цель достижима
• Дайте команде доступ до Пользователя
• Позвольте команде самой коммититься
• Удаляйте помехи и скептиков

3. Лидерство

Тут понятно. Все время ищи проблемы у себя и анализируй их.

Не могу делегировать процесс бизнес-анализа так как решаю сам их проблемы.

Нет давления по тестированию - нет крутого тестирования.

Проблемы архитектуры не становятся проблемой команды - потому нет желания делать KISS решения.

4. Экспертиза

С трудом вижу возможности для распространения различной экспертизы в рамках Компании. Это настолько не свойственно для крупных компаний. И все то обучение что выстроено - оно кажется таким малополезным. 

• Как делать презентации? 
• Изучаем SQL. 
• Делегирование. 

Это все здорово, но это не экспертиза. Это какие-то навыки. Потому меня полезным кажется только платные обучение в ScrumTrek. Хотя мы сами можем выстроить все эти тренинги внутри и иметь их бесплатными.

• У нас отсутствует процесс тестирования в проектах. Его заменяет процесс создания бессмысленных скриптов на Selenium. 
• Процесс аналитики выстраивается только в рамках старой Waterfall парадигмы. 
• Разработка? Нет смены культуры с создания value для бизнеса вместо технических задач.

Думаю эта настоящая экспертиза. Это хотелось бы развивать. Но желание в Компании отсутствует. 

Определение целей

Мои 7 Insights по эффективности

За последние полгода сильно изменилась жизнь в части моей собственной эффективности. А именно

1. Я очень доволен своим развитием. Есть ощущение прогресса, которого раньше не было.
2. Я доволен своей эффективностью.  
3. Я не ночую на работе. Я не перегружен, и потому могу принимать решения более правильно. Я вижу лес за деревьями. 
4. Теперь хочу еще больший прогресс.

Соответственно мои инсайты по увеличению эффективности (по приоритету):

1. Цели

По текущей модели я ставлю 10 целей на 3 месяца, и делаю все чтобы их достичь. Раньше были 3 цели на год - это слишком долго и скромно. За год цели успевают устареть + нужно хотеть большего, 3 - это слишком мало.

Кто-то говорит что у меня жизнь наперед расписана на будущее, все по плану. Это не так. У меня нет плана - у меня есть цели. Я не всегда знаю что я буду делать завтра, но я знаю цель, которую хочу достичь. Это разные вещи. 

И на самом деле очень странно жить без явно сформулированных целей. Странно жить лишь примерно понимая куда ты хочешь двигаться. Если нет четкой, измеримой цели - как тогда понять стал ли ты ближе к тому что ты хочешь или нет.

2. Agile results

Тут может быть любая GTD система которую вы выдержали более 3х месяцев, и сформировали привычку. Я использую Agile Results. Почему? Потому что Agile. Мне в ней нравится что 

1. Она простая
2. Она сфокусирована на цели, а не на time management
3. Там есть ретроспектива каждую неделю, когда я и правда нахожу что было плохо за неделю и строю предположения как это можно изменить. 

Нельзя делать одно и тоже каждую неделю и ожидать что когда-то будет лучше. Я каждую неделю тестирую 2-4 новые идеи. Из них 20% приносят пользу и изменяют систему эффективности. И это сильно.

За тот год что я применяю Agile Results, я ее модифицировал под себя и четко понимаю почему то, что было раньше не работало, и почему я сейчас делаю именно так.    

3. Рано вставать

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

Но по статистике успешные люди рано встают + они успевают сделать кучу всего до приезда на работу. И это правда офигенно. 

Я ложусь спать в 23 часов и встаю в 6 часов (раньше не могу - нужно будет ложиться в 22 часа, а это тяжело). Делаю физическую нагрузку или бегаю. Потом еду на работу и в 8 бываю в офисе. Голова свободна от разных мыслей, и с 8 до 10 часов я имею 2 креативных часа. За это время я успеваю сделать пару фокус задач из 3-х задач на день. Успеваю сделать задачи на levelup в области, которая мне интересна. К 10 часам когда в офис начинают приходить коллеги, у меня возникает ощущение что я уже сделал все, что планировал на день. И остались лишь рутинные задачи и встречи по работе.

Раньше (или сейчас если я неожиданно вдруг просплю) из-за рабочих вопросов и встреч я мог не успеть даже запланировать свой день, и потому не сделать ничего из фокус задач. Теперь этого не происходит. Каждый день я сделаю что-то что приближает меня к моим целям. 

4. Восстановление энергии

Есть такая книжка "The Power of Full Engagement: Managing Energy, Not Time, Is the Key to High Performance and Personal Renewal". По названию походит на очередную псевдо-теорию про мотивацию. Но на самом деле очень чудная книжка с понятным подходом о том почему энергия важнее чем время ("вечером есть время сделать что-то важное и полезное, но сил что-либо делать нет"). И про простые способы постоянного восстановления энергии. 

Исходя из описанного я понимаю почему я бегаю по утрам. Не чтобы похудеть. Чтобы похудеть - нужно есть на 2 ведра меньше. Я бегаю чтобы восстановить умственную энергию для утренних креативных часов и быть эффективнее на работе. Я не работаю в выходные, и хочу провести их максимально ярко, чтобы восстановиться на неделю и быть сильнее. 

Я работаю в среднем с 8 до 19 часов. Полчаса на обед. Не курю, чай не пью, в настольный футбол не играю. В результате раньше часам к 15 был как овощь, часто болела голова. Делать перерывы на полчаса, отдыхать, пить чай - не помогало. Я сделал список из 5 занятий, которые меняют мою активность и помогают восстановить умственную энергию. Например, общаться с коллегами чтобы узнать/решить их проблемы, визуализировать проблему на доске чтобы найти решение, визуализировать на графическом планшете знания для предстоящих встреч. Ага, видимо мозг здесь не включается.

Это помогает гораздо лучше чем просто отдохнуть и перекусить. И это согласуется с теорией.    

5. Книги 

Есть огромное количество супер полезных, общепризнанных книг в оригинале на Amazon. Они дают бесконечно количество знаний, которые делают тебя лучше.  

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

http://www.shelfari.com/andreysapozhnikov/shelf

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

6. MacBook

Не знаю как это работает, но MacBook физически приятнее открывать чтобы поработать. Какой-то позитив от работы увеличивает внутреннюю мотивацию и делает тебя эффективней. Или это так мобильность в работе с ним делает тебя лучше. Не знаю. 

Но этот ноут что-то изменил по сравнению в тем, что было раньше. Мистика. Не реклама.

7. Любовь 

Yep.


Еще есть vision, который описывает в одном предложении, "Зачем?" я что либо делаю и "Почему?" Это интересно иметь чтобы периодически сверятся с ним в тяжелых жизненных решения.

Инкрементальность и прозрачность

Мы не успели. Мы хотели реализовать фичу с межведом и не успели.

Какие есть факты?

1. Команда А потратила в совокупности примерно 2 месяца на фичу межведомственного взаимодействия.
2. После этого была полная уверенность что все хорошо. Мы видели запросы - они создавали ощущение что все OK 
3. Комнада Б получила неделю чтобы показать свою часть и общее демо по задаче при сильно уменьшенном scope.
4. В результате продемонстрировать фичу в полном объеме не смогли.
5. Не смогли показать - значит все потраченное время это waste.

Знакомо?

Сейчас когда все видят fail, лучше всего пытаться что-то изменить. Мы все делали как раньше - это привело к fail, наверное есть что можно поменять.

Я вижу 2 проблемы.

Инкрементальность 

"Scrum employs an iterative, incremental approach to optimize predictability and control risk." Из Scrum Guide.

Как было в нашем случае. 

Мы разбили фичу на отдельные US, которые можно было делать параллельно. Потратили неделю. За день до демонстрации стали соединять куски в общую фичу. Вылезли проблемы. В результате ошиблись в сроках где-то на день, и как результат - фичу не показали. Это не единичный случай - большинство fail спринта имеют эту проблему в основе.

Как можно было сделать в рамках инкрементального подхода. 

Сделать маленькую сквозную задачу чтобы получить результат в самом минимальном объеме:

1. На форме ввода данных запроса есть только кнопка отправить запрос.
2. На клиентской части показываем лишь номер запроса и кнопка "Ответить".

Получить работающий прототип. На основе него принять следующие решения что и куда инкрементально развивать.

В рамках этого подхода через 2 дня была бы работающая фича в MVP виде. Риски по интеграции были бы удалены. Можно было бы параллельно развивать любые части, и в любой день иметь работающую фичу и тем функционалом, который был бы возможен с учетом сроков. Не нужно было бы сидеть по ночам.

Если бы это было бы не специальное демо, а просто обычный спринт - мы так же увидели бы фичу в конце спринта возможно с неполным АС. Но фича бы была. По ней можно было бы узнать больше и принимать следующие решения. Это крайне важно.

Какие варианты решения я вижу? 

Shift

Нужен shift мышления самих разработчиков. Его сейчас нет ни в одной из команд. Более того сейчас у разработчиков позиция что это нельзя делать, так как в инкрементальном подходе стоимость фичи выходит дороже. Нет - это не так. Это такое же заблуждение как с парной разработкой. "2 разработчика отдельно сделают всегда больше чем в паре." 

Эта смена мышления решит все проблемы с инкрементом продукта, но это сложно. Каждому в голову не залезешь.

Backlog 

Сверхспособный РО умеет так бить User Stories заранее что вынуждает команды из-за WIP ограничения поставлять продукт в рамках спринта инкрементально. Но фактически это означает что РО будет думать не над тем как быстрее и эффективнее сделать продукт. Его мысли направлены на то, чтобы вместо Scrum Master сформировать такие ограничения чтобы команда самоорганизовалась в сторону инкремента продукта. Это возможно, но это печально. 

Scrum Master 

SM может добиваться постепенной смены мышления в команде обсуждая реализацию каждую фичу и сподвигать их на инкрементальную разработку внутри монолитной единой крупной story как фичи. 

Прозрачность 

Второй факт что усугубляет проблему - это отсутствие прозрачности. Мы используем следующие утверждения:

1. Команда самоорганизована и отвечает только за финальный результат спринта. За промежуточные результаты в спринте никто не отвечает. То есть команде можно сказать что "у вас есть проблемы" только в самом конце спринта уже на демо. Когда все что могло случится - уже случилось и изменить ничего нельзя.
2. Burn-down chart ни о чем не говорит. Это мое любимое! Не важно что прошло пол-спринта и мы не съели ни одного point! Это не твои проблемы, Чувак! Ты нам мешаешь. Еще полчаса и мы сразу закроем 2 задачи на 5 и на 8, и все сразу станет OK.

В результате burn-down chart не используется, перетаскивание задач по статусам используется только чтобы видеть статус конкретной истории. То есть НЕТ НИКОГО прозрачного механизма, который бы мог показать как идет дела в любой момент времени. 

А его нет потому что он и не нужен. Подход прост - мы как Команда делаем что можем и в конце просто смотрим успели мы закрыть спринт или нет.

И все управления процессом поставки продукта у нас сводится к тому чтобы прийти за пару дней до демо и сказать - Чувак, нижних 3-х задач не будет, не жди. Давай выкинем их из спринта.

Chart - это один из механизмов перехода с Push управления на Pull на управление через  сигналы и прозрачности. РО должен не присутствовать на daily, и просто проходя мимо доски глядя на chart понять если ли риски на fail спринта и какие. Смысл chart-а в том что он убирает все эти эмоции и ощущения членов команд (Да, эта фича уже готова. Там пара тестов написать, залить в develop и перенесем в "Done"), и показывать просто цифры. Chart показывает факт - остальное ему не важно. В этом и смысл.

Для РО гораздо лучшей стратегией будет сократить scope ряда историй чтобы успеть сделать все запланированые фичи, чем выкинуть нижние фичи. Но он должен своевременно это увидеть. 

Что делать?

Я изменю процесс определения scope истории на более формальный и более определенный. Должно быть лучше видно как можно вырезать scope в случае проблем. Но это не решение.

Что делать командам А и Б?

Проведите ретроспективы и найдите решения по инкременту и прозрачности, которые будут работать у вас.