Frame 951.png

Всем привет, меня зовут Стас, я техлид в Mish Product Lab.

Тема возникла не просто так: внутри команды у нас было немало споров и дискуссий о том, какой инструмент для проксирования и терминации SSL лучше использовать в различных ситуациях. Изначально все наши гипотезы были основаны больше на личных предпочтениях, чем на реальных данных. Мы долго спорили, надеясь, что истина будет где-то рядом с нашими любимыми решениями. Но в итоге пришли к выводу, что единственный способ получить действительно объективный ответ — это протестировать и сравнить различные варианты на практике.

Проксирование из коробки: сравнительный анализ HAProxy, Envoy, Nginx, Caddy и Traefik

Дубич Станислав

инструкция по выживанию.png

Привет, я Стас Дубич, ведущий разработчик в продуктовой лаборатории Mish. До Mish я часто сталкивался с задачами вроде «там просто поменять кнопочку» или «ну ты же поймёшь». Спойлер: не понимал — и никто не понимает.
В Mish всё иначе: здесь ценят ясность и структуру, поэтому каждое ТЗ звучит чётко: что нужно, зачем и как это должно работать. Да, все эти формулировки — не самая весёлая часть процесса, но без этого всё ломается. Не только техника, но и нервы разрабов, а они как мы знаем не железные.

<h3>Это база</h3>
<p>У&nbsp;нас в&nbsp;Mish есть три главных правила, которые помогают облегчить жизнь и&nbsp;тому кто ставит задачу, и&nbsp;тому кто&nbsp;ее&nbsp;исполняет.</p>

<h5>Правило&nbsp;1: Все задачи&nbsp;&mdash; только письменно.</h5>
<p>Если задача живёт только в&nbsp;голове менеджера, она погибнет в&nbsp;бою. Любые договорённости должны быть зафиксированы&nbsp;&mdash; в&nbsp;Jira, Notion или другом трекере, а&nbsp;не&nbsp;в&nbsp;переписке &laquo;где-то в&nbsp;телеге&raquo;. Так меньше риска, что&nbsp;кто-то что-то забудет или неправильно поймёт.</p>
<p>Письменная фиксация&nbsp;&mdash; это не&nbsp;бюрократия, а&nbsp;страховка для всех: разработчиков, менеджеров и&nbsp;проекта.</p>

<img src="/uploads/vc_1_fc9cd43c33.png">

<h5>Правило&nbsp;2: Любое изменение фиксируется.</h5>
<p>Если в&nbsp;процессе работы меняется логика, дизайн или сроки&nbsp;&mdash; это не&nbsp;&laquo;подумаем потом&raquo;, а&nbsp;новая реальность, которую нужно записать. Важно отметить, что именно изменилось, почему и&nbsp;кто это согласовал.</p>
<p>Так команда понимает, что происходит, а&nbsp;не&nbsp;ловит сюрпризы на&nbsp;этапе тестирования.
Без фиксации изменений проект превращается в&nbsp;игру &laquo;сломанный телефон&raquo;, где каждый слышит своё.</p>

<img src="/uploads/vc_2_8b8f79e358.png">

<h5>Правило&nbsp;3: Есть шаблон, ему и&nbsp;следуем.</h5>
<p>Хаос начинается там, где каждый пишет задачи &laquo;по&nbsp;настроению&raquo;. Чтобы избежать путаницы, есть три простых вопроса, на&nbsp;которые нужно ответить:</p>
<ul>
  <li>Что нужно сделать?</li>
  <li>Почему это важно?</li>
  <li>Как это должно работать?</li>
</ul>

<p>Эти пункты помогают выстроить общий контекст и&nbsp;убрать догадки.
Если хотя&nbsp;бы один из&nbsp;ответов отсутствует, разработка превратится в&nbsp;гадание на&nbsp;макете&nbsp;&mdash; красиво, но&nbsp;непредсказуемо.</p>

<p>Эти пункты помогают выстроить общий контекст и&nbsp;убрать догадки.
Если хотя&nbsp;бы один из&nbsp;ответов отсутствует, разработка превратится в&nbsp;гадание на&nbsp;макете&nbsp;&mdash; красиво, но&nbsp;непредсказуемо.</p>

<blockquote>
Разработчики, если хотя&nbsp;бы один пункт непонятен&nbsp;&mdash; возвращаем задачу автору.
Не&nbsp;на&nbsp;ревью, а&nbsp;на&nbsp;доформулировку.
</blockquote>

<p>Нет времени на&nbsp;выстраивание процессов? <a href="https://mish.design/brief">Пишите нам</a>, Mish найдет подход к&nbsp;любой проблеме.</p>

