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

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

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

💰 Заранее обсуждайте с руководством все нюансы переработок. Если не готовы овертаймить ни при каких обстоятельствах — это нормально. Если иногда готовы — обсудите, в каких случаях и как это будут компенсировать.

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

🏃‍♂️ Занимайтесь спортом и хорошо высыпайтесь. Тут комментарии излишни. Сон восстанавливает энергию, а физическая активность — пополняет ее запасы. Отвлечетесь от работы, а заодно и здоровье поправите.

💬 Не храните недовольство в себе. Терпеть — это, конечно, хорошо, но еще лучше — не терпеть. Сделайте с коллегами чат-оральню, где можно в любой момент написать, как вас всё бесит. Так вы выльете всё, что накипело, и получите лучи поддержки.

Другие способы не выгореть дотла в IT — в нашем блоге.

12 техник управления временем и задачами, помимо «Метода помидора»

Часть вторая

Правило 3-2-1. Каждый день вы фокусируетесь на трех основных задачах, двух дополнительных и одной по саморазвитию или личному росту. Помогает сосредоточиться на ключевых целях и приоритетах.

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

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

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

Task batching. Это техника группировки задач, где для каждой группы выделяется свой период времени. Например, вы объединяете ответы на письма и звонки и выполняете их в установленное время. Это помогает не распыляться.

Правило 90/90/1. Метод предполагает, что вы посвящаете первые 90 минут каждого утра в течение 90 дней на работу над самым важным проектом или задачей. Это помогает создать привычку приоритизации важных задач и эффективно расходовать силы.

Часть первая — по ссылке.

12 техник управления временем и задачами, помимо «Метода помидора»

Часть первая

Техника GTD. Эта система поможет организовать все ваши задачи и освободить ум от стресса и беспокойства о них. Принцип работы с задачами по GTD в пяти шагах: сбор, обработка, организация, обзор, действие.

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

Eat That Frog. Если начать день с выполнения самой неприятной задачи — буквально «съесть эту жабу», — то остальные задачи покажутся легкими по сравнению с ней. Помогает избежать прокрастинации и повышает продуктивность.

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

Zero-Based Calendar. Этот метод предполагает, что вы планируете каждый час рабочего дня заранее, не оставляя пустых слотов. Так не остается места для пустой траты времени и простоев.

2-Minute Rule. Этот метод предложен в книге Getting Things Done. Он гласит, что если задача занимает менее двух минут, ее следует выполнить немедленно, а не откладывать на потом. Это помогает избежать скопления небольших задач и повышает производительность.

Почему FilamentPHP — это хорошее решение для создания CMS

FilamentPHP — набор Fullstack-компонентов для Laravel. Последнее время мы в AGIMA часто используем его для построения админок. И вот почему:

1. Он красивый

Особенно в сравнении с Bootstrap. Filament же использует компоненты, стилизованные с помощью Tailwind CSS: 

Живую демку можно посмотреть и потрогать по этой ссылке.

2. Он доступный

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

А здесь найдете пример кода для создания формы авторизации.

3. Использует стек TALL (TailwindCSS, AlpineJS, Laravel, Livewire)

Livewire позволяет создавать приложение динамическим. Не нужно писать тонны кода на JQuery, как этого требует тот же Voyager. И, коли уж это Laravel, нам всегда доступны все его возможности.

4. Есть библиотека плагинов

И они закрыли уже почти все насущные проблемы.

Но и минусы у этого решения тоже есть:

• Стек TALL можно отнести и к минусам тоже, потому что Livewire иногда кажется достаточно сомнительной затеей.

• Filament достаточно прожорливый и требует OPCache и кеширования всего, что можно. И с включенным laravel-debugbar всё начинает тормозить.

• Часть плагинов платные.

• Код форм порой бывает достаточно… монструозным. Но это решается грамотным переиспользованием кода и разнесением его по разным местам.

Это краткий пересказ статьи Егора Черненка, PHP-разработчика AGIMA — полную версию читайте тут.

Наш опыт внедрения компонентной разработки

