Новогодние каникулы - не только время праздновать новый год, но и пауза между делами прошлого года и делами будущего. И это - повод завершить незавершенное. А из незавершенного у меня остались отчеты об осенних AnalystDays и SQAdays - с самих конференций я вел трансляции в ленте facebook, но если не собрать эти посты, то они так в ленте и пропадут. Ну и заодно это повод вспомнить о коференциях в целом. А еще сейчас видео докладов с обоих конференций уже выложено и можно смотреть и те доклады, о которых я пишу, и все остальные - на конференциях было по три трека, и я не мог быть на всех одновременно.
Но сначала я хочу отметить еще одну конференцию, сентябрьскую Точку Сборки. Это конференция Питерского сообщества аналитиков, которую организуют Анна Абрамова и Анна Горбатенко. В этот раз они экспериментировали с новым форматом: вместо обычных докладов были большие слоты, посвященные отдельным темам и мастер-классы. В процессе подготовки через опрос участников в сообществе были выделены интересные темы и интересные докладчик, а дальше докладчикам по одной теме было предложено соорганизоваться между собой и сделать совместный интерактив с аудиторией, а организаторы были готовы в этом помочь. И получилось очень интересно - конференция реально формируется участниками. Хотя для организаторов такую конференцию, думаю, делать сложнее: надо не просто найти докладчиков и темы, но и при необходимости фасилитировать обсуждение. Слот по обучению аналитиков вели четыре человека, которые были незнакомы между собой. Но у аналитиков - высокая культура коммуникации, и все получилось.
Видео доступно на канале Сообщества аналитиков СПб, программа на FB
На очередной конференции 17.02.19 этот формат, наверное, будет повторен, а сейчас идет сборка тем. Голосуйте и участвуйте, конференция - в воскресенье 17.02 и стоит совсем недорого. А для тех, кто живет не в Питере, это еще и повод приехать на выходные. Тем более, что записи не было, потому что съемки и монтаж интерактива - сложнее, чем запись обычного доклада, на волонтерских началах это сделать не получается, а обязывать участников оплачивать запись для всех остальных как-то не справедливо.
Я сам выступал совместно с Верой Петровой, она - профессиональный фасилитатор и мы устроили разбор кейса, который сами участники предложили и выбрали, с работой в группах и со мной в роли эксперта. Мы опасались, что люди не решатся предъявить личные кейсы для публичного обсуждения, но, как оказалось, зря: более 40 участников были на это готовы. Разбирался кейс про приоритизацию бэклога в условиях множества стейкхолдеров, которые не могут договориться. Не могут - не потому что не хотят, а потому, что каждый делает запросы в системе в рамках своего бизнес-контекста, и просто не может сопоставить их с запросами, сделанными другим стейкхолдеров в рамках их контекстов, потому что их не представляют. И человека, который был знал все бизнес-контексты с детальностью, нужной для содержательной расстановки приоритетов, просто не существует. Как сказала автор кейса, она бы сама могла стать арбитром, расставляющим приоритеты, но полагает это неправильным, во-первых, потмоу что ее знаний тоже недостаточно и расстановка будет произвольной, а, во-вторых, это требует достаточно много времени, чтобы обеспечить баланс интересов стекйхолдеров и убедить их, что все происходит разумно, а она видит свою реализацию вовсе не в политических коммуникациях. В результате обсуждения было высказано довольно много идей, и часть из них автор кейса решила попробовать в ближайшее время.
А еще был сделан вывод, что этот кейс - хороший пример расширения круга ответственности аналитиков и руководителей проекта: в них входит, в частности, такая вот организация социальной системы стейкхолдеров, обеспечивающая расстановку приоритетов и баланс интересов, этого ждут. А раньше полагалось, что это - за пределами проекта, приоритизированный список запросов команда проекта получает как исходные данные. При этом понятно, что такая социальная система существенно зависит от условий, в которых разворачивается конкретный проект, она не может быть типовой для всех. В ходе обсуждений участники рассказывали про разные системы, которые у них работают, а другие - об аналогичном опыте, который не сработал потому что оказался не адекватен условиям проекта. Таким образом, ее надо собирать под проект, при этом она должна быть встроена в культуру организации и общую систему принятия решений.
А потом, до конца конференции, я, как и обещал, разбирал с участниками те кейсы, которые были предложены, но не прошли в голосование. И я хочу отметить, что несколько кейсов было связано с ростом аналитиков. Ситуация: большая компания, в ней большой IT-отдел, хорошие условия работы, много проектов. Но все проекты - более-менее одинаковые, и через 3-5 лет становится не интересно. При этом руководство - не слишком заинтересовано в росте аналитиков и не понимает проблемы, например, в конференции они участвовали за свой счет. Мой ответ был в том, что первым шагом надо снять ментальные ограничения, которые сейчас направляют размышления о росте только внутри компании, и начать рассматривать задачу роста в более широкой рамке. А рост - он предполагает что ты пробуешь делать то, что раньше не делал, и если внутри текущей компании это невозможно, то попробовать за пределами. Компаний - много, рынок труда - дефицитен, так что это - не слишком рискованное мероприятие, плюс потом можно вернуться и даже с повышением за счет нового опыта, если сама компания нравится. Самое главное тут в том, что такая смена позиции размышлений над задачей дает эффект сама по себе, если ты начинаешь опрокидывать это в деятельность и коммуникации. Потому что ты должен, для начала, дать себе ответ на вопрос: а какой именно рост я хочу, какой проект и компанию выберу? Сейчас-то человек выбирает из закрытого меню проектов, которые есть в его компании, а тут получается открытый список. Ну а дальше, в процессе ответа на вопрос, может оказаться что какая-то деятельность покажется привлекательной настолько, что уход из компании перестанет пугать. А может, наоборот, оказаться, что какие-то виды активности вполне можно организовать и в процессе текущей работы, если сфокусировано поговорить об этом с руководством, заодно объяснив потенциальные проблемы и риски ухода. То есть снятие ментальных ограничений вовсе не означает немедленного и обязательного ухода неизвестно куда.
А еще на конференции у меня родилась метафора про гибкость организаций (пост FB). Гибкий человек на конференции: приходит со своими целями, ведет открытую коммуникацию, не только получая, но и давая собеседнику. чутко следя за возможностями, открыт к новому и готов перестраиваться прямо в процессе, узнав что-то новое и важное. Так вот, организации в мире должны быть такими же - вести коммуникацию с миром, с людьми и организациями, знать и работать на свои цели, но не только получать, но и отдавать миру, быть открытыми к новому и готовыми перестроить цели прямо в ходе коммуникации. Вернее, это - не просто художественная метафора. Надо представить организацию как коллективного субъекта, ведущего коммуникацию с другими субъектами мира.
В посте было обсуждение.
На этом я закончу про Точку сборки. И надеюсь встретитьcя со многими читателями на ней в феврале.
Девятая конференция AnalystDays прошла на границе ноября и декабря (30.11-01.12) в Москве, как всегда интересно, было много общения и интересных докладов.
Мои основные инсайты
Остальное читайте в заметках к докладам, тем более, что во многих из них были интересные обсуждения.
Сам я выступал на конференции с двумя докладами. Спиральная динамика для аналитика - работа на стыке культур был подготовлен заранее и посвящен модели Спиральной динамики, позволяющей работать с корпоративными культурами. Что важно для налитиков, потому что они служат коммуникаторами между заказчиком и командой разработки, культуры которых часто отличаются очень сильно. Второй доклад Визуальные модели корпоративного приложения был подготовлен быстро как замена для докладчика, который не смог приехать и был по слайдам повторением доклада на meetup в Райффайзене. А слова наверняка отличались.
Пост FB Yulia Malyarevskaya. Роль Руководителя проекта в процессе управления требованиями. Интересное сопоставление PMBOK, который описывает руководителя как чистого менеджера, котором управление требованиями не заложено, и RUP, в котором существенна учтена IT-специфика, и управление требованиями занимает существенную часть. При этом достаточно детально рассматривается разделение активностей между аналитиками и руководителями проекта, при котором РП не подменяет аналитиков, они работают совместно. И такое детальное рассмотрение встречается довольно редко, было интересно услышать. Были рассмотрены плюсы минусы и накладные расходы, которые из этого вытекают.
А потом была вторая часть, посвященная тому, как аналитик может вовлечь руководителя проекта в работу с требованиями, если тот этими аспектами пренебрегает и это приносит ущербы течению проекта. Тоже достаточно глубоко, с учетом стилей руководства и доминирующего мотиватора, которые позволяют выделить нужды и аргументы, которые конкретному руководителю проекта будут близки, и провести переговоры, на которые он откликнется. Модели стилей руководства и доминирующих мотиваторов тоже были, по 9 типов в квадратах 3*3, и я их с ходу не опознал, хотя наверняка где-то слышал. В презентации были в конце ссылки, заглянем...
В кулуарах выяснил, что модели лидерства и мотивации, о которых говорила Юля, практически неизвестны в России. Делюсь ссылками. Лидерство http://leadership.org.au/resources/leadership-models-tools/ австралийская модель
Мотивация http://www.motivationalleadership.co.uk/uploads/Example%20Motivational%20Map%20-%20FantasyTeam.pdf
Еще, отмечу мысль, которая в докладе звучала очень активно. Важная часть работы РП - это удержание скоупа проекта, проверка все решений на полноту, с одной стороны, и предотвращение произвольного расширения скоупа. При этом аналитик дает полную картину - потому что мы должны представлять, что за границами системы в пространстве и за границами текущего проекта во времени.
Александр Турханов "PMBOK, который описывает руководителя как чистого менеджера, котором управление требованиями не заложено" - с чего бы это? Управление содержанием проекта, управление изменениями, там явно прописано управление требованиями. Не инженерия требований, конечно, именно управление, логистика - где и как хранить, какие снять какие оставить.
Пост FB Irina MINOIU. Children do not need user manuals. Доклад про разнообразное мышление. В числе прочего - эксперимент с созданием конструкций из спагетти, пластилина, скотча и веревок, проведенный в бизнес-школах и у детей. В школах придумывают и идут по плану, дети - пробуют разные способы. В среднем дети успешнее. На самом деле, это проявление известного деления на ежей и лисиц, или, в Майерс-Бриггс - на решающих и воспринимающих (J-P). Получается, что в детстве мы все - воспринимающие, экспериментирующие лисы, а планирование - результат позднейшего обучения, и некоторых захватывает настолько, что первоначально заложенные способности к экспериментам оказываются жестко подавленными как неуместные в жизни... Интересно, особенно при том, что в ряде теорий указанные дихотомии объясняют наследственностью, а не обучением. Получается, что все-таки обучение, но, возможно, в бессознательное в очень раннем возрасте.
Дальше была россыпь разных техник мышления и его тренировки. Соединение разнородных объектов от де Боно, чтобы научить выходить за рамки. Техника 5 шляп и много другого.
Заметки о круглом столе: рассадка влияет на складывающуюся ролевую структуру команды. Кстати, об этом были интересные эксперименты Белбина: он исследовал влияние размеров и формы стола в рабочей комнате на ролевую структуру команды. Маленький стол способствует выделению управляющей группы даже в маленьких командах.
Татьяна Гороховская То есть продакты это чисто дети? 👶
И очень интересный трек обсуждения, в котором вышли на различные типологии и их достоверность.
Пост FB Мысли по поводу доклада Наталия Алиева из T-Systems. В ряде докладов появляется ощущение дежавю - воспоминание о первой волне Agile, которая прошла по России в 2008-2012, и тогда широко отражалась на конференциях размышлениями о роли аналитиков в Agile, об организации процесса без четкого разделения ролей, предписанного тяжелыми гайдами и т.п. (можно посмотреть в моих отчетах о старых конференциях). И тогда - разобрались, потом была определенная пауза, количество этих докладов не сошло до нуля, но новизна и актуальность темы уменьшилось. А вот сейчас явно идет вторая волна, когда agile приходит в крупную корпоративную разработку, в телеком-разработку, который придерживался более традиционного взгляда на процессы. И идет вторая волна осмысления того же самого.
А в других докладах есть еще встречное движение, осмысление тяжелых технологий менеджмента в том мире, который пользуется легкими технологиями управления проектов - углубление и конкретизация специализаций, создание легких вариантов, например, чек-листов, на основе накопленного в тяжелых подходах списков и так далее.
А в целом доклад был о том, что аналитику не надо замыкаться в своих специализациях, особенно узких, а надо осваивать смежные области: быть немного разработчиком, заказчиком, переводчиком, читать код и так далее. В общем, на оставаться I-специалистом, а становиться T-специалистом (хотя эти термины в докладе не употреблялись).
Пост FB Oleg Ramanovich. История о том, как пошли в другой домен, который не знают - автохолдинг. Надо было освоить. Осваивали, рассказ был о том, какими диаграммами они пользовались - BPMN, UML-активности, UML-последовательности и др. Встречи, до 30 встреч по одному процессу. Важно - с маркерами, чтобы эксперты рисовали в вольном стиле. Верификация - для этого надо абстрагировать и снизить объем до нужного уровня. В целом они освоили домен. И было выбрано коробочное решение и его адаптация, пилот эксплуатируется.
Пост FB Roger Burlton. Enabling Business Agility. Я слушаю Роджера второй раз, первый раз было на весенней AnalystDays (http://mtsepkov.org/AnalystDays-2018-Питер). Доклад очень хорошо показывает мышление, привыкшее и умеющее делать систематизацию внешнего мира через описание его структуры, раскладывание его по полочкам сложной модели, в которой все есть. Когда в мире появляется новый абстрактный объект, например, Value Chain, мы его тоже подвергаем знакомой операции декомпозиции, раскладываем на stream и их кусочки. Когда появляется новая задача, например, организации надо стать гибкой, мы ее рационализируем, вводим координату гибкость - стабильность и за счет этого определяем области гибкости. И как бы мы ее решили, мы конкретизировали гибкость до конкретных областей, и указали на проявление гибкости, например, на следование за нуждами клиентов с быстрой обратной связью.
Проблема в том, что такой подход выплескивает новую целостность, раскладывая ее по бесчисленным старым полочкам в нашей системе понятий. Value stream как поток создания ценностей, с оптимизацией прохождения, основанной на реструктуризации потока, теряется после того, как мы его иерархически описали, потмоу что иерархическое описание предназначено для стабилизации, а не для непрерывной перестройки. Новое требует новых онтологических конструкций, обеспечивающих эффективную работу, и именно поэтому дает больше, чем старое. Если мы посмотрим на школы классической работы с требованиями и школы UX/Usability, то увидите, что в учебниках по этим дисциплинам используются принципиально разные подходы и онтологии, и что если сформулировать UX в терминах работы с требованиями, то ценность практически исчезнет.
Пост FB Дмитрий Безуглый (Dmitry Bezuglyy). Аналитик в продуктовой разработке. Три этапа автоматизации.
Дима, как обычно, сыпет афоризмами. Требования пользователей меняются в тот момент, когда они увидели нашу софтинку!
Сложность + анализ + неопределенность = аналитический паралич.
Responce time маленький, часики завертелись быстро, а вот а время предоставления результата - неизвестное.
Но это лучше, чем раньше. Что бесит бизнес? Запланировали скоуп, время и ресурсы. Потом подходит время - и разработчики говорят 99% сделали, 99% осталось. Agile это решает.
Но! Если 200 команд каждая генерит что-то новое каждый месяц, то что будет через год-другой предсказать нельзя. Если мы не знаем, что будет через два месяца, то никто другой - тоже не знает. Многие подменяют нефиксацию скоупа отсутствием цели, и частая проблема практического agile.
Классический agile - за конечный эффект отвечает бизнес. А PO отвечает за Product backlog. За счет постоянного взаимодействия на демо и в других активностях получается команда полной компетенции. И именно это нужно для создания цифровых продуктов.
Digital team обладает компетенцией учиться. Аналитик больше всего любит изучать. Накопление знаний о предметной области - структурировать, разобрать - это основная компетенция аналитика. А формат представления - не важен.
Бизнес-аналитик и системный аналитик - общие компетенции, но разные предметные области: бизнес и софт. И разная сложность: софт - чаще complex, а бизнес - complicated. Но при инкрементальной поставке софта, разрабатываемого большим количеством команд, софт тоже уходит в complicated.
В условиях высокой неопределенности требования быстро тухнут. Все, что проанализировали вперед - протухло. Это надо понимать, и не анализировать в будущее. Нужно видение продукта. Потому что каждый шаг - эксперимент, и он должен быть осмысленным.
Vision. Раньше было обязательно фиксация как документ. Однако, если продукт ведет одна команда полностью, то это - не обязательно. Он видел варианты эффективных команд, у которых был vision без документа, видел и наоборот.
Данные быстро устаревают. То, что 20-летние предпочитали 10 лет назад почти ничего не говорит о том, что будет сегодня. Поэтому аналитика по данным тоже нужна свежая, и делать надо здесь и сейчас. Данные не так много предсказывают о будущем.
В конце схема. Три уровня управления продуктами
И компетенции и дисциплины для каждого уровня - надо смотреть на схеме в презентации.
За 6 месяцев свежими остаются 60% требований, а за год свежесть сохраняют 20%. В длинных проектах можно многому научиться, но полезность созданного софта - очень сомнительна.
Дмитрий Безуглый Максим Цепков Спасибо за фиксацию экспромптов.
Пост FB Максим Шаломович (Max Shalomovich). Архитектура и ее аналитики: как с этим жить?
Что архитектору нужно от аналитиков? Требования! А какие? А архитектурные - наиболее важные, которые помогают принять архитектурные решения! И это определение пишут не только в заумных стандартах, но и в популярных книгах :)
Ограничения. Уже принятые решения, которые есть в системе. Большая разница между "сделать только так" или "сделать так, но если очень хочется, то можно иначе". Поэтмоу формулировать надо аккуратно и обязательно должны быть основания. Редактировать или удалить это
Совет: если можно не фиксировать ограничения - не фиксируйте их! Выбор базы данных или языка можно изменить или в новом модуле может быть другой язык. Исключения - требования по нормативам ИБ фиксируйте обязательно, в том числе - отсутствие этих требований.
Требования к структуре системы. Аналитики их часто используют, чтобы эстетически сгруппировать требования, а потом их приходится тащить до конца, эмулируя несуществующую подсистему хранения данных или взаимодействия с пользователям.
Требования к перспективам развития и модифицируемости. Какие функции системы будут развиваться, и каким образом. Тут важно, может ли добавить новый атрибут в справочник или новый протокол интеграции добавить пользователь, или это делают разработчики, а это часто опускают. И сейчас это - наиболее важные требования, потмоу что все системы развиваются, и эти возможности надо закладывать в архитектуру.
Точки архитектурных функциональных требований.
Yuri Veretelnikov А зачем архитектор сидит и что-то ждет от аналитиков, интересно и непонятно..
Пост FB На #AnalystDays был интересный баркемп с Ольга Самарина (Olga Samarina) о смене mindset при переходе на другую позицию, в котором я участвовал как эксперт. В ходе обсуждения слушатели и сама Ольга делились своими историями и разбирали их. Получилось сформулировать рабочее определение mindset как набора мыслительных техник. И получить рабочий ответ на вопрос об изменении mindset. При смене позиции точно меняется фокус внимания. При этом в поле зрения могут появляться новые онтологические объекты, некоторые из которых могли быть известны теоретически, но не были включены в деятельность, а другие - могут просто отсутствовать. Для работы с этими объектами может быть достаточно имеющегося арсенала мыслительных техник, а могут потребоваться новые - тогда и происходит изменение mindset.
Иллюстрация была как раз на примере перехода Ольги о переходе с позиции бизнес-аналитика на позицию продукт-менеджера. Контекст работы и вопросы Зачем и Что делать - не меняются. Но ответ на эта вопросы начинает включать экономические аспекты деятельности - емкость рынков, трудоемкость реализации с разным качеством. И вовлечение этих экономических объектов в рабочую онтологию и работа с ними требует других мыслительных техник, обычно у бизнес-аналитика отсутствующих.
Хотя в некоторые у бизнес-аналитиков они могут иметься в арсенале. Например, если он уже решал задачи связанные с исследованиями рынков. Или умеет оценивать экономику собственной деятельности, сознательно управляя качеством и сроками написания концептов, требований и других документов, в зависимости от ситуации и контекста проекта.
В комментариях к посту - интересное обсуждение как раз о том, не путается ли изменение mindset с простым изменением переходом в другую позицию.
Пост FB Григорий Печенкин. Люди в разработке ПО: фактор или актор? Автоматизированная система по ГОСТ - это персонал + комплекс автоматизированных средств, обеспечивающая функцию... Персонал - рабы на галерах, а не люди :(
Модель Кано делит характеристики софта на
И в автоматизированной системе в модели Кано мы делаем обязательные, и иногда - желающие. Потому что для рабов.
Этот концепт - ролей, а не людей - давит очень сильно, он прошит в литературе достаточно мощно.
Все-таки делайте софт для людей, а не автоматизированные системы для рабов. И этих людей надо представлять. Есть три метода:
И вот роли - это про функции, про рабов. Но можно использовать их, потому что это наиболее простой метод, только видеть все-таки в них людей, а не роли.
Довлеющая инженерная культура: общение через документацию, сложные инструменты, сложные нотации. Это - тяжело.
ТЗ - приложение к договору. Давать программистам - не гуманно.
Сделали диаграммы в Enterprise Architect, послали бизнес-заказчику, он говорит: нам нравится, пришлите нам исходники мы хотим поправить... Что посылать?
Yury Solonitsyn Какой-то однобокий взгляд? Почему "рабы"? Элемент системы, которые также важен, как все остальные. И для его эффективной работы стоит постараться. И да, это определение по ГОСТ, а не требование ГОСТа считать людей рабами :)
Пост FB От Анны Абрамовой. Была на прошлой неделе на Analyst Days в Москве. Так как Maxim Tsepkov сподвигнул меня выступить в последний момент, то меня не было в программе в печатных материалах. В программу на стенах доклеивали по ходу дела.
Тем не менее, на мою мастерскую в начале второго дня пришло больше 30 человек и, хотя персональных напечатанных смайликов, как для других спикеров, для меня не заготовили, участники мастерской не поленились нарисовать их вручную! Что очень вдохновляет!
Был и один грустный смайлик. Что ж, не все готовы принять мысль, что выбор рабочих инструментов аналитика - это не единоразовая задача, и думать как сделать свои слова понятными нужно непрерывно, стандартные шаблоны не решают этой задачи. Могу понять.
Спасибо Thaya Tolstunova за помощь в подготовке выступления и Vladislav Orlikov за доверие!
24-я конференция SQAdays прошла 23-24 ноября в Москве. Как я писал в отчете о прошлых конференциях, "зрелая конференция зрелой отрасли". К сожалению, при этом из конференции уходит энергетика. Впрочем, на прошлой я весь первый день тоже думал, что энергетика ушла, а на второй - она вернулась. На этой возврата не произошло, но это может быть ситуативно, подождем до следующих конференций.
А содержание докладов по-прежнему хорошее. Инсайт для меня - доклад Marcin Sikorski (Польша) Этические аспекты общения с китайскими тестировщиками. Смотрите, он того стоит. Еще был очень интересный доклад Filipp Terekhov, в котором космические катастрофы детально разбирались - какие именно практики тестирования были нарушены, и это привело к печальному результату. И много других интересных докладов, читайте мои заметки, смотрите доклады.
Пост FB Данечка Майстренко Регресс без документации. Зал переполнен, докладчик жжет. Почему нет документации? Она есть, но мы не дадим - внутренняя. У нас эффективный менеджмент, а это лишнее. Или agile, а там не предусмотрено. Хотя чаще она есть, но настолько разрознена в разных googledocs и тасках, что собрать целостно невозможно.
ToDo: делаем исследовательский тур по проекту. Есть методика Виттакера, как это делать системно, но можно и самим пройти. Обращаемся к тем, кто знает. Можно к аналитикам, но надежда слаба: когда есть аналитики - есть документация. Можно к разработчикам - но они опишут как сделали, а не как нужно. Обращение к пользователям почему-то в крайнем случае. А еще сравнить с аналогами, если приложение носит общезначимый характер. А так же обращать внимание на дублирующиеся на разных экранах или версиях функции. В результате есть образцовый билд с описанными багами. Баги сейчас править не будут, но это - не важно. Теперь мы можем на этом основе нарисовать карту приложения в целом и писать тесты и чеклисты...
Vlad Tsypin ничего не понял:(
Максим Цепков Фишка в том, что докладчик из компании, которая занимается аутсорсингом тестирования. Их зовут в конкретную ситуацию проекта, и на вопрос "а как нам тестировать без документации?" отвечают "вы - профессионалы, вы сможете, мы верим". И он рассказывал, что они делают.
Alexei Vinogradov Многие беды начинались с ключевой фразы "аутсорсинг тестирования"
Пост FB Gojko Adzic From quality assurance to quality assistance. Шаг-1: Sell the problem, not the solution. Изобретательно: если 300 багов 1 приоритета, и все уверены, что именно такой приоритет - напечатайте их и повесьте на стену, это покажет ненормальность положения. Типичные проблемные места:
Чеканная формулировка: люди не сопротивляются изменениям, люди сопротивляются, чтобы их изменяли.
Поэтому вовлеките команду в поиск решений. и делайте малые, обратимые эксперименты, вместо глобальных изменений.
Фокус на тестах с высоким риском, не по площади, как часто предлагают разработчики.
До разработке прикиньте ожидаемые баги, напишите notes. И обсудите с разработчиками эти ожидания. Привлеките их к тестированию.
При тестировании - надо уметь выйти за рамки предписанной ситуации, придумать нетипичное поведение: пользователи ведь не идут по инструкции, они применяют софт творчески.
Дальше было большое количество техник разной сложности, с общим посылом "Пробуйте!"
И по организации работ:
Такой обзорный доклад.
Пост FB Michael Pilaeten Shift Left - testing in the land of acronyms. Стоимость исправления возрастает по мере сдвига момента обнаружения дефекта на более поздние стадии. Это понятно. Но дальше идет пара не слишком понятных графиков. Первый - про водопад, с возрастанием ресурсов ближе к концу проекта, в том числе для исправления ошибок, которые выявляются позднее. И другой, парадоксальный, для Agile: ближе к концу проекта трудозатрат меньше, а вот ближе к началу - наоборот, больше, с сохранением общей площади (это отмечено в рассказе). Моя гипотеза - сомнения на начальных стадиях вызывают всплеск коммуникаций и обсуждений не соразмерный достигаемому эффекту. Но вообще - непонятно, что именно там меряли, надо будет посмотреть внимательно презентацию.
Code review - с ним оказывается дешевле, чем без него - потому что он позволяет обнаружить ошибки раньше. Ссылка на книгу Tom Gilb Software Inspection.
И еще цифры. 21% projects fails из-за требований. 57% дефектов заложено на стадии проектирования, до кодирования.
Прикольно! В числе методов ведения проектов - WaterScrum :) такое вот словообразование
Сергей Добриднюк Я для себя в деньгах мерял. Как то рассказывал (см слайд - спринты 1 недельные). Характер расходов - "исправление" или "догоняние" не особо важен. Они есть в WF на финале, и значительные - не попадаем в срок, а доводка уже после срока - сжирает ожидаемую прибыль (в лучшем случае, в худшем - получаем убытки от проекта)
Пост FB Bruno Manczak. Неожиданная мысль. Архитектура и организация кода существенно влияет на тестирование - инкапсуляция, изолированность разных частей программы влияют на организацию тестов и их объем. Вывод - они должны быть предметом пристального внимания тестировщиков. Предпосылка - известна и очевидна, но указанный вывод делают далеко не всегда, оставляя архитектуру на усмотрение разработчиков.
Алик Курдюков Идея отличная, но мне ни разу не удалось это продать самим тестировщикам
Пост FB Natalia Savastiuk. 15-минут для обучения команды любой теме. В тестировании много народа без технического образования, и это - проблема. Многие ее осознают, и у некоторых получается учиться, но таких мало. Она экспериментировала по-разному - внешние тренинги и конференции, еженедельные часовые доклады, но форматы - тяжелые, а знания часто остаются теоретическими. И она придумала легкий ежедневный формат, о которым рассказывала: 15 минут каждый день перед обедом время важно, утром - статусы, вечером - билды, которые ждали к обеду. А перед обедом - нормально. Три этапа: подготовка - проведение - закрепление знания. На подготовке - выбор темы. Кажется сложно, но присмотреться к процессам, ошибкам, жалобам, недостаткам экспертизы - темы появятся сами собой. А еще можно брать внешние темы - как быть оратором или конструировать шутки. Если тема большая - делим, был пример про клиент-серверное приложение, про postman или освоение iOS - они раскладываются на 15-минутные слоты, и это эффективно.
На тему назначается ответственный - тема для него может быть новой и незнакомой, полезно дать навигацию. Поскольку ответственный - не эксперт, то важно дать подушку безопасности, плечо поддержки. И надо следить за таймингом, 15 минут обычно превращаются в 20, чтобы закончить мысль и ответить, но важно оставить официальные 15 минут. Сначала они просто рассказывали, потом появились презентации для фиксации следов, и трансляции для распределенной команды.
Еще - закрепление знания
В целом - работает, инструмент - эффективный, по времени - не напрягает совсем.
Пост FB Marcin Sikorski (Польша) Этические аспекты общения с китайскими тестировщиками. Очень интересный доклад, и очень быстрый английский - поэтмоу конспекта на получится. Но я очень рекомендую посмотреть запись, даже если вы не работаете с китайцами для общего представления о культуре. Образ очень любопытный, а учитывая развитие мира - важно эту картинку представлять. Если кратко, то я во многом узнал идеальный образ, знакомый мне по советскому прошлому и воплощенный в книгах - гордость за страну и нацию, поддержка видения и планов будущего на 10-15 лет, которое есть у правительства. При этом - баланс между работой и личной жизнью. А еще образ современный, вписанный в цифровой мир с его коммуникациями и инновациями. И эта картина - не с плакатов, а из повседневного взаимодействия, хотя и поддержана плакатами в презентации, выполненными в советском стиле.
И много детальных аспектов - отношение к времени, интимность и важность оценки компетенций и лица, отношения с коллегами, отношение к языку, отношение к деньгам, законы, которые сильно защищают китайцев и которые сложнее понять, чем европейские, многое другое.
В вопросах: вы рассказывали, как несколько лет работаете с китайцами и шаг за шагом лучше узнаете и адаптируетесь к их культуре. А есть встречное движение? Ответ: скорее, нет.
Пост FB Владимир Крючков. Интеллектуальное игровое моделирование в нагрузочном тестировании бизнес приложений. Идея - есть сценарии работы отдельных типов пользователей. Пользователь-бот имеет внутри себя модель состояний. По сути, логика поведения ботов программируется так же, как логика поведения персонажей, управляемых компьютерами в играх. И есть профили входной нагрузки, которые вбрасываются, обрабатываются ожидающими их ботами. При этом можно увидеть показатели нагрузки и сроки отклика системы в условиях реальной нагрузки. В целом - круто, но, к сожалению, доклад в стиле "у нас работает так", то что рассказано - примерно ясно из основной идеи, а вот каких-то деталей реализации, не раскрыто. Может быть их и не было, и в создание такой нагрузки - простая задача, которую "берешь и делаешь". Однако, судя по тому, что нагрузочное тестирование нужно многим, а такой способ не является общераспространенным, проблемные моменты при реализации наверняка были. И как раз было бы интересно получить ответ на вопрос: если подход нас вдохновил, как его реализовать?
P.S. технологии: приложение на 1C ERP, для тестирования 1С Enterprise + Selenium
В ответах на вопросы сказал, что решение выложено в open source на github и призвал интересующих присоединяться к проекту.
Пост FB Галина Вострикова (Galina Vostrikova). Мы хотим формировать не просто команду, а dream team. И надо сохранить команду в этом состоянии. А для этого мотивировать надо не только членов команды, но и самого лида - что сложнее, а риски демотивации больше.
У нее была печальная история из прошлого, когда она была тестировщиком в команде, а лид оказался демотивирован. И вся команда получила последствия по полной программе, в результате лид и многие другие ушли. В роли лида у нее тоже был провал мотивации: общаться не хочется, критичность к ошибкам выросла. И команда это тоже ощутила. Но она во-время себя поймала, отрефлексировала и выправила ситуацию. И об этом рассказывает.
Она начала ловить следующие моменты, которые ее мотивируют.
В получился практичный доклад не просто о том, что надо держать рефлексивную позицию, а набор конкретных фокусов и приемов, которые ей помогли. Понятно, что не все из них подойдут каждому, но, во-первых, можно взять стартовый список, а, во-вторых - нарабатывать свое. В общем, надо заботиться о своем эмоциональном здоровье и мотивации.
И в ответах на вопросы: здесь работает тот же принцип "shift left" - чем раньше увидишь симптомы раннего выгорания, тем легче его устранить и предупредить.
И еще - часто кажется, что текучку нельзя остановить. За полтора года такой рефлексивной позиции у нее только один раз был реальный пожар. А в ряде случаев, когда казалось, что пожар-горим - при кратком обсуждении оказывалось, что пожара-то нет и вполне можно взять паузу на необходимое восстановление.
Александр Шен Т.е. человек, - это такой своеобразный робот, программируемый посредством мотивации?
Пост FB В докладе Johan Steyn про тестирование программ, которые работают с использованием искусственного интеллекта, был ролик - маленькая девочка играет в лего, беседуя с искусственным интеллектом. И это вызывает размышление на тему - насколько изменится мышление людей, если дети массово будут разговаривать в раннем возрасте не с родителями, а с субъектами искусственного интеллекта. Потому что, есть подозрение, что такие субъекты могут быть куда менее разнообразные, чем родители. Или более? При этом известно, что базовое мышление в значительной мере закладывается именно в раннем возрасте, это заложено в генетические программы развития.
Я отмечу, что по некоторым наблюдениям у поколений, воспитанных на компьютерных играх с закрытым сценарием вместо игр во дворе со сверстниками произошла определенная атрофия способности самостоятельно придумывать сюжеты и варианты. С этим сталкиваются, в частности, ведущие нарративных игр, можно посмотреть посты https://dreamer-m.livejournal.com/467651.html и https://dreamer-m.livejournal.com/468092.html (продолжение).
Впрочем, вполне возможно, что проблема будет осознана, и наоборот, обучены эффективные и развивающие собеседники для детей, и тогда следующее поколение удивит родителей.
А вы что думаете?
Игорь Беспальчук Более разнообразные, однозначно. Меньше будет шаблонов на детях надето.
Владислав Орликов У меня такое ощущение, что сейчас на этот вопрос можно ответить только так "А хрен его знает!". Недостаточно данных, чтобы строить модели развития.
Пост FB Filipp Terekhov. Чужие ошибки: Космические уроки для QA. В докладах про разработку софта к известным катастрофам и авариям в космической отрасли обращаются часто, однако обычно это идет во вводной части доклада, агитируя заботится о качестве, а далее спикер переходит к рассказу о том, как это правильно делать. Этот доклад принципиально отличается следующим уровнем подробности. Автор рассматривает катастрофы и аварии, и показывает, какие конкретные шаблоны в организации тестирования или организации проекта в целом там были нарушены. Нельзя сказать, что там какое-то супер открытие, проблемы часто обыденные. Такие как принятие проблемной работы как допустимой, потому что пока не стреляет. Или спешка и запуск изделия по сокращенному циклу, без необходимых испытаний принятых решений, которое в результате аварии задержало программу, а не ускорило ее, как любой баг, обнаруженный на продакшн, из-за непроверенных конструкторских решений. Или просто недоработка по тест кейсам, случаи когда не прописали вполне понятный негативный сценарий, или положившись на процесс некоторый девайс вообще не покрыли тестами. И все это проводит ик конкретным материальным потерям, и, в особо печальных случаях, к гибели людей. И вот этот разбор - весьма интересен. А Филипп - профессиональный тестировщик и глубоко интересующийся космонавтикой человек, поэтмоу доклад был очень интересным. Кейсы - разные, и наши и американские.
Пост FB Vojtech Barta, Newired. Journey to Effective Reporting. Пирамида product - project - test managers - project team mates. По мере продвижения увеличивается детальность представления, это верно. А вот два других тезиса - о том, что по мере продвижения увеличивается вовлеченность в проект, а верх пирамиды хочет более абстрактных ответов - неверно. Вовлеченность нельзя просто мерить в часах, проводимых на проекте, эта мера мотивации и заинтересованности в успехе, и, в разных проектах она по разным уровням пирамиды может изменяться по-разному. И ответы нужны не более абстрактные, и особенно не более простые, как это трактует докладчик, они нужны в разных терминах. При этом члены команды не менее продуктов нуждаются в ответах, которые бы показывали ему картину целиком - но в его терминах.
Пост FB Юлия Абрамова. Комплексы: как с ними жить и распознавать в себе. Доклад в современном тренде освоения IT softskill на уровне всех членов команды, а не только руководителей и менеджеров, что предполагает соответствующие знания, рефлексивное поведение, самооценку и оценку коллегами как компетенцию для каждого. В этом докладе речь шла о поведенческих паттернов, через которые проявляются разные комплексы - героя, вины, отличников, превосходства, власти, малого знания и неполноценности. При этом рассказ достаточно разветвленный, не примитивный: комплекс превосходства, например, рассмотрен по отношению к заказчикам, пользователям, коллегам, в паре руководитель-подчиненный в обе стороны. А комплекс власти - не только у руководителя, но и у рядового сотрудника "эта фича не пойдет в релиз!." В легком IT-стиле, а не тяжелом фундаментальном - такой чеклист, который можно практически использовать для распознания проявления комплексов и работы с ними. И дальше у тебя личный выбор: ты можешь просто включить этот чеклист в свою работу, или можешь решить разобраться в этих комплексах и их проявлениях глубже, можешь одновременно идти по обоим путям. Можно еще игнорировать - но если коллеги ее примут, то игнорировать не получится. Слушатели активно окликаются, обсуждают.
И, замечу, что именно в таких простых формах информация по психологии востребована в IT. В учебниках и книгах по психологии ее в таком виде нет, поэтмоу IT-шники ее создают в своих формах таких вот докладов и чеклистов.
Сергей Добриднюк А если это не комплекс, а мотив ?
Пост FB Андрей Ладутько (Andrey Ladutko). Экспертный тест-менеджер - почему им нельзя стать и что из этого следует. Доклад по сути посвящен принципиальному конфликту между англо-американской и германско-русской школам управления организациями. Английская имеет корни в принципе "джентельмен может управлять чем угодно, профессиональные скилы - не то, что ему нужно", это оформлено в английской политической системе, в подходам к управлению 19 века, а со сменой мирового лидерства - воcпринято в Штатах и воплотилось в школах MBA. А немецкая школа управления 19 века базировалось на том, что и военные и руководители росли из профессиональных низов, осваивая управление в ходе решения задач. И она была воспринята сначала в царской России, а потом - и СССР.
Но это - взгляд на доклад снаружи. А сам доклад начинался с того, что сертификация ISQTB выделяет 3 уровня: Foundation, Advansed и Expert построена именно в логике карьеры менеджера. Базовый уровень говорит о понимании процессов, продвинутый - о совершенствовании процессов и обучении, а экспертный выделяет три области - стратегия, управление людьми и операционный менеджмент. Профессиональные навыки там отсутствуют. И вот тут возникают проблемы, давно известные в IT, который не принимает менеджеров со стороны. Первая - в том, что тестировщики оценивают руководителя профессионально. А в профессии уважение вызывает тот, кто решает сложные задачи, внедряет сложные технические средства, протаскивает релиз на руках. И если руководитель этого не умеет, то он не получит уважения. Но самое главное другое: руководитель без профессиональных скилов не сможет хорошо оценить технические потребности команды, и организовать их прокачку, у него велики риски слепой зоны в технологиях.
Поэтому модель ISQTB в IT-практике в значительной мере остается сферическим конем в вакууме, а на практике менеджеры растут из профессионалов, становясь из I-людей в T-людей в областях менеджмента, а не отращивая глубокие компетенции менеджера - далеко не все могут стать m-человеком. И дальше были конкретные области, в которых полезно прокачиваться, при этом не распыляясь в попытке охватить все по площади. Важные фокусы, в которых менеджер должен быть прокачан относятся к соблюдению балансов: люди против процессов, тактика против стратегии, стремление к техническому совершенству против скорости, разные функции управления, для которых полезна модель PAEI Адизеса. И при этом есть смысл не удерживать менеджерские функции на себе полностью, а передавать их тем, членам команды, кто способен.
В вопросах было обсуждение про баланс технических и менеджерских деятельностей, в ответах - уже с 4 человек техническое тестирование для лида будет не более 50%, но при этм оно все равно не должно стремиться к нулю даже с ростом команды, а стабилизируется на некотором уровне (цифра не названа). И про то, как тестировщику осваивать новые технические области при том, что он техническими вопросами занимается слабо, а новые техники появляются быстро.
Отмечу, кстати, что вопрос о менеджерах в IT сейчас приобретает очень интересный аспект в связи с тем, что Яндекс вынес все то тестирование, которое у него было на аутсорсинге, на платформу толока. Без потери качества и с нулевыми расходами на менеджмент для сопровождения процесса. Ольга Мегорская (Olga Megorskaya) кратко рассказывала об этом в докладе на highload, и подробно - в докладе на Гейзенбаг (есть видео и презентация) Сейчас это касается простых задач, но планка неизбежно будет повышаться. И в перспективе это уберизирует тестирование, убрав операционный менеджмент в нынешнем понимании.
Пост FB Александр Александров. Экономика тестирования. Идеальное тестирование, в котором найдены все дефекты невозможно. Хотя некоторые менеджеры этого не понимают и предъявляют претензии "почему не все дефекты были исправлены до проноса на прод?" Ответ - потому что это слишком дорого и экономически не эффективно. И реальная оценка тестирования рассчитывается из экономической эффективности: затраты на тестирование против возможных ущербов. Об оценки тестирования он говорил в докладе 2011 года (https://sqadays.com/ru/talk/12185) и не хочет повторяться. В докладе речь пойдет про другое - очень часто эту оценку режут, из разных соображений, и в результате вместо 500 часов выдают 300. Или в ходе проекта возникают изменения, которые приведут к повторному тестированию, не заложенному в бюджет. Печальная практика состоит в том, что при этом часто тестировщики все равно продолжают следовать выработанной для 500 часов стратегии, потом бюджет вдруг кончается и возникают проблемы.
А правильная практика - выработать другую стратегию под реальный бюджет. И она вырабатывается из совершенно других экономических соображений - не возврат инвестиций, а максимизация результата при ограничении по бюджету. И поэтому подходы должны быть другими. Надо решать, какие нужны тест-кейсы и нужны ли, какие нужны тестовые данные, какие нужны тестировщики, нужна ли автоматизация и так далее.
В целом - все правильно. Однако, я отмечу, что надежная оценка тестирования требует повторяемых проектов. Уверенная оценка риска требует не менее 30 измерений, об этом у него тоже был доклад, но раньше 2011 и записи нет. Поэтому надо еще и оценивать свою ситуацию и поток ваших проектов - насколько они повторяемы, а насколько уникальны.
Alexei Vinogradov "Повторное тестирование" - в некотором смысле оксюморон. Как повторное программирование, например.
Рина Ужевко Максим верно заметил. Нельзя нормально и уж тем более эффективно оценить стоимость если у тебя не было аналогичного опыта ранее. Но тут опять же, есть грабли в виде проекции одного опыта на другой и это может вылезти с др стороны.