Два дня назад вышло интересное интервью с CPO GitHub Инбал Шани от Ленни Рачински. Так как GitHub со своим Copilot для разработчиков – один из лидеров внедрения инноваций в кодинг, захотелось законспектировать основные мысли. Итак, вот они:
Заменит ли AI разработчиков. Счастье и продуктивность разработчиков сильно зависят от среды разработки и AI Copilot, встроенный в нее имеет здесь решающее значение. Около 92% разработчиков уже используют подобные инструменты в работе, но страхи о замене специалистов машинами преувеличены. Люди все-таки более творческие и понимающие, чем даже самые лучшие модели, более стратегически мыслящие. Просто люди будут отдавать AI простые задачи, а сами думать над общей картиной, архитектурой, модульностью. И джуниорам они конечно позволят быстрее погрузиться в продукт, основные модули, да и старших они будут отвлекать меньше, при этом генерируя неплохой код с помощником. Ну и конечно AI в разработке будет повсеместно.
Уже сейчас 37000 организаций и 1.5 миллиона разработчиков используют Copilot, при этом, по опросам, они пишут код на 55% быстрее ,становятся на 85% увереннее в качестве кода и тестирование занимает на 15% меньше времени. В Accenture, например, код ревью прошло в итоге 88% сгенерированного кода. При этом сэкономленное время можно и нужно потратить на общение, творчество и инновации. Развитие AI ассистентов напоминает ситуации, когда все писали свои библиотеки и кучу кода для базовых вещей, а теперь многое есть прям в IDE, в новой версии какого-нибудь Python или скачивается одной кнопкой.
Чему уделяется меньше внимания, а зря. Тестированию с помощью AI. Информации мало, опыта мало, а ведь помощник может писать и модульные, и функциональные, и нагрузочные, и интеграционные тесты, порой даже лучше людей. Учитывая еще и что AI позволит генерировать больше кода в единицу времени, понадобится что-то сделать с другим узким горлышком - тестированием.
Какие ошибки совершают компании, внедряющие AI. Первое - думают, что изменения произойдут волшебным образом сами по себе, а ведь это огромное изменение парадигмы. И второе - пытаются везде запихнуть хоть какой-нибудь AI, не разбираясь, где вообще он нужен, а где - нет. Лучше сначала провести аудит своих типичных рабочих процессов, а потом обсудить с командами, где и каким образом можно использовать разные имеющиеся технологии. Если это будет насаждаться - вы просто заставите людей вас ненавидеть. Разработчики должны сами захотеть.
Как тестируют новое. В первую очередь используют внутри компании, тот самый догфудинг. Сначала раскатывают внутри, потом - на клиентов. При этом дают время разработчикам на внедрение инноваций и эксперименты, которые могут и не взлететь, и это нормально. Тратят много времени на общение с пользователями, а также дают возможность описывать идеи и добиваться финансирования их прототипирования.
Команда GitHub Next - что это. Ученые-исследователи, которые работают вместе и на самом деле думают о горизонте трех-пяти лет, а не ближайшего года. Пишут статьи, проводят исследования, пробуют новые технологии. Но при этом не чистые теоретики, а работают вместе с основными командами Такой внутренний исследовательский университет с инкубатором.
Что думают о возможности создания продуктов без знания кодинга.
Думает, что это радикально ускорит коммуникацию между продактами/аналитиками/дизайнерами и разработчиками, потому что сократит время ожидания следующей итерации, особенно когда много неизвестного. Если продакт может сам сделать прототип и убедиться, что он имеет нужные свойства, сделать фичу разработчику по нему вместо плохо проработанного ТЗ можно будет гораздо быстрее.
Любимый вопрос на собеседовании. Что является самым инновационным из того, что вы сделали, и почему, по вашему мнению, это инновационно?
Как стать CPO. Это должен быть руководитель, работающий и с продуктом и с бизнесом, лидер изменений, лидер команды в том числе. И учиться приходиться много, в том числе у людей, которые в чем-то лучше вас, просто для начала копируя их стиль и инструменты.
Самый большой фейл. Попытки просто прийти в работающий процесс с недостатками и с наскоку его изменить, не разобравшись, чего надо добиться, почему это происходит сейчас так, не замотивировав людей. В итоге конечно всё это обречено на провал.
3 книги, которые рекомендует. Failing Forward by John Maxwell, The Flywheel и Good to Great by Jim Collins, Dare to Lead by Dalia Feldheim.
Сериал. Весь невидимый нам свет
Девиз. Не будешь рисковать – не сможешь создать будущее.
P.S. Когда зарелизился OpenAI API и стало можно его внедрять в продукты (март-апрель 2023), мне посчастливилось поговорить с одним из членов команды общения с разработчиками из OpenAI. Я ему рассказал, как классно, всё, что они делают, и какие функции мы хотели внедрить в Wrike на базе API. Он посмотрел, что-то посоветовал, что-то подкорректировал, но сказал, что конечно люди пока не готовы к настоящим прорывным инновациям и такие небольшие шажки вперёд нужны, но глобально пора уже думать о новых рабочих отношениях, когда есть интеграция со всеми рабочими инструментами, и можно одним комментарием в рабочем чате "а кнопка тут должна быть левее" делать соответствующие коммиты в код, писать автотесты и сразу видеть результат. Тогда это казалось фантастикой, а сейчас мы кажется движемся именно в этом направлении. Удивительно время! Буду рад обсудить здесь или в телеграмме. Хороших вам выходных!
lair
...но нет. Ровно столько же времени: получить полные требования, спроектировать и реализовать. Возможность продакта самому сделать прототип влияет только на то, как быстро продакт может проверить свою гипотезу.
akimovpro Автор
Я думаю, тут с 2 сторон может быть преимущество.
Первое: проверка гипотезы при занятой другими задачами разработке. Продакт что-то придумал, попробовал, покрутил разные варианты, финальное показал другими командам или клиентам, собрал обратную связь, и все это не отвлекая разработку.
Второе: не совсем понятно, что делать надо, очень большая неопределенность. Нужно увидеть сочетание технологии и интерфейса, чтобы понять, что именно так и надо двигаться дальше, или что не выходит каменный цветок.
lair
Это то, про что я писал выше. Но это не влияет на скорость "сделать в продакшн-качестве".
Это называется "сбор требований".
Проблема в том, что в продакшне могут быть совсем другие технологии. И на переделку уйдет больше времени, чем делать с нуля.
akimovpro Автор
Вот с этапом "прототип -> продакшен" пока сделать действительно ничего радикального нельзя, но этап "сбора требований", как описал выше - запросто.
lair
Напомню, что в статье вы написали дословно вот так:
То есть именно про этап "прототип - продакшн".
akimovpro Автор
Ок, я исправил текст, чтобы было более понятно. Основная мысль, что когда от продакт-менеджера вместо документа, плохо сформулированного, приходит работающий прототип со всеми нюансами и корнер кейсами, количество вопросов от разработчиков и возможных проблем в финальной версии радикально уменьшается.
lair
В этот момент я перестаю понимать - вы пишете: "вышло интересное интервью [...] захотелось законспектировать основные мысли". Вы конспектируете свои мысли или то, что в интервью сказано?
Нет. Потому что перенести нюансы и корнер-кейсы из прототипа сложнее, чем из требований. Не говоря о том, что я не верю, что продакт-менеджер (не аналитик) способен на то, чтобы корректно найти и реализовать корнер-кейсы, это просто не его работа.
Я, так уж получилось, больше одного раза был в ситуации, когда мне давали прототип, и его надо было преобразовать в продакшн-версию, и все разы это было дольше и сложнее, чем если бы я работал по требованиям.
akimovpro Автор
Ок, я скорее на свой опыт ориентировался. У нас нет бизнес-аналитиков и основная неопределенность - в том, будет ли удобно пользоваться определенной технологией в определенном интерфейсе. Figma не дает возможность это реализовать, а полновесная реализация - дорого и возможно придется выкинуть.
lair
Серьезно? У вас нет неопределенностей "сможет ли система выдержать нагрузку"? "Будет ли это достаточно безопасно"? "Сможем ли мы это поддерживать в будущем"?
Если это так, я завидую уровню технологической зрелости вашей компании.
Apoheliy
Хм, ... например, у НАС нет бизнес-аналитика и очень сильная неопределённость: "будет ли удобно пользоваться определённой технологией в определённом интерфейсе". Про поддерживать в будущем - это боль, но так уж получается, что "здесь и сейчас" ещё решать рановато (хотя можно подготовиться). Вопрос про "безопасно" и "нагрузку" вообще не стоит (так как интернета нет и не будет). Приходите к нам, у нас печеньки :)
---
Про прототип согласен и с lair и с akimovpro: вменяемых прототипов не видел и не видел продактов, которые САМИ были готовы что-то накрутить-навертеть. Однако, ЕСЛИ БЫ продакт (или другое лицо, влияющее на конечный результат) сам что-то напрототипировал, то это было бы полезно.
Вопрос в сторону/продолжение темы: [Мало интересовался, но] есть ли простые средства прототипирования, чтобы условный продакт мог бы набросать прототип на основе некоторых скриншотов (так как это всё не веб и гуй там другой)?
lair
У вас какая-то нестандартная технология? Тогда вопрос, сможет ли Copilot вам помочь с этим.
Внезапно, безопасность и производительность - это не только про интернет.
...если у вас нет аналитиков, зачем мне ваши печеньки?
akimovpro Автор
Ну самый простой вариант - это Keynote, потом Figma, потом no-code инструменты разработки всякие.
akimovpro Автор
И она там еще говорила, что Copilot может же и вопросы продакту за разработчиков задавать, в итоге вытягивая из него все нужные данные вместо того, чтобы команде обнаруживать несоответствия уже на этапе демо.
lair
Гм, на основании чего?
akimovpro Автор
Типа жаловаться на его плохо сформулированное ТЗ )
lair
Это не имеет никакого отношения к "продакт может сам сделать прототип".
А главное, ощутимая часть вопросов, задаваемых разработчиками - они возникают как следствие имплементации в конкретные технологии и конкретную ситуацию. Откуда у Copilot этот контекст?
akimovpro Автор
Они прикидывали ситуацию из демо GPT-4 Vision: сфоткал дизайн сайта на салфетке и получил код.
https://www.youtube.com/shorts/i0bGZffYUNs?feature=share
В итоге AI, если не понимает, что конкретно делать-то, сможет задавать вопросы. Конечно, без контекста конкретных технологий, а скорее чтобы снять совсем уж непроработанные вещи.
lair
То есть задает те вопросы, которые бы задал хороший аналитик, еще не дойдя до разработчика. О чем я и написал выше.
akimovpro Автор
Да, если бизнес-аналитики хорошие, есть в наличии и доступны.
Apoheliy
Вот и задал я copilot-у задачу сформулировать проверки/тесты для алгоритма выбора лучшего сигнала из нескольких радиостанций. Ведь прежде чем писать алгоритм, нужно понять, что он должен делать. Вдруг copilot что-то полезное бы предложил?
Ответ copilot-а: ничего не понял и для проверок нужно понять алгоритм.
курица - яйцо - курица?
akimovpro Автор
Ну промт-инжиниринг иногда довольно много времени требует.