#sqadays Нэлля Сердюк и Алексей Алешин из Ростелеком ИТ. Продукт, который можно "пить". Название - из метафоры очистки воды. А проект - про тестирование порталов видеонаблюдения за ЕГЭ и выборами. Но в рассказе специфики проекта не было, был рассказ про реорганизацию процесса и используемые практики. И я из их числа хочу отметить не очевидную реорганизацию: они откладывают описание тест-кейса до стабилизации задачи, а до этого работают по чек-листам. Это дает относительную легкость изменений и убирает фактор сроков - тест-кейс можно описать и после выкатки срочного функционала в прод, в режиме устранения тех.долга. При тестировании новой фичи чек-листа хватает, так как тестировщики в контексте: команда знакомится с задачей на груминге, и ее помнят, а вот при регрессе проверяют сделанное давно, и важно хорошее описание, чтобы регресс мог провести любой из тестировщиков. Это описание собирают на основе чек-листов и финальных комментариев тестировщика по каждому тестированию, которые тоже является обязательным для каждого такта тестирования и должен описывать - что было проверено с техникой. Груминг для знакомства с задачей был новой практикой, казалось бы. он дает накладные расходы, но реально он сокращает количество возвратов задач, когда ТЗ поняли неверно и делали не то. Я тут хочу заметить, что ненадежность передачи через артефакты из-за того, что тексты трактуют по-разному была осознана уже больше 20 лет назад, это - одна из предпосылок agile-методов, но те, кто создают процессы почему-то по-прежнему верят текстовым описаниям, практики коммуникации типа груминга появляются позднее и далеко не везде...

#sqadays Алексей Петров, Одноклассники. Индивидуальные планы развития на базе матрицы компетенций. Цели индивидуального развития: рост знаний и компетенций, карьерный рост, рост финансового вознаграждения, увеличение вариативности развития. Но! куда расти?
Два пути: автоматизация тестирования и управление командой, еще в разработчика и смежные дисциплины. Это ограничивает. А реально путей больше: нагрузочное, мобильное, платформы, предметка (финтех или страховые) - вариаций много.

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

В матрице ставим самооценку 0-3: 0 - ничего не слышал, 1 - что-то слышал, 2 - пользуюсь иногда с помощью других, 3 - пользуюсь регулярно. Это - самооценка, она не связана с зарплатой, обманываешь ты самого себя.

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

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

Дальше был проект прокачки с конкретным примером. Формат:
* прокачиваемые компетенции,
* описание проекта,
* пользовательские сценарии,
* бизнес-ценность
* точки поэтапного контроля (вехи)
* DoD
* артефакт
* в какую цель бьет
Важно, чтобы сотрудник сам заполнял, в частности описывал бизнес-ценность, а не получал готовое от руководителя. Точки контроля и артефакты позволяют сотруднику вести самоконтроль.

В примере были цели - тест-дизайн, TMS, продуктовую компоненту, и проект включал разработку тест-кейсов для этой компоненты с использованием TMS. Реализуя проект мы приносим ценность для бизнеса - получаем больше тест-кейсов, и развиваем сотрудника.

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

Дальше plan-do-check-act - цикл Деминга. Если на промежуточных точках выясняется, что вы ничего не сделали - задайте вопрос, почему не пошли. 5 почему - может выбрали не то, может - другие причины, может стало не актуально. Корректируйте действия, при необходимости - меняйте план. Ситуация на проекте меняется, вы тоже узнаете о себе новое.

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

Объединяем матрицы и ИПР всех сотрудников - и видим компетенции команды в целом, взаимозаменяемость, узкие места и так далее.

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

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

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

Вопрос: надо ли вбирать свобождно, или ограничить меню потребностями компании. Ответ: всегда двунаправленное движение, нужно дать поле выбора. Но для джунов, стажеров есть смысл подсказать.

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

#sqadays Вадим Лунин и Вадим Зубович, Альфа-Банк (Беларусь). ИИ в тестировании: помощник, или угроза. ИИ уверенно переходит из фазы "посмотрим, что он может" в фазу "сделаем помощника и будем использовать". На Merge я неделю назад Газпромнефть рассказывал, как собрал ИИ-помощника для работы с вакансиями и подбор персонала, закрывающего полный цикл. А тут был рассказ об использовании ИИ для тестирования.

