Agile Pizza #48 Дмитрий Ефименко рассказывает о хождении по граблям - публикую набор цитат. Алексей Ященко (tuxslayer@grammarly) с, как всегда, интересным рассказом о построении культуры tech excellence

 

• Дмитрий Ефименко - длинная дорога через грабли
  • Лучший kpi - жизненный цикл фичи - time to market - показатель скорости реакции на изменения
  • OPD model - outsourcing product development
  • Жизненный цикл команды 1-3 года, потом обновление.
  • Если вам через год нравятся ваши процессы - то у вас двойные стандарты
  • Вопрос на собеседовании - что тебе не нравится, какие у тебя ограничения
  • Fuckup Driven Development
    • Не спешите впрягаться, попытайтесь решить проблему, как инженер
  • Оценка фич не только реализацией, но и сколько стоит в поддержке, как трассировать требования, ЖЦ включает смерть фичи. Если вы остановились на продакшн - думайте еще. А что поддержкой...
  • У заказчика понятие готово одно - "я взял, развернул и начал на этом зарабатывать"
  • Любой Джун менеджер своего маленького проекта
  • Крутейший продукт требует крутейшего devops
    • Скрипты мониторинга, сетевой связанности...
  • Сопротивление изменениям f(n*m) n-количество сотрудников m-уровни менеджмента
  • Результаты груминга и ретроспектива выливаются в to do листы - если у вас плодятся - значит делается неправильно
    • Квадрат кантора risk/value/cost
    • Иногда длинные деньги значительно приятнее
  • Хорошие тестировщики более редкие чем программисты. Поэтому 1 тестировщик на 2 программиста

 

• Алексей - техническая культура в Grammarly
  • 5M users with 60 engineers
  • the only way is intensive growth
    • Организационный долг
  • культура штука хорошая - позволяет многие вещи автоматизировать на уровне человека
  • technical excellence - Just excellence 'all the time' is hard.
    • если его постоянно пытаться достигать - это боль
    • чтобы он стал реальностью - он должен стать культурой
  • Техническое совершенство нужно стоить на чем-то
    • оргструктура - TEC - технические способы
  • Time Eaters
    • Low development pace
      • Buggy releases
        • Regular outages
          • Tired developers
  • Что-то чтобы команды были
    • кросс функциональными
    • инженеры несли ответственность за то, что они делают
    • tools solve all the hassle
  • Story #1
    • Cross-functional teams - QA => SE in Test => Feature Teams
  • Сделали из QA -> software engineering test
    • Catch bugs -> Build for quality, Write code, well... catch bugs...
  • XP
    • pair programming
    • defensive programming
    • code review
    • test for new code
    • 
      
  • CI/CD release often
    • Feature branches on git
    • CI Server (TeamCity)
    • Unit / Integration / Load / ... test
    • Continuous Deployments
  • UI Bitmap testing - делать скриншоты и сравнивать с предыдущими
  • Чтобы все работало нужна отдельная телега - monitoring в grammarly
    • make it engineering practice
    • measure everything - choose what to monitor
    • validate monitoring data
    • logs: back-end and front-end
    • time-series metrics: counters, timers
      • пример метрики - количество accept corrections - чтобы пользователи нажимали на accept correction должно очень много должно происходить.
    • сезонность - производные и сравнение логарифмически с предыдущими периодами.
  • Результаты упражнений
    • zero ping-pong between teams
    • developers release "at will"
    • QA people are involved from day 1
    • Everybody writes tests
    • Everybody can fix a bug
    • time to release from 1-2h to 1-10min
    • Rollback instead of fixing => Short outrages
    • Whole team does not get distracted by outages
  • Story #2
    • ORG: no-Ops
    • Platform team
    • Embedded ops in Teams
    • Tech: containers
      • docker
      • rocker
      • terrafrom
    • Not a "service" team
    • PaaS
    • Strategic rather than tactical
    • Software devs as Devops
    • конфигурация лежит вместе с кодом. девелоперы сами делают контейнер
    • Configuration as a code (versioning, automatizing, templateing)
    • multi service deployments
  • Foundation
    • Optimize every single phase of dev cycle
    • Create an env for dev practices
    • Apply best practices
      • Stop fire fighting and free more time and mindset for improvements.
  • Culture
    • Hire the best
    • Fun days
    • Free books
    • internal hackathon
    • Mentorship
    • Courses and conferences
  • Build Excellence
    • Definition of Done
      • позволяет быстро отсечь разговоры - пусть полежит - давайте релизнем...
    • Tech Ecellence check lists (forever)
    • SLOs (service level objectives) /SLAs
  • Самая важная часть в построении культуры - похвала людей, которые делают хорошо...
  • Create more space for communication

Harvard Business Review - Delusions of Success

• Примеры провалов
  • Oxford Health Plans не смогла компьютеризовать системы в 92м
  • в 80х годах Англия, Германия, Испания запланировали построить боевой истребитель за 20млрд, в результате потратили 45млрд и не построили
  • В 96м железная дорога Union Pacific купила конкурента и так и не смогла его интегрировать
  • 70% новых заводов в США закрываются в течении десяти лет
  • три четверти слияний и поглощений не окупаются
• Экономика поясняет провалы статистически. Риски неотвратимы - а в целом тренд положительный
  • Авторы не соглашаются с этим мнением - и считают, что провалы - логическое следствие плохих решений менеджеров
