вторник, 20 августа 2013 г.

Мои 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. Они дают бесконечно количество знаний, которые делают тебя лучше.  

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


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

6. MacBook

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

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

7. Любовь 

Yep.


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

среда, 14 августа 2013 г.

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


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

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

  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 в случае проблем. Но это не решение.

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

среда, 7 августа 2013 г.

Lean №11 - Поставляйте как можно быстрее

Зачем поставлять быстро?

  1. Это нравится Заказчику. Чем быстрее покажешь, тем ему приятнее, тем быстрее он сможет использовать продукт.
  2. Это снижает риски. Вы можете много закодировать, но пока это не в проде, вы не снимите все риски.
  3. Это позволяет принимать решения как можно позже. Вместо того чтобы месяц думать над сложным решением, лучше показать через неделю и снизить уровень неопределенности, чтобы иметь возможность принять более правильное решение.
Что предлагается для этого:
  1. Переход с Push системы на Pull. Всегда кажется что чтобы команда работала наиболее эффективно, необходимо микроменеджмент чтобы каждому говорить что ему нужно делать в каждый момент времени. Проблема в том что ИТ системы довольно сложны и комплексны, и четкий план мало вероятен. Лучше работает Pull система, основанная на сигналах и договоренностях. Для этого можно использовать:
    1. Короткие итерации.
    2. Визуальный контроль. Так как работа само-управляема, необходима визуализация того что происходит для всех. Burn-down chart, список проблем, список возможных рефакторингов, список идей для улучшений, статус сборок, статус тестов. Это все улучшает процесс само-организации. Нужно подумать как это можно улучшить сейчас.
  2. Теория очередей. 
    1. Необходимо постоянно оценивать время цикла и работать над тем чтобы его снизить. Время от начала грумминга истории до ее закрытия. Время от начала разработки истории с спринте, до ее установки на UAT стенд. 
    2. Постоянная скорость прибытия работ. Скидки в ресторанах в дневное рабочее время, дешевый трафик по ночам. Все стараются избежать пиковых нагрузок и распределить их более равномерно. Не нужно выгружать все истории на тестирование в конце спринта - нужно стараться распределить поставку более равномерно. Не важно что вы много кодируете, если не успеваете это тестировать. Не важно много тестировать, если вы не успеваете выгружать это в прод.
    3. Малые объемы работ. Чем меньше объем задачи, тем быстрее она пройдет весь процесс, тем меньше для нее будет время цикла. Тем быстрее ее можно будет протестировать и закрыть. Это позволяет распределить процесс тестирования по спринту более равномерно, и не сваливать его в самый конец.
    4. Оценивайте объем работы, который ждет чтобы его выполнили. Он будет соотносится с временем цикла. Нужно посмотреть на все наши процессы более обще, со стороны.  
    5. Чем больше вариативность времени прибытия работ или времени исполнения работ, тем выше будет время цикла и время ожидания работ. 
    6. Чем больше объем работ, тем больше вариативность времени прибытия и исполнения (при чем не линейно). Из этого следует что более эффективно уметь разбивать User story для спринта на примерно одинаковый объем (оценку в points) чтобы сделать процесс более предсказуемым. Тогда время цикла будет меньше, ожиданий будет меньше, визуализация на Burn-down chart лучше.
    7. Уменьшение вариативность в начале процесса оказывает больше влияния чем уменьшение вариативности в конце процесса.
Надо измерять и много думать. Можно использовать как одну из тем на ретроспективе.

Как быстро оценить стоимость проекта

Читаю How to Measure Anything - очень круто и жутко полезно.



Приходит на оценку проект с большой степенью неопределенности. Даже не проект - Концепция проекта. Идея, из которой я даже vision не могу сформировать. Есть Идея на создание федеральной системы - "Самой Главной".  Но для vision в самом начале нужны пользователи и их проблемы. Их нет в концепции, есть лишь ощущение что Система будет Самой Главной и потому жутко полезной.

Нет vision - нет целей. Нет целей - нет объема предположений, которые нужно провалидровать для их достижения.

Оцени!

Книжка крута мыслью что "оценка - это снижение неопределенности под нужным углом зрения". То есть главное здесь определить нужный вам угол зрения, и неопределенность после оценки должна снизиться.

Метод 1 - MS Project.

Лет 5 назад процесс предварительной оценки у меня сводился к следующему. Берешь MS Project, вписываешь в него работы, назначаешь людей на работы, задаешь рейт и MS Project сам считает себестоимость. При чем в начале сумма выходила не очень большой. Тогда ты расписываешь все работы в глубину, и общая сумма начинает увеличиваться. Расписываешь до тех пор пока сумма не увеличится до нужного тебе числа. Как только общая сумма стала солидной, ты останавливаешься и говоришь что дальше расписывать смысла нет - это уже частности.

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

