Pull to refresh
Хабр Карьера
Помогаем строить карьеру в IT

Где работать в ИТ в 2022: Flowwow

Reading time15 min
Views7.3K

Наша рубрика «Где работать в ИТ» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Представители индустрии отвечают на вопросы о найме, условиях, командах и технологиях. 

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

А ещё в выпусках мы рассказываем об оценках компаний на Хабр Карьере, чтобы вы были в курсе, за что их любят (или нет?) сотрудники. Кстати, если вы тоже оцените своего работодателя, то это поможет тем, кто ищет работу в ИТ.

оценить работодателя


Кто отвечал на вопросы

Обо всех процессах в Flowwow нам подробно рассказали:

Дмитрий Шестернин

CTO

Оксана Клементьева

HR-директор

Андрей Боярчук

Тимлид команды курьеров

Виталий Перятин

Тимлид команды Android

Павел Кузьмин

Тимлид команды iOS

Иван Могилат

Тимлид команды бэкенда

Артем Гамбицкий

Тимлид команды фронтенда, сооснователь компании


О компании

Flowwow — онлайн-платформа для продавцов и покупателей, на которой собрано более 6000 магазинов из 950 городов мира. Магазины размещают на Flowwow товары из разных категорий: цветы, кондитерские изделия, игрушки, украшения, продукты и многое другое. С 2020 года компания является резидентом «Сколково». А еще вы могли слышать про нее от друзей и блогеров. 

Публичная оценка компании на Хабр Карьере в 2021 году — 4,77 из пяти. Сотрудники особенно ценят Flowwow за интересные задачи, связь с топ-менеджментом, отношения с коллегами, профессиональный рост, а также за то, что компания делает мир лучше. Увидеть оценку в деталях и почитать комменты сотрудников можно в профиле Flowwow на Хабр Карьере.

Оценка компании в 2021 году на Хабр Карьере
Оценка компании в 2021 году на Хабр Карьере

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

Об условиях работы

Какой рабочий график сложился в вашей компании  и какое отношение к переработкам?

Дмитрий Шестернин: Наша компания изначально строилась как удаленная и «международная». Мы работаем из разных городов и стран, живем в разных часовых поясах, поэтому каждый сотрудник разработки сам организует свой рабочий график. Свои часы работы анонсируем в личной карточке в Slack: так все знают, когда кого можно застать за работой.  

Желательно всем быть на связи с 9.00 до 16.00 по московскому времени: это «командное» время, когда у нас возникает больше всего оперативных вопросов, бывает, нужно созвониться и что-то быстро решить.  

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

Тогда как ведется контроль? Очень просто: если какое-то время ваши задачи лежат без положительной динамики, «тогда мы идем к вам» — спросить, как дела, в чем затык, и что мешает показать результат. 

Наш главный инструмент контроля — ежедневный план. В начале рабочего дня проводим получасовой дейли-митинг, после чего каждый пишет в канал, что планирует делать. В середине рабочего дня пишем, как успехи и куда продвинулись. Этого достаточно для того, чтобы координировать действия команды!

О переработках

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

К счастью, в нашем бизнесе есть предсказуемый и понятный график сезонных пиков. На мобильную разработку основная предпраздничная нагрузка ложится за 2-3 недели до пикового дня (14 февраля, 8 марта, день Матери в конце ноября). Для бэкендеров, фронта, админки и девопс — максимальная нагрузка приходится на сами праздники. За 7 лет работы мы научились готовиться к пиковым дням и распределять нагрузку, чтобы пики были максимально безболезненными.  

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

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

Какие бытовые условия ждут нового сотрудника на рабочем месте?

Оксана: Офис располагается в Москве, ровно в 1 минуте от метро Сухаревская. Здесь светло, уютно, самый громкий сотрудник — кофемашина. Летом открыт выход на веранду. Каждый день там можно встретить сотрудников бухгалтерии и команду клиентского саппорта, часто операционного директора и двух из трех сооснователей компании. Остальные сотрудники команды работают удаленно. 

