Сделайте что-нибудь для людей перед людьми

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

В настоящее время произошли заметные сдвиги в производстве продуктов, особенно среди технологических компаний. Компании хотят выполнять поставку как можно быстрее. Благодаря CI / CD код можно легко отправлять несколько раз в день. Существуют такие механизмы, как флаги функций, позволяющие подмножеству пользователей опробовать незавершенные функции продукта до того, как они станут общедоступными.

Кроме того, мы можем легко делиться информацией с потенциально тысячами или даже миллионами людей. Социальные сети, такие как Twitter, новостные сайты, такие как Hacker News, сообщества, такие как Indie Hackers, и дискуссионные сайты, такие как Reddit, позволяют нам найти аудиторию, которая хочет узнать больше о наших продуктах, даже если они еще не доступны. Вот несколько отличных примеров людей, проектов и компаний, которые держат всех, кто интересуется, в курсе.

  • Популярные проекты с открытым исходным кодом, такие как React, Tensorflow и Kubernetes, имеют тысячи участников и миллионы пользователей. Идеи, предстоящие изменения и обновления обычно сообщаются заранее, и любой может принять участие в разговоре.
  • GitLab обнародовал практически все: от кода до дорожной карты компании и их OKR.
  • Mighty стремится предоставить значительно более быстрый Google Chrome. Сухайль регулярно публикует в Твиттере сообщения о проделанной работе.
  • Илон Маск иногда отвечает на твиты, в которых он упоминается (например, относительно запросов функций). Для такого занятого человека, как он, делать это аутентично, довольно необычно.

Как все это влияет на нашу повседневную работу, как на инженеров-программистов? Давайте разберемся.

Строительство за закрытыми занавесками может быть верным рецептом катастрофы

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

Как часто с вами случалось, что

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

Взглянув на приведенные ранее примеры (например, Mighty, GitLab), вы увидите, что таких ситуаций можно избежать. Идея проста: поделившись информацией во время создания, вы с большей вероятностью создадите что-то, что решит реальные проблемы ваших пользователей. Вот почему модель Building in Public становится все более популярной.

Как применить модель Building in Public

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

  • Обеспечение большей прозрачности, что создает хорошие и честные отношения с вашими пользователями.
  • Ранняя проверка и тестирование функций продукта
  • Создание заинтересованной аудитории, которая любит участвовать в процессе

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

Однако мне нравится верить, что мы можем использовать модель Build in Public, даже если «публичный» означает «внутри компании» в нашем случае. Вы можете относиться к своим коллегам так же, как вы относитесь к людям в Твиттере в этом отношении. Вот базовый план игры, которому я люблю следовать:

  1. Создайте канал Slack (или любое другое чат-приложение, которое вы используете). Любой сотрудник вашей компании должен иметь возможность присоединиться к нему.
  2. Пригласите на канал ключевых заинтересованных сторон: например, инженеры, дизайнеры, владелец продукта, любой заинтересованный руководитель (например, CPO).
  3. Делайте указанные ниже действия, чтобы создать отличный продукт (более или менее).

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

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

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

Краткий реальный рассказ о строительстве в общественных местах

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

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

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

«Привет, команда, я сказал вам вчера, что работаю над этой частью. Что ж, теперь вы сами видите, как это происходит вживую ».

Есть ли что-то, что нравится людям больше, чем постоянные обновления продукта?

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

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

«Вы знаете, что преуспели, когда #insert_hard_to_please_person аплодирует вам за ваши усилия».

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

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

В целом, публичное строительство у нас получилось хорошо.

Заключение

Спасибо, что прочитали этот пост. Подведем итоги:

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

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

Рекомендуемая литература: