Новогодние каникулы - не только время праздновать новый год, но и пауза между делами прошлого года и делами будущего. И это - повод завершить незавершенное. А из незавершенного у меня остались отчеты об осенних AnalystDays и SQAdays - с самих конференций я вел трансляции в ленте facebook, но если не собрать эти посты, то они так в ленте и пропадут. Ну и заодно это повод вспомнить о коференциях в целом. А еще сейчас видео докладов с обоих конференций уже выложено и можно смотреть и те доклады, о которых я пишу, и все остальные - на конференциях было по три трека, и я не мог быть на всех одновременно.

Но сначала я хочу отметить еще одну конференцию, сентябрьскую Точку Сборки. Это конференция Питерского сообщества аналитиков, которую организуют Анна Абрамова и Анна Горбатенко. В этот раз они экспериментировали с новым форматом: вместо обычных докладов были большие слоты, посвященные отдельным темам и мастер-классы. В процессе подготовки через опрос участников в сообществе были выделены интересные темы и интересные докладчик, а дальше докладчикам по одной теме было предложено соорганизоваться между собой и сделать совместный интерактив с аудиторией, а организаторы были готовы в этом помочь. И получилось очень интересно - конференция реально формируется участниками. Хотя для организаторов такую конференцию, думаю, делать сложнее: надо не просто найти докладчиков и темы, но и при необходимости фасилитировать обсуждение. Слот по обучению аналитиков вели четыре человека, которые были незнакомы между собой. Но у аналитиков - высокая культура коммуникации, и все получилось.

Видео доступно на канале Сообщества аналитиков СПб, программа на FB

На очередной конференции 17.02.19 этот формат, наверное, будет повторен, а сейчас идет сборка тем. Голосуйте и участвуйте, конференция - в воскресенье 17.02 и стоит совсем недорого. А для тех, кто живет не в Питере, это еще и повод приехать на выходные. Тем более, что записи не было, потому что съемки и монтаж интерактива - сложнее, чем запись обычного доклада, на волонтерских началах это сделать не получается, а обязывать участников оплачивать запись для всех остальных как-то не справедливо.

Я сам выступал совместно с Верой Петровой, она - профессиональный фасилитатор и мы устроили разбор кейса, который сами участники предложили и выбрали, с работой в группах и со мной в роли эксперта. Мы опасались, что люди не решатся предъявить личные кейсы для публичного обсуждения, но, как оказалось, зря: более 40 участников были на это готовы. Разбирался кейс про приоритизацию бэклога в условиях множества стейкхолдеров, которые не могут договориться. Не могут - не потому что не хотят, а потому, что каждый делает запросы в системе в рамках своего бизнес-контекста, и просто не может сопоставить их с запросами, сделанными другим стейкхолдеров в рамках их контекстов, потому что их не представляют. И человека, который был знал все бизнес-контексты с детальностью, нужной для содержательной расстановки приоритетов, просто не существует. Как сказала автор кейса, она бы сама могла стать арбитром, расставляющим приоритеты, но полагает это неправильным, во-первых, потмоу что ее знаний тоже недостаточно и расстановка будет произвольной, а, во-вторых, это требует достаточно много времени, чтобы обеспечить баланс интересов стекйхолдеров и убедить их, что все происходит разумно, а она видит свою реализацию вовсе не в политических коммуникациях. В результате обсуждения было высказано довольно много идей, и часть из них автор кейса решила попробовать в ближайшее время.

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

А потом, до конца конференции, я, как и обещал, разбирал с участниками те кейсы, которые были предложены, но не прошли в голосование. И я хочу отметить, что несколько кейсов было связано с ростом аналитиков. Ситуация: большая компания, в ней большой IT-отдел, хорошие условия работы, много проектов. Но все проекты - более-менее одинаковые, и через 3-5 лет становится не интересно. При этом руководство - не слишком заинтересовано в росте аналитиков и не понимает проблемы, например, в конференции они участвовали за свой счет. Мой ответ был в том, что первым шагом надо снять ментальные ограничения, которые сейчас направляют размышления о росте только внутри компании, и начать рассматривать задачу роста в более широкой рамке. А рост - он предполагает что ты пробуешь делать то, что раньше не делал, и если внутри текущей компании это невозможно, то попробовать за пределами. Компаний - много, рынок труда - дефицитен, так что это - не слишком рискованное мероприятие, плюс потом можно вернуться и даже с повышением за счет нового опыта, если сама компания нравится. Самое главное тут в том, что такая смена позиции размышлений над задачей дает эффект сама по себе, если ты начинаешь опрокидывать это в деятельность и коммуникации. Потому что ты должен, для начала, дать себе ответ на вопрос: а какой именно рост я хочу, какой проект и компанию выберу? Сейчас-то человек выбирает из закрытого меню проектов, которые есть в его компании, а тут получается открытый список. Ну а дальше, в процессе ответа на вопрос, может оказаться что какая-то деятельность покажется привлекательной настолько, что уход из компании перестанет пугать. А может, наоборот, оказаться, что какие-то виды активности вполне можно организовать и в процессе текущей работы, если сфокусировано поговорить об этом с руководством, заодно объяснив потенциальные проблемы и риски ухода. То есть снятие ментальных ограничений вовсе не означает немедленного и обязательного ухода неизвестно куда.

А еще на конференции у меня родилась метафора про гибкость организаций (пост FB). Гибкий человек на конференции: приходит со своими целями, ведет открытую коммуникацию, не только получая, но и давая собеседнику. чутко следя за возможностями, открыт к новому и готов перестраиваться прямо в процессе, узнав что-то новое и важное. Так вот, организации в мире должны быть такими же - вести коммуникацию с миром, с людьми и организациями, знать и работать на свои цели, но не только получать, но и отдавать миру, быть открытыми к новому и готовыми перестроить цели прямо в ходе коммуникации. Вернее, это - не просто художественная метафора. Надо представить организацию как коллективного субъекта, ведущего коммуникацию с другими субъектами мира.

В посте было обсуждение.

Vladimir Fedorov Интересно, в чем ценности того, кто такие организации прокламирует, т.е. Максима. Другими словами, почему организации должны быть такими? Что хорошего миру и приятного душе, таких как сам Максим они сделают?

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

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

На этом я закончу про Точку сборки. И надеюсь встретитьcя со многими читателями на ней в феврале.

Девятая конференция AnalystDays прошла на границе ноября и декабря (30.11-01.12) в Москве, как всегда интересно, было много общения и интересных докладов.

Мои основные инсайты

• Доклад Димы Безуглого - очень рекомендую смотреть. Помимо глубокого содержания там великолепные искрометные экспромты!
• От Юлии Малеревской австралийская модель лидерства и британская модель мотивации, обе практически неизвестны в России, при этом достаточно глубоко проработаны.