Метод 2 - Простой.

Оценивая Концепцию по своему опыту определяешь за какой время возможна ее реализация силами твоей команды. N месяцев * стоимость Команды = Себестоимость. Далее Маржа, НДС и тп = Сумма проекта.

Метод 3 - Экспертный, 90%.

Смотришь на Концепцию и оценки стоимости в голове не возникает. Можно оценить диапазон, в которую стоимость входит с вероятностью 90% (что довольно хорошо для данной оценки)
Спрашиваешь себя с вероятностью 90% какая минимальная стоимость проекта? 150 руб. То есть меньше чем за 150 руб ты бы точно не взялся за проект.
Какая максимальная стоимость проекта? 600 руб. То есть при сумме больше 600 руб ты уверен что проект не будет интересен Заказчику, или ты точно проиграешь в конкурсе на него.
То есть ты оцениваешь что с вероятностью 90% сумма проекта должна быть между 150 и 600 руб.
Нужно одно число? 600 + 150 / 2 = 375 руб

Метод 4 - Метод Монте Карло.

Формируешь крупно блочно состав работ по проекту. Для каждой работы оцениваешь диапазон сроков куда эта работа попадает с вероятностью 90%. Оцениваешь какое количество людей понадобится на данную работу - можно так же с диапазоном. Далее простая формула для общей суммы и метод Монте-Карло.

У меня результаты Методы 3 и 4 сошлись с расхождением меньше 5%.

воскресенье, 4 августа 2013 г.

Lean №10 - Простые правила

Решения принимаются на любом уровне. Не возможно предугадать все ситуации или все контролировать. Не возможно сформировать инструкции для всего. Потому предлагаются простые правила для принятия решений:
  1. Удаляйте потери. Тратье время только на то^ что приносит Заказчику ценность (value).
  2. Развивающее обучение. Если есть проблемы, увеличивайте feedback.
  3. Принимайте решения как можно позже. Оставляйте варианты решений как можно дольше. 
  4. Доставляйте как можно раньше. Доставляйте value Заказчику как можно раньше.
  5. Заряжайте свою команду. Позвольте сотрудникам раскрыть весь свой потенциал.
  6. Встраивайте целостность системы. Не пытайте достраивать целостность системы после, выстраивайте ее сразу.
  7. Смотрите в целом. Не стоит оптимизировать части системы, только всю систему.
Это основные принципы Lean.

четверг, 1 августа 2013 г.

Lean №9 - Принятие решение в самый последний момент

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

Что предлагается для того чтобы это было возможно:
  1. Не делайте дизайн системы в самом начале. Дизайн системы должен развиваться по мере того как мы больше узнаем про систему и требования к ней. 
  2. Оптимизируйте процесс взаимодействия между теми что знает бизнес и тем кто знает код чтобы упростить внесение изменений в дизайн системы.
  3. Любители пытаются сделать все правильно с первого раза. Эксперты выявляют ошибки до того как они приведут к проблемам.
  4. Используйте объект-ориентированный дизайн и компонентную разработку. Например:
    1. Используйте модули. Прячьте поведение внутри модуля, откладывайте дизайн модуля как можно дольше.
    2. Используйте интерфейсы. Отделите интерфейсы от реализации.
    3. Используйте параметры.
    4. Используйте абстракции.    
    5. Декларативное программирование, а не процедурное. Алгоритмы не должны зависеть от окружения.
    6. Избегайте повторений кода - DRY. 
    7. Модуль имеет одну, простую функцию. Поэтому метод по валидации объекта не должен менять содержимое этого объекта (чтобы оптимизировать лишний SQL запрос), Марат.
    8. Инкапсуляция. Изменения не должны приводить к каскадными изменениям в других модулях.
  5. Реализуйте максимально простое решение сейчас вместо того чтобы делать решение которое будет удовлетворять "будущим" потребностям. Завтра вы будете знать больше, потому завтра вы сделаете более крутое решение.
  6. Избегайте лишних фич, добавляйте их лишь just-in-case. Любая фича - это потери на понимание, реализацию, тестирование, подддержку. НЕ бывает бесплатных фич.
  7. Исследуйте то что критически важно бизнесу. Малое время формирования ответа. Когда тратить на него силы? В самом начале и потом поддерживать его до конца проекта, или оставить на завершение работ и сэкономить время? Это не ваше решение - это приоритет бизнеса. Если ему это критически важно - сделайте в самом начале, чтобы снизить риски изменения архитектуры в конце работ.
  8. Чем медленнее ваша реакция на изменения, тем раньше вам нужно принимать решения. Чем быстрее вы можете менять код системы, тем больше вы сможете отложить решение.