Привет, Хабр!

Я — Денис, Junior Android-разработчик в «Лайв Тайпинге». В этой статье расскажу о своём опыте внедрения нового процесса в отделе. Мы поговорим о важности образовательных митингов, а также найдем решения проблем, с которыми можно столкнутся во время его внедрения. У этой истории нетипичная концовка: я поделюсь тем, как митинги помогли мне выпустить собственную книгу. Так что в качестве бонуса — несколько советов о том, как опубликовать книгу на «ЛитРес: Самиздат».

Как я построил процесс образовательных митингов в отделе

На первом курсе ОмГУПСа я устроился работать в «Лайв Тайпинг». Это команда мобильных разработчиков из Омска, которая занимает 7-мое место в рейтинге Ruward. Меня сразу посадили за проект, и я быстро начал качать свои хард и софт скиллы.

Я каждый день создавал экраны с классами, интерфейсами и адаптерами, как по шаблону. Написал — скомпилировал, написал — скомпилировал и… все по новой. С одной стороны, я очень быстро это освоил, но с другой — начал скучать. Хотелось взять задачи посложнее, попробовать новые технологии и обсудить их с коллегами. Хотя бы во внутренних пет-проектах. Моим топом желанных инструментов в тот момент были Ktor и Jetpack Compose.

Первое правило митингов — все должны знать о митингах: как я создавал регламент

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

• спикер начинает готовить доклад за неделю до выступления;

• на встрече с готовым докладом подключает всех, кто работает удаленно, в Google Meet;

• запускает трансляцию экрана, если есть презентация или материал;

• рассказывает;

• отвечает на вопросы;

• после митинга все возвращаются к рабочим задачам.

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

Но этого лишь малая часть работы. Что ещё я сделал, чтобы идея превратилась в реальное дело

1. Продумал регламент для митингов. Я обозначил длительность митинга, количество докладов в один день и ближайшие темы для изучения.

Зачем это сделал: каждому процессу нужны свои правила и ограничения, которые помогут людям сориентироваться в нём.

2. Ввёл процесс по выбору спикера. Вместо не самого удобного списка с чек-боксами в iOS-отделе я создал таблицу в Notion. В ней помимо спикера доклада можно узнать тему, статус и дату выступления. Если тоже захотите научиться чему-то новому в отделе, то шаблон можно найти в ноушене.

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

Как уговорить коллег выступать на митингах 

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

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

Ну и поскольку я сам могу выбирать тему доклада — выбрал Jetpack Compose — совместил желанное для себя с полезным для команды. 

Jetpack Compose значительно упрощает процесс верстки, он позволяет справиться с ней в несколько раз быстрее. Помимо лаконичности, фреймворк предоставляет возможность писать мультиплатформенный reusable код, который легко поддерживать.

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

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

Но верстали экраны только ¼ отдела из-за занятости и нежелания делать домашку. Поэтому от домашки я отказался. Вскоре митинги по Jetpack Compose закончились, и мы перешли к другой теме.

Мой пример помог ребятам привыкнуть к образовательным митингам, научится выбирать темы для докладов, создавать наглядные презентации к ним. И вскоре все начали записываться спикерами в табличке на самые разные темы.

На первых порах, конечно, было заметно волнение, но на третий-четвертый раз уже никто не стеснялся и ребята демонстрировали свои знания.

Какие уроки я вынес из организации митингов

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

1. Человек может уйти в отпуск или заболеть 

Если ты пропустил митинг, то ты его совсем пропустил, — мы не сохраняли и не записывали выступления, поэтому доклады было никак не воспроизвести.

Я хотел, чтобы у всех была возможность послушать выступление коллег, поэтому написал простую инструкцию «Как начать запись видео экрана для Windows и MacOS». После доклада я загружал видео на корпоративный аккаунт YouTube, чтобы доступ был у всех.

2. Информации может быть слишком много

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

Спустя время я решил написать сообщение-просьбу, в которой расписал все «‎за‎‎»‎ и «‎против‎‎» двух докладов в один день‎. В итоге мы снова стали проводить ‎один доклад за раз‎‎‎ — это вернуло вниманию фокус.

3. Глубокие знания в одной области лучше широких, но поверхностных

Хоть коллеги и подключились к процессу, но я всё равно делал доклады чаще. И иногда огребал, так как у меня коммерческого опыта — год и месяц. Гораздо меньше, чем у коллег. Для кого-то информация, которую я для себя открывал впервые, — была... ну, как London is the capital of Great Britain. Они знали тему намного глубже и подлавливали меня, когда я допускал ошибки. Критика меня демотивировала, но позволила выучить несколько уроков для роста:

— первый: недостаточно недели, чтобы разобраться на 100% в технологии.

За неделю, параллельно работая на проектах, вам не удастся на 100% изучить тему. Просто примите критику коллег — в споре сможете докопаться до истины. С такой мыслью я шел на каждый доклад и больше не расстраивался после выступлений, а слушал и учитывал комменты, которые помогают расти.

— второй: изучение всего понемногу не приносило пользы.

