
Вы выбрали Mish. Что дальше?
Вы только написали нам, а в голове уже крутятся вопросы: подойдём ли мы друг другу, как будет устроена работа, кто за что отвечает и что вообще происходит после первого «привет».
Рассказываем
Мы за честные отношения с самого начала, поэтому не делаем из процессов огромную тайну. Наоборот, нам кажется полезным показать подход, который сформировался у нас за 8 лет работы. Мы давно внутри рынка и хорошо понимаем, как устроены сильные процессы и за счёт чего получается хороший результат. Не случайно Mish из года в год занимает лидирующие позиции в «Рейтинге Рунета» и забираем золото в различных премиях, например «Tagline Awards», Золотой Сайт и «Workspace Digital Awards».
В Mish проект не летит в работу сразу после первого созвона. Сначала мы собираем задачу, синхронизируем ожидания, определяем рамку проекта, а уже потом переходим к исполнению.
Если совсем коротко, работа над проектом проходит через 7 этапов:
- Первый контакт
- Пред-предпроектная работа
- Запуск
- Концепция
- Основная фаза
- Разработка
- Финал
Очерёдность понятна, но за этими шестью этапами скрывается большая работа.
Шаг первый. Первый контакт
Каждый проект в Mish начинается по-разному.
Кто-то приходит с конкретным запросом на сайт, интерфейс, исследование, бренд или только разработку. Кто-то — с тендером. А кто-то — с ощущением, что бизнесу нужно меняться, но пока непонятно, с чего начинать.
Первым в работу включается аккаунт-менеджер. Он проводит первый созвон и собирает все вводные (цели, сроки, ограничения, критерии успеха и т.д.).
Если вы сами еще не знаете чего хотите от этого проекта, тогда уже на первой встрече подключается команда: продюсер, арт-директор, аналитик или технический руководитель. Чтобы оформить какое-то общее желание в более структурированный запрос.
Шаг второй. Пред-предпроектная работа, сверяем ожидания и бюджет
После первого контакта начинается пред-предпроектная работа. Да, звучит как уровень до уровня, но по сути так и есть.
На этом этапе мы разбираемся, что нужно сделать, зачем это бизнесу и в каких границах будет жить проект.
Аккаунт-менеджер фиксирует запрос и ведёт коммуникацию с клиентом. Дизайн, аналитики, арт-директора и разработка помогают оценить объём работ, риски, сроки и нужный состав команды. Здесь же формируется общее видение задачи: что делаем, за что отвечаем, какой результат считаем хорошим.
Именно на этом этапе решаются все вопросы про деньги. Мы определяем стоимость, формат оплаты и условия, которые потом попадут в коммерческое предложение. При этом всегда детально обсуждаем финансовую часть с клиентом и готовы рассмотреть разные варианты оплаты.
Иногда наше КП может выглядеть дороже предложения другой студии. А потом открываешь их «выгодное» КП и видишь, что там забыли аналитику, адаптивы, тестирование, менеджмент, подготовку к разработке или ещё пару этапов.
Мы так не делаем. Если понимаем, что чего-то нет в ТЗ, но проекту это понадобится, говорим об этом на старте. Лучше честно обсудить объём до начала работ, чем потом каждые две недели говорить, что нужна ещё доплата, а потом ещё.
Шаг третий. Запуск
После согласования коммерческого предложения начинается формальный запуск.
В Mish работа не стартует, пока не собраны документы и не согласованы финансовые условия. Нет, мы не фанаты бюрократии. Мы просто верим, что любому проекту нужен сначала нормальный фундамент, обе стороны должны чётко понимать роли, сроки и правила игры.
Аккаунт-менеджер организует подписание договора и всех необходимых документов. После этого назначается менеджер проекта и формируется рабочая команда. Проходит внутренняя стартовая встреча, где команда синхронизируется по целям, ролям, календарному плану, рискам и приоритетам.
Начиная с этого момента главным связующим звеном становится менеджер проекта. Он организует все созвоны и собирает статусы, отвечает за ритм работы, сроки, ресурсы, приёмку, коммуникацию и последовательность этапов.
Менеджер создаёт рабочие чаты проекта:
- внутренний для команды,
- внешний для клиента.
Дальше всё зависит от сложности проекта. Где-то команде хватает коротких синков, где-то нужны еженедельные встречи и статусные созвоны. Все материалы сохраняются во внутренней базе знаний, встречи записываются, а итоги фиксируются письменно.
Здесь важно не количество встреч, а их смысл. Хорошо выстроенные процессы помогают нам фокусироваться на задаче. По данным исследования Контур.Толк, 45% респондентов считают, что из-за неэффективных бесконечных созвонов бизнес теряет деньги.
Шаг четвёртый. Первое свидание с концепцией
Когда всё согласовано, команда переходит к разработке концепции.
Если вся работа над проектом строится по принципу от общего к частному, то работа над концепцией строится иначе: от содержания к самой точной форме этого содержания. Именно для этого мы и проводим предпроектное исследование, без него легко сделать красиво, но мимо.
Разрабатывая концепцию, мы можем проверить разные направления, поспорить, пересобрать решение и ещё раз всё перепроверить. Но вам мы всегда показываем одно решение.
Кому-то такой подход может показаться не клиентоориентированным, но наша логика здесь проста. Задача Mish — не переложить на клиента груз ответственности за выбор точного решения, а перебрать все варианты внутри, отсеять слабое и принести то, за что мы готовы отвечать.
Концепция — это не набросок. Это основа всего проекта. Его вертикальный срез.
Она сразу показывает, каким будет решение и как оно будет жить дальше. Это как демо-версия всего проекта, пилотный эпизод сериала, тизер фильма или демо-версия игры. Взлетит или нет, о том или не о том, насколько точно всё сделано, на показе концепции это сразу видно. Мы презентуем не только форму, но и логику.
После этого менеджер проекта собирает обратную связь и фиксирует договорённости.
Цель этапа — согласовать базу, которую команда будет масштабировать дальше. Всё важное фиксируется письменно, чтобы проект сохранял единую логику, а новые пожелания не растворялись в переписке.
Шаг пятый. Основная фаза
После утверждения концепции начинается основная рабочая фаза.
Идея превращается в полноценную систему, в зависимости от потребностей проекта появляются экраны, сценарии, тексты, визуальные элементы, носители, компоненты и другие артефакты.
На этом этапе концепция становится рабочим результатом, который можно передавать, внедрять, тестировать и развивать.
- Менеджер проекта держит процесс, сроки и точки согласования.
- Арт-директор следит за качеством и за тем, чтобы результат не уехал от концепции.
- Команда проектирует, пишет, рисует, исследует, разрабатывает, проверяет и доводит всё до нужного состояния.
Если проект объёмный, работа идёт поэтапно: с внутренними проверками, промежуточными синхронизациями и согласованиями с клиентом. Так команда вовремя замечает спорные места и сохраняет темп.
Шаг шестой. Разработка
Разработка в Mish — не бонус к дизайну, а полноценное направление работы. Иногда она идёт вместе с дизайном, а может и быть ядром проекта, например разработка сайта, сервиса, личного кабинета, внутренней системы, мобильного приложения или сложной интеграции.
Мы используем гибкие методологии разработки, поэтому клиент регулярно видит промежуточные результаты. В проект с самого начала вовлечены специалисты разных направлений: разработчики помогают продумать архитектуру, интеграции и техническую реализацию, QA-инженеры готовят тест-кейсы ещё на этапе аналитики, а DevOps настраивают процессы сборки и релизов.
В чисто разработческих проектах мы начинаем с погружения в задачу, требования, текущую систему и ограничения.
Дальше работа идёт в зависимости от задачи, она может строиться последовательно, параллельно или короткими циклами. За нами остаются приёмка, тестирование, передача готовых блоков и контроль качества.
Шаг седьмой. Остаёмся друзьями
Формат финальной передачи результата мы согласуем заранее и фиксируем в документах. Это может быть Figma, код, утверждённые материалы, внедрённый функционал или другой набор артефактов. Всё зависит от проекта и состава работ.
На финале мы не отправляем ссылку и исчезаем в закате. Аккаунт и менеджер проекта помогают пройти согласования, передать результаты, закрыть документы и убедиться, что у вас есть всё нужное для дальнейшей работы.
Дальше проект может завершиться, перейти в поддержку, следующий этап или новую задачу. После финала мы разбираем итоги внутри команды и, если нужно, вместе с клиентом: что сработало, что можно улучшить и что добавить.
Что в итоге вы получаете?
В итоге клиент получает понятный и управляемый проектный путь с ясной логикой, прозрачными этапами, закреплённой ответственностью и предсказуемым результатом.
Именно в этом для нас ценность сильного процесса. Он помогает не терять суть задачи по дороге, вовремя принимать решения, держать качество и в итоге приходить к результату, который можно внедрять, использовать и развивать дальше.
Если вам близок такой подход, приходите в Mish. Мы любим проекты, где важно сначала разобраться, потом собрать и довести результат до финала.
Ещё статьи
Предыдущая статья
Как мы решили проблему хаотичной структуры проекта с Pug и Vite
Привет, я Андрей Беннер, фронтенд-разработчик в Mish. Сейчас я расскажу вам о нашем опыте в оптимизации хаотичных процессов с помощью собственных разработок. Если вы когда-либо работали с проектами на стеке Vite + Pug + SCSS + TypeScript, то наверняка сталкивались с хаосом в файловой структуре и рутиной, мешающей сосредоточиться на главном — решении задач бизнеса и создании удобного интерфейса для пользователя. В этом материале мы поделимся тем, как столкнувшись с проблемой, создали решение, которое сделало процесс разработки более эффективным, а структуру проекта — интуитивно понятной. А ещё расскажем, как это решение родилось внутри команды и стало частью нашего вклада в open source.

Следующая статья
Как мы решили проблему хаотичной структуры проекта с Pug и Vite
Привет, я Андрей Беннер, фронтенд-разработчик в Mish. Сейчас я расскажу вам о нашем опыте в оптимизации хаотичных процессов с помощью собственных разработок. Если вы когда-либо работали с проектами на стеке Vite + Pug + SCSS + TypeScript, то наверняка сталкивались с хаосом в файловой структуре и рутиной, мешающей сосредоточиться на главном — решении задач бизнеса и создании удобного интерфейса для пользователя. В этом материале мы поделимся тем, как столкнувшись с проблемой, создали решение, которое сделало процесс разработки более эффективным, а структуру проекта — интуитивно понятной. А ещё расскажем, как это решение родилось внутри команды и стало частью нашего вклада в open source.