<h3>Что должно быть в&nbsp;задаче перед стартом</h3>
<p>Прежде чем задача попадёт к&nbsp;разработчику, она должна быть полностью собрана&nbsp;&mdash; без пустых полей и&nbsp;магических &laquo;само поймётся&raquo;.</p>

<img src="/uploads/vc_3_9ae4d8d815.png">

<p>Хорошая подготовка экономит часы, а&nbsp;иногда и&nbsp;нервы всей команде.
Вот базовый чеклист, что нужно проверить перед тем, как нажать &laquo;в&nbsp;работу&raquo;.</p>
<ul>
  <li>Полное описание бизнес-требований.</li>
  <li>Список зависимостей (что должно быть готово, чтобы задачу можно было начать).</li>
  <li>Примеры и тест-кейсы, хотя бы базовые.</li>
</ul>

<h3>Разбор полётов</h3>
<p>Хорошая задача&nbsp;&mdash; как командная игра: каждый знает свою роль и&nbsp;не&nbsp;лезет в&nbsp;зону другого. Когда ответственность распределена чётко, проект движется быстрее, а&nbsp;споры &laquo;а&nbsp;кто это должен был сделать?&raquo; исчезают сами собой.</p>

<img src="/uploads/vc_4_baf463a19e.png">

<p>Разберём, кто за что отвечает:</p>
<ul>
  <li>Автор задачи&nbsp;&mdash; менеджер или аналитик. Формулирует &laquo;что&raquo; и&nbsp;&laquo;зачем&raquo;. Именно от&nbsp;него зависит, насколько понятен контекст и&nbsp;цель.
</li>
  <li>Эксперт&nbsp;&mdash; техлид или архитектор. Отвечает за&nbsp;&laquo;как&raquo;, выбирает подход, инструменты и&nbsp;архитектуру, чтобы задача решалась не&nbsp;только быстро, но&nbsp;и&nbsp;правильно</li>
  <li>Исполнитель&nbsp;&mdash; разработчик, тестировщик или любой, кто делает задачу руками. Он&nbsp;реализует решение, уточняет детали и&nbsp;даёт обратную связь, если требования противоречат реальности.</li>
  <li>Проверяющий&nbsp;&mdash; человек, который валидирует задачу перед запуском. Проверяет, всё&nbsp;ли ок&nbsp;по&nbsp;данным, срокам и&nbsp;зависимостям.</li>
</ul>

<h3>Что и у кого просить</h3>
<p>Чтобы задача получилась чёткой, нужно не&nbsp;просто &laquo;поставить&nbsp;её&raquo;, а&nbsp;собрать нужные данные от&nbsp;всех участников процесса. Мы&nbsp;уже разобрались с&nbsp;тем кто за&nbsp;что отвечает, теперь давайте определимся с&nbsp;вопросами, которые нужно задать.</p>

<h5>Вопросы к&nbsp;менеджеру, они про контекст и&nbsp;приоритеты:</h5>
</p>
<ul>
  <li>Что конкретно нужно сделать и зачем?</li>
  <li>Какой результат по&nbsp;бизнесу, метрикам или пользовательскому опыту считаем успешным?</li>
  <li>Есть&nbsp;ли у&nbsp;задачи дедлайн и&nbsp;кто его поставил?</li>
  <li>Какой у&nbsp;задачи приоритет по&nbsp;сравнению с&nbsp;остальными?</li>
  <li>Какие риски вы&nbsp;видите? Что может пойти не&nbsp;по&nbsp;плану?</li>
</ul>
</p>

<h5>Вопросы к&nbsp;аналитику, они про данные и&nbsp;логику:</h5></p>
<ul>
  <li>Какие входные и&nbsp;выходные данные участвуют в&nbsp;задаче?</li>
  <li>Есть&nbsp;ли примеры, чтобы проверить реализацию?</li>
  <li>Какие зависимости у&nbsp;задачи&nbsp;&mdash; от&nbsp;других модулей, сервисов или внешних команд?</li>
</ul>
</p>

<h5>Вопросы к&nbsp;эксперту, они про реализацию:</h5>
</p>
<ul>
  <li>Какой подход или архитектурное решение лучше использовать в&nbsp;этом случае?</li>
  <li>Есть&nbsp;ли готовые компоненты, которые можно переиспользовать?</li>
  <li>Что может стать узким местом?</li>
  <li>Какие требования нужно уточнить до&nbsp;начала, чтобы потом не&nbsp;переделывать?</li>
</ul>

<blockquote>
Главное&nbsp;&mdash; не&nbsp;стесняться спрашивать и&nbsp;требовать. Это не&nbsp;придирчивость, а&nbsp;профессиональная гигиена.
</blockquote>

