Маленькая поваренная книга ретроспективы

В прошлом 2016 году я выступил на CEE-SECR 2016 - конференции, которую посещаю, третий или четвертый раз, и на которой представляю свою компанию на стенде. В этот раз кроме стенда я попробовал выступить.

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

Если не хочется читать, то выступление доступно по ссылке: http://2016.secr.ru/program/submitted-presentations/retrospective-small-cook-book. Для тех кто предпочитает все таки читать - моя печатная версия далее.

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

На совещании спорили  конструктора (люди которые чертили в различных САПР-ах конструкции, схемы, устройства) и технологи (собственно те, кто все это реализовывал в железе). И те и другие были напряжены. Обсуждалось - как передавать схемы конструкций из одной системы документооборота в другую. Не было одной системы документооборота, было - два разных мира, два полюса. Но надо было работать, и надо было выполнять план.   На любой вариант решения одной стороны, вторая аргументировала "а вот какой нибудь технолог" или в обратную сторону - "а вот какой нибудь разработчик", и далее всякий неконструктив набрасывался на вентилятор.

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

- Коллеги! Мы же с вами профессионалы, а говорим о каких то гипотетических технологах и конструкторах - давайте попробуем!

Было молчание. Затем согласие  обеих сторон.

Два урока.

Первый урок -  "мы с вами профессионалы" магическим образом влияет на оппонентов. Они всегда соглашаются с первым утверждением, и очень часто затем соглашаются с любым вторым

"Мы же профессионалы - у нас нет багов, но если они появятся, то мы будем фиксить их на проде"

И это - манипуляция чистой воды.

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

Второй урок, который я вынес, это магия рецепта "давайте попробуем". Постоянным планированием успеха не добьешься. Постоянными обсуждениями - тоже.

На тот момент я был юн и не знал таких замечательных слов как Facilitator, Lesson Learn/Retrospective, Agile - услышал я их гораздо позже. Но встреча показала силу коллективной работы. Люди начали решать проблему. Впервые за долгое время технологи и разработчики создали правила обмена. И я понял, что "Давайте попробуем" это своего рода рецепт приготовления общего согласия. Позже я понял - таких рецептов масса.

С тех пор я начал копить рецепты, выверять их и использовать. "Давайте попробуем" трансформировалось в  "Экспериментируй!" и стало   первым рецептом в моей будущей, тогда еще не сформированной, поваренной книге ретроспективы.

Заметка сегодня большая и включает несколько частей:

Часть первая вступительная: определим что такое профессиональные поваренные книги.

Часть вторая основная: рассмотрим уникальные рецепты вкусной ретроспективы.

Часть третья заключительная: я предложу универсальный рецепт для всех поваренных книг.

Вспомнить все: Опросник ретроспективы в действии

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

Из подслушанного

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

Среди частых проблем ретроспективы стали всплывать с регулярной частотой ситуации "забытых провалов"  - те моменты, которые командой не обсуждаются или не вспоминаются. Причины подобного поведения разные - человек, непосредственно столкнувшийся с проблемой заболел либо не пришел, или просто проблему не вспомнили на фоне других более ярких провалов, либо боязнь обидеть хорошего человека перевешивает желание исправить проблему. Совершенно разные причины. Но больные темы пропускаются. Это не так критично, когда спринты короткие (так как проблема всплывет вскоре и выше шанс "вспомнить" и поправить), но в условиях  длительных (более месяца) релизов - решения приходят с большой задержкой, что влияет на ретроспективу и процессы скорее отрицательно.

Сегодня я бы хотел показать пример одного из способов не упустить из виду "невсплываемые" бреши в процессе. Поговорим сегодня об Опроснике - артефакте, чек листе, сборнике эвристических вопросов и просто удобном инструменте.

Моя система 34: помидоры, опилки и хомячки

Даже путь в тысячу ли начинается с первого шага

Лао-Цзы

Какой один маленький шаг я могу совершить, чтобы стать ближе к своей цели?

Шаг за шагом к достижению цели. Метод Кайдзен Роберт Маурер

Несколько лет назад была задумана заметка "Моя Система - 32". Несколько позже заметка стала называться "Моя система - 33". Мне стукнуло 34, и вместе с этим пришло понимание, прокрастинировать можно до бесконечности, и  еще - нужно зафиксировать текущее состояние системы.

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

Причина по которой заметка написана - желание самому разобраться в своей системе и перестать прокрастинировать.

Окончание заметки произошло благодаря "опилкам времени" - простой, но эффективной практике, о которой немного позже, немного ниже.  Мотиватором для окончания заметки послужил тренинг г-на Дорофеева (в благодарность, но скорее ссылаясь на авторитет, в статье он упоминается достаточно часто)

Польза для читателей? - скорее всего, имеется.  Новичкам - начать путь, средничкам - взять на вооружение "как это может быть еще", для профи получить удовольствие от состояния "улыбнуло".

Управление знаниями - модели и концепты

Это уже третья по счету заметка про знания. Она гораздо короче чем предыдущие Первая и Вторая. Ровно потому, что представлены картинки и комментарии к ним - этакие сгустки идей, которые могут помочь задуматься и построить что-то свое.

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

Чуни в процессе передачи опыта

