Про самоорганизацию

Про самоорганизацию

Пожалуй, самая важная трансформация, которая произошла со мной в части самоорганизации заключается в следующей смене парадигмы:
Как найти больше времени, чтобы всё успеть ➡️ Как успеть максимум за максимально короткое время.

Что меняется в концепции 👇

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

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

В треугольнике "задачи, время, мой ресурс (эффективность)" я фиксировал задачи, а время растягивал.

Этот подход оказался неверным:
☹️ Волны успеваемости сменяются волнами апатии и прокрастинации.
☹️ Ощущение "я много работаю" позволяет чаще делать непроизводительные паузы-награды: соцсети и прочее.
☹️ Если растягиваешь время — меньше думаешь о производительности: она не в фокусе. Ну, посплю поменьше — зато, сделаю побольше.

В какой-то момент (не так и давно, на самом деле) я стал фиксировать не задачи, а время: у меня есть 8-9 часов на все рабочие задачи и свои инициативы. Успевай.

И тут началось самое интересное в самоорганизации:
🙂 Работаю над действительно важными задачами.
🙂 Острее ощущается ограничение времени: стал меньше отвлекаться на постороннее.
🙂 Делегирование и работа с подрядчиками заиграли новыми красками.
🙂 Думаешь больше о самоэффективности: больше мотивации точить пилу и выбирать максимально эффективные инструменты.
🙂 Не надо жертвовать важными нерабочими делами: семья, спорт, саморазвитие и т.п.
🙂 Появляются левел-апы и вызовы: а можно ли успеть всё не за 8-9, а за 6-7 часов?

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

У меня появляются большие вопросы к людям, которые: "я работаю по 12-16 часов в день" — как долго они так могут работать и почему они считают это поводом для гордости?

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

Розыгрыш брифов!

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

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

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

Итак, посмотрим на то, какие еще проекты были представлены:

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

Revolut
Сервис по выгодному обмену курсов для путешественников. Выросли из этого, хотят быть круче, чем банк. Круто то, что проект международный. Цель проекта — предоставить пользователю различные банковские продукты в нужный момент времени (например, страховку в момент, когда пользователь приезжает в аэропорт)

SkyEng
Стартап, который уже давно не стартап. Цель проекта — удовлетворить запрос пользователей, которые хотят путешествовать.

Profi.ru
С лета 14 года помогают людям найти частных специалистов для решения любых задач. Все началось с доски объявлений на сайте университета по поиску репетиторов, сегодня это огромный сервис по поиску специалистов в любой сфере.
Сервис хорош тем, что с точки зрения специалиста в нем достаточно низкий порог входа, а с точки зрения заказчика огромная база специалистов.
Уникальность сервиса заключается в том, что взаимодействие в нем строится по принципу частник-частник.

КосмоЗоо
Однажды родился такой проект — московский космический зоопарк. Его целью является желание соединить ветеринаров и владельцев домашних животных. Ребятам предстоит изучить много нового в области домашних животных.

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

Наблюдения

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

Обучение наблюдателей отличается тем, что помимо вводной о проекте к обучению подключается картограф, который подробно объясняет методику наблюдения и принципы работы с картой. Так же, полевиков обучают работе в специальной программе — QGIS.
QGIS — это масштабная открытая геоинформационная система (ГИС), данные которой может использовать любой желающий.

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

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

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

По методологии, на наблюдения выходят обычно 4 полевика. Они работают в разные дни, делается это для того, чтобы каждый из них дал свою оценку и увидел то, что мог не увидеть другой (поэтому так важен опыт и внимательность). Иногда только на четвертом проходе обнаруживается какая-то важная пробема..
Получается, работу наблюдателя можно разделить на две части — работа в поле, где он собирает информацию, и обработка полученной информации за программой.
Благодаря этому, исследователям и аналитикам передается уже готовый проект — файл QGIS, где каждая проблема привязана к координатам, имеет индекс, описание и фотографию. Таким образом, информация уже готова для обработки.

7 важных факторов PHP-приложения

7 важных факторов PHP-приложения

Инженеры платформы Heroku (https://www.heroku.com/) на основе собственного опыта создали методологию (https://12factor.net/ru/) для разработки SaaS-приложений.

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

12 факторов приложения стали шаблоном для многих разработчиков и Ops-инженеров, а мы постарались адаптировать самые важные из них для приложений на PHP.

Кодовая база (https://12factor.net/ru/codebase). Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.

Зависимости (https://12factor.net/ru/dependencies). Используйте менеджер зависимостей Composer (https://getcomposer.org/) и его основные операции install и update для манипуляций c composer.json (https://getcomposer.org/doc/04-schema.md) и composer.lock.

Конфигурация (https://12factor.net/ru/config). Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv (https://github.com/symfony/dotenv).

Параллелизм (https://12factor.net/ru/concurrency). Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ (https://github.com/rabbitmq).

Паритет разработки/работы приложения (https://12factor.net/ru/dev-prod-parity). Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.

Журналирование (https://12factor.net/ru/logs). Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog (https://github.com/Seldaek/monolog) или компоненты фреймворков.

Задачи администрирования (https://12factor.net/ru/admin-processes). Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console (https://github.com/symfony/console). Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения (https://www.yiiframework.com/doc/guide/2.0/en/tutorial-console) и команды.

Болит за тексты

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

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

Логика такая:

1 - экран (приветствие)
2 - экран (рассказываем про топ возможности нашего каталога трусов)
3 - экран (говорим, что можно купить трусняк в один клик без мозговой боли)
4 - кидаем пользователя на каталог, а лучше на топовые труселя с покупкой в один клик

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

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

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

Расскажите, как у вас это устроено? Опрос будет под постом.

А я вам статеек накидаю полезных про UX копирайтинг:

1. https://bit.ly/2OLJEKY - подробно разложена тема UX копирайтинга

2. https://bit.ly/2QQ2JhE - опыт Google по написанию текстов

3. https://bit.ly/34oMOed - про UX писателей

Почему я предпочитаю удалённую работу

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

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

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

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