четверг, 24 октября 2013 г.

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

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

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




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

вторник, 22 октября 2013 г.

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


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

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

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

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

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

Ссылка на mindmap

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




понедельник, 21 октября 2013 г.

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

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

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

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

воскресенье, 6 октября 2013 г.

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

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

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


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

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


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

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

3. Лидерство


Тут понятно. Все время ищи проблемы у себя и анализируй их.
Не могу делегировать процесс бизнес-анализа так как решаю сам их проблемы.
Нет давления по тестированию - нет крутого тестирования.
Проблемы архитектуры не становятся проблемой команды - потому нет желания делать KISS решения.

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


С трудом вижу возможности для распространения различной экспертизы в рамках Компании. Это настолько не свойственно для крупных компаний. И все то обучение что выстроено - оно кажется таким малополезным. 
  • Как делать презентации? 
  • Изучаем SQL. 
  • Делегирование. 
Это все здорово, но это не экспертиза. Это какие-то навыки. Потому меня полезным кажется только платные обучение в ScrumTrek. Хотя мы сами можем выстроить все эти тренинги внутри и иметь их бесплатными.
  • У нас отсутствует процесс тестирования в проектах. Его заменяет процесс создания бессмысленных скриптов на Selenium. 
  • Процесс аналитики выстраивается только в рамках старой Waterfall парадигмы. 
  • Разработка? Нет смены культуры с создания value для бизнеса вместо технических задач.
Думаю эта настоящая экспертиза. Это хотелось бы развивать. Но желание в Компании отсутствует.