Метка: релиз

  • Разработка наоборот в Amazon

    Разработка наоборот в Amazon

    Гигант интернет-торговли Amazon внедрил у себя практику разработки “наоборот” — вместо PRD и спецификации они начинают с написания пресс-релиза и FAQ. Пресс-релиз пишут так, как будто новая фича уже вышла.

    Какие есть преимущества у этого подхода?
    – Ранняя валидация того, насколько новая фича на самом деле нужна. Менеджменту легко принять решение или опросить фокус-группы.
    – Всем участникам понятно, что именно они делают и как это должно восприниматься.
    – В самом начале понятно, какие могут возникнуть технологические вызовы.
    – Опыт и ценности для конечного пользователя становятся очевидны всем участникам процесса.

    В пресс-релиз включены:
    – Интро.
    – Проблемы пользователей, которые решает новая разработка (Jobs-to-be-Done).
    – Предлагаемое решение этих проблем.
    – Цитаты ответственного за внедрение.
    – Цитаты вымышленных персонажей с впечатлениями от продукта.

    Пресс-релиз пишется одновременно с большим FAQ с ответами на возможные вопросы как пользователей (Customer FAQ), так и команды (Internal FAQ).

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

  • Sentry для отлова ошибок

    Sentry для отлова ошибок

    Пользователи жалуются, что на сайте возникает ошибка. У разработчика “всё работает”. В команде разработки никто ошибку не может воспроизвести ни на одном устройстве. Бывает, что в логах нет ничего, потому что ошибка произошла на фронте. Или записи не информативны. А пользователи продолжают жаловаться…

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

    Это всё позволяет очень быстро найти реальную причину возникшей проблемы.

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

    Раньше мы пользовались SaaS-версией, но некоторое время назад всех РФ-пользователей попросили завершить обслуживание. Так что, я развернул бесплатную self-hosted версию на своей VDS. Система прожорливая, Docker Compose запускает три десятка контейнеров, поэтому требуется достаточно мощный сервер. Такой сервер у нас выходит на 4000 рублей в месяц, зато обслуживает десятки небольших проектов.

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

  • 🙌🙌🙌🙌  25+ документов для тех, кто в диджитал

    🙌🙌🙌🙌 25+ документов для тех, кто в диджитал


    В преддверии новой активности мы собрали в одну папку 29 Telegram-каналов известных профессионалов и попросили их авторов подготовить для вас документы, которые помогут:

    🔴Правильно писать запросы нейросетям;
    🔴Промпты для прокачки карьеры в IT;
    🔴20 игровых механик, которые повысят LTV вашего продукта;
    🔴Чек-лист SEO-требований к релизу нового сайта;
    🔴UX-аудит сайта своими руками;
    🔴и еще много много всего!

    ✔️ Я делюсь скриптом для автоматической настройки VDS.
    С ним вы научитесь использовать Ansible и примените все лучшие практики защиты вашего сервера от взлома.
    ➡️ Скачайте архив по ссылке или склонируйте репозиторий на GitHub.

    ❗️ Сохранив единожды папку «Документы для тех, кто в диджитал», вы сможете спокойно пройтись по всем каналам и скачать множество авторских документов, которые точно пригодятся в работе.

    Также они проводят розыгрыш с топовыми призами:
    🥇Главный приз — MacBook Air (M2)
    🥈2 место: Яндекс Станция Лайт 2
    🥉3 место: Наушники HUAWEI Freebuds 5i

    Как участвовать:

    1. Подпишись на папку: https://t.me/addlist/Qu1lhSIaUZVjZTFi
    2.
    Подтверди участие в боте

    До встречи 27 июля – дата подведения итогов!

  • Среда для приложения

    Среда для приложения

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

    Дев (dev, development, local, IDE) — тут сидит разработчик, приложение раскрыто и подключено к приборам, лампочки, мониторы, кишки наружу. Хирургическое отделение, идёт операция. По итогу работы приложение будет передано на следующую стадию разработки.

    Тест (test, QA) — тут его всячески проверяют. Заводятся выдуманные пользователи, которые выполняют заготовленные сценарии с синтетическими данными. В роли тестировщиков выступают и люди, и роботы. Их задача — найти ошибки и вернуть приложение разработчикам на исправление или отправить на следующую стадию.

    Демо (Demo, Review) — приём приложения у менеджеров. Смотрят продакт, проджект и аккаунт-менеджеры, представители клиента, стейкхолдеры.
    Часто демонстрацию проводят на стейдже или тесте, не создавая отдельное окружение.

    Стейдж (staging, stage) — тут разворачивают приложение на копии настоящих данных (иногда анонимизированных), проводят финальные тесты на совместимость, интеграцию с другими системами и делают проверки перед выходом в свет. Окружение максимально приближенное к проду.

    Продакшн (прод, prod) — тут с приложением случается релиз — его опубликовали и теперь с ним работают реальные пользователи. Это финальная стадия — эксплуатация. Акцент на надёжность, скорость работы и сохранность данных.

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

  • Спиральная динамика

    Спиральная динамика

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

    🟤 Бежевый — Выживание. Стая учится выживать, охотятся уже вместе, но все грызутся на делёжке добычи. Типичный отдел продаж в мелком агентстве недвижимости или свора фрилансеров. Бизнес в этой фазе ещё не разобрался, что он бизнес. Основатель научился создавать приток средств, пытается организовать работу коллектива и сам коллектив вокруг этого притока. Подбирается лояльный коллектив.

    🟣 Фиолетовый — Клановый. От каждого по способностям, каждому по потребностям. Главная ценность — причастность клану. Мистицизм, ритуалы. Увольнение через изгнание или выход через скандал с обидами. Уютный стартапчик, все мы друзья. На этом уровне организация может жить и расти десятки лет. Вся дальнейшая эволюция зависит от руководства и избыточности ресурсов. Если ресурсов не хватает — растём на следующий уровень.

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

    🔵 Синий — Порядок и бюрократия. Соблюдение правил, выполнение инструкций. Все винтики, трактор непостижим. Ресурсы есть, вокруг источника лидов построили добывающий комбинат и получают клиентов по плану. Люди занимают должности и выполняют роли. Личная инициативность, которую так ценили на прошлых стадиях, становится опасной. Учимся считать, планировать, прогнозировать, учитывать. Пересмотр оргструктуры, введение регламентов. Самый адекватный момент для реального выхода основателя-предпринимателя из операционки и передачи штурвала операционной команде. В один момент бюрократия сильно мешает развитию, бумажки теряют смысл, компания начинает буксовать. «Нужно идти в ногу со временем» — типичная фраза, которую говорят в сильно отстающих компаниях на синем уровне.

    🟠 Оранжевый — битва за эффективность. KPI, ОКР, лидерборды, корпоративные соревнования. Менеджеры, выполнявшие свои обязанности на синем уровне, оказываются неэффективными (раньше никто не измерял) и заменяются на новых управленцев. Оптимизация процессов, вынос неважных вещей в аутсорс, снижение рисков. Оптимизация высвобождает ресурсы и компания захватывает всю доступную долю рынка.

    🟢 Зелёный — Экосистема. Дальнейший рост — через рост всего рынка. Что его сдерживает? Развиваем отрасль, образовываем клиентов, открываем кафедру в университете. Как насчет отраслевого альянса?

    Далее есть ещё три ступени, но они слишком далеки от моей практики. При желании можете углубиться в эту тему — по спиральной динамике написано около десяти книг.

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

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

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

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

  • Пройти Тест Джоэля

    Пройти Тест Джоэля

    В 2000 году Джоэль Сполски — сооснователь StackOverflow и Trello, написал список из 12 вопросов, известные как Тест Джоэля. Часто ссылаюсь на этот тест, поэтому прокомментирую эти вопросы.

    1. Используете систему контроля версий?
    Кажется, что git — уже обязательная вещь. Но до сих пор встречаются проекты без системы контроля версий.
    Для тех, кто уже использует, вопрос всё ещё актуален, но теперь звучит так: Вы действительно используете систему контроля версий? У вас есть стратегия ветвления, процедура слияния веток, понятные правила для работы с репозиторием?

    2. Сборка проекта происходит в один шаг?
    Проект должен собираться в 1 команду и она должна быть написана в readme. Если для запуска проекта требуется поставить несколько сервисов, иметь нужную версию компилятора и запущенную базу данных — стоит прописать все эти зависимости в docker-compose и запускать одной командой. После прихода виртуализации оправданий для многошаговой сборки и зависимости от среды больше нет.

    3. У вас настроен CI/CD?
    В оригинале Джоэль говорит про daily build — оперативная сборка софта каждый день. Сейчас в большинстве команд нет нужды синхронизировать код раз в день, можно делать это автоматически каждый раз, когда код попадает в репозиторий.
    Настройте автоматическую сборку и выкатку приложения на тестовый сервер.

    4. У вас же есть база багов? Правда?
    Громоздкая Джира не единственный вариант. Эксель тоже подойдёт! Если у вас есть общий зафиксированный список проблем, вы можете с ними работать и планировать их устранение.

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

    6. У вас есть план работ со сроками?
    План, который знают все и который связан с реальностью. Roadmap, этапы или просто дата, в которую надо запуститься.
    Работа ведёт себя как газ — занимает всё выделенное время. Ставьте сроки.

    7. У вас есть спецификация?
    Банально, но без ТЗ результат ХЗ. Сейчас не нужно писать исчерпывающее финальное тех задание — требования поменяются по ходу разработки. Достаточно написать концепцию, сделать прототипы, записать user story и опубликовать. Задачи тоже нужно записать и поставить в трекер.

    8. У разработчиков есть тихие рабочие места?
    Ваш разработчик всё ещё сидит в опенспейсе? Зря-зря. Скорее всего, он уже обзавёлся наушниками и пытается от вас отвернуться. Помогите ему создать изолированную среду.

    9. У разработчиков лучшая техника и инструменты?
    Быстрый комп, 2ой монитор, современный софт, быстрые серверы — стоят копейки относительно времени программиста. Планка памяти стоит как час работы разработчика. Ускоряйте их всеми доступными способами, это очень дёшево.

    10. У вас есть тестировщики?
    Если баги ищут только разработчики — значит, баги находят пользователи.
    Менеджеры и программисты проверяют, что код работает. Тестировщики проверяют, ищут где он не работает. У вас должен быть хотя бы 1 тестировщик в команде на нескольких разработчиков.

    11. Пишут ли кандидаты код на собеседовании?
    Это единственный пункт, с которым я сейчас не полностью согласен в его изначальной формулировке. Изучить код и мышление кандидата на собеседовании получится, а вот показать реальные навыки в стрессовой ситуации собеседования — вряд ли. Мой рецепт — выводить подходящих кандидатов на тестовую неделю и смотреть совместимость без давления в реальной обстановке.

    12. Вы делаете usability тесты на добровольцах?
    Соберите группу для тестирования. Первые 5 случайных пользователей укажут вам на 95% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.

    Если вы фаундер или руководитель и у вас есть ответы “Нет” — их точно стоит обсудить с командой.

  • По прошлому посту может показаться, что продукт был доведён до совершенства перед релизом

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

    Всё совсем наоборот!
    – В первой версии продукта не было монетизации
    – До сих пор нельзя зарегистрироваться (а нам 2 года)
    – Техническая SEO-оптимизация до сих пор не дожата другими SEO-работами
    – Не хватает десятка “очевидных” разделов и фич

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

    Если вам не стыдно за первую версию вашего продукта, вы запустились слишком поздно.
    – Рид Хоффман

    Я знаю, что за продукт я делаю и для кого. У нас свои приоритеты и Roadmap.
    Пусть кому-то будет стыдно за первую версию, но не нам. Если мы в одних трусах – это так задумано!