Компонентная разработка подразумевает деление мобильного приложения на отдельные компоненты (фичи). За каждый из них отвечает конкретный разработчик — Feature-оунер. Часть времени он посвящает задачам компонента, а часть — технической документации (Roadmap). Feature-оунер также контролирует работу остальных разработчиков, прикрепленных к фиче.

Мы решили перейти на новую методологию на текущем проекте по двум причинам:

1. У тимлида на проекте было мало времени, его нужно было разгрузить.

2. Проект смело можно назвать супераппом, он большой. И чтобы новый разработчик полноценно въехал в работу, обычно уходило 3–4 недели. Нам нужно было этот процесс ускорить.

Вот как мы распределили роли:

И вот что нам это дало:

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

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

• На выходе у нас получился полностью задокументированный проект. Даже если мы вернемся к нему через пару лет, мы быстро вспомним, как он реализован, и не будем тратить много времени на ознакомление. А если другая команда начнет с ним работать, для них это не будет темным лесом.

Это короткая версия статьи о компонентной разработке от нашего тимлида Саши Омельяненко — весь текст читайте тут.

О школе Баухаус в цитатах дизайнеров

Наш арт-директор Федор Ноздрин и еще семь дизайнеров из известных студий рассказали порталу DSGNRS, как художественная школа Баухаус повлияла на них и на всё дизайн-сообщество. Делимся некоторыми цитатами из материала.

Федор Ноздрин, AGIMA:

«Ле Корбюзье — величайший архитектор-модернист. Он никогда не был среди преподавателей Баухауса, но его работы оказали огромное влияние на основателей и учеников школы. Еще он повлиял на стиль советской застройки: железобетонные панели, плоские крыши, отсутствующий декор — всё это отголоски его архитектурных догм».

Эмиль Исхаков, ONY:

«Баухаус объединил архитектурное, скульптурное и художественное мышление в мультидисциплинарной философии. Мы расширили это мультидисциплинарным подходом, включив типографику, CGI, генеративный, саунд- и диджитал-дизайн. Таким образом, мы являемся в некотором роде продолжателями Баухауса, создавая новые опыты для брендов через эксперименты с разнообразными медиумами и пробуя новые выразительные средства».

Павел Конюков, Nimax Brands:

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

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

О дуализме качественных и количественных исследований в UX

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

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

Об этом можно почитать у Джеффа Соро, известного аналитика: «Вам не нужно думать об этом как о ситуации или-или. Всегда можно использовать микс методов».

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

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

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

• Конвергентный параллельный дизайн — когда вы одновременно собираете качественные и количественные данные, а затем анализируете результаты.

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

P. S. Это часть статьи Кати Патрикеевой о мифах в UX — полную версию читайте тут.

Как за два кризисных года мы увеличили команду вдвое

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

1. Провели реформу косвенных

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

2. Стажировки

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

3. Усиление подбора

Мы в 2 раза расширили команду рекрутеров, стали активно применять инструменты автоматизации подбора, например, Хантфлоу. Сейчас работаем над узнаваемостью: проводим регулярные опросы среди новых сотрудников и соискателей. Также мы открыли Outreach-отдел, который занялся холодным поиском специалистов на горящие вакансии, а заодно — и новых заказчиков.

Результаты

За 2022–2023 годы мы наняли порядка 300 человек. Из них 200 человек пришли в департамент разработки. При этом, мы сохранили аутсорс на докризисном уровне, а прошлый год стал рекордным по оборотам.

О наших планах на будущее читайте в полной версии статьи.

Учимся различать виды мотивации сотрудников

Пост по материалам доклада Александра Шутая, руководителя направления PHP в AGIMA, о том, как мотивация влияет на качество работы.

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

С базовой и положительной мотивацией всё более менее понятно. Первая про потребность в нормальной зарплате, достойных условиях труда и т. п. Вторая — про поощрение инициатив сотрудников, которые совпадают с целями компании.

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

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

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

Внутренняя мотивация — похожа на положительную, но здесь совпадение на уровне работы и личности человека. Все любят выражать себя, создавать своими руками новое и полезное.