• Planning Fallacy (ошибка планирования)
  • менеджеры склонны переоценивать успех своих планов (иллюзорный оптимизм)
  • переоценивают преимущества и недооценивают затраты
  • корни проблемы - в когнитивном искажении - как мозг обрабатывает данные и в давлении на менеджера в организациях
  • но есть шанс - дополнив обычную "внутреннюю" оценку проекта (на основании внутренних возможностей компании - статистическим анализом менеджеры могут откорректировать свой прогноз
  • это авторы называют outside view - внешний взгляд - такая провера внутреннего взгляда - обычного подхода к планированию - с ожидаемым снижением шансов сделать опрометчивые инвестиции
• Розовые очки
  • Наука отслеживает корни оптимизма в следующем
  • тенденция преувеличивать таланты и возможности
    • в 1970 опрос 1 миллиона студентов показал
      • 70% считают себя лучше среднего показателя по навыку лидирования
        • только 2% считают себя хуже средних показателей
      • 60% считают себя выше среднего по атлетическим возможностям
        • и только 6% ниже среднего
      • по навыку ладить с людьми 60% считают, что они в первой десятке
        • и 25% причисляют себя к самому лучшему 1%
  • Тенденция неверно трактовать события
    • присваивать успех - это моя заслуга
    • перекладывать вину - это чужая вина или внешние факторы
    • в отчетах компаний успехи приписываются менеджерам исследованиям, стратегии компании
      • неудачи списываются на плохую коньюктуру рынка, погоду или инфляцию
  • преувеличение степени контроля над событиями
    • люди дисконтируют роль удачи в жизни
    • в эксперименте людей просили нажимать на кнопку что могло зажечь лампочку (а могло и не зажечь - на это дейстовал также случайный фактор)
    • большинство опрашиваемых сильно переоценили реальную вероятность загорания света от нажатия на кнопку
  • В целом - любые прогнозы просто заражены чрезмерным оптимизмом
  • 80% начинаний так не смогли достичь планируемой доли рынка
  • Переоценка собственных возможностей на примере слияний и поглощений
    • Слияния и поглощения происходят волнами в период роста экономики
    • в периоды роста экономики менеджеры присваивают себе и своим качествам (умению управлять) успехи вызванные ростом рынка
    • менеджеры верят, что благодаря их гениальным талантам управления они смогут преодолеть возможные проблемы
    • это приводит еще большей переоценке своих возможностей менеджерами
    • соответственно они считают, что используя свои таланты они смогут увеличить стоимость приобретенной компании и платят за нее больше
    • опыт показывает, что в большинстве случаев оценка компании не верна
  • Менеджеры находятся в плену иллюзий относительно вероятности
    • отказываются учитывать случайность в построении планов
    • Видят риск - как вызов - который нужно преодолеть силой и навыком управления
    • считают, что результат - заслуга их действий и действий организации
    • в их идеализированном восприятии они не игроки в казино, а агенты, которые управляют людьми и событиями
    • как следствие - игнорируют влияние случайностей на их планы
  • На искривленное восприятие также влияют лимиты человеческого воображения
    • никогда планы не точны
    • мирриады случайностей, проблем не учитываются
      • погода, курсы валют..
    • сценарии не учитвают, что все пойдет "не так"
    • чаще всего выбирается "наиболее вероятный" сценарий и принимается за факт, что все так и будет
    • даже если шанс каждого из негативных событий очень мал - все они вместе могут сильно повлиять на результат
• Еще большее искривление позитива происходит в реальной жизни компаний
  • Эффект "якоря"
    • когда оценивается инициатива за основу берется план, который делает лицо, инициативу предлагающее
    • он часто значительно переоценен, чтобы решение было принято
    • когда он рассматривается подсознательно мы привязываемся к нему (а он может быть вообще неверен)
    • это доказывается экспериментом
      • ученые попросили испытуемых четыре последних цифры номера их паспорта
      • затем - попросили оценить количество врачей в манхэттене
      • эти две цифры положительно коррелировали
    • чаще всего "якорению" подвержены бюджеты
    • анализ стоимости строительства 44 заводов в США показал, что реальные затраты более чем в ДВА РАЗА превышают бюджет
    • даже после года после запуска заводы работали на 75% мощности - а четверть менее чем на 50%. для некоторые так и не вышли на планируемые объемы производства
  • Игнорирование конкурентов
    • Поведение конкурентов без сомнения важный фактор
    • Менеджеры в прогнозах завсегда основываются на СВОЕЙ компании и ее возможностях
    • не учитываются - пересыщение рынка, ценовые войны...
    • бывший Глава Дисней сказал - когда мы планируем новое начинание мы думаем - "У нас есть возможности, у нас есть люди, у нас есть маркетинг" - и не думаем, что все это есть у них тоже
    • Особенно важно в открытии новых рынков. Часто компании бегут чтобы занять долю - тратят на производство и продвижение - расходы которые никогда не окупятся из-за потока конкурентов на этот же рынок
  • Давление в Организации
    • в компаниях есть только ограниченное количество денег и ресурсов для новых проектов
    • люди борются за продвижение своих идей и проектов
    • как результат:
      • все оценки сверхоптимистичны
      • повышается вероятность, что в выбирают именно те проекты, которые и были наиболее оптимистичны - увеличивая шанс провала и разочарования
    • Другие действия требуют оптимизм
      • менеджеры ожидают повышенные цели и результаты труда
        • а если эти завышенные цели становятся KPI - это еще имеет и негативный эффект в виде рискового поведения сотрудников
    • организации преследуют пессимизм - часто оценивается как нелояльность к компании
    • все это подрывает возможность незамутненного взгляда и планирования происходящего
• Внешний взгляд
  • Вряд ли компании откажутся от оптимизма
  • Уже понимание возможных факторов сверхоптимизма позволяет его корректировать
  • Но есть еще и объективный метод корректировать планы
  • Пример для иллюстрации
    • в израиле группа академических работников создавала новый учебный курс
    • после года команду собрали и спросили каждого отдельно - сколько займет завершить работу над курсом
      • ответы разнились от 18 до 30 месяцев
    • после этого один из академиков задал второму риторический вопрос
      • учитывая наше состояние работы над проектом и ваш опыт других команд - сколько им потребовалось, чтобы достичь результата?
    • ответ
      • не все вообще смогли завершить работу - около 40% вообще от нее отказались
      • никому не удалось завершить менее чем за семь лет и ни у кого не заняло более чем 10 лет.
    • а уверены вы, что мы чем-то лучше других? - Нет
    • Возможно на этом этапе команде стоило разойтись - но они продолжили работу - через ВОСЕМЬ лет они закончили свой труд, который к тому же редко использовался
  • В примере использованы два метода прогнозирования
    • внутренний взгляд
      • учитывая задачи и оценку возможностей команды/компании. Экстраполируя в будущее
    • внешний взгляд
      • оценка на основе референтных событий
      • полностью игнорирует текущее положение проекта
      • не пытается предвидеть события которые могут влиять на проект
      • вместо этого был выбрана референтная группа проектов - проведен анализ - и рассчитана вероятность отклонения
  • Разница в двух методах подтверждается исследованиями
    • когда людей просят использовать внешний взгляд - их прогнозы становятся точнее
    • когда студентов спросили как они оценивают свои успехи - они все оценили себя успешнее 84% других студентов.
    • вторую группу до этого спросили о их оценках и оценках их сокурсников - даже такая простая поправка улучшила показатель на 20%
  • Большинство организаций использует внутренний взгляд - он наиболее интуитивный
    • концентрация на природе проекта
    • даже внешние консультанты часто остаются в рамках такого взгляда
  • внешний взгляд - проходит через большинство барьеров
    • не требует проектирования будущего - построения оценок
  • наиболее сильное давление для использования внутреннего взгляда предполагается на новые проекты - именно там, где и нужен внешний взгляд - где вероятность искажения наиболее высока
  • Конечно у внешнего взгляда существуют прецеденты - где невозможно найти аналогии - в таких случаях возможно нужно попытаться найти близкие аналогии и сравнить результаты обоих подходов
• Поставить оптимизм "на место"
  • оптимизм - это не есть плохо - он создает гораздо больше энтузиазма, чем реализм
  • в то же время компаниям необходимы реальные прогнозы
  • решение - четко разделить позиции в компании - те, где важны прогнозы - и которые управляют действиями
  • для первых важнее реализм, вторым нужен оптимизм для мотивации людей
  • оптимистичный финдиректор - угроза для компании - точно также, как пессимист в исследованиях или продажа
  • возможно исполнителям и не стоит показывать результат анализа "внешний вид" - чтобы не подрывать их мотивацию
  • CEO компании и топ менеджеры должны быть и реалистами и оптимистами одновременно
  • Мы рекомендуем вам использовать внешний вид для построение планов и целей - а затем при переходе к исполнению забыть
    • постоянный пересмотр планов и целей будет плохо отражаться и на морали и на производительности сотрудников
  • а вот доля здорового оптимизма поможет вам достичь целей.
• Как проводить анализ "внешний вид"? (описание на стр. 8)
  • Выбрать референтную группу
  • Проанализировать разброс результатов работ
  • Интуитивно предположить положение вашего проекта в группе результатов
  • Оценить надежность вашей оценки
  • Исправить интуитивную оценку

Big Data

Two pics to start from

UX Ukraine "Сбор требований заказчик-исполнитель"

Спасибо Ray Manson за выступление

• События UX-Ukraine
  • UX-Ukraine на iforum
    • серия мастерклассов по 40 минут
    • условие входа - билет на iforum
  • UXmayday - 2014
    • майовка - россия, украина, белорусь
    • на шашлыки. расслабляющее мероприятие. самоорганизация.
    • в районе майских праздников.
    • своя роль изначально
    • есть идея совместить шашлыки с яхтой. 20+/-5 человек
    • бюджет делится на человек.
    • отслеживать UX Ukraine
• Сбор требований заказчик - исполнитель - темы дня
  • как донести до заказчика, что от него зависит результат, а не только от исполнителя?
    • важно понять - на каком этапе общения мы можем это донести.
    • часто это происходит при прояснении бизнес целей и бизнес процессов - требует большего участия со стороны заказчика - подвигает его к мысле о его участии
    • перепроверить бизнес процессы
  • каким образом зафиксировать все требования (даша - bigmir)?
    меня когда-то укусил злой юзабилист - Даша Волкова
    • транскрипты встреч
    • примеры
    • высылать выводы после встречи и требовать подтверждения / опровержения / вопросы
    • строить mid maps общения
      • mindmaster
    • в письме - "жду подтверждения - только после этого перехожу к следующему этапу"
      • повторять такие письма
    • clients from hell
  • как работать с эмоциями
    как объяснить, что то, что хочет заказчик - плохо
    • задавить авторитетом
      • есть сценарии в голове - нужно логически донести до клиента, что он в этом случае не прав.
      • расскажите свой сценарий.
      • метод 5 зачем? (root cause analysis - five whys)
    • нужно найти несколько людей из целевой аудитории и попросить их дать реальную оценку при заказчике
  • как рабоать с человеком, который не знает, чего он хочет?
  • должен и как платить заказчик $ за понимание?
    • никто не будет платить за presale
    • все происходит в зависимости от рынка
    • процесс сбора требований важен не только заказчику он также важен исполнителю - вы понимаете - с кем вы имеете дело - и стоит ли вообще продолжать
  • как не надоесть заказчику с вопросами?
    • нужно, чтобы заказчик понимал - зачем ему задают такой или иной вопрос
    • этикет и адекватность
    • в зависимости от типа клиента иметь паттерны вопросов + психология (что ответит в зависимости от типа человека)
    • работа с ожиданиями
    • если ты общаешься с человеком, которому интересно, и ты говоришь о том, что ему нужно - он сам будет готов отвечать на все вопросы.
  • типы требований и приоретизация
    • типы требований - requirement
      • к дизайну
      • к бизнес модели
      • к frontend
      • к backend
      • к редакции
      • технические
      • ...продолжить.
    • требования нужно классифицировать, хранить и передавать нужным участникам проекта
    • может быть требование за которое мы не отвечаем - за него отвечают программисты
    • требования к скорости работы - сокращение задержек между транзакциями
    • как на стороне интерфейса сделать чтобы работало быстрее
  • изменение требований
    • мы переделаем это один раз, потом это будет за деньги
  • документирование / согласование (отсылка к ответу - как зафиксировать требования)
• пример общения с заказчиком
  • Саша - сервис совместных покупок
    • идея - создание сервиса, собирает покупателей для выкупа
    • реализовали проект - непонятно - что реализовали
    • желание допилить/доделать
    • делал подрядчик - компания
    • роль в проекте - директор в компании.
      • с партнером составляли ТЗ решали, как будет работать
      • согласовываю
      • утверждаю
    • как это происходило?
      • составили свой бриф
      • отправили 15 студий
      • получили предложение
      • посмотрели на цену / портфолио / презентации на встрече
      • выбрали подрядчика
      • как ставили задачу
        • встречались на каждом этапе
      • мы сконцентрировались на движке, а не дизайне / UX
      • когда пришло время делать дизайн - проект не вкладывался в сроки
        • все решалось на быструю руку.
      • как происходило определение функциональности на движке?
        • мы встречались, обсуждали как должно работать.
        • По модулям?
        • нарисовали большую карту mindmap на каждом этапе кликаем сюда - приходим туда.
      • реплика - мы работали над функционалом - это не юзабилити - юзабилити в конце
      • мы встречались - потом я нарисовал карту
      • мы встретились - подпилили и начали писать
      • месяц они писали
      • мне так и не показали несколько вариантов основных страниц без прописовки
      • в период постановки задач было устное общение
        • было
        • говорили о том куда кликаем - куда попадаем
        • небыло обсуждений - как должны быть оформлены дизайнерские блоки
        • расположение на странице
  • Леша - компания UFL - доставка цветов по украине/миру
    • работаю с дизайнерами
    • считаю - заказчиков нужно ловить - особенно в дизайне
      • тендеры
      • часто обращался к дизайнерам по рейтингу
      • открытые тендеры на фрилансе
    • сам заказываю и утверждаю
    • если человек профессионал - в том числе и UX вижу, что нравится мне и видел у крутых компаний - я говорю Да
    • профессионализм сразу чувствуется
    • чтобы требовать предоплату нужно быть Лебедевым
    • мне сложно нарисовать карту Midmap
    • послушав я понял - что дизайн для меня сложная штука
    • отдавал помошнику - рисовал квадратики белые дизайнерам - они рисовали как это будет выглядеть.
    • мне как заказчику очень важно чтобы ко мне пришел подрядчик, спросил - опиши что ты хочешь.
      • я покажу конкурентов
      • расскажу - что мне еще хотелось бы
    • в период постановки задач было устное общение?
      • я отдаю программисту - он знает как порезать
      • он напрямую общается с дизайнером и делают сайт
• положительный опыт работы с заказчиком - Рей.
  • Заказчик зачастую не в Украине
  • Я занимаюсь UX дизайном долгое время. Была своя студия. Работал над разными проектами. 3-4 десятка магазинов, порталов, магазинов.
    • надеяться на то, что к вам придет заказчик и все разложит - наивно
      • нужно себя воспринимать в роли доктора
      • люди приходят к доктору - показывают пальцами "бобо"
      • доктор задает наводящие вопросы
      • испольнитель выступает в этой же роли
      • заказчик приходит - человек который не разбирается и приходит за экпертным мнением
      • задача - вылушав сумбур - получить информацию, которая вам нужна
      • если человек пришел к вам - он не дизайнер / разработчик
      • "опытный больной" - уже пообщался с дизайн студиями и разработчиками и понимает - что ему нужно
    • сбор требований как я вижду его "по-правильному"
      • определиться с информацией, которая есть на входе
        • информация разная по структуре и объему
        • mindmapping - позволяет их многостраничных требований выстроить структуру
          • структурирование позволяет увидеть проект в целом
          • часто - является для заказчика открытием
          • часто функционал есть - но он вообще не описан
          • mindmapping - это только технология - молоток - без работы не решает проблемы
      • анализ самой персоны заказчика
        • очень важно понять - насколько человек вообще понимает - чем он собирается заниматься
        • фразу "я хотел сделать украинский amazon" слышал два раза в месяц
        • нужно понять - насколько люди в теме
          • они в теме, если в состоянии в три часа ночи ответить - как и что будет работать
        • в зависимости от уровня исполнителя заказчик в состоянии или не в состоянии заняться вопросом
      • бизнес-анализ и анализ целей заказчика
        • цель бизнеса, который хочет получить заказчик
        • надо понять - что нужно бизнесу
          • часто бизнес говорит, что хочет это - но нужно сказать, что делать не надо
        • для заказчика интернет проект - это вложение
        • сайт - это инструмент бизнеса
        • перед тем, как делать заказ нужно оценить сайт - что он должен принести и это должна быть исчислимая величина
        • при каком количестве заявок - этот сайт будет считаться эффективным?
          • 1000 заказов в месяц
        • сколько заказов сейчас?
          • сейчас 100 заказов
        • Насколько рально достичь поставленные цели?
          • собирается ли меняться траффик?
          • какое будет контентное наполнение?
          • текущее количество заказов по какому траффику?
          • важный вопрос - предполагаются ли новые источники траффика?
          • вопрос - а что планируется менять в рекламной компании?
      • анализ рынка
        • емкость заказов на рынке есть?
        • нам нужно увеличение в 10 раз.
        • как зависит количество заказов от юзабилиста?
        • при 100 заказах в месяц, посещаемость 10000 посетителей в день.
        • какие источники траффика
        • процентное соотношение orgainc и direct
        • SEO по траффику
        • сколько источников траффика - 10
        • сколько прямого траффика - 10% - 10 заказов.
        • разные каналы траффика даютс разные конверсии
        • вопросы по поводу каналов/источников/таргетирования - тоже к юзабилистам
      • анализ продукта (сайта)
        • описать, кто является заказчиками продукта?
        • какая аудитория? (часто бывает - начали с B2C - а пришли к B2B)
        • какие планы клиента
          • планы были развития на 5 лет
          • через день они стали на 1 месяц
        • целевая аудитория
          • сегментировать аудиторию
          • разбить на персон
          • типажи людей (хотя бы групп)
          • на персонажей должен быть ориентирован проект
          • нужно выжимать всю воду, но чтобы живые люди остались
          • если мы не можем выбросить кого-то чтобы не упала конверсия - не выпало звено - пора останавливаться
          • в контексте бизнеса можешь охарактеризовать 5 категорий людей кому товар нужен больше всего
        • персоны продукта
          • это не возраст / секс
          • персона не есть социология, а есть сценарий
          • это событие / действие, которое происходит
          • человек решающий какую-то задачу
          • персона и сценарий идет парой - они неделимы
      • какие у заказчика уже есть свои ресурсы
        • придумали сайт - наделали скриншотов
        • пришли к дизайнеру "надо такое", синенький цвет и девочку
        • дизайнер запедалил
        • текстов нет - секретарша из буклетиков текста насобирала
        • верстальщик собрал
        • программист на какую-то CMS повесил
        • после этого приходят к SEO и далеют оптимизацию
        • получаются такие франкенштейны с ботоксом
      • новые ресурсы заказчика, которые потребуются
        • разработка - это не только работа студии но и работа заказчика
        • студия не в силах написать тексты - которые будут продавать (и ботам гугла тоже)
        • нужны качественные фотографии
        • нужно писать тексты
        • лучший контент - часто - pdf который получают от вендора - фотографируют на iphone.
        • 99% заказчиков не имеют выделенных ресурсов
        • важный вопрос - если что-то должен сделать заказчик - рядом должна быть им написана фамилия исполнителя и желательно когда они (фамилии) РАЗНЫЕ
        • проверка ресурсов - пришлите пожалуйста
      • технические требования и ограничения
        • с заказчиком нужно говорить на языке который ему понятен
        • если он в состоянии описать сценарии и на основании с этим можно формировать тех требования
        • можно обсуждать потом
        • технические ограничения - которые существуют у заказчика

Мастер класс по вебинарам

Почти год прошел с 13/06/13 и отличного мастер класса по вебинарам от ребят из компании http://tucha.ua/

Я только сегодня сподобился собрать вместе и упорядочить транскрипт. 

Это самый полный мануал по вебинарам, который я видел. Если вам придется заниматься вебинарами - обязательно к прочтению.

• Подготовка к вебинару
  • Определитесь - кто ваша целевая аудитория
    • На кого рассчитан вебинар?
    • Что их интересует
    • Где искать этих людей?
  • Темы для вебинаров
    • Формируйте сразу последовательность тем - несколько серий в сезоне
    • Всегда важна структура передачи информации
    • Не стоит все впихивать в один вебинар – бьём тему на серии – заранее продумываем последовательность серий
    • Выбор тем для вебинара
      • Анализ интересов
        • Отдел продаж
          • Люди общаются с клиентом
          • Знают, что клиенту непонятно
          • Знают какие у клиента есть мысли по поводу разных вещей
          • Общаясь раз в неделю узнаем, что тревожит клиента и что у него вызывает вопросы
        • Форумы и сообщества. Живые тусовки людей.
          • Тех людей, которые являются вашей целевой аудиторией
          • Мы идем туда, где эти люди обитают
        • Отраслевые издания
          • Периодика
          • Онлайн/Оффлайн
          • Статьи по проблематике рынка на который вы ориентируетесь
          • Если вам нравится тема, затронутая в журнале и вы хотите ее расширить и добавить пару слов.
          • Люди уже знают что-то из среды (из публикации) и у них будет бэкграунд (общие знания)
          • Бывает и так вышла статья – вы думаете «какой же умник написал?» - вы делаете вебинар в котором вы показываете другую точку зрения на освещаемые вопросы (без прямых ссылок)
        • Опыт коллег по рынку
          • Хорошо, когда уже есть коллеги по рынку
          • Сообщества компаний на рынке может помочь
          • Конкуренты – ваш источник информации
          • Можно узнать то же, что и от отдела продаж
          • Узнав больше о том, что интересно потенциальному потребителю.
          • Не стесняйтесь ходить по вебинарам конкурентов – можно подобрать много интересного.
      • Составление перечня тем для обсуждения в течении вебинара
        • Формируем список тем
          • Не отсеиваем ничего
        • Выбираем лучшие темы
          • Выбираем наиболее интересные
          • Что-то можно совместить
          • Получить перечень 7-10 тем, которые вы проведете как серию вебинаров
        • Составляем график вебинаров
      • Дополнительные материалы
        • Практические кейсы (ситуации из жизни)
        • Результаты бенчмаркинга (оценки производительности)
        • Инфографика и видео
          • Как можно больше
          • Визуальная информация лучше усваивается
        • Продукт в действии
          • Можно вывести некий рабочий стол, и показать – как работает ваш продукт
          • Если ваш продукт онлайн – покажите его в действии – как он работает
            • Особенно важно, когда продукт неосязаемый
            • Важно дать ощущение того, что он покупает реальный товар - услугу
          • Если ваш продукт оффлайн – покажите видео того, как он работает
            • Если продаете кубики-рубика – соберите кубики онлайн
  • Структура одной «серии» вебинара
    • Начало
    • Доклад – Информационный материал – 20минут 70% времени
    • Ответы на вопросы – 20минут – 30% времени
      • Когда отвечать на вопросы
        • Сразу или потом? – Собирать и аккумулировать.
        • Периодически делать отступления, чтобы ответить.
        • Даже если отвечать в процессе вебинара – в конце вебинара вопросы все равно будут.
      • Вопросы кто-то должен начать задавать – нужен первый смелый. После этого аудитория начнет это делать сама.
  • Работа с вопросами
    • Не стесняйтесь и не ленитесь подготовить вопросы, которые вы бы хотели, чтобы вам задали - и озвучивайте их, если вопросов не будет.
      • На вебинар может прийти 5 человек
      • Вопросы не зададут
      • Вы хотите, чтобы тема была раскрыта до конца
      • Можно даже зарегистрировать аккаунт под Именем «Иван Иванов» и задать вопросы от его имени
      • Те вопросы, которые ВЫ БЫ ХОТЕЛИ, чтобы вам задали.
      • Вопросы которые нужны для ПОЛНОГО раскрытия темы
    • Откуда брать вопросы?
      • Вопросы, которые задает ваш отдел продаж
      • Списки Часто задаваемых вопросов
      • Сайты
      • Форумы
    • Заранее готовимся к вопросам
      • Вопросы стоимости услуг
      • Очень важно дать ответ как можно скорее
      • Калькулятор стоимости услуг
      • Очень важно – могут сразу заказать
      • Технические детали реализации продукта
      • Вопросы по продуктам
      • Спорные вопросы
        • Лучше даже задать их самому себе в вебинаре
        • Вопросы которые были заданы и вы дали на них ответ лучше, чем вопросы, которые сформировались, но никто ответ не дал
  • Создание материалов
    • Заранее написать текст, который вы хотите рассказать
    • Сможете у себя в голове его лучше структурировать
    • Останется в сознании – будет легче его изложить
    • План вашего доклада
    • Реклама для каждой "серии"
  • Анонс и отчет по вебинару
    • Сайт – выкладываем на сайт новости
    • Анонс заранее
      • не забываем про часовой пояс при указании времени
      • Информационная рассылка
    • Дайджесты посвященные новостям отрасли, технологии, а также и нашим новостям
    • Через сеть партнеров
      • Оповещение клиентов партнеров
  • Команда подготовки к вебинару
  • Выбор площадки для проведения вебинара
    • Сформулируйте список требований к платформе, а потом выбирайте. (clickwebinar.com - $40/мес)
    • Реализуем все задумки
      • Демонстрация презентаций
      • Демонстрация рабочего стола
      • Брендирование комнаты
      • Режим флип-чарта – (белая доска учителя)
      • Переадресация на страницу по окончанию вебинара
        • После вебинара переадресация на страницу тестового доступа к услуге или на сайт компании
      • Опросники
        • Очень хорошо запускать в начале или в конце
          • В начале – возможность подождать тех, кто опаздывает.
    • Удобство посетителя
      • Регистрационная форма для пользователей
      • Напоминания о событии
        • В будний день в 15.00 – все заняты и нужно напомнить – за делами дня - вебинар не видно.
      • Поддержка русского языка
      • Мобильные устройства
        • Просмотр вебинара на планшетах
      • Поддержка iCal, Google Calendar
        • Добавляет в календарь пользователя событие вебинара
    • Технические компоненты
      • Поддержка браузеров
        • У пользователей может быть что угодно.
      • количество часов для записи видео вебинара
      • Доступность сервиса
        • Во время вебинара платформа не должна «зависнуть»
      • количество докладчиков (4ре)
      • Красивая ссылка
        • Отправляется в прямом виде
        • Можно делать ссылку с вашим доменом
  • Подготовка платформы (площадки)
    • Форма регистрации
      • Активация формы для регистрации участников
      • Настройка формы регистрации и обязательных полей
      • Добавление собственных полей
      • Активация ручной проверки данных
    • Удобство регистрации
      • Удобная регистрация - должны быть понятна и не требует ничего лишнего
      • Минимум обязательных полей
        • Имя
          • а как иначе к вам обращаться
        • почта
          • куда рассылать материалы вебинара
      • Должна происходить единожды
        • без введения дополнительных данных для каждого вебинара
      • Без нарушения логики и взаимосвязей
        • если вы хотите получить дополнительную информацию о человеке
        • соответствие полей - если выбрана страна никарагуа - номер телефона должен быть с кодом никарагуа.
      • Автоматическое подтверждение регистрации
        • не нужно ничего проверять
      • ClickWebinar не позволяет вводить имена на русском
        • при заполнении регистрационной формы можно сделать комментарии к полю
    • Делаем площадку яркой
      • Форма регистрации
        • оформление форм
        • лого
      • Комната для проведения вебинаров
        • лого компании
        • цвет фона
        • фоновое изображение
    • Дополнительные возможности
      • переадресация на посадочную страницу
      • Автоматическая запись вебинара
  • Создаем материалы для вебинара
    • Базовая комплектация
      • стандартный набор материалов для каждой серии
        • презентация в стиле компании
          • 720х540 пикселей
        • текстовая версия
        • баннер для сайта с анонсом вебинара
        • Шапки для FB, youtube
          • обновление баннера на сайте и шапок по расписанию
    • Расширенная комплектация
      • Тестирование услуг
      • Визуализация определенных данных
        • используем сервис infogr.am
          • Изображения без ограничений
          • Интерактивные диаграммы
          • Интеграция с youtube - можно встраивать внутрь инфографики
          • Таймер
          • - один шаблон с поддержкой русского языка
          • - жесткая структура шаблонов оформления
          • - работает с Youtube но не поддерживает ссылки
    • Огласите список
      • план вебинара также может рассказать ведущий в начале
    • Легкий первый кадр и музыка для ожидания
      • первым кадром может стать титульная страница презентации для вебинара
      • первый кадр и музыка нужны, чтобы поставить их онлайн заранее до начала вебинара
    • Удобные ссылки
      • для youtube: ссылки в описании, ссылки внутри видео.
  • Готовимся к видеозаписи
    • Планируем паузы для последующей резки
    • Обработка видеозаписи
      • вырезаем шумы, паузы, технические накладки
      • добавляем содержание вебинара
      • добавляем первый кадр и анонс следующего вебинара
      • Добавляем к видео ссылки на материалы описание и теги
      • основную мысль - внимание в первые две-три минуты - заинтересовать.
    • Запись экрана
      • внутренние возможности
      • CamStudio
      • Camtasia (Windows, Mac)
      • Microsoft Expression (windows)
  • Финальная подготовка перед началом вебинара
    • Подготовку на получасовой вебинар нужно начать за час до начала вебинара (до времени эфира)
    • Название комнаты должно быть со смыслом
    • Первый режим «быстрый старт». Второй режим – позволяет установить дату и время.
    • Не забываем выбрать правильный часовой пояс указываем его в анонсах
    • Выбираем максимально возможную продолжительность
    • Описание размещено на странице приветствия участника.
• Во время вебинара
  • Разминка перед стартом вебинара
    • Отдельное помещение
      • звонки и прочее мешает
      • люди вокруг
      • вы пытаетесь сосредоточиться
      • переговорная комната - хороший вариант
      • очень желательно, если помещение тихое и в нем нет эха
      • придти и сесть заранее, посидеть
    • Место ведущего
      • удобное
      • проводной интернет
      • вебкамера
      • микрофон
    • Подключение к Интернет
      • не доверяйте wifi
      • интернет должен быть проводным.
    • Место помощника
      • помощник может обратить ваше внимание на происходящее в чате и подать условный сигнал
      • таблички ("пошути")
      • с помощником нужно быть осторожным, чтобы не сильно отвлекали
    • Машина для скринкастинга
      • можете забыть нажать кнопку записи
      • качество записи, которая дает платформа неплохое, но своя лучше.
      • можно зайти в вебинар как клиент и записывать все, что происходит.
    • Напоминания и регистрация
      • отдельное напоминание за час до вебинара и предупредить, что скоро начнем
    • Опечатки в материалах
      • просмотрите материалы еще раз.
      • люди могут отнестить с подозрением.
      • сложно удалить из записанного видео
    • Нужные вкладки / компьютеры
      • откройте заранее все страницы в интернете - не ждать, пока загрузится
      • положите в отдельную папку на рабочий стол все нужные файлы, чтобы их не искать.
      • сделайте отдельный компьютер
    • Ненужные вкладки
      • закройте заранее
      • а вдруг - это порнография? :)
    • Шпаргалка для ведущего
      • краткий конспект
      • которым вы не должны шелестеть!
        • просто положите пару листиков на стол
      • структура доклада
      • цифры
    • Видео, музыка, промо-ролики
      • музыка и видео ставим за 15 минут ДО начала вебинара
      • это сразу позволяет протестировать работу системы ДО начала вебинара
    • Тест "видно? слышно?"
      • в самом начале вебинара
      • делать пару раз в течении вебинара - может быть у человека не работает но они не говорят.
      • задавать вопрос "всем ли все понятно" - провоцировать на вопросы
      • если у пользователя что-то не работает - может он запустил торрент?
  • Тишина на площадке
    • Помощь участникам вебинара
      • хорошо, когда есть человек, который может помочь справится участникам с техническими трудностями.
    • Никаких шумов и телефонов
      • Для связи помощников с ведущим skype - НЕ БУМАЖКАМИ. Бумажки можно не разобрать. Пусть ПИШУТ в СКАЙП.
    • Никаких односложных ответов
      • давайте развернутые ответы на любой вопрос
    • ведущий, структура вебинара!
      • слайды - шпаргалка для вас - оживляете структуру вебинара
      • картинки в слайдах - привязка к концепциям в вашей голове
      • 50-60% того, о чем вы хотели говорить забудется :) - не паникуйте.
        • те люди, которые пришли не знают, какая была структура
        • возьмите паузу, подождите, подумайте и вернитесь к теме
    • анонс и ссылка на регистрацию
    • озвучиваем вопросы участников
      • вопросы задают в окошке чата
      • не все смотрят в чат
      • не все люди в комнате знают, что вопрос вам вообще задали
    • опросы стоит проводить до начала и после окончания
      • можно в середине но:
        • короткая длительность на вопрос - +/- 45 секунд
        • покажите ответы - В ПРОЦЕНТАХ!
        • позволит переключиться вашим клиентам
      • вебинар интерактивная штука