Если вы решите работать в офисе, мы подготовим вам рабочее место ко дню выхода: обсудим вместе с вами, какая вам нужна техника, все закупим и подключим. Если выходите работать с завтрашнего дня — дадим технику, которая есть в активе, и за 2-3 дня подготовим рабочее место по вашему запросу. 

Еще о технике! Как правило, наши сотрудники предпочитают работать на своей привычной технике, но спустя 6 месяцев работы в Flowwow могут обновить ее по собственному желанию (выбираете все, что вам нужно) и получить от нас компенсацию в 50 тысяч рублей. Техника при этом остается вашей собственностью. Компенсируем по необходимости, как правило — один раз в три года. 

Нам неважно, на чем вы работаете, если ваша техника тянет наш стек.

Есть ли возможность удаленной работы?

Дмитрий: С 2015 года вся команда разработки Flowwow работает удаленно: сейчас это 30+ человек из разных городов России и других стран.

Какой социальный пакет получают сотрудники?

Оксана: ДМС. Каждому сотруднику после прохождения испытательного срока мы оформляем полис ДМС («Альфастрахование»). Полис включает амбулаторное, экстренное и плановое стационарное лечение, неотложную и скорую помощь, услуги стоматолога. Бонусы: 

  • Возможность раз в год пройти чек-ап здоровья без наличия страхового случая;

  • Полис страхования жизни и здоровья при поездке за рубеж. 

Корпоративная скидка на Flowwow. Составляет 15%, она бессрочная, действует на весь ассортимент магазинов, входящих в программу лояльности WowPass (более 2000 магазинов в 950 городах России). 

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

Праздники. 3-4 раза в году (на 8 марта, день Матери и т.д.) сотрудники получают от фирмы промокоды на фиксированную сумму — чтобы заказать подарки себе или близким.

Какие бонусы, премии и компенсации предусмотрены в компании?

Оксана Клементьева: Чтобы закрыть формальности: у нас все строго по ТК. Белая зарплата, ежегодная индексация, оплачиваемые отпуска, больничные. Есть еще 10 дней в году, которые вы можете поболеть, не открывая больничный: используются в случае, когда понятно, что нужно просто отлежаться день-два для того, чтобы быть снова в строю.

Ежегодная премия — выплачивается команде вместе с мартовской зарплатой, ее размер определяется руководителями подразделений. 

Оплата командировок. Мы поддерживаем желание съездить на важную отраслевую конференцию. Само собой, компенсируем дорогу, билет, проживание, если вы готовите доклад — поможем написать речь и сделать красивую презентацию. После мероприятия ждем, что сотрудник расскажет, что было интересного, и как мы можем это применить в работе. 

Регулярный пересмотр размера заработной платы. Нам хватает «бирюзовости», чтобы видеть и ценить успехи каждого сотрудника. В 2021 году пересматривали зарплаты 2-3 раза в год; в результате вырос заработок у всех сотрудников. 

Благодарности. У нас есть добрая традиция: в конце каждого месяца каждый сотрудник выбирает одного коллегу, который ему очень помог или с которым они круто поработали в этом месяце, и оставляет ему благодарность. За каждую благодарность в свой адрес ребята получают по 3000 рублей от компании. Максимальное количество благодарностей, полученных одним человеком за месяц — 7. Но ограничений здесь нет.

Какие есть перспективы для образования и личного развития у сотрудников?

Дмитрий: Как правило, сотрудник сам понимает, что у него есть какие-то «слепые пятна» или неосвоенные скиллы, или ему нужно прокачиваться в связи с ростом и расширением круга обязанностей. Тогда он приходит к своему руководителю, ко мне или напрямую к Оксане — либо с созревшим пониманием того, что ему нужно изучить, либо просто с запросом на обучение. 

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

