The GOVNO framework is a novel approach to project management that aims to improve upon the shortcomings of the popular scrum methodology. Each letter of the acronym represents a key aspect of the framework:

— Governance
— Objectives
— Visibility
— Networks
— Outcomes, not outputs

https://govno.works/

Шедевр же )

Нейросети отбирают работу у специалистов по Developer Relations :)

Нашёл образец фиговой документации.

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

Сижу на встрече с докладчиками дружественной конференции FrontendConf. Среди тем есть управление знаниями и всё что вокруг него. Классно, что ребята тоже это ценят и понимают важность. Если вам есть что рассказать про онбординг, профессиональный рост, документацию и сообщества во фронтенде — скорей подавайте заявку. https://cfp.frontendconf.ru

Зачем учить AI писать документацию, когда можно научить AI читать документацию, и он будет отвечать на произвольные вопросы пользователей

https://githubnext.com/projects/copilot-for-docs

Расскажите про IT-сообщества и всякий движ в Армении и Грузии? Что там по митапам и конференциям? Хочу совместить приятное с полезным: познакомиться с вами, выступить с каким-нибудь полезным докладом, посмотреть на страну, поесть вкусной еды.

Если вам удобнее голосом — давайте созвонимся и обсудим за утренним кофе. Букайте встречу. :)

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

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

TeamLead: https://t.me/addlist/l5DYX3mRhwtiYWU6

DocOps: https://t.me/addlist/3GI1i-KgDPI3ODli

Если не работает — обновите приложение :)
Подборки полностью субъективны, я наверняка что-то хорошее пропустил, так что фидбек и предложения принимаю. Пишите комменты )

Купил новую бутылку для воды. Принес домой, радостно налил в неё воду из помпы, потом заметил что внутри лежит инструкция.

Инструкция колд-брю — идеальный напиток для человека, который пишет инструкции.

Developer Relations и как я к этому пришел.

Пора рассказать, что я теперь делаю. С февраля я работаю в =nil; Foundation, мы делаем инструменты для разработчиков. Про компанию расскажу отдельным постом, пока что про себя. Я тут занимаюсь developer relations. Сейчас объясню, что это за штука такая.

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

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

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

Потом оказывается, что иногда текст воспринимается плохо, надо рассказывать и показывать. Мы с вами тренируемся это делать, осваиваем всякие комбинированные форматы: выступления, воркшопы, курсы, live coding всякий, тренинги. Теперь наша с вами специальность — технические коммуникации, а инструментов у нас много и мы их подбираем под конкретную задачу и аудиторию.

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

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

>>> Вы находитесь здесь <<<

Всё это в индустрии называется developer relations и этим я занимаюсь. Нас в команде двое, прямо сейчас есть вакансии на еще двоих: technical writer и developer advocate. Я напишу пост про вакансии на этой неделе, но если вам уже интересно, пишите в личку @nick_volynkin прямо сейчас.

Вакансии в команду Developer Relations в nil.foundation

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

Ссылки на вакансии, там внутри есть почта:

— Technical writer
— Developer advocate

Подробнее про команду и мой подход к работе я писал в прошлом посте.
Нужно находиться за пределами РФ и РБ, в идеале — в Европе или Штатах. Релокация на Кипр «под ключ» или в другую страну по номад-визе.

В developer relations мне не нравится одна вещь — само название. Я вот не могу прийти к сообществу разработчиков и сказать «привет, я Коля, я тут чтобы с вами отношения налаживать». Я и у себя в голове не могу такое всерьёз сказать, для меня это звучит очень неестественно. Я думал, почему это так, и вот что придумал.

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

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

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

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

И developer relations — это не предмет деятельности и не цель, а некоторая характеристика результата. Метрика. И определять профессию через метрику это в самом деле что-то странное.

Так что привет, я Коля, моя задача в том, чтобы вам было удобно и понятно как работать.

Подборка каналов для тимлидов.

Я недавно уже публиковал папку с подборкой тимлидских каналов. А теперь хорошие ребята, авторы таких каналов собрались и сделали свою папку. В ней разные каналы непосредственно про управление разработкой и просто полезные для тимлидов. На две трети я уже был подписан, а про остальные просто рад был узнать. Ну и мой там тоже есть.

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

Держите, подписывайтесь. Там можно на всё сразу, а можно повыбирать. https://t.me/addlist/mDWR2gD6UEhlOWRi

Технические коммуникации можно поделить примерно на три группы:
1. Что надо сделать и зачем.
2. Как именно мы это сделаем или уже сделали, как оно внутри работает, как это эксплуатировать.
3. Как этим пользоваться и зачем.

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

Через неделю, 19 июня, мы попробуем разобраться хотя бы в части этой истории. Александра Камзеева и Андрей Бураков позвали меня к себе в подкаст, чтобы обсудить техписателей и аналитиков: их роли, задачи и навыки. Что общего, в чем отличия, как те и другие могут друг другу помогать. Приходите послушать нас! И накидывайте вопросы заранее: здесь или в комментариях в @nextway_news.

(Да, надо сразу сказать, что я себя не считаю «гуру техписательства», но побуду в роли techwriter advocate. Раз у разработчиков есть авокадо, значит и у техписателей могут быть.)

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

Давайте писать такое же про всякие наши библиотеки, API, CLI, архитектуру, деплои, вот это всё.

Через 15 минут будем трындеть как будто про техписателей и аналитиков, но больше о том, как всё перепутано в ролях и профессиях, и как это починить. Присоединяйтесь: https://nextway.timepad.ru/event/2465836/.

Запись будет через пару дней, но прийти и задать вопрос в прямом эфире — бесценно.