Для начала - история. ИИ начал входить в тестирование для частных задач.
* Автомат результата автотестов - Report portal - анализировал причины падений
* Self healing automation - чтобы тестовые скрипты проходили. Helenium и еще несколько
* Автоматические анализаторы performance. Yslow, PageSpeed - рекомендации по ускорению
* Обнаружение визуальной регрессии - наложение текста и картинок.
Каждый из инструментов - узкий и изолированный, он не встраивается. Подход - от инструмента. Приходит идея - и делаем нейросеть.

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

Но появились большие языковые модели - универсальные инструменты. И тут получается история, аналогичная тому, что было 7 лет назад: был комплексный TestComplete для корпоратов за большие деньги, появился Selenium и сообщество быстро сделало инструменты. Так будет и здесь.

По направлениям - есть еще IDE-ассистенты - автокомплит на стероидах, работает неплохо. Тут он бы выделил Tabnine: начинаешь писать название метода - он выдает реализацию. И работает без VPN.

У банка ограничения - надо уметь развернуть локально. Они выбрали Llama, Mistral, Zephir. И еще Вихрь - русифицированный Mistral.

Направления
* генерация тестовой документации
* ревью кода автотестов (и вообще всех кодов)
* фазз-тестирование

Идея - порождать тесткейсы по спекам. Для начала ui-тест, по flow для мобилки. Ни одна из моделей результата не дала. Порождали обобщенные сценарии, не понимали язык. Но появилась saiga - русифицированная Llama-3, ей скормили спеку, где картинки описали текстом - и получили приемлемый результат. Еще UI запилили, куда кидаем спеку, из нее промпт идет

Бэкэнд-тесты - они проще UI, картинок нет.
* Llame-2 что-то сгенерировала, но по-английски, и там не тестовый сценарий, а какой-то ответ. И не учтен весь пользовательский путь.
* Zephir - получилось получше, похоже на описание шагов, по английски. И дописал сценарии, которые в спеке нет
* Mistral - лучше всех, по-русски, опознал полный путь. Но с промптами пришлось поиграться серьезно.
* Развернули Вихрь - тоже хорошо.

Планы: проработать спеки для UI, и еще чтобы alure, API - проработать интеграцию с инструментами типа swagger

Код-ревью. Просто попробовали отдать поруцию кода и pull request. Появился проект Alt-man review. дает pull request, пишет ответ комментарием в git. Но не взлетело - галлюцинации, неверный язык программирования

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

Фаззинг - шумовые данные, бомбардировка приложения чтобы найти утечки данных и крэши. Вышел OSS-fuzz от google - заточен на это, по задумке он сам все сделает. По факту - сам не может, тесты надо написать самим. oss-fuzz-gen - сморит коды и порождает, только для с++ - поэтмоу они пока не копали. И им им еще надо развернуть свой кластер, и обучить работать с их моделями GPT, а не с google. Это - в планах.

По горячим следам публикую отчет с #sqadays https://mtsepkov.org/SQAdays-2024a Кроме постов, которые я публиковал в ходе конференции, там пара докладов, которые были в конце и общие впечатления с конференции. Наиболее интересное для меня связано с использованием ИИ, которое перекликается с услышанным на MergeConf неделю назад: пока теоретики спорят, о том, что он может, а что не может, практики - используют.

В Питере возобновился IT Global Meetup. Для тех, кто не знает - это замечательное мероприятие, объединяющее IT-шников и организует его сообщество сообществ Piter-United.ru Один день, 15 сообществ, 50+ спикеров, 1000+ участников. Я был на нем в субботу и публикую отчет https://mtsepkov.org/ITGM-16_2024-05 Все выступления, на которых я был - интересные и очень разные. И много знакомых. Я унес с митапа интересный формат интерактива с залом, который был у Юрия Санникова и метод волшебных друидов для работы с ограничениями в TOC. А обсуждения нужны ли HR и нужны ли менеджеры дали фокусировку собственного понимания темы.

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

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