<h3>Если не&nbsp;описать задачу, она напишет себя сама (и вам не понравится)</h3>
<p>Можно, конечно, махнуть рукой и&nbsp;подумать: &laquo;да&nbsp;ладно, как-нибудь разберёмся&raquo;.
Только потом это &laquo;как-нибудь&raquo; превращается в&nbsp;серию пожаров, бессонных ночей и&nbsp;коллективный сеанс гадания на&nbsp;требованиях.</p>

<img src="/uploads/vc_5_a76221bba6.png">

<p><b>Качество падает.</b></p>
<p>Код превращается в&nbsp;лоскутное одеяло: каждый шил как понял, никто не&nbsp;знает, где начало, а&nbsp;где конец. Финальный продукт вроде работает, но&nbsp;не&nbsp;так, как задумывали.</p>

<p><b>Сроки утекают.</b></p>
<p>Сначала теряется пара дней на&nbsp;уточнения, потом неделя на&nbsp;переделки, а&nbsp;в&nbsp;какой-то момент проект живёт по&nbsp;календарю майя&nbsp;&mdash; конец света каждый спринт.</p>

<p><b>Команда выгорает.</b></p>
<p>Постоянные авралы, бессмысленные переделки и&nbsp;отсутствие ясности бьют не&nbsp;только по&nbsp;дедлайнам, но&nbsp;и&nbsp;по&nbsp;психике. Тут могла&nbsp;бы быть реклама всем известного сервиса, но&nbsp;увы и&nbsp;ах.</p>

<p>Когда всё рушится, кажется, что спасёт только одно волшебное слово&nbsp;&mdash; &laquo;срочно&raquo;.
И&nbsp;именно с&nbsp;этого момента начинается настоящий конец проекта.</p>

<h3>Срочно&nbsp;&mdash; любимое слово хаоса</h3>
<p>Если всё &laquo;срочно&raquo;, перестаёт быть срочным хоть что-нибудь.
Команда работает в&nbsp;режиме тушения пожаров, код превращается в&nbsp;костыли, приоритеты&nbsp;&mdash; в&nbsp;мем.</p>

<img src="/uploads/vc_6_3d36a0f1a9.png">

<p>Что происходит дальше? А&nbsp;всё просто. Код начинает сыпаться, потому что его писали в&nbsp;спешке, &laquo;на&nbsp;коленке&raquo; и&nbsp;без времени на&nbsp;рефакторинг. Дедлайны, конечно, сдвигаются потому что, когда горит всё, невозможно закончить ничего. Доверие к&nbsp;менеджерам постепенно тает: команда перестаёт верить, что приоритеты хоть&nbsp; что-то значат. И&nbsp;в&nbsp;какой-то момент люди просто уходят&nbsp;&mdash; не&nbsp;потому что не&nbsp;любят проект, а&nbsp;потому что устали жить в&nbsp;режиме постоянного &laquo;срочно&raquo;.</p>

<h3>Проекты не&nbsp;рушатся, их&nbsp;просто плохо описывают</h3>
<p>Хорошая задача это не&nbsp;стена текста, а&nbsp;понятная инструкция к&nbsp;действию.
Если её&nbsp;может прочитать любой разработчик и&nbsp;понять, что делать, зачем и&nbsp;как проверить результат&nbsp;&mdash; значит, всё&nbsp;ок.</p>

<p>А&nbsp;если нет&nbsp;&mdash; возвращаемся в&nbsp;начало и&nbsp;переписываем. Потому что лучше потратить час на&nbsp;формулировку, чем&nbsp;неделю на&nbsp;спасение прода.</p>

<p>В&nbsp;Mish мы&nbsp;умеем не&nbsp;только ставить задачи правильно, но&nbsp;и&nbsp;исполнять их&nbsp;так, чтобы всё работало, летало и&nbsp;радовало. В&nbsp;наших руках проект не&nbsp;просто продолжает существовать&nbsp;&mdash; он&nbsp;развивается.</p>

<p>Поэтому, если хочется, чтобы задачи выполнялись не&nbsp;&laquo;как-нибудь&raquo;, а&nbsp;&laquo;как надо&raquo;&nbsp;&mdash; мы&nbsp;знаем, как это сделать. Хотите убедиться? <a href="https://mish.design/brief">Заполните бриф</a> и&nbsp;вместе превратим ваши желания в&nbsp;чётко спланированные и&nbsp;работающие проекты.</p>

Дубич Станислав

Бриф сам себя не заполнит

hello@mish.design

Москва

Нижний Новгород