Остальное читайте в заметках к докладам, тем более, что во многих из них были интересные обсуждения.

Сам я выступал на конференции с двумя докладами. Спиральная динамика для аналитика - работа на стыке культур был подготовлен заранее и посвящен модели Спиральной динамики, позволяющей работать с корпоративными культурами. Что важно для налитиков, потому что они служат коммуникаторами между заказчиком и командой разработки, культуры которых часто отличаются очень сильно. Второй доклад Визуальные модели корпоративного приложения был подготовлен быстро как замена для докладчика, который не смог приехать и был по слайдам повторением доклада на meetup в Райффайзене. А слова наверняка отличались.

Yulia Malyarevskaya. Роль Руководителя проекта в процессе управления требованиями

Пост 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, который описывает руководителя как чистого менеджера, котором управление требованиями не заложено" - с чего бы это? Управление содержанием проекта, управление изменениями, там явно прописано управление требованиями. Не инженерия требований, конечно, именно управление, логистика - где и как хранить, какие снять какие оставить.

Максим Цепков Если быть точным, то заложено, но внутри, местами глубоко, а если брать оглавление первого уровня, то его там нет - об этом в докладе явно сказали. А вот в RUP вынесено на верхний уровень.

Irina MINOIU. Children do not need user manuals

Пост FB Irina MINOIU. Children do not need user manuals. Доклад про разнообразное мышление. В числе прочего - эксперимент с созданием конструкций из спагетти, пластилина, скотча и веревок, проведенный в бизнес-школах и у детей. В школах придумывают и идут по плану, дети - пробуют разные способы. В среднем дети успешнее. На самом деле, это проявление известного деления на ежей и лисиц, или, в Майерс-Бриггс - на решающих и воспринимающих (J-P). Получается, что в детстве мы все - воспринимающие, экспериментирующие лисы, а планирование - результат позднейшего обучения, и некоторых захватывает настолько, что первоначально заложенные способности к экспериментам оказываются жестко подавленными как неуместные в жизни... Интересно, особенно при том, что в ряде теорий указанные дихотомии объясняют наследственностью, а не обучением. Получается, что все-таки обучение, но, возможно, в бессознательное в очень раннем возрасте.

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

Заметки о круглом столе: рассадка влияет на складывающуюся ролевую структуру команды. Кстати, об этом были интересные эксперименты Белбина: он исследовал влияние размеров и формы стола в рабочей комнате на ролевую структуру команды. Маленький стол способствует выделению управляющей группы даже в маленьких командах.

Филипп Дельгядо А дизайн эксперимента подробно описывали? А то для подобных выводов хочется точно понимать, а что измеряли. Я уж не говорю, что в психологии сейчас делать хоть какие-то выводы можно только по метаисследованиям, уж слишком много экспериментов не повторяется при проверках (

Максим Цепков Филипп Дельгядо Если это про стол, то в докладе - нет, а у Белбина в книгах - достаточно подробно описано. На одном из этапов изучения команд они выделяли командам для работы разные комнаты, и смотрели, как это влияет. При этом они уже достаточно много знали о формировании команд в условиях эксперимента в зависимости от профилей участников, а наблюдатели, по идее, должны были фиксировать процесс рассадки и связанные эмоции детально, так что фактор был отделе от других - это 60е-70е, за статусом научных исследований следили.

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

Максим Цепков Про детей - надо гуглить по "Marshmallow Peter Skillman" (зефирный эксперимент, это я презентацию посмотрел, их уже выложили). Эксперимент известный, например, в посте https://manage-it.livejournal.com/64382.html есть рассказ на русском. Я думаю, можно найти детальные описания.

Филипп Дельгядо Спасибо.

Татьяна Гороховская То есть продакты это чисто дети? 👶

Максим Цепков Не, не чисто дети. Но они сохранили детскую способность экспериментировать и пробовать новое, которую у многих школа истребляет :)

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

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

Максим Цепков Дети - разные. Но достаточно интересный вопрос - что заложено генетически как способности, а что определяется разным воспитанием родителей и окружением, часто в том возрасте, когда ребенок еще не умеет говорить: тем. насколько разнообразен мир игрушек, насколько родители поощряют любопытство. Это разделение важно, потому что генетические предрасположенности нами не управляются, а результаты раннего воспитания можно компенсировать. Или нельзя, потому что соответствующая возрастная программа обучения уже выключилась - но тогда можно держать этот фокус в нужном возрасте...

Irina Muhina Maxim Tsepkov частично свойства ребенка заложеныв генетике, Веды говорят, что 4 типа детей приходит в мир : Учителя, Воины, Мастера и Бизнесмены. Но очень много можно в ребенке развить посредством игры при хорошем педагоге. К сожалению современная цивилизация детям засовывает гаджеты тогда когда их когнитивная емкость еще не развита и получаем цифровых Маугли на выходе. У нас есть частная школа в Канаде , где мыберем деток с 4 лет и по индивидуальной программе ведем в развитии: левой и правой половинки.

Игорь Беспальчук Максим Цепков Макс, еще имейте в виду, что врожденное не равно генетическое.

Максим Цепков Игорь Беспальчук Врожденное != генетическое - это как (если исключить родовые травмы)?

Дмитрий Цыганков Пожалуй, соглашусь с Игорем. Я никогда об этом не думал, но кажется, мои дети INTP и ESFJ. Причем всегда были более-менее.

Дмитрий Цыганков Или всё-таки ESFP? Не знаю, но точно менее P и более J, чем второй ребенок

Дмитрий Цыганков Хмм, нет, почитал - пожалуй, всё-таки ESFP. Ну тогда да, всё-таки мои наблюдения пожалуй подтверждают Максову мысль. Таки да, очень сложно представить ребенка, который структурирован и следует плану.

Игорь Беспальчук Максим Цепков Вот так. Как гомосексуализм, к примеру. Влияют события внутриутробного развития, гормональный фон, и т.п. вещи. Вроде это уже довольно точно. Правши-левши вроде тоже.

Дмитрий Цыганков Это да. Но в принципе, я наверное согласен с основной идеей, что J-измерение развивается (или не развивается) позже остальных. Хотя генетические задатки и фактор среды наверняка есть.

Дмитрий Цыганков Игорь Беспальчук сюда же: https://www.apa.org/monitor/julaug03/personality.aspx "Conscientious-ness, a trait marked by organization and discipline, and linked to success at work and in relationships, was found to increase through the age ranges studied, with the most change occurring in a person's 20s".

Дмитрий Цыганков Ну и да, чтобы было понятно, что это связанные вещи - "FFM-Contentiousness correlated to MBTI-Perception (r = .49)" https://psychology.stackexchange.com/questions/13460/what-correlation-research-has-been-done-on-mbti-vs-big5