Племена. Атрибуты племенного поведения.
* У племени есть общий враг - не надо им становиться
* Члены племени наделены внутренним сходством
* У племени свои ритуалы и обряды - объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить. но аккуратно
* Племя понимает источник успеха, не дает шатать
* Племени есть свой язык.

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

Концепция V'ger - это из первого фильма star track. В любой компании есть история, связанная с технологией или чем-то ядерным - и нельзя нарушать. Microsoft - Basic, он во всех продуктах. Для компании - доменного регистратора все строится вокруг домена, хостинг и другие услуги пришли как развитие. И сейчас у них проблема с продуктами в телеграм, которые строятся без домена - как так, vger отсутствует. Узнайте, что является vger компании или команды, с которой взаимодействуете. Следующий шаг - понять дает ли это ограничение, или объединяет и что с этим делать.

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

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

Социальная сплоченность: в племени думаем одинаково. Спектр от хаоса до тоталитарной секты. Социальные инновации: способность группы выдать идею. Может ли сплоченная группа выдать идею? Хуже. Команду сначала сплачивают, а потом говорят - придумывайте. Они не могут. Со сплоченностью надо остановиться как только поняли общую цель, не идти до полного единомыслия. А если вы сотрудник, то оценив сплоченность вы можете понять, как предлагать инициативу. В одних командах - можно принести самому публично, в других - привлекать сторонников по-одному, в третьих - через руководителя. А когда принесли - можно практику сделать vger чтобы она сохранилась.

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

Ритуалы. Как искать общее в новой команде? Первое - отношения с каждым. Выявляем соуиальные группы - ВУЗ, хобби, проживание. Дальше - разматываем, создаем личный контакт. Когда с каждым личный выстроен - объединяем. Если общее. И против проблемы. И сам: можем побороться - поддержите. С удаленщиками искать общее на порядок сложнее. Возможно, игры, стриминг, телеграм-чатики.

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

Как узнать компанию? Познакомьтесь на конференции, пообщайтесь, посмотрите доклады - там язык проявляется. Подпишись если блоги.

Я в заключении хочу отметить, что методы корпоративной антропологии. с одной стороны, дают рабочую модель, но, с другой - искажают восприятие. В основе лежит убеждение, что человек живет в придуманной парадигме первобытного племени, живущего в PVP с другими племенами, с этим смириться и хитрыми приемами направить эту глубинную психологию в конструктив, например, превратив PVP в PVE. Штука в том, что это - в основе - та модель псевдопервобытного племени, которую придумали, когда обосновывали колониальной экспансии белых людей. Сейчас в антропологии идет отдельная история, когда исследователи сопоставляют эти модели с реальной практикой, но это - сложно. потому что племен не так много сохранилось, а при исследованиях всегда идет интерференция понятий. Опасностей для практике несколько: мы приписываем всем людям то, что свойственно лишь части; мы видим в реальности то, чего в ней нет, потому что наша призма восприятия так настроена. Это касается всех социальных моделей.

Слайды моего доклада - на моем сайте https://mtsepkov.org/SysThink-AD24

#AnalystDays Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика. За докладом стоит интересный кейс: система доставки продуктов банка. Исторически была собственная доставка и система вендора, которая ей управляла, потом начали использовать курьерские компании и сделали маршрутизатор. который запросы направлял в собственную систему или универсальный гейт для внешних компаний, при этом вендорская система собственной доставки - в процессе разработки собственной для замены. Каждой системой занималась отдельная команда в реактивном режиме, и внутри - все разнообразно. В этой ситуации бизнес решил объединить все команды в одну, в ответственность которой передать всю ИТ-поддержку доставки. И для начала команде надо было разобратсья в том зоопарке, в который им достался. Для этого она пошла в обучение solution architect, и использовала эти методы для проекта.

Цепочка методов интересная.
* Canvas Остервальдера для бизнеса (доставки)
* Goal view из Archimate для интересов стейкхолдеров
* Концептуальная диаграмма бизнес-объектов
* Event storming для понимания операционной работы бизнеса

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