• После вебинара
  • Сделайте транскрипт вебинара
    • В отличие от вебинара транскрипт будет проиндексирован google
  • Отчитываемся о прошедшем вебинаре
    • если вас перестали смотреть онлайн - возможно вас стали смотреть в записи :)
    • стандартный отчет =
    • презентация на slideshare +
    • видео на youtube +
    • приглашение на следующий вебинар
    • каналы информирования
      • блог компании
      • рассылка компании
      • социальные сети
      • партнерский кабинет
      • почтовая рассылка компании
    • получатели отчета
      • участники и регистранты
        • рассылка регистрантам через платформу вебинара - мы не собираем адреса
      • партнеры компании
      • подписчики ваших дайжестов
  • Зазываем всех на следующий вебинар
    • вебинары требуют хлеба и зрелищ :)
    • нужно "подкачивать" новую публику - старые переходят смотреть на youtube
    • приглашение на вебинар =
      • стандартные отчеты +
      • ссылка для регистрации
    • используем все возможности
      • социальные сети
      • шапка FB - хорошая возможность зазывать людей на вебинары.
        • загрузка шапки по расписанию - шапка = анонс события
        • Шапка FB
          • шапка обновляется у компании и у всей ее команды
          • Анонс ближайших двух вебинаров (справа)
          • Регистрация на сайте - кликабельная ссылка и анонс в описании шапки
      • реклама на мероприятиях
      • партнерская сеть
        • партнеры активно используют материалы в партнерских рассылках
        • берут материалы из партнерского кабинета - нужно их туда положить
  • Реклама вебинаров на форумах
    • Рекламные листовки
    • Анонс вебинаров в презентации для доклада
    • Выступление на форуме
    • рассказывайте всеми возможными способами
  • Жизнь после вебинара
    • вебинары - ответы на вопросы ваших слушателей
    • точка соприкосновения желания клиента узнать о технологии и возможности рассказать о ней
    • раздел вебинары на сайте
      • пока мало - можно постить в блоге
      • лента
    • отдельная страница на сайте (может быть запись)
      • //все материалы после вебинара
      • описание вебинара
      • встроенное видео
      • презентация на slideshare
      • активная инфографика из infogr.am
      • ссылка на pastebin - стенограмму вебинара - google понравится
      • анонс следующего вебинара
      • максимальное повторное использование
    • баннер в блоге
      • записи опускаются в бездну
      • баннер - переходит в тег, или категорию, которой вы маркируете свои вебинары
    • добавить вебинары в слайдер на сайте
      • сначала - был баннер, через который шла регистрация на вебинары
      • заменили на слайдер посвященный вебинаром
    • компиляции презентаций
      • используйте ЕДИНЫЙ дизайн
      • собрание разных идей, объединенных одной концепцией
      • выглядит адекватно
    • шапка FB и своему другу
      • анонсы вебинаров
      • перечень тем вебинаров
      • ссылка на раздел, посвященный вебинарам
      • - ссылки в шапке не кликабельны - нужно делать отдельно.
    • youtube канал
      • появилась шапка - можно использовать для рекламы
      • можно делать кликабельные ссылки
      • только одна на сторонний сайт
      • остальные в раздел "информация"
        • Ссылки на корпоративный сайт - титульная страница
        • ссылки на продукты
        • ссылки на структуру облака
        • тест-драйв - может быть стоит поставить главной ссылкой!
      • подключить социальные сети
        • fb
        • twitter
        • pinterest
          • инфографики!
          • сервисы для размещения инфографик?
        • google+ идет по-умолчанию.
        • blogger
      • плейлисты
        • создаем плейлисты
        • можем сделать на странице пользователя ротации плейлистов
        • поднять ВВЕРХ вебинары
      • заполните ВСЕ описания для роликов
        • видна одна строчка - пользователи не любят развернуть
        • ссылка с видео на соответствующий раздел с материалами вебинара (презентация и прочее)