Филипп Дельгядо Ну, соционический тип (да и эквивалентные ему схемы типа майер-бригс) точно не связаны с генетикой - у однояйцевых близнецов типы разные. Да и повторимость определения вызывает сомнения (как и вообще минимальная научность подобных классификаций и уж тем более выводов из них).

Дмитрий Цыганков Филипп Дельгядо ну, учитывая что у женщин и мужчин статистически очень разные психотипы, то с генетикой это точно как-то связано - как минимум, с полом. Но не на сто процентов. Научно признанной является сейчас скорее Big 5, а не Майерс-Бриггс.

Филипп Дельгядо Связанность с полом не означает связанности с генетикой, может быть дело в стереотипах воспитания.

Дмитрий Цыганков Филипп Дельгядо ну, блин, опять двадцать пять :) Я тут тоже общаюсь с людьми, которые считают, что вообще любая статистика может быть объяснена дискриминацией против женщин. Типа, если мужчин больше работает - это от того, что женщин дискриминируют. А если где-то женщин больше работает - так это от того, что... дискриминация против женщин во всех остальных местах. Это практически нефальсифицируемая система убеждений.

Дмитрий Цыганков Филипп Дельгядо https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5068715/ "According to twin studies, the Big Five personality traits have substantial heritable components"

Игорь Беспальчук Дмитрий Цыганков Ага. Components. Пока все это носит характер очень смешанных моделей, смешивающих кусочки личностных проявлений с разными источниками.

Филипп Дельгядо При чем тут дискриминация, не надо мне приписывать какие-то бредовые взгляды. Просто нельзя считать, что сдвиги в статистике по полам (кстати, а откуда вообще эта статистика взялась? Личные ощущения тут точно не показатель) свидетельствуют о генетической причине этого сдвига. Данный вывод просто некорректен, в любой оптике или принципах.

Дмитрий Цыганков Филипп Дельгядо а о чём еще это свидетельствует? Сама статистика по MBTI - вот: https://www.slayerment.com/mbti-gender Я считаю, это очень яркая иллюстрация (частично) генетической природы явления - но вообще, научные исследования такого рода проводятся на близнецах, это раз, а во-вторых, они проводятся применительно к Big 5, а не к MBTI, потому что это доминирующая модель в современной психологии. То есть это предыдущая моя ссылка. В общем, есть довольно строгие научные доказательства того, что прав и Макс, и Игорь, каждый по своему.

Филипп Дельгядо Ээ, а где собственно статистика, ссылка на статью с дизайном сбора данных, методом опроса, отбором респондентов, доверительными интервалами? При том, что мэйербригс вообще к науке отношения не имеет. Впрочем, и big5 наукой назвать сложно.

Дмитрий Цыганков Филипп Дельгядо мне эта тема интересна, поэтому я нашел несколько ссылок и фактов, которые кажутся убедительными и интересными мне. Но я не считаю её настолько важной, чтобы пытаться переубедить в чём-то вас. Попробуйте порыться сами, Филипп, если что-то найдете интересное, можете поделиться - буду благодарен.

Филипп Дельгядо Ну, а что искать? Что типология по майер-бриггс не подтверждается статистикой - написано даже в википедии (не определяет типы, не устойчива во времени, не коррелирует с профориентацией или любыми наблюдаемыми параматрами личности). Что основания для Майер-Бриггс не подтверждаются никак (увы, Юнг был великим философом, но модели его все-таки не соответствуют реальности) - тоже уже общее место.

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

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

Наталия Алиева из T-Systems

Пост FB Мысли по поводу доклада Наталия Алиева из T-Systems. В ряде докладов появляется ощущение дежавю - воспоминание о первой волне Agile, которая прошла по России в 2008-2012, и тогда широко отражалась на конференциях размышлениями о роли аналитиков в Agile, об организации процесса без четкого разделения ролей, предписанного тяжелыми гайдами и т.п. (можно посмотреть в моих отчетах о старых конференциях). И тогда - разобрались, потом была определенная пауза, количество этих докладов не сошло до нуля, но новизна и актуальность темы уменьшилось. А вот сейчас явно идет вторая волна, когда agile приходит в крупную корпоративную разработку, в телеком-разработку, который придерживался более традиционного взгляда на процессы. И идет вторая волна осмысления того же самого.

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

А в целом доклад был о том, что аналитику не надо замыкаться в своих специализациях, особенно узких, а надо осваивать смежные области: быть немного разработчиком, заказчиком, переводчиком, читать код и так далее. В общем, на оставаться I-специалистом, а становиться T-специалистом (хотя эти термины в докладе не употреблялись).

Александр Турханов Аналитики должны вымереть, отвечать надо за весь жизненный цикл, а не перебрасывать рабочие продукты через стену.

Konstantin Okorokov У 1С аналитиков широко развиты смежные специальности - инструктора и технического писателя. Также хороши технологические компетенции, но увы, непосредственно навыки того же бизнес-анализа отсутствуют напрочь.

Konstantin Okorokov Александр Турханов если аналитики - часть обеспечивающей (по большей части) системы, мало у них шансов за весь ЖЦ отвечать.

Александр Турханов Konstantin Okorokov я же не говорю про восстание аналитиков против тирании руководителя проекта. Конечно, им сверху должны дать полномочия и ответственность за весь ЖЦ. Кто требования писал, тот их и проверяет/принимает.

Oleg Ramanovich

Пост FB Oleg Ramanovich. История о том, как пошли в другой домен, который не знают - автохолдинг. Надо было освоить. Осваивали, рассказ был о том, какими диаграммами они пользовались - BPMN, UML-активности, UML-последовательности и др. Встречи, до 30 встреч по одному процессу. Важно - с маркерами, чтобы эксперты рисовали в вольном стиле. Верификация - для этого надо абстрагировать и снизить объем до нужного уровня. В целом они освоили домен. И было выбрано коробочное решение и его адаптация, пилот эксплуатируется.

Denis Beskov Непонятно, о чем рассказ. У меня была какая-то стратегия и я её придерживался

Александр Турханов Рассказ о том, как разработчики осваивали новую предметную область - universe of discourse.

Oleg Ramanovich Denis Beskov Рассказ как "у нас" это сработало ) метод, который можно использовать или не использовать, дело ваше)

Максим Цепков Денис, они рассказывали конкретную стратегию, которой придерживались, с конкретными инструментами. И слушатели могут использовать их опыт. В посте - не воспроизведено. Но можно будет посмотреть доклад.

Denis Beskov Александр Турханов нет рассказа. нужно было освоить, мы освоили. в чём саспенс и вызов — не ясно. смотрите основы сторителлинга, морфологию волшебной сказки, например

Александр Турханов Denis Beskov разбаловались люди со всем этим сторителлингом и пирамидой Минто. Любое мыслительное напряжение уже саспенс и вызов.