#AnalystDays Ekaterina Goncharova. Что такое Custom GPTs и как их готовить. На мой взгляд, самое интересное в докладе - ситуация: Екатерина из аналитиков стала продуктом, времени на аналитические задачи стало меньше, но вместо передачи их аналитикам она выделила рутинную часть, которую передала ChatGPT. B это в целом получилось. И это как раз те изменения, которые происходят, включение GPT в виде помощников вместо людей. А в целом в докладе была техника - как добавить к GPT дополнительную информацию, которую он учитывает в ответах. Это есть в платной версии, раздел ExporeGPT. Что туда стоит класть?
* Шаблон результатов ответа, с объяснением для каких сиутаций их применять, в разных файлах.
* Инструкции - то, что добавляешь в промпе, это процедура: описал бизнес - подумай про user story и далее.
* Информация о проекте или продукте
* Информация о предметной области. Включая книги, словари и так далее

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

Децентрализация
* Несколько аналитиков на проекте
* Взаимное ревью аналитиками
* Делегирование
* Новые практики

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

Естественный отбор - выживание приспособленного
* тимлид: матрицы компетенций, соревнование (быстрее согласовать задачу)
* аналитик: защита интересов (если хочешь поменять задачу), инициативность

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

#AnalystDays Ольга Павлова. Конфликты в команде между БА и разработкой: как реализовать проект и не подраться. В докладе интересная форма: Ольга проводила опрос коллег, аналитиков и разработчиков, о причинах конфликтов и о способах их решения, и в докладе была кластеризация ответов. Поэтому он дает относительно репрезентативный срез мышления сотрудников, и проблем этого мышления. Дело в том, что основной претензией (около 50%) и для разработчиков и для аналитиков были проблемы с компетентностью другой стороны. А вот собственные ошибки аналитики относили за счет объективных обстоятельств: задача прилетела вчера, сделать надо срочно и так далее. И это - проявление основной ошибки атрибуции в части оценки негатива: ты приписываешь свои проблемы объективным обстоятельствам, а у других видишь причины в их негативных личных свойствах, в данном случае - некомпетентности. Логично было бы учесть эту проблему, когда обсуждали ситуацию и ее решения. Но в докладе этого не было. Хотя один из методов - позвать разработчика поиграть роль аналитика на встрече с заказчиком или хотя бы присутствовать на демо - как раз это решает. А вот все остальное, про поговорить и понять - он не совсем про это. Хотя, конечно, рациональный разговор без эмоций способствует тому, чтобы этой ошибки избежать. И отношение к конфликту как к точке роста, который происходит, когда ты ищешь конструктивное решение - тоже правильно.

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

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

#AnalystDays Елена Михайлова. BPM vs API: перестать писать код и начать его рисовать. Интересный доклад о том, как вместо алгоритмической реализации в коде, например, для расчета цены, делают реализацию в виде bmpn-схемы вызова методов, который обеспечивает нужную логику. Представление алгоритма получается наглядным и гибким, и в этом - профит.

#AnalystDays Роман Васильев, Яндекс Лавка. Data-Driven Retail: синергия бизнеса и Data Science для оптимизации процессов. Интересный доклад, в фокусе которого форма сотрудничества data-аналитиков с бизнесом. У яндекс-лавки - задача управления ассортиментом и его хранением в дарк-сторе, откуда идет доставка продуктов, и которые имеют ограниченный объем хранения. И надо учитывать специфику спроса в районах, например, в центр и спальных районы спрос различается. Он пришел два года назад, с опытом аналитики в других компаниях - Мегафон, Магнит. И сделал ошибку в позиции: мы - аналитики, мы умеем считать и все сейчас посчитаем. Выяснилось, что параметров - много, критерии оцифрованы далеко не все, а главная проблема - результат не получается объяснить :"система посчитала". И у бизнеса теряется представление об управляемости.

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

Как делать?
* Понять оргструтуру заказчика и процесс принятия решений
* Понять процессы, которые существуют
* Выделить ключевые боли бизнеса
* Совместно определить направления
* Начать внедрять аналитические продукты.

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

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