P. S.13 апреля Саша выступит на «Стачке» в Ульяновске. Тема: Как совместить работу в IT с жизнью. Приходите!

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

Ребята из компании AGIMA AI недавно сделали для NL International бота Nelly, который умеет моментально находить ответ на любой вопрос пользователя. Работает это так: человек заходит на сайт компании, понимает, что ему нужна консультация, и пишет в чат. Тут же он получает список статей, в которых, скорее всего, найдет ответ на свой вопрос.

В отдельной статье подробно описываем весь ход работы над ассистентом, а здесь приведем только те технологии, которые использовали. Их пять:

• Chatwoot — интерфейс оператора с открытым исходным кодом и база знаний.

• Rasa — фреймворк с открытым исходным кодом для создания чат-ботов.

• Botfront — визуальный интерфейс для создания чат-ботов на RASA.

• Qdrant — векторная база данных для хранения векторных представлений статей из базы знаний.

• Datapipe — ETL, с помощью которого мы извлекаем статьи из Chatwoot, обрабатываем их и помещаем в Qdrant.

В результате количество запросов в поддержку, обрабатываемых чат-ботом, увеличилось с 30% до 70%. Команда контента продолжает добавлять статьи, чтобы чат-бот мог обрабатывать всё больше и больше запросов. Все подробности — в блоге.

Найти слабое звено: делаем команду эффективнее без перегруза

Слабое звено — это участок работы, из-за которого рушится весь процесс. Выявить его помогает теория ограничений, она же ТОС (Theory of constraints). Ее разработал, а затем подробно описал физик Элияху Голдратт в 1984 году.

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

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

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

3. Подчинить всё этому решению. Важно направить все имеющиеся ресурсы на решение конкретной проблемы/ограничения. Вся система должна работать на расширение узкого места.

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

5. Повторять цикл. Если ограничение устранено, необходимо вернуться к первому шагу — снова найти самое слабое звено и работать с ним.

Работая по методологии ТОС, мы не растрачиваем усилия на улучшение всего и сразу, а бросаем ресурсы на самый слабый участок системы. И шаг за шагом делаем процесс максимально эффективным. А как найти узкие места, читайте в статье нашего CTO Андрея Непряхина.

Главные принципы инклюзивного дизайна 

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

Чтобы соответствовать высокому уровню доступности по WCAG, необходимо придерживаться 4 принципов.

1. Воспринимаемость

• Всегда должна быть текстовая альтернатива нетекстовому контенту.

• Капча должна быть представлена в нескольких формах.

• Нельзя пренебрегать контрастностью.

2. Понятность

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

3. Управляемость

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

4. Надежность

Интерфейс должен оставаться доступным при изменении версий продукта или операционной системы.

Больше примеров доступных и недоступных интерфейсов найдете в нашей статье. А за вдохновением приглашаем в тг-канал нашей дизайн-команды. 

Как мы определяем грейд руководителей проектов

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

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

Для подготовки к тесту достаточно нашей Wiki, базы знаний. Все регламенты в ней разбиты по уровням: как раз для джунов, миддлов и сеньоров. На сегодняшний день у нас более 200 вопросов для разных уровней. Но на самом «экзамене» ответить нужно на 20. Тестирование проходит онлайн в системе INDIGO.

В тестах мы используем вопросы разных типов: с одним ответом, с несколькими, с полем для свободного ввода. У каждого вопроса свой вес. Считается, что успешно пройденный тест — это 80% правильных ответов. Любой вопрос можно разобрать после тестирования. А если сотрудник не согласен с результатом — то и оспорить.

Плюсы такой системы:

• помогает адаптировать стажеров;

• помогает менеджерам проанализировать свой опыт;

• мотивирует больше читать и погружаться в профессию;

• она не привязана к зарплате и не давит на человека;

• позволяет в игровой форме запоминать регламенты.

Кроме того, тестирование помогает нам улучшать качество базы знаний. Как — рассказываем в нашем блоге.

