Успешный продукт. Ладно. Поэтому я здесь и буду рассказывать про этот процесс, как он происходит естественно, и в целом. 28 лет я начинал как разработчик, 8 лет был разработчиком, постепенно развивался, затем перешел в менеджмент проектов, управление разработкой. Последние 3-4 года работал в роли Agile Coach. Сейчас, как написано на слайде, я занимаюсь тем, что готовлю различные практики и внедряю их. Я работаю сейчас в группе компаний ДИТ. Мы готовим практики Agile, DevOps и выбор процессов.

Я работаю в группе компаний ДИТ. Это большая группа компаний, больше тысячи человек, и там очень много разных компаний и подразделений. Я буду говорить сегодня про две из них. Первое - ДИТ Технологии, я сам в ней работаю. Думаю, что вы сталкивались с продуктами, которые она делает, например, ГЛОНАСС - самая основная система. Скорее всего, вы так или иначе сталкивались с ней. Если у вас есть машина, то вы опосредованно знакомы с тем, где оформляете все полисы ОСАГО, КАСКО - это тоже наш заказчик. Также закупки и логистика - это больше про большие инфраструктурные системы.

ДИТ Артезио - это другая компания. Если в ДИТ Технологии больше 1000 человек, то в Артезио больше 400 человек. Это немного другая сфера деятельности - разработка, консалтинг и аутсорсинг. Отрасли сильно более распределены по разным направлениям, разработка и технологии нужны везде. У коллег есть ссылки на карточки сайтов Артезио и ДИТ Технологии, презентация останется, потом можете посмотреть.

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

Ну хорошо, еще один вопрос. Что такое value stream? Поток создания ценности. Есть такое понятие, все поняли. Ну и user story - что это? Отлично, все понял, спасибо большое.

Ну хорошо, еще один вопрос. Что такое value stream? Поток создания ценности. Есть такое понятие, все поняли. Ну и user story - что это? Отлично, все понял, спасибо большое.

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

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

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

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

Кроме разработки, есть и продуктовые метрики, их тоже много. Вопрос: с этой частью, которая отвечает за анализ, если на предыдущем слайде мы потратили примерно 40% времени. Хорошо, если вы можете предложить метрики здесь, то что можно измерить в процессе не разработки, а подготовки к разработке? Я подскажу.

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

То есть некоторые проблемы... Давайте посмотрим проблемы, или их нет у вас? Может быть, у вас нет проблем, я просто придумал. Например, вот у нас есть разработки слева. Если вы знакомы с Kanban, то это, в принципе, типичная картинка.

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

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

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

Еще вариант – мы делаем, и вроде хорошие у нас аналитики, разработчики молодцы, но почему-то у пользователя какие-то вопросы возникают. То есть мы сделали даже хорошо и быстро, но что-то не то. Попадаю куда-нибудь, да?

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

То же самое с ChatGPT: если вы знаете 3.5 и 4 версии, то знаете, что между ними большая разница, потому что они сильно отличаются по размеру. Но ChatGPT тоже не ограничивается, потому что есть еще много чего. Это не все, но основное.

Давайте посмотрим, как можно использовать чат для работы с продуктами и аналитиками - часть, которую делали коллеги из рабочей группы по этой проблематике. Допустим, у нас есть заказчик, с которым вы как-то общаетесь, и каким-то образом оттуда требования фиксируете для себя, пишете постановки, используете Google Docs, что угодно. Что сделали коллеги: они взяли и записали разговор, просто в диктофоне, что-то, что они спрашивают, беседу. Дальше прогоняют через одну из моделей, называется Whisper, в чате GPT тоже открывают.

Дальше прогоняют через одну из моделей, называется Whisper, в ChatGPT тоже открывают OpenAI, чтобы превратить в текст. Логика в следующем: чтобы потом из текста создать, есть такая техника, создать векторную базу, сгенерировать как бы цифрового аватара нашего пользователя или заказчика.

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

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

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

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

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

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

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

Вот такие были примерно отзывы. Позволяет более детально проявлять требования к задаче. Обычно все гораздо короче, а тут получилось более детально. Можно было написать действия пользователя более корректно. Явно позволяет ускорять работу с нуля. Есть новая система, продукт или сервис - с нуля можно очень быстро все сгенерировать, сильно ускоряется.

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

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

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

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

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

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

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