Максим Цепков Denis Beskov Александр Турханов (Alexander Turkhanov) про сторителлинг - это о чем? Про доклад, про мой пост, про что-то другое?

Александр Турханов Максим Цепков нет, не про твой доклад. Я про то, что сейчас от любой заметки, статьи и другого текста часто ожидают, что он что-то будет продавать, объяснять и подсаживать идеи. Такое ощущение, что мы в англосаксонской культуре живем. Только в англосаксонской культуре все нормально с извлечением подтекста, иронии и скрытых смыслов, а у нас просто хотят разжеванной в пюре пищи для ума. И это раздражает, потому что такое поведение встречается на каждом шагу. Я уж не говорю о том, что это страшно мешает вести бизнес, потому что с абстракциями вообще невозможно работать, каждый раз приходиться спускаться до уровня фактов.

Максим Цепков Александр Турханов Тут несколько аспекта. Первый - про извлечение подтекста, содержания из открытой информации. Это - отдельная компетенция, и, если честно, меня периодически удивляет, что ей мало владеют. Возможно, дело в том, что в советское время ей явно учили на разборах литературы и истории, выявляя из текста классовое и идеологическое содержание, а неявно этому еще и учился в жизни, воспринимая действительность. Сейчас в школе учат слабее или не учат, но зато в жизни столько рекламы - казалось бы, тренируй навык, очень полезно.

А вот второй аспект - многозначность терминов в разных культурах и дисциплинах. И вот тут для любых абстракций указывать соответствующий 4d-объект очень полезно, а без этого текст может быть трактуем совершенно по-другому. Многозначность мира сильно повысилась, люди работают через мемы и фолксономии, а не через научную картину мира и таксономиии, и, явно или неявно рефлексируя свое клиповое мышления, знают, что в разных клипах одно слово означает совершенно разное, и не всегда понятное из контекста.

Roger Burlton. Enabling Business Agility

Пост FB Roger Burlton. Enabling Business Agility. Я слушаю Роджера второй раз, первый раз было на весенней AnalystDays (http://mtsepkov.org/AnalystDays-2018-Питер). Доклад очень хорошо показывает мышление, привыкшее и умеющее делать систематизацию внешнего мира через описание его структуры, раскладывание его по полочкам сложной модели, в которой все есть. Когда в мире появляется новый абстрактный объект, например, Value Chain, мы его тоже подвергаем знакомой операции декомпозиции, раскладываем на stream и их кусочки. Когда появляется новая задача, например, организации надо стать гибкой, мы ее рационализируем, вводим координату гибкость - стабильность и за счет этого определяем области гибкости. И как бы мы ее решили, мы конкретизировали гибкость до конкретных областей, и указали на проявление гибкости, например, на следование за нуждами клиентов с быстрой обратной связью.

Проблема в том, что такой подход выплескивает новую целостность, раскладывая ее по бесчисленным старым полочкам в нашей системе понятий. Value stream как поток создания ценностей, с оптимизацией прохождения, основанной на реструктуризации потока, теряется после того, как мы его иерархически описали, потмоу что иерархическое описание предназначено для стабилизации, а не для непрерывной перестройки. Новое требует новых онтологических конструкций, обеспечивающих эффективную работу, и именно поэтому дает больше, чем старое. Если мы посмотрим на школы классической работы с требованиями и школы UX/Usability, то увидите, что в учебниках по этим дисциплинам используются принципиально разные подходы и онтологии, и что если сформулировать UX в терминах работы с требованиями, то ценность практически исчезнет.

Дмитрий Безуглый. Аналитик в продуктовой разработке

Пост FB Дмитрий Безуглый (Dmitry Bezuglyy). Аналитик в продуктовой разработке. Три этапа автоматизации.

• Индивидуальные инструменты - АРМ того, АРМ сего
• Автоматизация бизнеса всего ERP-тотальное. Если процесс автоматизировали - еще больше жертв богу автоматизации
• Цифра. Софт должен начать делать работу человека. Замещать.

Дима, как обычно, сыпет афоризмами. Требования пользователей меняются в тот момент, когда они увидели нашу софтинку!

Сложность + анализ + неопределенность = аналитический паралич.

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

Но это лучше, чем раньше. Что бесит бизнес? Запланировали скоуп, время и ресурсы. Потом подходит время - и разработчики говорят 99% сделали, 99% осталось. Agile это решает.

Но! Если 200 команд каждая генерит что-то новое каждый месяц, то что будет через год-другой предсказать нельзя. Если мы не знаем, что будет через два месяца, то никто другой - тоже не знает. Многие подменяют нефиксацию скоупа отсутствием цели, и частая проблема практического agile.

Классический agile - за конечный эффект отвечает бизнес. А PO отвечает за Product backlog. За счет постоянного взаимодействия на демо и в других активностях получается команда полной компетенции. И именно это нужно для создания цифровых продуктов.

Digital team обладает компетенцией учиться. Аналитик больше всего любит изучать. Накопление знаний о предметной области - структурировать, разобрать - это основная компетенция аналитика. А формат представления - не важен.

Бизнес-аналитик и системный аналитик - общие компетенции, но разные предметные области: бизнес и софт. И разная сложность: софт - чаще complex, а бизнес - complicated. Но при инкрементальной поставке софта, разрабатываемого большим количеством команд, софт тоже уходит в complicated.

Дмитрий Безуглый Максим Цепков Я хотел сказать с точностью до наоборот. Но так тоже хорошо - Просто к другому контекста подходит ))

Дмитрий Безуглый Максим Цепков (Maxim Tsepkov) Все зависит от рынка , к которому бизнес ближе. Где то бизнес RUN и ближе к Complicated, А где то бизнес Change и ближе к Complex. Написанная программа всегда Complicated

Максим Цепков Дмитрий Безуглый Я тоже хотел написать наоборот. Я complex и complicated путаю, когда пишу быстро, тем более, что в переводе complex - запутанная, а complicated - сложная. Обычно я проверяю по эталонной схеме, а тут - забыл... Написанная программа - не всегда complicated, она может стать complex с точки зрения предсказания ее работы. Тривиальный пример - нейронные сети, которые обучаясь - выходят из области complicated, и весь ИИ. Но, я думаю, даже windows со всем софтом поверх, установленным на домашнем компе сейчас уже complex. А на сотовых телефонах ИИ (всякие распознавалки) уже встроен в софт, и телефон с их помощью выполняет команды...

Дмитрий Безуглый Максим Цепков Все что выполняется на процессорах - complicated )) Только не компетентность может сделать его Complex. А перевод запутанная и сложная реально путаница , кто использует суть теряет ))

Максим Цепков Дмитрий Безуглый "Все что выполняется на процессорах - complicated" - не согласен. Но, возможно, это надо лично разбираться. Тезисы.

