Демо — это не отчёт для галочки, а инструмент, который показывает ценность сделанной работы для бизнеса и пользователей. Чтобы команда и стейкхолдеры одинаково понимали, зачем и что мы сделали, презентация должна быть выстроена по логике «от ценности — к решению».
1. Вступление: команда и цель спринта
Слайды:
Название команды и даты спринта.
Роли (PO, BA, BE, FE, QA, MOB, Design) и укомплектованность.
Цель спринта (1–2 предложения, не «сделать задачи», а «проверить гипотезу/закрыть потребность/улучшить метрику»).
Совет: цель должна быть связана с ценностью для бизнеса или пользователя.
Когда технический директор приходит в компанию без базовых процессов, продукт превращается в череду хаотичных «подвигов». Чтобы вернуть предсказуемость, сначала наденьте шляпу директора по трансформации и выстройте фундамент.
Что важно включить в адаптивный плейбук?
Спринты и ритуалы. Определяем продолжительность, частоту встреч и четкое расписание: планирование, ежедневные стендапы, ревью, ретро.
Метрики ценности. Фокус не на закрытых задачах, а на том, сколько пользы получает клиент.
Автономность команд. Полномочия + ответственность = скорость без микроменеджмента.
Прозрачность. Общий календарь релизов, открытые доски задач, видимые цели.
Устойчивая скорость. Откажитесь от «геройских» овертаймов — выигрыш в долгую даёт именно стабильный темп.
Постоянное улучшение. Каждая ретроспектива — не отчёт о неудачах, а план апгрейда процессов.
Живая документация. 24-страничный плейбук должен обновляться по эволюции команды, а не пылиться в Wiki.
Вчера я залез в конфиги своего роутера. Роутер на Linux, конфиги в виде файлов, всё как у людей. Прежде чем что-то менять — делаю бэкап. Просто копирую файл и добавляю .bak в конец. Иногда выходит config.bak, потом config.bak2, config.bak_final, config.bak_final2_really… Думаю, у многих такая же история.
В какой-то момент я понял: это же полнейший бардак. И главное — зачем всё это, если у нас есть Git?
Репозиторий на роутере — почему бы и нет
Решение пришло само собой: я инициализировал Git-репозиторий прямо на роутере. Удалил все .bak-файлы, сделал первый коммит и начал экспериментировать. Что-то сломал — спокойно откатился. Заработало как надо — сделал новый коммит. Всё просто и прозрачно.
И вот тут в голове щёлкнуло: почему я не делаю так везде?
Git как способ мышления
Сейчас я работаю над резюме. Постоянные правки, новые формулировки, добавления, удаления. До этого всё шло в один файл, и если я что-то «переигрывал», то часто терял предыдущий вариант. А теперь у меня есть репозиторий с историей изменений. Можно вернуться, посмотреть, как развивались мысли, какие достижения вспоминались, какие формулировки оказались лучше.
И это безумно удобно.
Мир больше, чем код
Git — это не только про код. Это про мышление. Про контроль над изменениями. Про возможность безопасно экспериментировать и видеть историю своих действий. У нас в руках мощный инструмент, который легко переносится на любую работу с текстом.
Где ещё можно использовать Git?
— В личных заметках — В черновиках статей или постов — В резюме и портфолио — В планах обучения — В подготовке к публичным выступлениям — Даже в договорённостях по проектам (если вы технарь, конечно)
Всё, что можно представить как «файл с изменениями», можно завернуть в репозиторий.
Хаос против структуры
Мир не делится на «код» и «не код». Мир делится на хаос и репозитории.
Продолжаю серию лайфхаков для разработки своих pet-проектов. Сегодня мы всего за 2 мегабайта заглянем внутрь базы данных на своем сервере.
Для этого нам понадобится Adminer — легковесный интерфейс для просмотра своих таблиц. Больше подходит, конечно, для вашего dev/stage окружения, но можно и на проде, только учитывайте риски и не публикуйте порты наружу для коммерческого продукта.
Все что нужно сделать — добавить в docker compose следующий код:
# Adminer для управления базой данных (доступен только через внутреннюю сеть)
adminer:
image: adminer:latest
depends_on:
db:
condition: service_healthy
restart: unless-stopped
environment:
- ADMINER_DEFAULT_SERVER=db
networks:
- app_network
# Не публикуем порты наружу для безопасности
Дальше хитрый трюк, хотите открыть его в браузере у себя на компьютере? Запустите команду ssh туннеля для маппинга портов:
ssh -L 8080:localhost:8080 user@remote_server_ip
Это одна из тех команд, которые я хотел бы знать гораздо раньше в своей карьере. Теперь на локалхосте у вас удаленный сайт открывается, и доступен он только вам!
Сегодня меня пригласил на вебинар по трудоустройству в качестве соведущего Алексей Голобурдин, автор канала Диджитализируй. Я согласился сразу — ведь во многом благодаря его каналу я ответил на многие вопросы на технических собеседованиях. С его разрешения публикую на своем блоге:
Для максимально стройного изложения своих мыслей я решил написать эту статью. У меня несколько необычный опыт в IT, но велика вероятность, что он поможет таким же специалистам, которые решили сменить сферу работы после 30.
Мой опыт в IT
Я пришел в технологии 12 лет назад предпринимателем. Я не делал проекты на заказ, я делал их для себя, сам ставил задачи, сам их выполнял. Так как я не был разработчиком в прямом смысле этого слова — решения я находил такие, которые можно установить на сервер своими силами через скрипты-установщики, связать через плагины или встраиваемые скрипты. Сейчас подобная парадигма называется No Code, так вот именно этим я и занимался всю свою карьеру. И, конечно, много опыта в бизнесе — ведь это были мои магазины, а значит маркетинг и продажи тоже должны быть настроены. До 2019 года я делал это все в команде с моими соучредителями, затем — уже самостоятельно, полный цикл решений.
Почему я решил идти в программирование?
В определенный момент времени ты понимаешь, что нужного тебе плагина не существует, или две системы не общаются между собой, но у каждой есть описание API. И чем дальше ты ищешь нужное тебе решение, тем больше убеждаешься, что его либо нет, либо оно сырое.
Так как я давно уже автоматизировал все в своем бизнесе — у меня было время на стороннее консультирование. Несколько лет я настраивал IT-системы в фитнес-клубе, делал их взаимосвязь, применял свой бизнес-опыт и профильное банковское образование для бизнес-консультирования. В общем, был занят. А в какой-то момент на мир спустился черный лебедь — пандемия. Естественно, фитнес-клуб закрыли одним из первых, и у меня появилось свободное время. И я решился — сейчас, пора. Python, я иду!
У меня есть отдельная статья про Яндекс.Практикум, там есть плюсы и минусы. Рекомендую ознакомиться, здесь повторяться не буду. Здесь я сосредоточусь на тех шагах, которые я предпринял после обучения.
Подготовка к устройству на работу
Мне нужно было разобраться в моих знаниях. Я решил сделать это через книги. Понятное дело, что что-то могло пройти мимо. Я взялся за «Изучаем питон», «Чистый питон», «Грокаем алгоритмы», «Программист-прагматик» и другую литературу, которая гуглится по запросу «Лучшие книги по питону» и которые можно заказать на бумаге — с технической литературой я умею только так.
Также я начал участвовать в Open Source проектах. Нашел интересного ментора, Леона Сендоя, и помогал ему писать систему резервного копирования различных баз данных Blackbox. Читал код, разбирался в фабричном методе проектирования, и что самое главное — решал поставленные задачи. Причем почти все они были для меня абсолютно новыми, я разбирался в проблеме с нуля. Серьезный буст для саморазвития и в качестве бонуса ревью от очень хорошего норвежского специалиста и владельца сообщества Python-Discord на 200 000 человек.
Размещение резюме
Также я разместил резюме на HH и Хабр.Карьере. Я неплохо говорю по-английски, поэтому, проконсультировавшись с сестрой, которая уже много лет живет в Англии и работает HR, разместил резюме еще на следующих сайтах:
Также заручился рекомендациями от моих менторов — Леона Сендоя и Андрея Ли — на LinkedIn (рекомендации приложены в конце статьи для примера).
Первое собеседование
Довольно быстро пришло приглашение на первое собеседование на английском. Сказать что было страшно — ничего не сказать. Это был грандиозный выход из зоны комфорта. Но у меня есть один трюк, как бороться со страхом принятия решения — я его сразу принимаю. Не раздумывая, не переживая, да и еще раз да.
Теперь у меня был уже совсем другой повод беспокоиться — надо было готовиться к собеседованию на английском. Я составил речь, позвонил сестре, рассказал ей, она похвалила. Что ж, кажется я готов, подумал я.
Пройти собеседование с HR было несложно, но нервно. У меня красивая история, я подготовился — и вот у меня уже назначено техническое собеседование. Как мог я готовился, читал все, что попадалось под руки. Вот список того, что вам поможет в этом:
Техническое интервью тоже прошло на ура, я отвечал на вопросы, я знал как устроены некоторые сложные фичи питона и уверенно об этом говорил. Настало время технического задания, и вот тут я первый раз сделал все неправильно. Я прочитал задание, и сразу побежал выполнять. Я был слишком уверен в себе, ведь я понравился на всех этапах собеседования! И я решил задачу, получил данные по API, распечатал их в консоль, ничего сложного. Но техдиректору компании все это не понравилось от слова совсем. Потому что я не использовать паттерны проектирования, писал без классов, код нельзя было переиспользовать. Не то, что я не умел это делать — умел, но торопился, переживал, сделал тяп-ляп. Первый отказ. Я был чрезвычайно расстроен.
Следующие 30 собеседований
Дальше моя стратегия поменялась. Я должен был набрать опыт собеседований. Не важно, нравится ли мне компания или нет — я всегда откликался на все предложения разговоров от HR. Я внимательно изучал компанию, стек — по каждому непонятному слову сразу смотрел подробное руководство на Youtube (выбирал длинные ролики и скорость 1.75х). И с каждым разом отвечал все лучше. Попадались хитрые вопросы, попадались скучные, но почти всегда я проходил стадию HR на ура, а вот технические собеседования были успешны в 50% случаев.
Что стоит знать:
напиши свой декоратор
напиши свой декоратор с параметрами
паттерны проектирования и где ты их применял
SOLID, ACID, принципы ООП
Нормализация БД и вообще вопросов на построение запроса к БД много, в основном на Postgres
Базовые алгоритмы и их сложность
Структуры данных
Индексы и устройство хешей в общем виде
Контекстный менеджер with
REST/OpenAPI/принципы проектирования, SOAP
Очереди Kafka и RabbitMQ
AWS будет плюсом
Redis
Celery
Асинхронное программирование и принцип работы GIL
Микросервисы
Рекурсия
MongoDB
Два типа собеседований
Все можно поделить на два типа, вот и собеседования тоже. Первый тип — самый распространенный — собеседования, которые очень плохо подготовлены. Вопросы точечные, твой уровень никак не показывают, пытаются проверить не твои знания, а твой зубреж. Наверное, хороши для людей с идеальной памятью, я не из них. Я не могу вписать в поле название класса джанго, который я буду наследовать при создании своего фильтра — без подглядывания в документацию или проект, где я это уже делал.
Второй тип — это собеседования, где интервьюер выясняет область твоих знаний и четко начинает ходить по ее грани, пытаясь понять, как ты размышляешь, когда сталкиваешься с неизвестным. Вот из таких собеседований я выносил максимальное количество новой информации и именно они меня готовили к самому важному собеседованию — в компанию мечты.
Собеседование в EPAM
Так как компания ЕПАМ большая и ей уже 25 лет — то и процессы там гораздо лучше отлажены, в том числе собеседования. Это без преувеличения мой лучший опыт за весь период поиска работы. Ребята задавали интересные вопросы, где я что-то упускал — рассказывали, давали возможность раскрыться. Суммарно 5 часов технических собеседований, я был уставший, но довольный. Я рассказал свой опыт, я позиционировал себя как специалиста, который делает горизонтальный переход, и претендовал на должность Мидл-разработчика. Как я понял — позиционирование и вера в себя — это самые важные вещи после знаний.
И вот я получил оффер от ЕПАМ, и сразу на достойную сумму. Не принимая его сразу, я сказал, что мне нужно две недели на принятие решения и продолжил изучать рынок. Теперь была задана планка, и я хотел перепроверить — точно ли я правильно выбрал ЕПАМ.
Еще 10 собеседований, в том числе 3 технических, и я принял решение — я иду в ЕПАМ. Я пытался следовать советам из статей про то, как принимаются офферы и сколько надо выждать, но в итоге все равно договорился с HR о звонке и сообщил о своих намерениях. Всего процесс трудоустройства занял около трех месяцев, и это были самые насыщенные на учебу месяцы.
Пример резюме
Примеры моих резюме, если вам интересно как я себя позиционировал:
В своих проектах я всегда придерживался философии «как можно меньше правок в фреймворк». Основная задача была сделать проект автообновляемым и не теряющим своей актуальности на протяжении долгого времени. Как я пришел к этой философии?
Почему No или Less Code?
Свои самые первые интернет-магазины я запускал в 2009-2010 годах, тогда не было еще того разнообразия готовых фреймворков и плагинов к ним. Был вордпресс, были скрипты интернет-магазинов с самоустановкой — укажи данные базы и проект начинает свое MVP-путешествие. Что происходило дальше? Если нужен новый заголовок, я лез в код и менял заголовок. Когда нужно было поставить какое-то условие в шаблоне — лез в Smarty и делал условие. Когда менялась логика бизнеса — я копал еще глубже и менял уже PHP-файлы. И вылилось это все в невозможность обновления продукта. А когда у вас успешный сайт, вам нужны новые функции для сохранения бизнеса в игре, и получить вы их можете только сделав еще больше правок в коде, или, как мы их называли всегда, костылей.
В итоге шли годы, а сайт устаревал, а сменить все и при этом сохранить трафик из поисковых систем — задача около нереальная. И когда все-таки этот момент наступал — наступали последствия в виде просадки позиций и падения продаж.
Концепция самообновляемости сайта
В итоге самым правильным решением для бизнеса стал переход на фреймворки с поддержкой плагинов. Таким образом, новые функции прилетали с обновлениями, плагины были изолированы от основного кода и всегда можно было заказать доработку под себя. Тут оставался простор для небольшого фронтенд кодинга, но все в очень жестких рамках.
No code сервисы
Не я один полюбил эту концепцию. В интернете появилось множество сервисов, которые стали помогать делать вам сайт совершенно без кода. Вы собираете интерфейс или даже целое мобильное приложение в визуальном редакторе. Если мои проекты все еще лежат на моих же серверах, то современные тенденции предлагают хранить их у провайдеров услуги за небольшие деньги и при этом всегда иметь возможность принять больше посетителей в моменте, чем позволил бы один свой сервер.
Рассмотрим некоторые из no code сервисов:
Скриншот из видео сверху (оригинал недоступен, сайт не работает):
webflow.com
Удивительный сервис, где даже базы данных нужно проектировать в визуальном интерфейсе. Получается, что это какой-то новый уровень разработки, и теперь можно делать не только сайты-визитки или посадочные страницы, но и полноценные системы управления контентом и онлайн-магазины!
editorx.com
Еще один сервис с возможностью полного проектирования как дизайна, так и базы данных. Проекты, построенные с помощью этой платформы — впечатляют.
bravostudio.app
Неожиданный поворот — это сервис Браво, позволяющий делать мобильные приложения без кода. В какой-то момент начинаешь понимать, что за этим всем будущее. Только сложные проекты с запутанной логикой будут писаться с нуля, все остальное можно будет сделать за пару вечеров без каких либо знаний программирования.
supernova.io
Сверхновую позиционируют уже не как no code, а как удобный код рядом с дизайном. Для тех, кто все еще хочет держать руку на пульсе, но уже хочет упростить себе жизнь.
Какие еще сервисы?
Обратите внимание на Notion (рич-блокнот с коллаборацией), Anima (ожившие прототипы), Play (дизайн мобильных приложений прямо на мобильных приложениях) и Airtable (прекрасная смесь экселя и баз данных).
Миграция на чип М1 от Apple прошла для меня практически бесшовно. Встретилась лишь одна проблема — с установкой psycopg2-binary, что является утилитой, с помощью которой Django Framework подключается к PostgreSQL.
Проблема неприятная и свежая, по ней много вопросов в англоязычной части интернета и очень мало хорошо расписанных инструкций. А на вариант с докером инструкции нет вовсе, это решение мне пришлось придумать самому.
Проблема 1: Не устанавливается psycopg2-binary в Docker-контейнере через Dockerfile или docker-compose (MacOS Big Sur M1)
Здесь самым простым способом будет отказаться от урезанных образов наподобие alpine или slim. Просто используйте самый обычный Python 3.9:
FROM python:3.9
После этого контейнеры поднимутся именно так, как вы их задумывали. Здесь, видимо, проблема в том, что архитектура чипа M1 пока неизвестна и не так популярна. В скором времени эту проблему наверняка исправят.
Проблема 2: Не устанавливается psycopg2-binary в MacOS Big Sur M1
Возможные выводы ошибки:
$ pip install psycopg2-binary
Collecting psycopg2-binary
Using cached psycopg2-binary-2.8.6.tar.gz (384 kB)
ERROR: Command errored out with exit status 1:
И дальше длинный трейс ошибки. Как победить? Если вы только купили свой мак, скорее всего у вас не установлен пакет brew и вам нужно сделать следующие шаги:
Чтобы он запускался без указания полного пути вам нужно добавить этот путь (к многим другим путям) в переменную PATH. Не пугайтесь, это страшно лишь по началу. В unix-подобных системах терминал умеет запускать приложения только если он знает где их искать. А brew установилась в хитрую папку и наш терминал просто не знает этого пути. Пока не знает. Давайте его научим, и рекомендую запомнить этот трюк, он часто нужен (и не только на маках, но и на виндус). На вашем маке в качестве терминала по умолчанию стоит ZSH. Вам нужно создать файл в домашней директории (если там его еще нет, проверить можно командой ls -la) с названием .zshrc (именно с точкой в начале) и положить туда одну строчку:
export PATH=/opt/homebrew/bin:$PATH
Перезапустите терминал, теперь у вас есть brew.
3. Дальше проще, установите сам пакет с Постгресом
brew install postgresql
4. Теперь установите SSL, без него не заработает
brew link openssl
5. Пропишите в наш созданный в пункте 2 файл еще один путь:
Получил список рекомендаций от знакомого разработчика — что нужно знать, программа-минимум. Решил оставить в блоге этот перечень, чтобы не затерялся. Итак:
Как минимум поверхностное понимание работы JavaScript
Если учить React, то сфокусироваться на практическом применении, а также разобраться с фреймворками на его основе, например next.js, который позволяет обойтись без бэкенда вовсе
Ознакомиться с технологиями публикации сайтов прямо из репозитория, например Netfly
Понять JAMstack, так как он очень популярен и удобен
Взять на вооружение технологию htmx, которая позволяет сделать отзывчивый интерактивный сайт без JS, только на питоне
Узнать больше про безсерверную архитектуру на основе AWS и Lambdas (причем докер образы будут прямо в Лямбде). В питоне это позволяет сделать утилита Zappa
Также общий набор рекомендаций для софт-скиллов:
Писать хорошие коммиты
Уметь делать CI/CD
Писать тесты для своих проектов на гитхабе
Проявлять активность на гитхабе в целом
Писать красивый PEP8 код
Писать статьи в блог
Может, даже вести подкаст
Помогать с опен-сорс проектами
И это ведь только начало. Впереди столько интересных технологий!