Более того, нам было бы неплохо, чтобы не сразу все истории генерировались, а потом по ним - сценарии и критерии приемки. А если мы получили, допустим, 20 историй, из них 10 поправили, а 10 выкинули, то по тем, что поправили, хотелось бы быстро перегенерировать остальное, а не по всему сразу. Ведь мы получили наполовину "чушь" и должны где-то в середине снова что-то подправить в промптах и все перегенерировать. А что будет в середине? Твой разберет, непонятно.

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

Хочу отметить, что подход, возможно привычный - есть законченное ТЗ, из него делаем постановки, пишем спецификации - с использованием языковых моделей просто не работает. Это лишнее мучение. Так работает: у нас есть сырые требования, мы каким-то образом их достали, общались с заказчиками, узнали, чего они хотят на самом деле. Дальше - какая-то магия, много шагов, но магия - мы получили на выходе user story со всеми кейсами тестирования. И уже из этого собрали спецификации, а из спецификаций - ТЗ. То есть совсем наоборот: не из ТЗ идем к юзерсториям через спецификации, а из сырых требований, ожиданий, интервью формируем ТЗ уже через промежуточные шаги.

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

..Шанс, что что-то пошло не так, весьма велик. В этом случае у нас ТЗ сформулировано на основании всех откликов, и шансы, что оно будет не то, сильно меньше. User story позволяет получить ТЗ быстро, не за месяц. И ТЗ, которое с высокой вероятностью соответствует всем самым актуальным ожиданиям заказчика и прочим требованиям. Потому что мы все это учли. Это генерация ТЗ.

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

Давайте вспомним, мы начинали вот с этих трех стикеров, когда минимум 40% времени тратится, где возможны потери. На самом деле, там даже больше возможны потери, потому что если мы что-то не то закинули в разработку, пока мы об этом не узнаем, разработка сделала, что-то уехало дальше на продакшн, и мы - "ох тыж, не туда", закрываем все обратно и все переделываем. Так что это даже, пожалуй, побольше 100%.

так, напоминаю, вот этот слайд и вот про эти самые потери, даже не 101%, что мы потратили. У нас есть time to market. Если у нас продуктовая разработка, то преимущество такого подхода с использованием языковых моделей таких, как на этом фреймворке, сокращает время вывода на рынок, операция становится короче - мы тратим сильно меньше времени на спецификации, меньше времени на получение обратной связи. И при прочих равных, если у нас поиск product/market fit, то мы можем это сделать быстрее. При прочих равных, подчеркиваю - это не панацея.

У нас есть хорошее влияние на разработку, потому что спецификации делаются не только в виде user story, но к ним еще добавляются критерии приемки. Думаю, даже разработчикам будет полезно увидеть, как это мы будем проверять, тестировать. Одна из парадигм, хорошая практика - вписать краевые ситуации в левую сторону до разработки. Когда мы описываем corner cases до разработки, а не после - "мы типа разработали, а сейчас будем проверять". И разработчик смотрит, ему прилетает ошибка, потому что он проверил не то, что написано в тикете в Jire, а еще где-то. А разработчик, может, и знает об этом, но забыл из-за выходных. Когда есть связка с user story и приемкой, это сильно положительно сказывается на качестве разработки.

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

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

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

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

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

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

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

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

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

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

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

С первых лет существования компании финальные собеседования со всеми кандидатами проводил наш СЕО, он же со-основатель компании. За ним было последнее слово: он лучше всех понимал, какой должна быть компания в будущем и какая команда для этого необходима. Когда количество финальных собеседований выросло до 3-5 в неделю, CEO перестал успевать их проводить, и это стало тормозить процесс. Он был готов передать эту задачу тимлидам, но для этого нам нужны были общие принципы принятия решений, которые на тот момент не были сформулированы.

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

Многие участники не понимали своей цели и роли в командных собеседованиях, а приходили потому что «так принято». Тимлиды и HR не учили людей проводить собеседования и не объяснили, как и какие вопросы задавать, что важно узнать, как оценивать. Это уменьшало вовлечённость: люди считали, что зря тратят своё время, отмалчивались на собеседованиях и в итоге не понимали, как принимать решение по кандидату.

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

Проблемы командных интервью усугубились, когда мы открыли зарубежные офисы и в собеседованиях стали принимать участие коллеги из России, Европы и Америки. Различия в национальных культурах ещё сильнее усложнили принятия решений и возможности договориться о найме. Например, в Америке вполне естественно менять работу каждые 2 года, в России мы чаще долго работаем на одном месте, а частую смену работы можем расценивать негативно. И это только один небольшой пример, которых в реальности было огромное количество.

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