#AnalystDays Михаил Лоренц из Инфосистемы Джет. ИТ-стратегия – фундамент устойчивого развития современного бизнеса. Как известно, в условиях неопределенности и изменений ситуации оказывается востребованной разработка стратегии, она представляется волшебной палочкой, которая решит проблему: что делать и куда идти. В докладе был рассказ о том, как принято это делать. Необходимое предусловие - понятная стратегия бизнеса, потому как стратегия ИТ должна на нее опираться. Дальше делаем картину As Is, которая особенно полезна, если в руководстве ИТ поменялись люди и им надо понять, в какой ситуации они оказались. Потом - стратегическая сессию, на которой фиксируем сценарии и развилки. А дальше создаем стратегию из четырех разделов: (1) зрелость ИТ-процессов, которую мы будем повышать; (2) операционная модель, описывающая кадры и их оплату; (3) развитие инфраструктуры - hardware; (4) портфель проектов развития с диаграммой Ганта взаимных зависимостей. Если же стратегии бизнеса нет, то вместо стратегии ИТ предлагается делать план унификации и повышения надежности и доступности.

Я тут зафиксирую ряд важных моментов, которые опущены в докладе. Во-первых, откуда берется, идея целевых преобразований? Ее нельзя вывести из As Is и проблем. Часто она уже есть у заказчика, и он заказывает стратегию, чтобы ее обосновать. Это отчасти было в примерах: на стратегической сессии обсуждали варианты ЦОД, но идея, что ЦОД необходим была постулирована. Во-вторых, по докладу есть впечатление, будто существует единственный способ создавать стратегию. Это не так, Минцберг в Стратегическом сафари выделяет 10 разных школ стратегирования, описанный процесс - это школа планирования. У бизнеса стратегия может быть разработана в рамках других школ, например, школы позиционирования, и не факт, что она будет сочетаться со стратегией школы планирования для ИТ. А если посмотреть на список Минцберга, о интересным может быть школа обучения - построение стратегии как развивающийся процесс:инкрементальные шаги, инициативы, ретро по результатам; школа внешней среды – построение стратегии как реактивный процесс и
школа конфигурации – построение стратегии процесс трансформации. Кому интересно, полный список был в моем докладе на Подлодке https://mtsepkov.org/StratPodlodka и можно читать первоисточник - Минцберга. Ну и, в-третьих, насколько полезна стратегия, разработанная внешними консультантами - не слишком понятная штука. Кроме, конечно, ситуации, когда заказчик просто хочет получить обоснование для своих идей в корпоративной среде и разработка стратегии - инструмент получения этого обоснования.

#AnalystDays Ксения Мельник из NAUMEN. Роль аналитика в маркетинге B2B-продукта: оптимизация стратегий продвижения и привлечения клиентов. Ксения работает во внутреннем стартапе, разрабатывает систему управления проектами. И это - продукт, который для компании является новым, и ориентирован на другую аудиторию потребителей, чем другие продукты. Поэтому ему необходимо отдельное продвижение, и маркетингом продукта занимается не отдел маркетинга, а сотрудники команды стартапа. Это логично: у компании много продуктов, и отдел маркетинга работает с имиджем компании в целом, и продвигает продукты пакетом, а тут аудитория и продукт сильно отличаются. А продвижение продукта - необходимо. Есть мнение у инженеров, что совершенный продукт сам себя продвинет, но оно - ложное. Каким бы ни был совершенный продукт, если он никому не известен, то его никто и не купит.

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