Peer recommendations

From what's the future of business Slideshare

Dead Zone Streamline requirements flow in distributed projects by Sergey Prokhorenko @ Agile Pizza

Presentation

Dead Zone (v1.1 in English for AgileEE 2013) from Sergey Prokhorenko

• Whoami
  • http://ua.linkedin.com/in/sergeyprokhorenko
  • Head of head of Agile Practice at Luxsoft
    • Since 2005
    • 15+ customers
    • 50+ ongoing projects
    • 700+ Agile practitioners
    • 100+ Certified Scrum Masters
    • 15+ internal Agile Coaches
• Agile as a silver bullet
  • Agile Providers vs Client problem
    • Business value driven prioritization to deal with Always late with the things we really need
    • Pay for DONE to deal with Paying for the wrong things
    • Change without penalty to deal with Too expensive to make even little changes
    • Client is in full control of the project to deal with Difficult to understand where we are right now
  • Actual use of requested features
    • Always 7%
    • Often 13%
    • Sometimes 16%
    • Rarely 19%
    • Never 45%
    • Source: The CHAOS Manifesto, The Standish Group, 2011
  • Simple rules
    • RUP Referece and certification guide - 289 pages
    • SCRUM Guide - 16 pages
    • presentation slide 4
  • Scrum is a game of chess - simple rules - but endless combinations
  • idealized role of PO in a company
    • Responsible for maximizing the value of the product and the work of the Development Team
    • Sole person responsible for managing the Product Backlog
      • Power
      • Expertise
      • Dedication
    • Does Sprint Planning and PBR with the Development Team
    • Tracks total work remaining at least every Sprint Review
  • Real life PO example - a team of PO
    • presentation slide 7
    • End users / stakeholders - Product vision team - prototypes - PO - pPOs for teams.
    • several PO - customer side PO, user side PO, intermediate pPO.
    • customers are on the "other side"
    • there are different time zones - 8hrs turnaround to get a solution
    • product owner is involved either in business, or in PO activities.
  • SCRUM becomes a cargo cult - doing SCRUM for SCRUM sake - no results.
    • things don't happen
  • How did we end like this? presentation slide 10