Мы стали проводить митинги «треками». Это значит, что теперь мы изучаем только одну тему. И постепенно совершенствуем свои навыки в ней.  Сейчас это Котлин-трек — мы ищем топики, о которых раньше ничего не слышали или не использовали в своей работе. На протяжении нескольких месяцев я с командой готовлю доклады только по этой теме. Мы перестали распылять свое внимание на смежные области. Так, например мы успели глубже познакомиться с дженериками, котлин-контрактами и коллекциями.

Как я сохранил всю информации с митингов в красивой и удобной упаковке

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

А не изобретаю ли я велосипед? Поиск аналогичных руководств по Jetpack Compose

Сперва я обратился к англоязычным источникам в поисках аналога. Но нашел только целые книги по Jetpack Compose. А не краткое и емкое руководство по отдельным UI-компонентам. Вот на что я наткнулся во время поисков:

• Android UI Development with Jetpack Compose: Bring declarative and native UIs to life quickly and easily on Android using Jetpack Compose, Thomas Kunneth – много отступлений в сторону архитектуры в Android-приложениях и базы для его разработки;

• Jetpack Compose Essentials: Developing Android Apps with Jetpack Compose, Android Studio, and Kotlin, Neil Smyth – автор затрагивает тему ЯП, книга больше для новичков в Android-разработке.

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

Я видел такое флоу работы с моим будущим руководством:

1. разработчик увидел в дизайне мобильного приложения компонент X;

2. почесал затылок в попытках вспомнить как его сверстать;

3. открыл мое руководство в нужном месте – Ctrl C + Ctrl V;

4. профит.

Почему я не остановился на достигнутом, а продолжил развивать руководство

Книжку писал в Pages — это стандартный инструмент для MacOS. Он не перегружен функциями и кнопками как Word, — и мне казалось, что это удобно. Но позже это сыграло злую шутку.

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

Книгу тепло приняли в отделе, но эта новость распространилась и дальше. Хороший отклик натолкнул меня на мысль опубликовать книгу на крупной российской площадке «ЛитРес: Самиздат», тем более это бесплатно. Чтобы бо́льшему количеству разработчиков принесло пользу мое руководство. Но тут таилась проблема — жёсткие редакторские требования площадки.

Форматируем книгу для ЛитРес, или как я проходил все круги ада

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

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

Редактура заняла несколько недель. Текст я продолжал править в Pages. И не обратил внимания, какие форматы принимает «ЛитРес». Но вскоре ужаснулся, увидев там отсутствие PDF — моя книга содержала большое количество скриншотов и цветных вставок. К сожалению, площадка принимала только Word-файлы.

Пришлось дополнительно вносить множество корректировок в форматирование:

• изменил тип обтекания всех изображений в панели форматирования;

• удалил лишние пробелы между абзацами и указал стиль для них;

• конвертировал все фотографии из формата tiff (это расширение имеют все скриншоты на компьютерах Mac, а также эмодзи) в png – а это ручное сохранение из документа 139 картинок и их конвертирование, которое заняло 14 часов.

А также удалил все, что ЛитРес расценивало как рекламу уже на последней итерации внесения правок. Я с трепетом ждал ответа модерации и… снова получили отказ.

С вопросом в поддержку почему так, получил ответ, что в книге присутствует реклама — ссылки на сторонние ресурсы. Они ввели на документ в Notion, где были дополнительные примеры кода и репозиторий GitHub. Без этого техническая книга была бы бесполезной. 

В итоге при условии удаления ссылок на личные контакты менеджеры согласились опубликовать книгу на площадке «ЛитРес».

Три совета тем, кто решит написать нечто подобное и опубликовать на ЛитРес: 

1) пишите сразу в Word — сэкономите себе время и нервы; 

2) не бойтесь задавать вопросы поддержке сервиса — там отвечают быстро и по делу. На пути к реализации задумки поддержка сильно выручала;

3) найдите себе редактора или хотя бы человека со стороны — так можно избежать нелепых ошибок. Но и сами не плошайте ????

Что мне дал опыт написания книги и какие материальные богатства я с нее получил

Уже спустя несколько месяцев настольная книга «для своих» превратилась в хорошего помощника для разработчиков из СНГ, кто желает изучать этот фреймворк и использовать в своих проектах.

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

На момент написания статьи книгу скачали уже более ста людей, которым интересен Jetpack Compose. Я не ставил целью заработать на книге, поэтому установил почти минимальную отметку цены, возможную на ЛитРес. В итоге за два квартала, удалось выручить четыре тысячи. Я доволен. Чувствую себя известным.

Отдельная благодарность моему редактору, Лере Васильевой????. Она помогла при написании руководства по Jetpack Compose и этой статьи. Ты супер!

Если захотите больше узнать о публикации книги — пишите, всё подробно объясню!

Связаться со мной и задать вопросы можно в Телеграмм — @MolodoyDenis. 

Ссылка на книгу со скидкой — https://www.litres.ru/denis-sergeevich-popkov/razrabotka-android-prilozhenii-s-jetpack-compose/?lfrom=188180842&ref_offer=1&ref_key=3e1cb253c9480c1f5299c5477fb8e7fbf02e10aead965d7253d54b13c4fb27ed.