Менеджерские школы учат, как готовить проекты правильно. А реальность говорит про 30% успешного завершения проектов. Чувствуете проблему?
Этот доклад про опыт. Про множество подходов, которые смогут помочь ускорить разработку. Никакой уличной магии нет, есть множество рецептов, приводящих к результату, который даёт на выходе работающий продукт и радует заказчика. Это факторы планирования, технологий, психологии, презентации, приоритезации и многие другие.
Приготовьтесь к изменениям!
Продуктовая Аналитика — Карго Культ в современных компанияхEvgeny Kuryshev
В условиях быстрой разработки становится более важным и более сложным такой вопрос: если мы можем менять вектор развития продукта очень часто и умеем жить с изменяющимися требованиями, то как понять что мы рационально используем эту возможность, не прыгаем вперёд-назад, а остаемся сфокусированными в своём развитии продукта?
Тут, разумеется, есть куча инструментов и практик lean практики get out of the building, традиционная продуктовая аналитика и, конечно, всеми любимые A/B тесты.
Но многие бросившись использовать всё это внезапно понимают, что получившиеся процессы больше напоминают карго культы: A/B тестирование красных против зеленых кнопок на страницах где 100 человек в день с конверсией в 5% делают какой-то экшн. Или обвешивание счётчиками Google Analytics всех элементов интерфейса, который используют 3 человека в день. Или мы идем в гости к своим друзьям, чтобы узнать их мнение о новом дизайне, забывая о том что наши друзья совсем не репрезентативны.
С какими проблемами мы сталкивались, как мы разочаровались в этих практиках, успели их возненавидеть и как обратно поверили и полюбили эти и другие подходы развития и эволюции продук
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Менеджерские школы учат, как готовить проекты правильно. А реальность говорит про 30% успешного завершения проектов. Чувствуете проблему?
Этот доклад про опыт. Про множество подходов, которые смогут помочь ускорить разработку. Никакой уличной магии нет, есть множество рецептов, приводящих к результату, который даёт на выходе работающий продукт и радует заказчика. Это факторы планирования, технологий, психологии, презентации, приоритезации и многие другие.
Приготовьтесь к изменениям!
Продуктовая Аналитика — Карго Культ в современных компанияхEvgeny Kuryshev
В условиях быстрой разработки становится более важным и более сложным такой вопрос: если мы можем менять вектор развития продукта очень часто и умеем жить с изменяющимися требованиями, то как понять что мы рационально используем эту возможность, не прыгаем вперёд-назад, а остаемся сфокусированными в своём развитии продукта?
Тут, разумеется, есть куча инструментов и практик lean практики get out of the building, традиционная продуктовая аналитика и, конечно, всеми любимые A/B тесты.
Но многие бросившись использовать всё это внезапно понимают, что получившиеся процессы больше напоминают карго культы: A/B тестирование красных против зеленых кнопок на страницах где 100 человек в день с конверсией в 5% делают какой-то экшн. Или обвешивание счётчиками Google Analytics всех элементов интерфейса, который используют 3 человека в день. Или мы идем в гости к своим друзьям, чтобы узнать их мнение о новом дизайне, забывая о том что наши друзья совсем не репрезентативны.
С какими проблемами мы сталкивались, как мы разочаровались в этих практиках, успели их возненавидеть и как обратно поверили и полюбили эти и другие подходы развития и эволюции продук
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Тактическое управление продуктами: все еще недостающее звеноMaxim Gaponov
«Эти люди делают то, о чем я их прошу. Но в результате каждый раз получается не то, что мне нужно». Эта фраза, в той или иной форме, произносится каждым клиентом, с которым я работаю.
«У нас было все, что нужно. Требования, выборки, прототипы. В итоге не успели сделать и половину. А то, что сделали нежизнеспособно» — такое тоже встречается часто.
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Вы помните, как вы представляли себе Канбан, когда первый раз о нем услышали? Я помню. И с тех пор мое мнение о методе менялось, и не один раз, помогая найти новые пути для совершенствования сервисов в компании, в которой я работаю. В докладе я расскажу о своих наблюдениях глазами тренера и коуча, как меняются со временем взгляды команд на инструмент и какие новые возможности они для себя открывают
Джон Сильвер: Как управлять неидеальной командойDenis Tuchin
Чем больше я пишу и рассказываю о гибких методологиях управления проектами, тем больше получаю ответов, что эти методологии работают только в идеальных условиях, когда все сотрудники профессиональны, мотивированы достигать результаты и рады работать в команде. На деле же в большинстве случаев это не так – приходится работать с теми, «кого дают». Так вот доклад как раз о том, как руководить неидеальными сотрудниками, чтобы проект был успешным.
It talk №23: "Если не Scrum, то что?", Екатерина ШалапановаMarina Peregud
Докладчик: Екатерина Шалапанова, деливери-менеджер финансовой практики DataArt, Петербург
О чем пойдет речь:
Что делать:
Если ваш заказчик не подписывал Agile Manifesto и не читал Scrum Guide?
Если в итерацию врываются сверхсрочные задачи?
Если бизнес-процессы не позволяют регулярные релизы?
Идеологи Scrum создавали процесс для небольших вовлеченных и нацеленных на результат команд. Что же делать, если вам приходится работать с корпорациями?
Процесс приходится строить заново, беря все самое лучшее и подстраиваясь под нужды и возможности любимых клиентов.
Я расскажу, какие подходы мы используем при создании процесса разработки, что, по моему опыту, важно, а чем можно пренебречь, ну, и обязательно о чем-нибудь еще.
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
Презентация к вебинару - https://youtu.be/mZEJ_YEFdoI
Вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники, которые помогают командам проводить совместные обсуждение и принимать решения.
О чем узнаете на вебинаре?
2 техники для “обсуждения-дискусcии", они обе хорошо подойдут как для малых (4-5 человек) так и для больших (12-14 человек) команд. Плюсы и минусы этих техник, особенности и возможности их трансформации под ваши рабочие условия.
2 техники для “обсуждения-обратной связи". Одна из них довольно распространенная и она мне не очень нравится своей банальностью, а вторую вы вряд ли знаете, она интереснее, но и сложнее в применении.
1 техника для “обсуждения-анализа”, называется “Декартовы Координаты”, часто применяется в индивидуальном коучинге, но в 99% упускается одна интересная деталь при ее использовании, на вебинаре я про нее расскажу.
2 техники для голосования, про точко-голосование вы все, конечно, уже в курсе, я расскажу еще две простые техники, может, они вам тоже знакомы. Я бы хотела больше остановиться даже не на самих техниках, а на том, как можно манипулировать будущими результатами голосования еще до самого голосования.
Продолжая тему манипуляций, мы рассмотрим валидность мажоритарного способа принятия решений и познакомимся с другими, возможно, более подходящими для ваших команд, подходами.
Запись прошлых вебинаров:
https://youtu.be/7x3uHaFqe1I
https://youtu.be/ykx54Kx6wOA
https://youtu.be/mjIu06mvO4A
Раскрась свой Бэклог! Или о том как принимать решения на основе разных типов ...Timofey (Tim) Yevgrashyn
Вы знали, что Бэклог Продукта может содержать элементы разного типа? Да-да, об этом еще дедушка Швабер говорил. Я наблюдал молодых СкрамМастеров и Владельцев Продукта, которые бьются головой об стену мучаются вопросом, что можно положить в Бэклог Продукта, а что нельзя, и если нельзя, то куда.
В докладе мы рассмотрим несколько основных типов Элементов Бэклога, на примерах посмотрим как и на что они влияют. И самое главное обсудим как принимать решения о планах итерации и выпуска, на основе комбинации разных типов.
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Денис Тучин - Лучшие практики внедрения изменений на уровне командDenis Tuchin
1. Правильная постановка цели (Больше чем SMART)
2. Взвешиваем все за и против
3. Ищем единомышленников
4. Создаём атмосферу безотлагательности действий
5. ADKAR
6. Инструменты, процессы, борьба с бюрократией
7. Маленькие победы (планируем, осуществляем и распространяем)
8. Другие поощрения изменений
9. Кадровые перестановки
10. Институционализация
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
- Как понять, что менеджмент – это твое?
- Переход из специалиста в менеджеры
- Разные компании и разные менеджеры
- Что выдвигает людей в менеджеры
Видео выступления: http://www.happy-pm.com/blog/?p=6244
Тактическое управление продуктами: все еще недостающее звеноMaxim Gaponov
«Эти люди делают то, о чем я их прошу. Но в результате каждый раз получается не то, что мне нужно». Эта фраза, в той или иной форме, произносится каждым клиентом, с которым я работаю.
«У нас было все, что нужно. Требования, выборки, прототипы. В итоге не успели сделать и половину. А то, что сделали нежизнеспособно» — такое тоже встречается часто.
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Вы помните, как вы представляли себе Канбан, когда первый раз о нем услышали? Я помню. И с тех пор мое мнение о методе менялось, и не один раз, помогая найти новые пути для совершенствования сервисов в компании, в которой я работаю. В докладе я расскажу о своих наблюдениях глазами тренера и коуча, как меняются со временем взгляды команд на инструмент и какие новые возможности они для себя открывают
Джон Сильвер: Как управлять неидеальной командойDenis Tuchin
Чем больше я пишу и рассказываю о гибких методологиях управления проектами, тем больше получаю ответов, что эти методологии работают только в идеальных условиях, когда все сотрудники профессиональны, мотивированы достигать результаты и рады работать в команде. На деле же в большинстве случаев это не так – приходится работать с теми, «кого дают». Так вот доклад как раз о том, как руководить неидеальными сотрудниками, чтобы проект был успешным.
It talk №23: "Если не Scrum, то что?", Екатерина ШалапановаMarina Peregud
Докладчик: Екатерина Шалапанова, деливери-менеджер финансовой практики DataArt, Петербург
О чем пойдет речь:
Что делать:
Если ваш заказчик не подписывал Agile Manifesto и не читал Scrum Guide?
Если в итерацию врываются сверхсрочные задачи?
Если бизнес-процессы не позволяют регулярные релизы?
Идеологи Scrum создавали процесс для небольших вовлеченных и нацеленных на результат команд. Что же делать, если вам приходится работать с корпорациями?
Процесс приходится строить заново, беря все самое лучшее и подстраиваясь под нужды и возможности любимых клиентов.
Я расскажу, какие подходы мы используем при создании процесса разработки, что, по моему опыту, важно, а чем можно пренебречь, ну, и обязательно о чем-нибудь еще.
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
Презентация к вебинару - https://youtu.be/mZEJ_YEFdoI
Вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники, которые помогают командам проводить совместные обсуждение и принимать решения.
О чем узнаете на вебинаре?
2 техники для “обсуждения-дискусcии", они обе хорошо подойдут как для малых (4-5 человек) так и для больших (12-14 человек) команд. Плюсы и минусы этих техник, особенности и возможности их трансформации под ваши рабочие условия.
2 техники для “обсуждения-обратной связи". Одна из них довольно распространенная и она мне не очень нравится своей банальностью, а вторую вы вряд ли знаете, она интереснее, но и сложнее в применении.
1 техника для “обсуждения-анализа”, называется “Декартовы Координаты”, часто применяется в индивидуальном коучинге, но в 99% упускается одна интересная деталь при ее использовании, на вебинаре я про нее расскажу.
2 техники для голосования, про точко-голосование вы все, конечно, уже в курсе, я расскажу еще две простые техники, может, они вам тоже знакомы. Я бы хотела больше остановиться даже не на самих техниках, а на том, как можно манипулировать будущими результатами голосования еще до самого голосования.
Продолжая тему манипуляций, мы рассмотрим валидность мажоритарного способа принятия решений и познакомимся с другими, возможно, более подходящими для ваших команд, подходами.
Запись прошлых вебинаров:
https://youtu.be/7x3uHaFqe1I
https://youtu.be/ykx54Kx6wOA
https://youtu.be/mjIu06mvO4A
Раскрась свой Бэклог! Или о том как принимать решения на основе разных типов ...Timofey (Tim) Yevgrashyn
Вы знали, что Бэклог Продукта может содержать элементы разного типа? Да-да, об этом еще дедушка Швабер говорил. Я наблюдал молодых СкрамМастеров и Владельцев Продукта, которые бьются головой об стену мучаются вопросом, что можно положить в Бэклог Продукта, а что нельзя, и если нельзя, то куда.
В докладе мы рассмотрим несколько основных типов Элементов Бэклога, на примерах посмотрим как и на что они влияют. И самое главное обсудим как принимать решения о планах итерации и выпуска, на основе комбинации разных типов.
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Денис Тучин - Лучшие практики внедрения изменений на уровне командDenis Tuchin
1. Правильная постановка цели (Больше чем SMART)
2. Взвешиваем все за и против
3. Ищем единомышленников
4. Создаём атмосферу безотлагательности действий
5. ADKAR
6. Инструменты, процессы, борьба с бюрократией
7. Маленькие победы (планируем, осуществляем и распространяем)
8. Другие поощрения изменений
9. Кадровые перестановки
10. Институционализация
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
- Как понять, что менеджмент – это твое?
- Переход из специалиста в менеджеры
- Разные компании и разные менеджеры
- Что выдвигает людей в менеджеры
Видео выступления: http://www.happy-pm.com/blog/?p=6244
Доклад: “Продукт: Вам нарезать или целым куском?”
Известно, что изначально Agile позиционировали себя не так амбициозно, как сейчас. Все изменяется и, возможно, Вы по-другому посмотрите на свою ситуацию. К тому же у меня для Вас две новости: плохая и хорошая.
«Слона нужно есть по частям» — все так говорят, но мало кто знает — почему?
Конечно можно сказать словами Вольтера, что мол «common sense is not so common». Всегда есть какие-то причины, почему люди не делают очевидные вещи. Я приведу буквально три оправдания, которые мне довелось слышать недавно, и мы вместе посмотрим, как это звучит со стороны.
Как есть «Слона» или пять практических советов. Ну и самое «мясо» — инструменты, которые я считаю жизненно необходимыми. Точнее это даже не совсем «инструменты» («серебряной пули нет», мы же помним, да?) — это области особого внимания при продуктовой разработке. Все проверено на реальных командах — от стартапа до многомиллионного и долгоиграющего проекта. Будет о чем задуматься, обещаю.
Практические советы о планировании того, что и как вы будете выпускать. Как придать объем вашим бесплотным идеям, а по дороге добавить понимания куда мы идем, когда там будем и чего нам это будет стоить. В докладе будут примеры из опыта продуктовых команд, с которыми мне довелось работать. Также “недокументированные проблемы”, о которых многие не подозревают, и техники как все это по прежнему направлять к выпуску хоть чего-то стоящего
Практические советы о планировании того, что и как вы будете выпускать. Как придать объем вашим бесплотным идеям, а по дороге добавить понимания куда мы идем, когда там будем и чего нам это будет стоить. В докладе будут примеры из опыта продуктовых команд, с которыми мне довелось работать. Также “недокументированные проблемы”, о которых многие не подозревают, и техники как все это по прежнему направлять к выпуску хоть чего-то стоящего
We have a lot of businesses working in Ukraine as Outsource company. But all we know that outsource is not options as the long-term
business strategy. From the other perspective, there are a few firms that are trying to move to the product development but it too risky
for two reasons:
— You need to invest your money and losing your margin.
— You have no any experience in product management or startup landing neither fundraising.
We in Octoberry, start to work as Product Sourcing company three years ago. We find this way very useful to gain experience in product
management and fundraising and after we moved to own product development and we want to share our case. In this talk, we will
discuss:
— What is product sourcing?
— Why product source.
— Five steps key steps to run Product Source project
— Moving from product source to Product Company
AgileCamp — летняя практическая конференция, которую ежегодно проводить компания ScrumTrek. Участники процессного трека на практике отрабатывают все цепочку создания продукта. Используются такие техники как проведение опросов, игра в ТЗ, user story mapping, bucket estimation, planning poker, getkanban, world cafe и др.
Как создать концепцию продукта в виде Lean CanvasMagneta AI
Lean Canvas — инструмент, который позволяет быстро понять ценность продукта, проблемы, которые он решает, его основную аудиторию и способы монетизации. В презентации подробно рассмотрен шаблон lean canvas и дается подробное руководство по заполнению.
Зачем нужны ретроспективы и как их проводить? Основные отличия ретроспектив в различных фреймворках, например, Scrum или Kanban, рекомендации по продолжительности, наполнению, советы по каждому этапу ретроспективы.
3. Вынос мозга малосвязанной информацией
Немного очевидности
Немного лозунгов
Немного провокаций
Немного опыта
Немного холивара
Немного советов
Немного юмора
Объясняю свою картину мира тем, с кем работаю
Общие (единые) понятия
Чтобы говорить «А помнишь, я рассказывал…?»
Что это за доклад?
5. Название доклада – способ включить ассоциации
Скорость езды зависит не от лошади
Рассмотрим идеального сферического коня, без ограничений породы
Скорость – заслуга наездника
Нужно научиться подавать правильные команды
(надеюсь, эта анимация движется)
Шаг Рысь Галоп
Шаг-Рысь-Галоп
6. Скорость света достижима
На нашей планете – пока в теории
К сожалению
Нужно ускорение
Постоянное
Непрерывное
Давайте искать способы
7. E = mc2
Не сегодня
Сила
Си́ ла — векторная физическая величина, являющаяся мерой
интенсивности воздействия на данное тело других тел, а также полей
Сила как векторная величина характеризуется модулем, направлением
и «точкой» приложения силы
Трение
Сила трения равна коэффициенту трения, умноженному на силу реакции
опоры
Путь к скорости света:
Общий вектор сил
Снижение трения
Непрерывность воздействия (постоянство)
Формулы от К.О. - физика
8. Вся работа = Полезная работа + Бесполезная работа
Полезная работа = Вся работа – Бесполезная работа
Меньше бесполезной работы => больше полезной отдачи
Чем больше отдачи – тем выше скорость
Больше фич
Чаще демо
Формулы от К.О. - арифметика
9. Бесполезная работа -> Муда (Lean)
Перепроизводство
Запасы
Избыточная обработка
Лишние движения
Дефекты и брак
Ожидание
Транспортировка
Там же (в Lean)
Мура (неравномерность)
Мури (перегрузка)
Меньше бесполезной работы
http://wkazarin.ru/wp-content/uploads/2013/09/LSSAGLM.pdf
10. Вроде бы очевидно
Когда просят сделать быстро, не просят сделать плохо
Но я хочу ещё раз об этом напомнить
Со временем инструменты заботы о качестве преобразуются в инструменты
повышения скорости
Скорость не должна влиять на качество
11. Думаете, что знаете?
Уверены? Он вам сказал? Показал? Нарисовал?
Он пробовал это? Пользовался? Другим показывал?
Заплатил за это? Больше ничего не хочет? Доплатит?
Вы не знаете. Примите это.
В «русской рулетке» шансы выше
Вы не знаете, что хочет заказчик
12. Это единственный способ его понять
Показывайте чаще
Чаще = меньше, а меньше - не проблема
Проблема не в «показать мало»
Проблема – показать не то
Покажите заказчику результат
13. Человек – устройство для преобразования сигналов
Сигнал = проекция
Заказчик проецирует ожидания
Заказчик находится в своём контексте
Контакт – обмен проекциями
Окно контакта – видим одно и то же?
Важно получить обратную связь
Убедитесь, что проекция понята
Снижайте когнитивный диссонанс (разрыв шаблона)
Займёмся когнитивной психологией
14. Ешьте слона по кусочкам
Сразу – подавитесь
Небольшой функционал – небольшие затраты
Небольшие затраты понести не страшно
Маленькая ошибка – маленький ущерб
А ещё это проще тестировать
Делайте меньше
15. Каждая фича стоит денег
Анекдот в тему:
Выбросьте лишнее
http://www.slideshare.net/agiledays/ss-19544297
16. Уверенность = скорость
Замкнутый круг
Уверенность – когда фича не кладёт код
Круто, да?
Это про технические нюансы: тестирование, автоматизация деплоя…
Скорость = уверенность
http://msk15.agiledays.ru/members/profile/908/
Непрерывное качество в непрерывной разработке
17. Уверенность – знаем что делать, а не придумываем на ходу
Придумывание (не уточнение) антипродуктивно
Прорабатывайте задачи ДО постановки в разработку
Груминги для оценки и уточнения требований
Прототипы для понимания функциональных требований
Описывайте НФТ
Рассматривайте граничные случаи
Quality-Driven Task Creating Описывайте User Story, начиная с «как проверить»
Скорость = уверенность
18. Не накапливайте проблемы
«Разберемся потом» - не работает
Записывайте сразу, потом - забудете
Ретроспектива!
Не скрывайте проблемы
К сожалению, проблемы есть всегда
Наказаний нет
Ищем «бриллианты»
Проблема = повод найти улучшения
Скорость = прозрачность
http://expert.ru/expert/2003/15/15ex-instrum_33307/
19. Продукт должен быть рабочим всегда
20% готовности продукта - bullshit
Должна быть 100% работоспособность 5% продукта
У нас есть Agile!
Итеративность
Инкрементальность
Здравый смысл
Правильное разрезайте слона
http://www.maxkir.com/sd/methyperproject_RUS.htm
20. Меньше не значит хуже
Меньше – значит завершённее
Каждый функционал – закончен и полезен
Дорабатывать не нужно
Приносит пользу / решает проблему клиента
Запомните умные слова – MMF и MVP, делайте это
Minimal marketable feature
Minimal viable product
Стремитесь к завершенности
http://morrozmsk.livejournal.com/138016.htmlhttp://habrahabr.ru/post/230637/
22. Простое правило: слева - зло, справа – добро
ЗЛО = Заинтересованное ЛицО
Важно НЕ ДВИГАТЬ задачи слева направо
Важно ДОТАСКИВАТЬ задачи направо до конца
Усмиряйте Kanban
23. Маленькими вы тоже ничего не боялись
Ошибки – это нормально
Даже если вы их боитесь, они всё равно случатся
Фэйлиться раньше (Agile)
Plan-Do-Check-Act (цикл Деминга)
Для открытых систем
Открытые = не можем контролировать
У взрослых - цикл Колба (Дэвида)
Не бойтесь ошибок
http://www.ted.com/talks/regina_dugan_from_mach_20_glider_to_humming_bird_drone
24. Видимость - слово не из психологии, а из оптики :)
Результаты вашей работы должно быть видно
Делайте не «для видимости», а то, что видно, реально, ощутимо
Делите задачи по типам
Так проще не забывать выделять на это время
Видимость – хорошее слово
25. Напоминайте об этом
Новости (официально)
Блог (менее официально)
Заставка в mobile app
Больше внимания к видимости
26. Выбирайте с пользой
Reformal (закрывайте запросы)
Письма в обратную связь (цитируйте)
Тенденции (вы в тренде)
Конкуренты (сокращайте разрыв)
Легко и быстро!
Наш выбор - 1
Метод Кано в помощь
Выбирайте правильную видимость
https://vimeo.com/album/3306009/video/118003815
27. Вы НЕ ЗНАЕТЕ, что нужно
Усмиряйте фантазию
Потерпите с изменениями
29. Приоритеты – единственное, чем можно управлять
Разработка это услуга, ускорение возможно только за счёт качества.
Проблемы ускорения проявятся в любом случае.
9 женщин не родят ребёнка за 1 месяц (с)
Не забывайте - мы делаем софт, а не хард
«Вредные советы»
http://microsat.sm.bmstu.ru/e-library/Books/TheMythicalManMonth_rus/The%20Mythical%20Man-Month.pdf
30. Улыбайтесь чаще
Улыбаясь, мы кажемся более компетентными (с)
Умное лицо это еще не признак ума, господа… Все глупости на земле делаются именно с этим
выражением лица… Улыбайтесь, господа… Улыбайтесь! (с)
http://www.ted.com/talks/ron_gutman_the_hidden_power_of_smiling http://www.youtube.com/watch?v=moAK_fBoWcw
«Вредные советы»
31. Бокс смотрите?
Впечатление всего боя - от последних раундов
Или от fatality
Готовьтесь
Сценарий
Тестовый прогон
Держитесь уверенно
И позитивно
Ведите
Не давайте перебивать
Вопросы потом
Помогите похвалить
Презентуйте ярко!
32. Главный критерий – удовлетворённый заказчик
Делать меньше = делать больше
Стремиться к завершенности
Повышать прозрачность и доверие
Больше видимости!
Постоянно совершенствоваться = постоянно ускоряться
Уверенность и позитив – залог доверия
Готовить демо, презентовать демо!
Что в итоге?