• Sprint level visualization
  • SCUM rules - describe moves & technics, but not the strategy.
    • What to do on the higher level to sync teams is left in the "grey", "dead" zone
      • Management
        • Are we on track to deliver scope on time?
        • When release epics will be ready and what is the current status?
        • What are PO (BA, pPO) doing? Do they have blockers?
        • How many stories are ready for the next sprint?
        • Are we ready for the next release planning?
      • Developers
        • What is the goal of the current release?
        • Are we on the track to deliver on time?
        • What are other teams doing?
        • Are there any dependencies on a project level?
        • Does PO and BA have enough requirements? - what would we do, when this sprint ends?
• What can we do about it?
  • People and interactions!
    • Who is PO?
      • man from business - no time for team - BETTER - can at least explain something.
      • man from IT - no time for business.
    • Clear roles and Responsibilities of dedicated PO on/from customer side
      • Prioritization - only PO can do. If PO can't do - SCRUM wont live on
      • Expertise - we can live with it. At least PO will understand business globally and get priorities.
        • we can get external experts to help with
      • Communication
        • first in a list to save time on.
        • least important - can gather once in a week to work.
  • Processes and tools
    • Use Kanban on high level at Project (program) level (presentation slide 18)
      • Goals / epics
      • Analysis ongoing
      • Ready for Development
      • Next 20 stories to pick
      • InDev
      • Acceptance OnGoing
      • Ready for production
    • High level flow
      • Request from stakeholders
      • Backlog prioritization
      • Backlog refinement
      • Ready for development
      • Sprint
      • Ready for release
    • Value stream mapping
      • Request from business sponsors
      • Program initiation <- involve / add team here!!!
      • Project chartering
      • Epics breakdown
      • User story drafting
      • User story grooming <- if team joins here - you will get waterfall
      • Ready for spring
      • In development
      • Ready for demo
      • Ready for UAT
      • in UAT
      • Ready for release.
      • 
        
      • Backog prioretization
      • +Addons
      • sign off
      • release publishing
  • DoD Agreements (Definitions of Ready) (Analysis phases)
    get more detailed on each phase
    • Do not build a formal contract, but rather visualize as much as possible for sprint.
    • Finishing of ready. (FoR)
    • Program initiation
      • PID is shared with BAs
      • Project charter is drafted and shared with business sponsors and BAs
    • Project chartering
      • Charter is approved by business sponsors
      • Final charter is reviewed with BAs in a meeting
    • Epics breakdown
      • Charter breakdown into epics is approved by PO
      • All epics are described in Confluence with:
        • Business context
        • Problem statement
        • High-level acceptance criteria
      • All epics are presented to the team(s)
      • Epics are included into backlog and prioritized
      • Business contacts identified
    • User story drafting
      • User story is well-analyzed by BA and conform to INVEST criteria
        • https://en.wikipedia.org/wiki/INVEST_%28mnemonic%29
      • Detailed BDD scenarios are created
      • Mockups are created (where applicable)
      • Data requirements specified (if any)
      • Business logic is specified (if any)
      • US reviewed with business SME
      • Acceptance criteria are reviewed by business SME
      • US is prioritized in backlog and priority approved by PO
    • User story grooming
      • Team reviewed and agreed that US conforms to INVEST criteria
      • BDD acceptance scenarios are well understood by team and approved by business
      • All research spikes identified and completed
      • US breakdown is approved by team (and re-approved by business if any changes)
      • Business contacts are shared with the team
      • Design is approved
    • DoD for last analysis phase = DoR for sprint
  • Limit WIP for BAs - not more than one Epic. Only 30% value added as they work on several projects
  • Backlog grooming Ground Rules
    • Regular
      • At lease once a week, scheduled with PO
      • Started upfront (at least a week before planning)
    • Timeboxed
      • 15-20 min per story
      • If timebox isn't enough - go offline and prepare for next session
    • Includes the whole team
      • All team members ask questions upfront
      • Team members (not only PO/pPO) describe story value and scenarios
    • Strict DoD
      • If artifact doesn’t follow agreed DoD it isn’t moved to the next phase
  • Effective collaboration
    • Feature team US - Scrum of Scrums - Feature team UA
    • Scrum of Scrums
    • Cross-functional teams
    • Single backlog with unified estimates
    • Single Product Owner for the whole backlog.
    • Proxy Product Owners for each location #TBD - feedback loop
    • Joint release planning
  • SCRUM of SCRUMs = Big picture of the project
    • Anything depends on everything. SCRUM as a mirror of the processes.
    • also as a feedback to management
    • Inspect and adapt