Оксана: Иногда мы предлагаем сотруднику равноценную альтернативу курсу, который он выбрал, а порой и более интересный вариант. Затем оплачиваем 100% стоимости обучения. Возможны ситуации, когда мы сами рекомендуем сотруднику пройти какой-нибудь хороший курс — и здесь решение остается за ним.  

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

С середины 2021 года практикуем развитие команды разработки через привлечение внешних консультантов. Начали строить новую вертикаль — пригласили экспертов на аутсорсе, что позволило прокачать всю команду, а отличившимся повысили ЗП.

О найме

Во сколько этапов проходит наём и что на них ожидает соискателя?

Дмитрий: В 2021 году мы почти полностью перешли на формат One-day offer: по итогам отбора резюме проводим единственное собеседование. Оно совмещает в себе и техническое, и мотивационное интервью. С нашей стороны участвуют IT-рекрутер, технический специалист и тимлид, который выбирает человека к себе в команду. 

Собеседование длится в среднем 60 минут. Если кандидат нам нравится, мы запрашиваем фрагмент боевого кода и в тот же день делаем оффер. 

На собеседовании мы в равной степени презентуем продукт, компанию и команду. Рассказываем, как и чем собираемся мотивировать сотрудника. Со своей стороны, обязательно спросим о том, чего человек ждет от работы. Тем, кто говорит о жажде развития, задаем уточняющий вопрос: что было с развитием на предыдущем месте работы? Очень ценим, если кандидат честно расскажет, что побудило его уйти с предыдущего места работы.

Даете ли вы тестовое задание кандидатам? Как оно устроено?

Дмитрий: Тестовых не даем, но просим показать примеры кода, с которым человек работал в последнее время. Мы уважаем NDA, но еще больше нам нравится, когда человек блюрит то, что показывать нельзя, меняет переменные, названия классов — и все равно находит возможность познакомить нас со своим боевым кодом. А вот код из тестовых заданий мы не очень любим: 2-3 странички боевого кода, пусть не такого красивого, но живого, скажут о вас гораздо больше.

Как отличается подход к найму в зависимости от позиции и стека?

Оксана: Подход един для всех. Единственный нюанс: если беседуем с соискателем на руководящую должность (тимлид, сеньор), обязательно спросим об опыте управления командой в отрасли, может быть, обсудим вместе пару кейсов, посмотрим, как кандидат мыслит и как решает задачи. 

Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

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

В этих случаях мы откажем соискателю.

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

Кого последнего вы уволили и почему?

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

Как происходит онбординг нового сотрудника?

Оксана: Во-первых, каждый сотрудник Flowwow в первый момент работы у нас получает подробный велкам-бук: в нем все о наших правилах, традициях, экскурсия по нашим ценностям, приветственный промокод на заказ, контакты самых нужных людей и даже правила эффективного общения в SLACK — в общем, все что нужно. 

Для разработчиков у нас есть еще один емкий и короткий документ, в котором четко написано, что в какой последовательности включить, куда зайти и как начать работать. Уже в первый день разработчик может показать, на что он способен (но мы настаиваем, чтобы в первый день он осмотрелся, прочитал мануал и вник в продукт). 

Каждый новичок в команде разработки закрепляется за одним из тимлидов, который помогает ему быстро погрузиться в проект и начать продуктивно работать. Также за состоянием новых сотрудников следят эйчары компании, в этом нам помогает взаимодействие с новичком и статистика slack. Согласно внутреннему опросу, у 70% сотрудников онбординг занимает около месяца, а некоторые отмечают, что «как будто работали здесь всю жизнь».

О команде

Какая методология разработки у вас используется и почему?

Дмитрий: У нас нет скрама или ватерфола в классическом виде, так как ключевая метрика нашей эффективности — time to market. Под эту метрику и адаптирован весь процесс разработки. 