🍏 Компания Apple сообщила об официальном возвращении в Россию

Всё же в компании, похоже, почувствовали откусанный кусок рынка. В своем заявлении, Apple объявила об официальном возвращении на российский рынок после длительного перерыва. Конечно, все не так гладко, как звучит, но.

1. Компания внедрит систему привязки продаваемых устройств к местным операторам связи, аналогично тому, как это происходит в США. Покупатели iPhone и других гаджетов Apple смогут приобрести их только в пакете с тарифным планом от определенных партнеров-операторов. Есть подозрение, что цена на устройства или не снизится, или снизится незначительно.

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

3. Система Trade-In: Apple расширит свою программу обмена старых устройств на новые для российских клиентов.

4. Речи о том, что удаленные приложения санкционных компаний будут возвращены — нет. Но, как сообщают инсайдеры, сейчас идет обсуждают возможность запуска RuStore на iOS. Возможно, вопрос только в цене.

5. Ожидается, что в линейке появятся чехлы для iPhone, Apple Watch и AirPods только для России. Ждем коллаба со студией Лебедева.

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

Ссылочка: [тык]

UPD: Хотелось бы, чтобы всё так и было, но нет. Пока просто мечтаем об этом в формате первоапрельской шутки

Прекрасный и ужасный Kubernetes

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

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

👎 Помещают внутрь Supervisorctl несколько процессов.

👎 У каждого свои лог-файлы для разных мест.

👎 Состояние лежит рядом в виде файла.

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

Чтобы ехать хорошо и быстро, нужно правильно написать, собрать и доставить код.

👍 Если конвейер CI/CD построен правильно, мы успешно доедем до финиша.

👍 Чтобы было куда доставить код, нужен правильно приготовленный Kubernetes.

👍 Приложение должно быть написано в соответствии с 12 факторами:

👍 И еще 7 факторами:

• наблюдаемость (observable);

• прогнозируемость (schedulable);

• обновляемость (upgradable);

• минимальные привилегии (least privilege);

• контролируемость (auditable);

• защищенность (securable);

• измеримость (measurable).

Финансовые и нефинансовые системы мотивации

Это главные тезисы доклада Андрея Рыжкина, консультанта AGIMA, с митапа «TeamLead: Как управлять командой разработки и качеством на проекте». Мы подготовили серию таких постов, и сегодня делимся первым.

Профессиональная мотивация соотносится с уровнями пирамиды потребностей Маслоу, известной нам еще со школы:

Для мотивации на каждом уровне можно использовать финансовые и нефинансовые инструменты. И вот какие.

1. Физиологические потребности

💰Финансовые инструменты: уровень зарплаты. Если сотрудник получает достаточно, он думает о более высоких потребностях по пирамиде.

💖Нефинансовые инструменты: нет переработок и проблем с рабочим местом. Если работать приходится 24/7 — нет времени на сон и остальную жизнь. Мотивация падает.

2. Защищенность

💰 Стабильная зарплата. Не придется брать в долг, волноваться о регулярных платежах, и в итоге — поменять работу.
💖 Заботливый руководитель, отсутствие постоянного стресса, вежливые коллеги и комфортный офис.

3. Принадлежность

💰 Командные бонусы. Если все поработают хорошо, в конце месяца весь отдел получит премии.
💖 Дружеская атмосфера в команде. Вместе отмечаем победы, релизы и поддерживаем друг друга в случае неудач.

4. Уважение

💰 Индивидуальные премии.
💖 Авторитет в компании, карьерный рост, корпоративные подарки.

5. Самоактуализация

💰 Премия по показателям компании/отдела/команды.
💖Руководящая должность, партнерство, признание в экспертной среде, социальная значимость работы.

[Отладка] git bisect

Сегодня хочу рассказать об инструменте Git, который может очень помочь при отладке. Этот инструмент называется git bisect.

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