• Product vision and goals. Sprint Zero Workshop
  • Who needs it most?
    • Scrum Team
    • Product owner
    • Scrum Master
    • Gathered all together in the same place
  • How long it takes?
    • one - two weeks
  • What do we get from it?
    • Synchronize product vision - get same language
    • Establish long term goals
    • Get Shared understanding of business
    • A common training and common language for the team
  • How do we do it?
    • Synchronize the product vision between the stakeholders (business canvas)
      • why do we need this product?
      • what problem does it solve?
      • who are the users - what are their problems?
      • what this product can do you can't do with other tools?
      • if you automatise something existing- how better the life would be with this product?
      • The goal is to get to a point, where team get a first hands on the product vision
      • Business model canvas as a tool
    • Obtain Goals
      • Create middle-term goals for the close half year. Some examples are:
        • get userbase
        • get to some minimal functionality
        • if it is an internal product - create SMART (measurable) goals (70% of manual activity to automatize)
        • get to understand - how do we measure success/failure
    • Create user personas for story mapping
    • Go for Story mapping.
      • Story mapping is created from the system users (persona's) point of view
      • Create a separate storymap for each user
        • as a user ... (persona from previous step)
        • I would like to do ...
        • so I would achieve ...
      • Use different coloured stickers for different personas - the one who needs the story - gets it
      • We must create complete story
        • either for one user
        • or for single process
    • Storymap becomes first backlog draft
    • Add weight for each story (can use fibonacci numbers as indicative weight) - affinity estimation
      • if some stories are over some measure in points - they are key target for splitting or lower priority
    • Slice user stories
    • Establish DoD (definition of done), Acceptance criteria
      • unit tests
      • introduction
      • testing
    • Set Priorities
    • Formulate Sprint 1 from stories (half sprint or quarter - better as they tend to grow ;)
    • Agree on working agreements (DoD partially, DoR (definition of ready) for requirements, Sprint pulse (timings)
• Recommended literature
  • Implementing Lean software development
  • Lean from the trenches
  • Scaling lean and agile development
  • Practices for Scaling lean and agile development