1. Из простых элементов можно собрать сложную слабо предсказуемую структуру. Пример - игра жизнь.
2. На процессорах идет обработка данных, а сами данные накапливаются. Возникают обратные связи, адаптация к внешнему миру, данные отражают этот самый внешний мир и поведение становится столь же сложным (в пределе). Примеры - обучающиеся нейронные сети, алгоритмы поиска и т.п.
3. Для понимания системы (то есть для классификации как complicated) нужна система сопоставимой сложности. Для комплексов софта даже на десктопе или телефоне со многими приложениями такой системы из людей не существует. Наверное, она может быть собрана в принципе для конкретного экземпляра, но это никогда не будет сделано, потому что никому не нужно. А классификация Cynefin - относительно наблюдателя, а не абсолютная (наблюдателем может быть не индивидуальный, а коллективный субъект, например, человечество). Поэтому complicated не достижим.

Замечу, что каждый из тезисов опровергает утверждение независимо от других.

Дмитрий Безуглый Максим Цепков Да, правильнее сказать что все что мы исполняем в детерменированной среде потенциально сводимо к complicated

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

Vision. Раньше было обязательно фиксация как документ. Однако, если продукт ведет одна команда полностью, то это - не обязательно. Он видел варианты эффективных команд, у которых был vision без документа, видел и наоборот.

Данные быстро устаревают. То, что 20-летние предпочитали 10 лет назад почти ничего не говорит о том, что будет сегодня. Поэтому аналитика по данным тоже нужна свежая, и делать надо здесь и сейчас. Данные не так много предсказывают о будущем.

В конце схема. Три уровня управления продуктами

• способность команды поставить хоть что-нибудь
• понимать пользователя
• понимать рынок

И компетенции и дисциплины для каждого уровня - надо смотреть на схеме в презентации.

За 6 месяцев свежими остаются 60% требований, а за год свежесть сохраняют 20%. В длинных проектах можно многому научиться, но полезность созданного софта - очень сомнительна.

Дмитрий Безуглый Максим Цепков Спасибо за фиксацию экспромптов.

Максим Цепков Я еще не все успел записать! Там были очень крутые формулировки!

Максим Шаломович. Архитектура и ее аналитики: как с этим жить?

Пост FB Максим Шаломович (Max Shalomovich). Архитектура и ее аналитики: как с этим жить?

Что архитектору нужно от аналитиков? Требования! А какие? А архитектурные - наиболее важные, которые помогают принять архитектурные решения! И это определение пишут не только в заумных стандартах, но и в популярных книгах :)

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

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

Denis Beskov ограничения можно фиксировать в бизнес-терминах. Не PostgreSQL, а «промышленная СУБД, количество доступных резюме с упоминанием которой на момент сдачи системы в эксплуатации не менее 500»

Максим Цепков Можно. В докладе речь о том, что есть случаи, когда Заказчик фиксирует конкретную СУБД по своим соображениям - и тогда это надо писать в требованиях, а есть - когда ему без разницы, и тогда лучше вообще ничего не указывать. Потому что это уже дело архитекторов, а не аналитиков. И решение можно принять позднее. Требование в пописанной выше формулировке - вообще какая-то хрень на мой взгляд, то есть это просто завуалированное указание на конкретную СУБД, которую почему-то указывать нельзя. Наплевать заказчику на эти референсы, и для проекта это без разницы. Зато это не позволит или осложнит применение другой СУБД в одном из модулей системы, а это может быть полезно.

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

Denis Beskov кто мешает выделять подсистемы по фичам, а не по техническим уровням?

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

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

Denis Beskov Требования к перспективам развития— это абсурд, надеюсь, Максим описался

Максим Цепков Требования к перспективам развития, говорят, стандартные термин из ГОСТ, за которым скрываются требования к легкой модифицируемости по отдельным запросам - легкое добавление атрибутов, легкое добавление новых протоколов интеграции, не требующее реинжиниринга, легкое добавление новой бизнес-логики. А иногда - еще и легкое добавление новых, уже понятных способов работы, которые появятся точно через год-два-три, но пока их нет, например, работа с RFID-метками вместо сегодняшних штрих-кодов.

Denis Beskov Максим Цепков а ты можешь не гадать, а глянуть ГОСТ? минутное дело же. Перспективы развития — это ни к не чему не обязывающий раздел бла-бла-бла. А требования к модифицируемости — это отдельные требования.

Максим Шаломович Ориентировался на это. Все ТЗ, которые попадали мне в руки, даже самые детальные, обычно тоже содержали только один раздел, где были и требования к модифицируемости и "бла-бла". Возможно, это действительно не точно. Но, судя по короткому опросу зала, ТЗ по ГОСТ пишет не больше 5 человек, поэтому никто не пострадал)) В целом мой посыл был именно про модифицируемость, перспективы развития упомянул вскользь.

Максим Цепков Denis Beskov В ГОСТ 34.602-89 в разделе 2.6.1.1. В требованиях к структуре и функционированию системы приводят: ... 6) перспективы развития, модернизации системы. То есть термин - есть. Там нигде не написано, что это - "ничего не обязывающий раздел, бла-бла-бла", это - твое личное мнение. Зачем мне было смотреть в ГОСТ?

Denis Beskov Maxim Tsepkov чтобы увидеть, что перспективы развития не являются требованиями на самом деле

Максим Цепков Denis Beskov С моей точки зрения, перспективы развития являются требованиями, и достаточно важными. Расширяемость наборов атрибутов, быстрая адаптация под бизнес-процессы и многое другое. Если этого не учитывать, то реализуется жесткая система, не способная поддержать развитие бизнеса. Но поддержка этого по площади повсеместно (супер-конструктор, как 1С) при заказной разработке - супердорогая. Поэтому должны быть выделены точки и области. где перспективы развития надо поддерживать. При том, что сама траектория развития еще неизвестна. И ГОСТ это подтверждает.

Denis Beskov Maxim Tsepkov перспективы развития могут порождать требованиями к сопровождаемости/модифицируемости но сами по себе являются событиями в будущем с определенной вероятностью. Я продолжаю офигевать, как ты меня тут лечишь

Alexander Pavlyut Denis Beskov возможно Максим имеет ввиду что есть некая стойкая уверенность заказчика в том, что в конкретной текущей конструкции будет (должна быть) реализована поддержка конкретного модуля, которым он по своему личному ощущению и спасется от потопа который он предвидит - вымышленных (слабо сконструированных в своем сознании) ситуаций в будущем. Это мною пишется в ограничения, потому что человек хочет а время на споры идет. Я ставлю отметку "assesment" (оценочное суждение) за авторством этого персонажа и предупреждаю под его подпись об отвественности (в неуспешности такого архитектурного решения) за безосновательно внедрение в конструкцию. Перспективы развития, возможные ситуации, обозримые перспективы - называют по разному и пытаются "подстелить" соломку с ответственностью на архитектора/исполнителя. В такой ситуации обычно не дают модель возможной динамики с цифрами и подписью, поэтому я пишу это в ограничения и вопрос снимается.