1) Аналитика воронки - кто обращается а запросом на демонстрацию, чем обоснована потребность, как они решают проблему сейчас, какие причины отказов называют, что отличает компании, которые купили - надо организовать текущую информацию, чтобы были основания для анализа. Аналитика по отраслям - почему такие, и аналитика поражений - можно ли было избежать. Выявили топ-3 отрасли, и попробовали найти выходы на компании этих отраслей. И проанализировали причины поражений
2) Уточнение профиля клиента. По результатам первого этапа. Фреймворк HADI: гипотеза, действия, данные, выводы. Кто: отрасль, специфика деятельности, проблема, текущее решение, ЛПР. Результат - ценность для каждого профиля клиента и план по взаимодействию.
3) Карта сервиса. CJM наоборот, мы анализируем взаимодействие клиента с компанией и смотрим, где происходят провалы. И как можно устранить. Или материалы или доработка продукта. Результат - прозрачный и понятный процесс для вас и коллег.
4) Подготовка материалов. SEO-статьи - оптимизация поиска, обновление лендинга - утонение ценности (и это не просто), обновление sales tool kit для команды продаж - скрипты, референсы - увеличение конверсии; структурное ведение базы знаний - регулярно сохранять информацию для аналитики поиске паттернов
5) Работа со смежными командами. Не только рассказать, но и налаживать сотрудничество, регулярные встречи с разбором текущих активностей, и ежемесячный анализ воронки продаж - то доработать, и квартальный анализ показателей

#AnalystDays Андрей Москаленко. Применение аналитиком генеративных нейронных сетей в реверс-инжиниринге. Я ожидал от доклада гораздо большего, конкретики по применению GPT либо в виде сложных задач, либо в виде рассказа про фактуру применения. А в нем сначала был рассказ со схемами про нейронные сети вообще стиле популярной книги для детей с красочными иллюстрациями, потом про известное использование GPT для перевода текстов, переноса таблиц ии спецификаций на yaml в markdown, и резюме по интересующим станадртам, например, по медицинскому оборудованию. При чем без подробностей, просто что "он это может". При чем не только переложить конкретную таблицу из Excel в маркдаун, но и написать скрипт на питоне, который это делает - решить задачу в общем виде. И дальше было про нетривиальную задачу - по плоскому списку конфигурации оборудования выделить типы этого оборудования. Но там тоже было без деталей: выдвигал гипотезы, GPT писал по гипотезам скрипты, я их применял и проверял гипотезы, получилось. Андрей - молодец, решил задачу. Правда, я не очень понял, зачем так там GPT. На мой взгляд, эта задача решается через то, что грузишь список в Excel и там вертишь, там всего 19к строк? и за день это делается, а с GPT потребовало 40 часов. Может, я недооцениваю - но тогда было интересно увидеть это в докладе...

#AnalystDays Артем Волчков. Применение модели Захмана для анализа корпоративной БА и жизненного цикла ИС при импортозамещении ПО. Мне было интересно посмотреть, как применяют модель Захмана для реальных задач импортозамещения, какие это профиты это дает, кроме ссылки на то, что работаем не абы как, а по науке, обоснованными методами, в чем получается практический профит. К сожалению, это не получилось, доклад в формате: вот модель, мы ее применили к такому крутому проекту и к такому, и у нас получилось их успешно сделать. Механика конкретного применения и роль модели раскрыты, увы, не были. Жаль.

#AnalystDays Юлия Дробина из Nexign. Витрина API для Solution driven подхода в разработке. У них API кастомизируется в конкретных проектах под заказчика, при этом у разных заказчиков установлены разные версии компонентов, не всегда последние. API описывали в confluence, и разобраться в этом множестве версий у разных заказчиков, найти нужное - было сложно. Поэтому была идея перевести описание API в формат, сохраняемый в git, чтобы версионирование было встроено в хранение и связано с хранением кода и его версиями. Они обозначили проблему руководству, получили поддержку. И год делали пилот с Swagger Hub, и вроде успешно по функционалу. Но потом посчитали пользователей, которые читают API, их оказалось много, 400+, и стоимость лицензий получается очень высокой. И решили делать свой продукт, пилот показал ту функциональность, которая нужна им. В оаснове спецификация OAS 3.0. Сделали. Выстроен процесс: системные аналитики пишут api в it, и разработчики там же проверяют - им нравится работать в git. Дальше ревью техписов для нормальной доки по-русски, генерация идет автоматом. А тестеры - порождают тесты. И на это переведены все проекты. Перевод занял год, так как объем описаний confluence был достаточно большим, и надо было не просто научить аналитикам новому, а еще побудить их практически поработать руками над переводом, да еще в условиях текущей загрузки по проектам. Но справились, где-то административно, а где-то - проводя беседы, что "у вас все получится".