Обсуждали с коллегами, что такое плохо комментированный код, ну там были истории про комментарии на румынском и т.д. Самая прикольная история была про большую компанию, которая купила другую компанию со всеми их наработками. Когда стали разбираться в коде новой компании, то выяснилось, что большая часть написана китайцами, а добил их комментарий перед злобной реализацией некого алгоритма на несколько страниц: "описание алгоритма смотри в тетрадке у Чуня". Где тот Чунь уже было неясно :)

http://bash.im/quote/401544

Сегодня поговорим о грустном. О передаче опыта

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

Человек уходит, и вместе с ним уходят 1-2-3-назовисвоечисло лет опыта, ошибок (из разряда за одного битого...) и истории. Мой жизненный опыт показывает, что, к сожалению, не всегда безболезненно проходит передача производственного опыта, не всегда - в полном объеме. Хотя опять же, как ты передашь каждое свое знание накопленное за годы работы проекта втискивая их в 10 рабочих дней?

В последнее время приходится часто организовывать передачу знаний. Появился материал для систематизации. Как критичны эти знания из тетрадки Чуня. Как слабы мы в условиях неопределенности...

Образы и концепты практикующего тест менеджера

Одна картинка заменяет 1024 слова

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

Инфографика меня таки просто завораживает.

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

За последние полгода поток информации был мощным и самое главное освежающим. Появились несколько вещей, которые ранее не приходилось делать. И на основе опыта появились картинки, таблицы, схемы...

Тема заметки - красивые картинки. Просто образы, картинки, концепты... Они таки иногда приносят "вкусные" идеи. 

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

Если работа тестировщика некрасивая - она неправильная.

Процесс с нуля. Первые шажки 3: Отчетность и Визибилити

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

Нет более неблагодарной работы, чем подготовка отчетов и постоянное подтверждение, что ты тот самый, в то самое время, на том самом месте.

Процесс с нуля. Первые шажки 2: Планирование и Знания

В первой части своих же первых шажков я упомянул о двух стратегических направлениях новичка-тестировщика: взаимоотношениях и тестовой лаборатории. Сегодня я бы хотел коснутся планирования работ и знаний.

То, сколько я знаю о проекте всегда сильно влияет на мою оценку трудоемкости. Причем наблюдается тенденция, когда зная больше - я больше и закладываюсь на тестирование. Впору придумывать теорию расширяющего знания тестировщика ))).

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

Процесс с нуля. Первые шажки - 1: Взаимоотношения и Тестовая лаборатория

За последние 2 года мне удалось "поосваивать" - в хорошем смысле слова - несколько разных по сложности о составу команды проектов. Каждый проект уникальный. А задачи с созданием группы тестирования - вроде бы одни и те же...

Новый проект. Новые люди. Новые традиции и новые горизонты в тестировании.

Знакомиться с новыми людьми.

Изучить новый продукт.

Построить свою работу с нуля.

Как не утонуть в новом хаосе?

Я бы хотел сегодня покопаться в этой нелегкой куче.

QA NewComer Checklist

Адаптации нового сотрудника в новой (ом) компании\проекте\команде. 

Более быстрый и более дешевый ввод в проблемную область нового специалиста.


Как можно быстрее, и как можно качественнее обучить новичка...

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

Я не так часто в своей жизни менял работу (смотря с кем сравнивать ;) ) .  Но мне приходилось и учиться, как новичку и обучать новичков. Данная заметка - мой взгляд на непростую ситуацию, когда хочется и быстро и хорошо: разделить успех сытых волков и тучных овец.

В одной заметке, конечно же, сложно полностью охватить нелегкий вопрос обучения/ адаптации нового сотрудника к условиям выживания в новой компании/проекте. Более того , мне кажется, выводить один общий унифицированный подход к этому вопросу сложно. Компании разные, проекты еще более разные, а уж люди какие бывают  непохожие (по знаниям,  опыту,  возрасту, весу и вероисповеданию). Сложно все причесывать одной гребенкой. Поэтому в этой небольшой статье мне бы хотелось упомянуть одну из best-practice "на местах": Newcomer Checklist.

Собственно я столкнулся на своей новой работе с так называемым Newcomer Checklist. До этого мне приходилось читать, в потом и создавать официальные документы. Плюсы от таких документов конечно же есть, но были и минусы: подписать один документ своим начальником, зам ГД по кадрам + генеральным директором - дело не одного дня. А вот  Necomer CheckList это страница в wiki подобной системе, в которой просто по пунктам указано:

1. Программы, аккаунты, права доступа и соответственно процедуры получения программ, аккаунтов, прав доступа.

2. Общие процедуры: оформление отпуска или отгула, ведение календаря или табеля учета времени, внутренние ссылки.

3. Процедуры и процессы (например, в моем случае, по обеспечению качества), шаблоны (тест планов/спецификаций/тестовых сценариев), руководства пользователя и линки на информацию по проблемной области.

Уместилось в три пункта, но новичку для того, чтобы полностью пройти чек лист нужно около месяца (с учетом проблемной области может понадобиться и больше времени).

После выполнения всех пунктов чеклиста, я немного расширил страницу и добавил ответвление: QA Necomer Checklist, но смысл остался примерно тот же самый.

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

Сложного ничего нет. Нужно  просто обновлять страницу по мере необходимости. Информация же не меняется сразу и вся ;)

Форма чек листа помогает настроить новичка на нужную волну и отслеживать, как продвигается его адаптация.

Wiki подобная система ликвидируют ограничения формальных письменных документов.

Собственно сплошные плюсы проекту.

Как говорил мой преподаватель философии: "Это нужно обдумать".