Точки архитектурных функциональных требований.

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

Yuri Veretelnikov А зачем архитектор сидит и что-то ждет от аналитиков, интересно и непонятно..

Максим Цепков А потому что так бывает устроен процесс, что архитектора подключают позднее. А вообще доклад был сформулирован из позиции объяснения взаимных ожиданий в коммуникации, рассказать аналитикам, что важно архитекторам в том, что они делают, а что - не важно. А что наоборот, делать не надо, и почему. В целом материал практичен.

Баркемп с Ольга Самарина о смене mindset

Пост FB На #AnalystDays был интересный баркемп с Ольга Самарина (Olga Samarina) о смене mindset при переходе на другую позицию, в котором я участвовал как эксперт. В ходе обсуждения слушатели и сама Ольга делились своими историями и разбирали их. Получилось сформулировать рабочее определение mindset как набора мыслительных техник. И получить рабочий ответ на вопрос об изменении mindset. При смене позиции точно меняется фокус внимания. При этом в поле зрения могут появляться новые онтологические объекты, некоторые из которых могли быть известны теоретически, но не были включены в деятельность, а другие - могут просто отсутствовать. Для работы с этими объектами может быть достаточно имеющегося арсенала мыслительных техник, а могут потребоваться новые - тогда и происходит изменение mindset.

Иллюстрация была как раз на примере перехода Ольги о переходе с позиции бизнес-аналитика на позицию продукт-менеджера. Контекст работы и вопросы Зачем и Что делать - не меняются. Но ответ на эта вопросы начинает включать экономические аспекты деятельности - емкость рынков, трудоемкость реализации с разным качеством. И вовлечение этих экономических объектов в рабочую онтологию и работа с ними требует других мыслительных техник, обычно у бизнес-аналитика отсутствующих.

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

В комментариях к посту - интересное обсуждение как раз о том, не путается ли изменение mindset с простым изменением переходом в другую позицию.

Григорий Печенкин. Люди в разработке ПО: фактор или актор?

Пост FB Григорий Печенкин. Люди в разработке ПО: фактор или актор? Автоматизированная система по ГОСТ - это персонал + комплекс автоматизированных средств, обеспечивающая функцию... Персонал - рабы на галерах, а не люди :(

Модель Кано делит характеристики софта на

• Обязательные характеристики - без них использовать не будут
• Восхищающие характеристики - именно за ними выбор пользователей
• Желаемые характеристики. Есть - хорошо, нет - плохо
• Безразличные, пользователю наплевать.

И в автоматизированной системе в модели Кано мы делаем обязательные, и иногда - желающие. Потому что для рабов.

Этот концепт - ролей, а не людей - давит очень сильно, он прошит в литературе достаточно мощно.

Все-таки делайте софт для людей, а не автоматизированные системы для рабов. И этих людей надо представлять. Есть три метода:

• Use case - роли пользователей, диаграмма. Кто на какие кнопки нажимает.
• Классы пользователей - для user story. Поиск работы: соискатели, работодатели, администраторы. Типы соискателей: уволенные, вчерашние студенты, наблюдатели...
• Персонажи или персоны. Алан Купер. Для вида пользователя - этнографическое исследование, кластеры пользователей. Архетипы.

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

Довлеющая инженерная культура: общение через документацию, сложные инструменты, сложные нотации. Это - тяжело.

ТЗ - приложение к договору. Давать программистам - не гуманно.

Сделали диаграммы в Enterprise Architect, послали бизнес-заказчику, он говорит: нам нравится, пришлите нам исходники мы хотим поправить... Что посылать?

Yury Solonitsyn Какой-то однобокий взгляд? Почему "рабы"? Элемент системы, которые также важен, как все остальные. И для его эффективной работы стоит постараться. И да, это определение по ГОСТ, а не требование ГОСТа считать людей рабами :)

Максим Цепков Рабы, конечно, метафора. Но в целом мысль вот какая: софт делается для того, чтобы система работала эффективно. А не для того, чтобы приносить удовлетворение пользователям этой системы, потому что пользователи - лишь лишь элемент системы, а не самостоятельные субъекты - люди.

Такое противопоставление ориентации на пользователей против ориентации на системы в Enterprise-разработке. Оно - важное, его надо в мозгах держать. Что корпоративным приложением пользоваться заставят, а продуктом - нет. И это - такое неявное обременение в мозгу аналитика, который много лет работал в Enterprise, особенно "старом". Стреляет когда он переходит в продуктовую компанию. А сейчас уже начинает стрелять ив enterprise-мире, там, где голод по персоналу - люди оценивают софт, с которым придется работать, и учитывают это при выборе работы.

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 ничего не понял:(

Евгений Антонов Vlad Tsypin наоборот, всё ясно, как божий день. Обычный проектный хаос без аналитиков и нормальных коучей ))

Vlad Tsypin Евгений Антонов о нет. Коуч в данном случае что, лекарство от всех бед? Про хаос - ок.

Евгений Антонов Vlad Tsypin коуч (не люблю это слово) поможет осознать ненормальность тезисов, озвученных выше (типа в аджайле документации не предусмотрено)

Vlad Tsypin Евгений Антонов и как люди без коучей жили и живут?:) Если кто-то считает, что в аджайле документации не надо, тот ССЗБ и херак-в продакшн. Хипсторство жи есть:))

Евгений Антонов Vlad Tsypin нормально живут, примерно как описано выше. Им ок, а остальным непонятно, что у них происходит и где результат. Но это нормально отличается от другого нормального.

Евгений Антонов лечение больного должно начинаться с правильного диагноза и признания болезни у оного. вот тут и нужна помощь извне. Если больной не согласен, то... ну и пусть. эволюция, дарвинизм, все дела

Максим Цепков Фишка в том, что докладчик из компании, которая занимается аутсорсингом тестирования. Их зовут в конкретную ситуацию проекта, и на вопрос "а как нам тестировать без документации?" отвечают "вы - профессионалы, вы сможете, мы верим". И он рассказывал, что они делают.

Vlad Tsypin Вот. Ну и в одним и з первых пунктов анализа и аудита смотрю общаюсь с тестированием, т.к с позиции тестировщиков и с позиции разработчиков или бизнеса релизные и прочие модели могут радикально отличаться друг от друга

Alexei Vinogradov Многие беды начинались с ключевой фразы "аутсорсинг тестирования"

Максим Цепков Тем не менее, много компаний это заказывают - и много компаний эти услуги предоставляют. Потому что "эффективный менеджмент" говорит что это правильно Ха-ха :)