У нас темпераментная, скоростная разработка: можем выкатывать микрорелизы по 20-30 раз в день. Главный риск при таком темпе — ошибки, поэтому у нас жестко выстроены процессы автоматизации деплоев, сбора ошибок и код ревью. Это позволяет контролировать число багов на разумном уровне. 

А вот безошибочная, гладкая работа нас скорее насторожит: мы считаем, что если мы мало ошибаемся, значит, слишком медленно развиваемся. Такой методологии придерживаемся везде, кроме мобильной разработки: там действует адаптированный скрам. Есть спринты, релизы и другие атрибуты гибкой методологии.

Каковы размеры и структуры команд?

Дмитрий: Вся команда разработки — это 30 человек. Команды прямо сейчас активно формируются: до 2021 года мы справлялись как единое целое, но сейчас оно естественным образом распалось на структурные элементы: 

  • iOS,

  • Android,

  • Фронтэнд, 

  • Админка,

  • Несколько команд на бэкенде: API, команда нагрузок и т.д. 

Каждая команда — не больше 4-х человек, включая тимлида. Все тимлиды у нас «играющие»: участвуют в написании кода и инициируют основные изменения.

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

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

Оксана: Мы редко берем на работу джунов — только в том случае, если нам вдруг нужен человек под постоянный поток мелких коротких задач (например, верстка имейлов). В остальных случаях предпочитаем брать мидл специалистов.

Кто чаще возглавляет команды — продуктовый специалист или технический?

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

При этом практически все наши сотрудники шарят в технике (в ДНК мы IT-компания!) — это базовое требование. Например, все, кто хоть чуть-чуть работает с данными, обучены sql, сами себе делают выгрузки и не приходят к разработке с такими задачами.

Как часто люди меняют команды?

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

Что важнее, софт-скиллы или хард-скиллы?

Дмитрий: Я бы отдал 45% хард-скиллам и 55% софт-скиллам — учитывая, что мы удаленная команда и каждый должен быть себе хорошим менеджером. Организовать рабочий процесс, наладить коммуникацию с командой, спланировать свой день. Бывало, мы отказывали очень крутым специалистам с низким уровнем коммуникативного навыка. 

С другой стороны, у ребят с высоким уровнем софт скиллс харды, как правило, тоже бывают на хорошем уровне. Поэтому хардам отдаем не менее 45%.

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Дмитрий:

  • Дейли митинг на 30 минут в начале каждого рабочего дня (время выбираем удобное для всех, смотря по часовым поясам);

  • Обязательный созвон по девопс делам раз в 2 недели: обзор нововведений по серверной схеме, разработчики задают вопросы девопсу и обозначают приоритеты;

  • Тимлидский созвон с CTO раз в неделю: обсуждаем управленческие и административные вопросы. 

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

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

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

Как вы боретесь с выгоранием сотрудников?

Оксана: Во-первых, наша корпоративная культура отвечает всем требованиям work-life balance. Мы даем людям возможность отдыхать, самоорганизовываться, брать паузы — это уже важная часть профилактики выгорания. 

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

 Дмитрий: С командой разработки все еще проще: на горизонте двух недель по результатам работы вдруг становится ясно, что человек немного (или много) перегрелся. Растет число багов, больше возвратов от тестировщиков… Первое, что я делаю, это предлагаю взять неделю отпуска. Почти всегда это работает. За последние 2 года минимум четверых сотрудников я отправлял в такой вот профилактический отпуск — и один из них был я сам. Просто понял, что начал косячить, и ушел на перезагрузку.

О технологиях

Какие языки, фреймворки и библиотеки используются на проекте? Что вы можете рассказать об архитектуре проектов?

Андрей Боярчук, тимлид команды курьеров: Используем бэк-стек php8, серверный стек yii2, mysql, rabbitmq, redis, graphhopper, supervisor, docker. Представление на js, vue. Приложение kotlin. Из yii2 mvc, rest, patterns, corecept, swagger, github ci/cd.