Принцип работы git bisect основан на методе бинарного поиска. Тебе лишь нужно указать «хороший» коммит, в котором ошибка точно отсутствует, и «плохой» коммит, в котором ошибка уже есть. Git bisect автоматически проведет тебя через процесс бинарного поиска между этими двумя точками, поможет постепенно сузить круг «подозреваемых» и найти коммит, начиная с которого стал проявляться баг.

Использование git bisect начинается с запуска команды git bisect start, после чего ты помечаешь известные «хороший» и «плохой» коммиты соответствующими командами. Git затем предложит тебе проверить определенный коммит, и ты сообщишь, есть ли в нем данная ошибка. Процесс повторяется, пока не будет найден коммит, который послужил причиной появления бага.

Ссылка на доку здесь.

А тут мой тг-канал со свежими новостями из мира мобильной разработки.

Платформенные интеграции во Flutter

Интеграция нативных SDK в Flutter-приложение — классный способ использовать функции и возможности, недоступные во Flutter. Для этого используют Platform Channels, которые позволяют Flutter общаться с нативной частью приложения — отправлять и получать сообщения.

Platform Channels — мостики, которые позволяют запускать нативный код из Flutter-приложения. Стандартный декодер обеспечивает эффективную двоичную сериализацию простых значений типа JSON. Сюда относятся логические значения, числа, строки, массивы байт, а также списки и мапы.

Сперва нужно выбрать тип канала в зависимости от потребностей:

• MethodChannel: используют в большинстве случаев, когда вызов метода во Flutter запускает нативный метод. Поддерживает асинхронные вызовы методов.

• EventChannel: для передачи потоков данных из нативного кода во Flutter.

• BasicMessageChannel: для отправки простых сообщений между Flutter и нативным кодом.

Для интеграции нативных SDK чаще всего используют MethodChannel:

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

class CartPage extends StatelessWidget {
  static const MethodChannel _channel = MethodChannel('co.wawand/stripe');

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      // Widget...
    );
  }
}

Подробнее о том, как как работает интеграция нативных SDK для iOS и для Android и с какими особенности платформ вы можете столкнуться, читайте в нашем переводе.

Что такое матрица компетенций и зачем она нужна

Матрица компетенций (МК) — инструмент управления рисками. Она помогает распределять ресурсы, определять грейды спецов и мотивировать команду.

По сути, это таблица с важными для проекта компетенциями. Она отражает, насколько каждый член команды владеет нужными навыками.

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

Как использовать МК:

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

• С помощью МК можно мотивировать сотрудников. Таблица с навыками удобно перекладывается на систему грейдов. Планировать развитие каждого члена команды проще.

• С помощью МК удобно бороться с Bus-фактором. Это ситуации, когда все ключевые навыки сосредоточены в руках одного человека. Матрица это наглядно покажет.

Как оценивать навыки для МК, как ее составлять и как с ее помощью распределять ресурсы внутри компании, рассказываем в отдельной статье. А больше про управление командой разработки — в телеграм-канале для тимлидов.

Идеальная продуктовая команда

Пост про идеальный состав продуктовой команды. Но сперва давайте выясним, а нужна ли вам она вообще?

Мы считаем команду продуктовой, если:

• она работает над одним продуктом/его частью;

• можно прогнозировать работу команды;

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

• она стремится к самоорганизации.

Такая команда вам не нужна, если:

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

• У вашего продукта есть конечная цель. Например, имиджевый сайт, который нужно запустить, но развивать не планируется (только актуализировать контент и поддерживать).

• Ваш продукт — это пока неподтвержденная гипотеза. Только ПОСЛЕ ее валидации стоит собирать Product-команду, ДО — рановато.

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

Вот базис продуктовой команды:

Но такая команда встречается нечасто, т. к. требует значительных финансовых затрат.

Продуктовая команда — единственно правильный вариант, когда «страшно, очень страшно, если бы мы знали, что это такое. Мы не знаем, что это такое». То есть, когда нужно запускать и развивать продукт, но непонятно, куда и как.

Подробнее об этом поговорим на онлайн-митапе «Как разрабатывать продуктовую стратегию» 29 марта в 18:00. Детали и регистрация тут.