Пост FB Gojko Adzic From quality assurance to quality assistance. Шаг-1: Sell the problem, not the solution. Изобретательно: если 300 багов 1 приоритета, и все уверены, что именно такой приоритет - напечатайте их и повесьте на стену, это покажет ненормальность положения. Типичные проблемные места:

• ent-to-end delivery cycle speed - когда делим на кусочки, каждый кажется не большим.
• waiting time for tasks
• amount of rewowk
• satisfaction

Чеканная формулировка: люди не сопротивляются изменениям, люди сопротивляются, чтобы их изменяли.

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

Фокус на тестах с высоким риском, не по площади, как часто предлагают разработчики.

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

При тестировании - надо уметь выйти за рамки предписанной ситуации, придумать нетипичное поведение: пользователи ведь не идут по инструкции, они применяют софт творчески.

Дальше было большое количество техник разной сложности, с общим посылом "Пробуйте!"

• Парное тестирование с разработчиком, со сменой ролей driver-observer.
• Риск-шторминг группой.
• Используйте фичу самих до пользователей - eat your dog food.
• Spec by Example. Key example - основа для тестов, в том числе автоматических.
• Testing tour. Есть разные стратегии для организации тура, при этом метафора тура - мощно работает.

И по организации работ:

• Waste snake: пишите заметки, где вы были непродуктивны. И периодически список коллективно просматривайте.
• rotate testers across team.
• От google: тестеры клеят стикеры про тесты в туалете :) Люди там скучают - пусть думают про тесты :)

Такой обзорный доклад.

Пост FB Michael Pilaeten Shift Left - testing in the land of acronyms. Стоимость исправления возрастает по мере сдвига момента обнаружения дефекта на более поздние стадии. Это понятно. Но дальше идет пара не слишком понятных графиков. Первый - про водопад, с возрастанием ресурсов ближе к концу проекта, в том числе для исправления ошибок, которые выявляются позднее. И другой, парадоксальный, для Agile: ближе к концу проекта трудозатрат меньше, а вот ближе к началу - наоборот, больше, с сохранением общей площади (это отмечено в рассказе). Моя гипотеза - сомнения на начальных стадиях вызывают всплеск коммуникаций и обсуждений не соразмерный достигаемому эффекту. Но вообще - непонятно, что именно там меряли, надо будет посмотреть внимательно презентацию.

Code review - с ним оказывается дешевле, чем без него - потому что он позволяет обнаружить ошибки раньше. Ссылка на книгу Tom Gilb Software Inspection.

И еще цифры. 21% projects fails из-за требований. 57% дефектов заложено на стадии проектирования, до кодирования.

Yuri Veretelnikov Цифры впечатляют, только непонятна производная от приложенных к проектированию усилий (отрицательный прирост дефектов, отнесенный к кол-ву усилий по лучшему проектированию)

Прикольно! В числе методов ведения проектов - WaterScrum :) такое вот словообразование

Евгений Антонов waterscrumfall вообще-то и про него написано давно. и как оказалось многими (в т.ч. нами) это используется интуитивно. https://reqcenter.pro/water-scrum-fall/

Максим Цепков Да, я сейчас я вспомнил, что термин мне попадался, и даже документ я, вроде, проглядывал.

Сергей Добриднюк Я для себя в деньгах мерял. Как то рассказывал (см слайд - спринты 1 недельные). Характер расходов - "исправление" или "догоняние" не особо важен. Они есть в WF на финале, и значительные - не попадаем в срок, а доводка уже после срока - сжирает ожидаемую прибыль (в лучшем случае, в худшем - получаем убытки от проекта)

Максим Цепков График - супер!

Пост FB Bruno Manczak. Неожиданная мысль. Архитектура и организация кода существенно влияет на тестирование - инкапсуляция, изолированность разных частей программы влияют на организацию тестов и их объем. Вывод - они должны быть предметом пристального внимания тестировщиков. Предпосылка - известна и очевидна, но указанный вывод делают далеко не всегда, оставляя архитектуру на усмотрение разработчиков.

Алик Курдюков Идея отличная, но мне ни разу не удалось это продать самим тестировщикам

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

Пост FB Natalia Savastiuk. 15-минут для обучения команды любой теме. В тестировании много народа без технического образования, и это - проблема. Многие ее осознают, и у некоторых получается учиться, но таких мало. Она экспериментировала по-разному - внешние тренинги и конференции, еженедельные часовые доклады, но форматы - тяжелые, а знания часто остаются теоретическими. И она придумала легкий ежедневный формат, о которым рассказывала: 15 минут каждый день перед обедом время важно, утром - статусы, вечером - билды, которые ждали к обеду. А перед обедом - нормально. Три этапа: подготовка - проведение - закрепление знания. На подготовке - выбор темы. Кажется сложно, но присмотреться к процессам, ошибкам, жалобам, недостаткам экспертизы - темы появятся сами собой. А еще можно брать внешние темы - как быть оратором или конструировать шутки. Если тема большая - делим, был пример про клиент-серверное приложение, про postman или освоение iOS - они раскладываются на 15-минутные слоты, и это эффективно.

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

Еще - закрепление знания

• В конце обсуждение: что я запомнил или нового узнал, повторяться нельзя.
• Практическое задание в конце для тренировке, можно сделать отдельно и обсудить результата в отдельные 15 минут. Может быть даже серия обучений. И еще взаимная оценка решений участниками - чтобы люди разобрались со своими непонятками. За задания ставят оценки по 10-бальной школе, она долго не хотела вводить из-за коннотаций со школой, но оказалось, что при правильном объяснении хорошо работает.
• Просто попробовать научить других - для этого групповое выполнение заданий, с практическими вопросами про использование инструментов.

В целом - работает, инструмент - эффективный, по времени - не напрягает совсем.

Пост FB Marcin Sikorski (Польша) Этические аспекты общения с китайскими тестировщиками. Очень интересный доклад, и очень быстрый английский - поэтмоу конспекта на получится. Но я очень рекомендую посмотреть запись, даже если вы не работаете с китайцами для общего представления о культуре. Образ очень любопытный, а учитывая развитие мира - важно эту картинку представлять. Если кратко, то я во многом узнал идеальный образ, знакомый мне по советскому прошлому и воплощенный в книгах - гордость за страну и нацию, поддержка видения и планов будущего на 10-15 лет, которое есть у правительства. При этом - баланс между работой и личной жизнью. А еще образ современный, вписанный в цифровой мир с его коммуникациями и инновациями. И эта картина - не с плакатов, а из повседневного взаимодействия, хотя и поддержана плакатами в презентации, выполненными в советском стиле.

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

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