Виталий Перятин, тимлид команды Android: Наш язык — Kotlin. Библиотеки — GSON, Retrofit, Glide, Firebase, Kotlinx Coroutines, Koin.

В Android используется архитектура MVVM на базе ViewModel от Google и корутин + флоу от команды Kotlin. Благодаря гибким возможностям флоу получается отправлять данные и подписываться на данные из View без лишних костылей. А с ViewModel от Google легко обрабатываем все корнер-кейсы от Android по смене конфигурации и сохранению данных.

Павел Кузьмин, тимлид команды iOS: Используем язык swift. Из фреймворков у нас Moya, netfox, Swinject, Firebase, GoogleMaps, SwiftLint, Periphery, а также другие для локальных потребностей: DeviceKit, Agrume, Shimmer, FaveButton, lottie-ios. Всё подключено через CocoaPods.

Что касается архитектуры, мы используем MVVM+Coordinator паттерн и для удобства бьём всё на модули.

Иван Могилат, тимлид команды бэкенда: Проект написан на PHP (7.4, прямо сейчас мигрируем на 8.0). Основная база данных — Mysql8. Также используем RabbitMq, Redis, Clickhouse, Firebase. 

Мы выросли из стартапа, у нас никогда не было возможности переписать все заново, поэтому проект сменил несколько фреймворков. На основном проекте — модифицированный под современные требования Yii1, на сайд-проектах — Yii2. Стараемся писать независимый от фреймворка код, чтобы в дальнейшем миграция давалась легче. 

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

Инфраструктура построена на Amazon, она хорошо масштабируется (а нам это важно — с ростом нагрузки х30 во время пиков). Используем master-slave репликацию Mysql, кластер RabbitMQ, группы серверов под различные траффики с балансировщиками. После праздничных дней легко уменьшить количество и размеры серверов и экономить значительные суммы.

Артем Гамбицкий, тимлид команды фронтенда, сооснователь компании: Фронтенд на текущем этапе развития использует Vue.js с Nuxt, покрытые TypeScript'ом, и сдобренные Cypress-тестами.

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

Какая у вас принята политика код-ревью?

Дмитрий: Главное золотое правило — непроверенный код не уезжает в продакшн (см. пункт про разумное количество ошибок). Даже если внутренний заказчик сучит ногами. 

Мы используем статистические анализаторы кода (на бэке это Phan). 

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

Как тестируется код?

Дмитрий: У нас принята трехзвенная  система: есть микро-окружение разработчика (тестируем на своих локальных машинах), окружение девелоперское (дев-сайт, дев сборки приложений) и последний рубеж —  продакшн (тестируем и фиксим максимально оперативно).  

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

Как устроен процесс документации и ведения базы знаний на проектах?

Дмитрий: Документация тоже ведется на трех уровнях: 

1. Комментарии прямо в коде;

2.  Уровень в конфлюенс (Jira): здесь прописываем уже на нативном языке, как устроен тот или иной модуль, функционал, сервис и т.д;

3. Уровень бизнес-документации. ТЗ ставится через написание этой документации — в фигме.

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Дмитрий: Мы — компания почти с 8-летней историей и бурным темпераментом: естественно, легаси-кода у нас достаточно. Адекватно относимся к рефакторингу: у нас собственный продукт и кодовая база, с которой мы будем работать сегодня, завтра и через год. Нам важно содержать ее в порядке. 

Разработка нового модуля или плановая переработка старых модулей начинается с переписывания старого кода. Задачи по рефакторингу появляются по мере необходимости. Никто не будет перелопачивать что-то только ради процесса: мы готовы выделять время и ресурсы только на необходимые задачи по рефакторингу. 

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

Оценивайте компании на Хабр Карьере и делитесь мнением о них с теми, кто сейчас ищет работу в ИТ. Это анонимно.

оценить работодателя

Tags:
Hubs:
+11
Comments0

Information

Website
career.habr.com
Registered
Founded
Employees
11–30 employees
Location
Россия
Representative
Анастасия