Пост FB Владимир Крючков. Интеллектуальное игровое моделирование в нагрузочном тестировании бизнес приложений. Идея - есть сценарии работы отдельных типов пользователей. Пользователь-бот имеет внутри себя модель состояний. По сути, логика поведения ботов программируется так же, как логика поведения персонажей, управляемых компьютерами в играх. И есть профили входной нагрузки, которые вбрасываются, обрабатываются ожидающими их ботами. При этом можно увидеть показатели нагрузки и сроки отклика системы в условиях реальной нагрузки. В целом - круто, но, к сожалению, доклад в стиле "у нас работает так", то что рассказано - примерно ясно из основной идеи, а вот каких-то деталей реализации, не раскрыто. Может быть их и не было, и в создание такой нагрузки - простая задача, которую "берешь и делаешь". Однако, судя по тому, что нагрузочное тестирование нужно многим, а такой способ не является общераспространенным, проблемные моменты при реализации наверняка были. И как раз было бы интересно получить ответ на вопрос: если подход нас вдохновил, как его реализовать?

P.S. технологии: приложение на 1C ERP, для тестирования 1С Enterprise + Selenium

В ответах на вопросы сказал, что решение выложено в open source на github и призвал интересующих присоединяться к проекту.

Пост FB Галина Вострикова (Galina Vostrikova). Мы хотим формировать не просто команду, а dream team. И надо сохранить команду в этом состоянии. А для этого мотивировать надо не только членов команды, но и самого лида - что сложнее, а риски демотивации больше.

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

Она начала ловить следующие моменты, которые ее мотивируют.

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

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

И в ответах на вопросы: здесь работает тот же принцип "shift left" - чем раньше увидишь симптомы раннего выгорания, тем легче его устранить и предупредить.

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

Александр Шен Т.е. человек, - это такой своеобразный робот, программируемый посредством мотивации?

Максим Цепков Нет, конечно. В докладе этого точно не было.

Александр Шен Так речь не о докладе, а о подходе к мотивации.

Максим Цепков О подходе - чьем? Есть школы психологов и менеджеров, в которых это так (человек - робот, программируемый мотивацией), есть школы, которые против этого возражают. Если вопрос про мое мнение, то человек - не робот. А мотивация - не программа. Так что ответ тоже - нет.

Александр Шен В смысле, "в чьем подходе"? В подходе, изложенном в содержании поста. Раньше у "менеджера" в руках был стимул - палка, которой лупили рабов. Теперь ее роль смещается к "мотивированию", т.е. когда кто-то наверху пытается управлять твоим желанием работать и изобретает для этого разные фишечки. Прогресс налицо, но это все еще одна из форм рабства.

Максим Цепков Александр Шен Нет, это неверное понимание поста. Спровоцированное телеграфностью моего изложения, где контекст IT-отрасли не проявляется. В IT идея подгонять сотрудников палкой признана не работающей уже лет 15 назад, а то, что "механически" мотивировать человека снаружи нельзя - тоже в IT очевидно.

Теперь подробнее о контексте и реальном содержании доклада.

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

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

Александр Шен Maxim Tsepkov, забавно видеть, как менеджмент переиначивает психологические понятия, но мотивация - это что угодно, только не "мера энергии". В действительности, мотивация представляет собой производную от смысла, задающую направленность активности человека. Человек так устроен, что ему сложно выполнять бессмысленные для него действия, но именно такую ситуацию "продвинутые" менеджеры новой школы рассматривают в качестве "болезни", ставя над ним надсмотрщика, чтобы "не болел". По сути, это все та же палка для рабов, только куда более изощренная.

Максим Цепков Александр Шен Разные дисциплины используют одни и те же термины по-разному. Так что не "менеджеры переиначивают психологические понятия", а менеджеры определяют термин мотивация иначе, чем психологи. И дальше психологи могут либо освоить эти определения и понимать менеджеров, или их НЕ понимать.

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

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

Пост FB В докладе Johan Steyn про тестирование программ, которые работают с использованием искусственного интеллекта, был ролик - маленькая девочка играет в лего, беседуя с искусственным интеллектом. И это вызывает размышление на тему - насколько изменится мышление людей, если дети массово будут разговаривать в раннем возрасте не с родителями, а с субъектами искусственного интеллекта. Потому что, есть подозрение, что такие субъекты могут быть куда менее разнообразные, чем родители. Или более? При этом известно, что базовое мышление в значительной мере закладывается именно в раннем возрасте, это заложено в генетические программы развития.

Я отмечу, что по некоторым наблюдениям у поколений, воспитанных на компьютерных играх с закрытым сценарием вместо игр во дворе со сверстниками произошла определенная атрофия способности самостоятельно придумывать сюжеты и варианты. С этим сталкиваются, в частности, ведущие нарративных игр, можно посмотреть посты https://dreamer-m.livejournal.com/467651.html и https://dreamer-m.livejournal.com/468092.html (продолжение).

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

А вы что думаете?

Игорь Беспальчук Более разнообразные, однозначно. Меньше будет шаблонов на детях надето.

Максим Цепков А почему более разнообразные? Сейчас каждый родитель накладывает свои стереотипы, которые еще комбинируются от разных родителей и разных культур, с учетом еще нянь и воспитателей - вспомним Арину Родионовну у Пушкина. А будет 10-20 тиражированных субъектов искусственного интеллекта, ориентированных на разговор с детьми. Или вообще 1-2. На весь мир.

Игорь Беспальчук Максим Цепков Потому что создание разнохарактерных персонажей или персонажей с разными ценностями станет управляемым процессом. Почему сейчас существует не 2-3 книги на весь мир и не 2-3 фильма на весь мир? При том, что базовых сюжетов - мало, как мы знаем. Уже сегодня во многом человека воспитывает литература и кино. А будут - еще и разнообразные ИИ-собеседники, которых ты подбираешь и советуешь другу.

Владислав Орликов У меня такое ощущение, что сейчас на этот вопрос можно ответить только так "А хрен его знает!". Недостаточно данных, чтобы строить модели развития.

Максим Цепков А их всегда недостаточно. Значит надо просто мерить. Хотя бы по своим детям и внукам в будущем :)

Пост 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 "Повторное тестирование" - в некотором смысле оксюморон. Как повторное программирование, например.

Максим Цепков Тут имелась ввиду ситуация, когда после разработки и тестирования в сделанный функционал вносятся изменения и требуется повторное тестирование. Обычно неявно считается, что объем тестирования пропорционален объему разработки, поэтому если доработка дает 5-10% к начальной разработке, то и тестирование займет пропорционально. А для изменений это часто не так, небольшие изменения на базовом уровне могут потребовать практически полного повторения тестов.

Рина Ужевко Максим верно заметил. Нельзя нормально и уж тем более эффективно оценить стоимость если у тебя не было аналогичного опыта ранее. Но тут опять же, есть грабли в виде проекции одного опыта на другой и это может вылезти с др стороны.