Бизнес юзкейс в ит
ИТ-бизнес в США: как открыть компанию за месяц
Четверть мирового ИТ-рынка сфокусирована в США. Тут работают 100 тысяч ИТ-компаний, 99% из которых — малые и средние со штатом до 500 сотрудников. Это благоприятные условия, поэтому многие предприниматели стараются либо сразу создать ИТ-компанию в США, либо хотят открыть филиал уже существующего бизнеса.
Это не так сложно, как кажется на первый взгляд. При должном уровне организации открыть ИТ-бизнес в США с нуля можно всего за месяц. А мы подскажем, как это сделать.
Шаг 1. Подготовка и разведка рынка
Первое и главное — разработка идеи и бизнес-плана. Если вы планируете закрепиться на американском рынке, рекомендуем провести масштабное маркетинговое исследование.
Нужно как можно более подробно изучить потребность в вашей идее на рынке, количество и характер целевой аудитории, перспективные способы продвижения.
Лучше заказать исследование у американской компании, которая хорошо знает рынок. Да, это дорого, но впоследствии вы сможете сэкономить, ведь сделаете намного меньше ошибок в самом начале.
Планировать. Делегировать. Контролировать. — ключевые навыки проджект-менеджера. А ещё: общаться с клиентами и сотрудниками, использовать современные методы управления проектами.
Cossa рекомендует один из лучших российских онлайн-курсов для проджект-менеджеров. Прокачай свои PM-скиллы по программе Сибирикса — одного из крупнейших digital-продакшнов России.
Старт курса уже через несколько дней!
Реклама
Анализ рынка средней глубины занимает около двух–трёх недель. Если вы планируете анализировать рынок, то этот пункт выполняется сразу же после детальной разработки идеи.Если вы уже придумали название своей компании, проверьте доступность этого названия. На официальном сайте каждого штата есть раздел Name Availability, проверка займёт две минуты.
Пример на сайте Калифорнии
Шаг 2. Выбор формы бизнеса и места регистрации
Выбор правовой формы бизнеса предопределяет цели предпринимателя.
В США существует четыре организационных формы ведения бизнеса.
- Индивидуальный предприниматель (Sole Proprietorship).
- Партнёрство (Partnership).
- Корпорация (Corporation).
- Общество с ограниченной ответственностью (Limited Liability Company).
У каждой формы свои преимущества и недостатки, поэтому расскажем немного обо всех.
Sole Proprietorship
Наиболее простая форма бизнеса с точки зрения менеджмента. Предприниматель платит налоги как частное лицо — с доходов компании.
Но есть и минусы. Есть бюрократические сложности с наймом большого количества сотрудников. А банки не слишком охотно дают кредиты на развитие SP.
И главный минус — неограниченная финансовая ответственность бизнесмена. Это значит, что если суд взыщет с компании штраф или обяжет возместить убытки клиента, то недостаток средств компании будет покрыт личным имуществом предпринимателя.
Эта форма удобна для единоличных специалистов в ИТ-сфере, но слабо подходит для полноценных компаний.
Partnership
Равноправное партнёрство нескольких учредителей компании. Существует два типа такого партнёрства: общее и с ограниченной ответственностью.
Общее аналогично SP, и в нём предприниматели несут полную финансовую ответственность. В ограниченном ответ по обязательствам идёт только в рамках вкладов и капитала компании.
Партнёрство — отличная форма организации ИТ-компании для равноправных специалистов.
Corporation
Наиболее распространённая форма бизнеса в ИТ. Самый привлекательный вариант для инвесторов из-за своей гибкости в управлении.
Финансовую ответственность несёт сама компания в рамках собственного имущества. Кроме того, банки относительно лояльно относятся к кредитованию таких компаний.
Это наиболее выгодный тип организации бизнеса для стартапов, которые рассчитывают на быстрый рост.
LLC
Идеально для небольших компаний, которые работают в узких нишах бизнеса. По своей структуре практически полностью отвечают российским ООО. Это некий гибрид, который совместил позитивные стороны партнёрства и корпорации.
Отсутствие гибкости в управлении делает эту форму бизнеса менее привлекательной для инвесторов. Но если нет острой нужды во вливании средств извне, то такой способ организации может запросто поспорить в удобности с корпорациями.
Сравнительная таблица по формам организации бизнеса в США.
| Ограниченная ответственность | Нет | Зависит от типа | Да | Зависит от типа | ||
| Двойное налогообложение | Нет | Нет | Да | Нет | ||
| Корпоративное владение | Нет | Да | Да | Да | ||
| Больше 100 собственников | Нет | Да | Да | Да |
Теперь выбираем штат регистрации.
Выбор один из ключевых, ведь в каждом штате есть собственное налоговое законодательство и налоговые ставки.
Многие компании стремятся зарегистрироваться в штатах с наиболее лояльными налоговыми условиями. К примеру, в Неваде, Висконсине или Делавере. Но к ИТ-компаниям это не относится.
Имидж у ИТ-компаний отыгрывает важнейшую роль. Абсолютное большинство ИТ-гигантов зарегистрировано в Калифорнии, в так называемой Кремниевой долине. Несмотря на то, что налоги для бизнесменов здесь одни из наиболее высоких, имидж профессионалов из Silicon Valley стоит таких затрат.
Сама процедура регистрации занимает несколько часов, и её можно сделать за один день. Причём форму можно заполнить в интернете без личного присутствия. Вот раздел для Калифорнии. Чтобы оформить весь пакет документов, потребуется несколько дней.Стоимость открытия компании — до 115 $. Но нерезиденту нужно дополнительно оформить почтовый ящик в США, на который будут приходить официальные извещения. Его стоимость от 200 до 400 $.
Шаг 3. Оформление в налоговой и открытие счёта в банке
Налоговый номер для бизнесменов-нерезидентов (TIN) позволяет компании платить налоги, нанимать сотрудников и открыть корпоративный счёт в банке.
Чтобы получить его, нужно распечатать и заполнить форму в налоговой.
Здесь есть сложность — формы нерезидентов принимаются только в распечатанном виде, онлайн-приёма нет. Нужно либо послать заполненную форму с остальными документами (список которых также можно посмотреть по ссылке выше) по почте, либо воспользоваться услугами агента.
Второй вариант более предпочтителен, ведь занимает намного меньше времени. Получение налогового номера в среднем занимает от трёх до семи дней.
Открытие счёта — последний бюрократический рывок. Чтобы открыть корпоративный счёт в банке, нужно предоставить свидетельство о регистрации компании и налоговый номер. Делать это нужно лично или через уполномоченного агента.
Предприниматель может выбрать абсолютно любой банк — разницы практически нет. Но мы рекомендуем выбирать крупные учреждения, которые входят в топ-50 банков США. Так вы сможете быть уверены в надёжности всех денежных операций. Кроме того, в крупных банках проще взять кредит на развитие бизнеса, и они предлагают более приятные кредитные условия.
Во время открытия счёта вас попросят положить на него от 100 $ до 1000 $. Сумма зависит от размера минимального вклада в банке.
Шаг 4. Запуск и развитие
Итак, все бюрократические сложностей пройдены, осталось самое главное — начать работу и вывести компанию на прибыль.
Будьте заранее готовы к высокой конкуренции и требовательности клиентов. Рынок США перенасыщен ИТ-компаниями, поэтому рекомендуем на нём не зацикливаться. Выводите проект сразу на международный уровень, если финансы позволяют.
Важный момент. Не ждите, чтоб компания выйдет на самоокупаемость через месяц–два. Клиенты в США предпочитают работать с проверенными компаниями, и основной метод продвижения — сарафанный маркетинг.
Вместе с этим американцы доверяют СМИ. Конечно, полноценная рекламная кампания в специализированных онлайн-изданиях обойдется недёшево, но она гарантированно принесёт клиентов для работы в первые полгода.
Первый год работы — самый сложный, ведь именно в это время база клиентов создаётся с нуля. Поэтому для гарантии выживаемости компании страховочный капитал должен быть в районе 70 000–100 000 $.
Ещё стоит запомнить, что в США в контрактах прописываются абсолютно все нюансы проектов: от сроков выполнения каждого из этапов разработки до штрафов и санкций за некачественную работу или срыв сроков.С другой стороны, в этом есть и плюс для предпринимателя. Ведь все виды работ, выполнение которых не прописано в договоре, оплачиваются отдельно.
Мы всё же рекомендуем нанять хорошего корпоративного юриста или даже нескольких — экономить на этом нельзя.
Сроки вывода ИТ-компании на прибыльность и расширение могут сильно отличаться. В среднем, стартовое развитие занимает полгода, как и в России. Потом становится ясно, жизнеспособна компания или нет.
Открытие компании в США — дело несложное
Намного труднее затем управлять такой компанией, ведь из-за высокой конкуренции в бизнесе остаются только самые лучшие. А тут уже всё зависит от навыков бизнесмена и его команды.
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.
Источник: https://www.cossa.ru/152/215159/
«Главное — не зависеть от ключевых клиентов»: как построить отдел продаж с нуля, кейс от ИТ-компании
Фото из архива компании «СофтТеко»
У отделов продаж в ИТ-сфере есть своя особенность: им приходится работать в жесткой сцепке с разработчиками. Как это происходит и в чем сложность? Как найти новых клиентов и освоить новые рынки — своим опытом делится руководитель отдела продаж компании «СофтТеко» Максим Делендик.
— Я пришел в ИТ-компанию «СофтТеко» в 2009 году. Это было тяжелый период мирового экономического кризиса. А для компании — время, когда она очень зависела от клиента № 1 — фирмообразующего клиента. И вдруг этот клиент ушел. У руководства было 2 пути: закрыться или искать выход. Выходом тогда стало решение открыть отдел продаж. Развивать его с нуля было поручено мне.
Тогда была поставлена главная задача: избавиться от зависимости от 1-2 ключевых клиентов. Мы определили, что сможем этого достичь, сделав акцент на двух вещах:
1. Развитие отдела продаж и грамотное выстраивание взаимодействия с отделом разработки.
2. Освоение новых рынков.
Максим Делендик. Фото из архива компании
В чем особенность продаж в ит
Специфика отдела продаж в ИТ-компании заключается в том, что в обсуждении потенциального проекта, а потом и в его реализации участвует, как правило, довольно большая группа людей:
- Отдел продаж выясняет информацию о потенциальном проекте и клиенте
- Со стороны отдела разработки выясняются технические детали проекта, предлагаются решения, дается экспертиза команды
В ИТ-компании, как правило, есть несколько основных форм сотрудничества с клиентом. Например, мы:
1. В одних случаях просто собираем команду специалистов для клиента — команда напрямую работает с технической командой клиента.
2. Иногда делаем проекты с фиксированной ценой — в том случае, если мы в нем уверены и можем адекватно оценить риски. Часто делается предварительная оценка проекта. Допустим, технической документации, которую предоставляет заказчик.
При необходимости также может прорабатываться архитектурное решение, пользовательский интерфейс. После этого делается оценка и бюджет.
Именно на этой стадии в общении с клиентом задействованы и разработчики, и отдел продаж — зачастую действительно большое количество сотрудников.
Почему в продажах ИТ-продуктов так важна команда
Продавцы в ИТ. Некоторое время я выстраивал систему продаж один. Сейчас в отделе работает 5 человек: продавцы и маркетологи.
Сотрудники отдела продаж в ИТ-компании должны иметь следующие компетенции:
1. Большим плюсом является технический бэкграунд. В идеале — если менеджер по образованию является техническим специалистом. Это позволяет ему говорить с заказчиком на одном языке, что значительно облегчает процесс переговоров.
Я сам окончил БГУИР и несколько лет работал разработчиком. Поэтому мне с самого начала было проще вникать в продукт, который нужно продавать.
И это, безусловно, значительно облегчает процесс переговоров с клиентом — я часто сам в них и сейчас принимаю участие.
Хотя бывают настолько сложные проекты, что приходится приглашать наших ИТ-специалистов для выяснения всех деталей — иногда до 3−4 человек дополнительно.Фото из архива компании «СофтТеко»
Конечно, не все наши менеджеры имеют техническое образование. Но мы постоянно обучаем их.
2. Очень важен английский язык. Чаще всего ИТ-проекты предполагают удаленное общение, поэтому умение правильно выстроить беседу, грамотно донести информацию ценится в нашей сфере очень высоко.
Все продавцы, как известно, делятся на 2 категории:
- Люди, которые продают услуги
- Люди, которые продают продукты
Не важно, какой продукт — его в любом случае всегда можно пощупать, сравнить и понять, что выбрать. Услуги, на мой взгляд, продавать сложнее, особенно сложные технологические ИТ-услуги.
1. Сложно объяснить, почему услуга у одного продавца стоит $ 5000, а у другого $ 50 000. Здесь важно, чтобы на стороне клиента были люди, разбирающиеся в технической части проекта.
Пример: программа для вызова такси выглядит как приложение с двумя кнопками. Но есть серверная часть, для разработки которой может понадобиться до нескольких лет и большое количество людей. Разобраться в разнице продуктов может только высококвалифицированный специалист.
2. Мы продаем часто очень долгосрочные и дорогостоящие проекты. Угадать, какими они будут в итоге, невозможно. Отсюда — очень длительный срок работы по одной сделке. Дешевые покупки люди совершают быстро.
Решения по нашим продуктам принимаются группой лиц и очень долго — от 1 месяца до 1 года. Все это время мы должны удерживать интерес клиента и вызывать доверие на каждом цикле продаж.
Причем участвуют все: не только продавцы, но и разработчики.
Фото из архива компании «СофтТеко»
И вот здесь очень важный момент: взаимодействие подразделений в ИТ-компании. У отдела разработки и отдела продаж разные задачи. Однако оба работают в одной связке. А значит, просто обязаны договориться.
- Разработчики должны создавать качественный продукт, изучать новые технологии, подбирать команду, обеспечивать сотрудникам карьерный и профессиональный рост
- Отдел продаж озабочен совсем другими вещами. Главное — это постоянный приток новых проектов. Мы должны найти клиента и продать ему наши услуги
Но я думаю, в каждой ИТ-компании есть определенный конфликт между этими подразделениями.
Например, у нас основные разногласия с отделом разработки случаются при старте новых проектов: в команду требуются свободные опытные разработчики, а их не хватает в нужный момент. Иногда бывает и другая ситуация: когда нам нужно думать, чем занять освободившихся людей. Хотя это, конечно, редкий случай.
Сложности могут быть и в оценке проекта. Разработчики чаще всего очень заняты и принять участие в процессе вовремя у них не получается. А нам нужно делать предложение, причем делать в тех временных рамках, в которых его делают конкуренты.
И разработке иногда приходится объяснять: вы замечательно пишите код, но я должен это вовремя продать!При этом, надо отдать должное, разработка всегда идет навстречу, если нужно поработать сверх нормы, в выходные, в другом городе и т.д.
Новые рынки
В самом начале, когда компания была относительно небольшая, мы фокусировались на рынке Америки, работали с Восточным и Западным побережьем. Однако это приносило очень много неудобств из-за разницы во времени. Проводить совещания нужно было в 10−11 вечера, это было сложно, особенно, когда проекты долгосрочные.
Также пока в России курс доллара был стабильно в районе 30 рублей, мы процентов на 15 работали с российскими заказчиками. Но в 2014 году ситуация там поменялась. Рубль стал плавать, а дополнительные риски нам ни к чему. С американцами тоже, в силу вышеназванных причин, работать стали меньше.
Решили осваивать новые направления.
Весь российский рынок мы перефокусировали на Израиль — сейчас большинство наших проектов именно оттуда.
Фото с сайта squarespace.com
Нам это нравится, проекты очень интересные, долгосрочные. И нет разницы во времени. Более того, с 2016 года Израиль отменил визы, что тоже облегчило наши коммуникации. Слетать туда очень легко.
Смена рынка для нас прошла практически безболезненно и даже принесла некоторые дивиденды.
Чем хорош Израиль: это страна с очень высокой концентрацией ИТ-компаний, которые нуждаются в опытных специалистах.
Внутренний рынок не справляется с таким запросом, и поэтому компании обращаются к аутсорсингу. В Израиле много выходцев из стран СНГ, поэтому они знают возможности и доступные расценки наших специалистов. Кроме того, нет разницы во времени. А это немаловажно для переговоров.
Как попасть на рынок Израиля. Мы просто ездили и знакомились. Нужно сделать очень много знакомств, чтобы в какой-то момент это переросло в качество и пошли заказы. И, конечно, важны рекомендации.
Если ты уже сделал продукт для кого-то, и этот заказчик тебя порекомендует — в Израиле это увеличивает твои шансы в несколько раз.
На израильском рынке мы не остановились. Сейчас перед нами стоит задача — увеличить свое присутствие в Европе, оптимизировать нашу стоимость.
Определяя страны, куда стоит заходить, мы прежде всего оцениваем:
- Уровень развития ИТ-рынка, потребность в наших услугах
- Уровень цен. Потому что, допустим, цены в Беларуси на наши услуги сейчас выше, чем в Румынии, Болгарии и Украине. Поэтому мы смотрим на страны, которые могут позволить себе эти услуги в нашем ценовом диапазоне
- Человеческий ресурс
В Европе мы нарастили количество клиентов в Швейцарии и Германии.
Что в результате
Сегодня компания работает стабильно. Главную задачу, которая стояла передо мной и отделом продаж — избавиться от зависимости от ключевых клиентов — мы на данный момент выполнили. Хотя, не скрою, это заняло очень много времени.
Сейчас мы не зависим не только от одного клиента, но и от одного рынка, одной страны, одной валюты. Если какой-то клиент уйдет, мы не пострадаем. Мы шли к этому целенаправленно. И это, повторюсь — одно из самых важных наших достижений.
Для компании очень важно — осознавать независимость от внешних факторов. Это как новый рубеж, новая точка отсчета.
Источник: https://probusiness.io/experience/3736-glavnoe-ne-zaviset-ot-klyuchevykh-klientov-kak-postroit-otdel-prodazh-s-nulya-keys-ot-it-kompanii.html
Как и зачем писать Use Cases
Image via Shutterstock.
Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.
Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.
Что такое Use Case
На собеседовании порой можно услышать следующее определение «Это такая UML-диаграмма с человечками и овалами». Давайте разберемся, что это такое, и рассмотрим несколько простых примеров.
Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.
Мне нравится определение из книги Коберна (советую, ее, кстати, всем аналитикам): «Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использования описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях».В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.
Текст vs диаграмма/схема
Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:
- Такой формат более понятен заказчикам (а они тоже предпочитают читать и согласовывать варианты использования).
- Текст проще и быстрее отредактировать, чем диаграммы и текст.
Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.
Кому и в каких случаях нужны сценарии
— Разработчикам. Очень удобно, когда ветвистое требование описано при помощи основного и альтернативного потока событий.
Все четко и понятно: кто, когда и что вызывает, и что получается в результате. В моем последнем проекте менеджер исповедовал подход: минимум описаний, максимум общения.
Но для нескольких сложных сценариев разработчики сами просили сделать подробное описание, и юзкейсы отлично подошли.
— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.
— Тестировщику. Почти готовый тест-кейс 🙂
— Всей проектной команде. Если сценарий нужно согласовать, а на каждом совещании пара-тройка альтернативных вариантов сценария звучит иначе, поможет строго описанный поток событий.
А также другим участникам процесса.
В каких случаях они нужны:
— Если вам нужна качественная, полная спецификация требований — юзкейсы прекрасно в этом помогут. Есть такие системы, для разработки и поддержки которых спецификация требований, содержащая модель данных, описание интерфейса, интеграции с другими системами и юзкейсы — очень хороший вариант.
— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.
— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария.
Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса.
Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.
Как их описывать
Давайте рассмотрим пару примеров, они говорят сами за себя.
Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):
| Действующие лица | Администратор, Система |
| Цель | Изменить статус учетной записи пользователя на «активный». |
| Предусловие | Учетная запись пользователя не активна. |
Успешный сценарий:
| |
| Результат | Учетная запись пользователя была переведена в статус «активный». |
Пример 2. Авторизация пользователя:
| Действующие лица | Пользователь, Система |
| Цели | Пользователь: авторизоваться в системе и начать работать;Система: идентифицировать пользователя и его права. |
Успешный сценарий:
| |
| Результат | Пользователь успешно авторизирован и может работать с системой. |
| Расширения: | |
| *а | Нет доступа к БД.Система выдает сообщение (ссылка на сообщение).Результат: пользователь не может войти. |
| 1а | В настройках безопасности для данного IP адреса существует запрет на вход в систему.Результат: форма логина не предоставляется, система выдает сообщение пользователю (ссылка на сообщение). |
| 2а | Пользователь выбирает: «Напомнить пароль».Вызывается сценарий «Напомнить пароль». |
| 3а | Пользователь с введенными логином и паролем не найден.Результат: отказ в авторизации.Система выдает сообщение (ссылка на сообщение).Переход на шаг 2. |
| 3б | Количество неудачных попыток авторизоваться достигло максимального, установленного в настройках.Результат: пользователь не может войти.Выдается сообщение: (ссылка на сообщение).Вход с IP адреса Пользователя заблокирован на время, установленное в настройках. |
Важные моменты
— Очевидно, что если Пример 1 можно было безболезненно описать простым текстом, то Пример 2 намного лучше воспринимается в виде сценария. Но если у вас вся функциональность описана в виде юзкейсов, то лучше описывать юзкейсами даже очень простые сценарии, из пары шагов. Пусть ваша спецификация будет в едином стиле.
— Используйте минимальное количество слов и пунктов, необходимых для однозначного понимания сценария. Если юзкейс получается слишком длинный, возможно, лучше будет разбить его на несколько. С очень длинными сценариями, с большим количеством расширений, работать крайне неудобно.
— Если в двух и более сценариях повторяется одинаковый набор шагов, есть смысл вынести эти шаги в отдельный сценарий, и ссылаться на них. Документ будет легче. А если что-то в этих шагах поменяется, то достаточно будет изменить в одном месте.
— Список сообщений, которые система выдает пользователю, стандартные тексты электронных писем и т.п. удобно расположить в едином месте в документе, и ссылаться на нужный пункт из разных юзкейсов, т.к. сообщения в сценариях часто дублируются.
— Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.
— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».
— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.
Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.
При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».
Источник: http://gs-studio.com/news-about-it/30205-----use-cases
Кейс: Как организовать работу IT-подразделения, чтобы оно развивало ваш бизнес — Офтоп на vc.ru
Отбрасываем второстепенные задачи, формируем продуктовые команды, налаживаем коммуникации с операционными подразделениями, приносим много пользы бизнесу небольшими кусочками.
Алексей Захаров, директор по продукту компании «Биглион»
Как реформировать работу ИТ-подразделения компании, чтобы в кратчайшие сроки получить ощутимые результаты для бизнеса, рассказывает директор по продукту компании «Биглион» Алексей Захаров.
Как было
Когда я пришел в «Биглион» в январе этого года, группы разработки в компании делились по платформенному признаку, то есть были группа сайта, группа приложений, группа внутренней CRM-системы и группа директ-маркетинга.
Поэтому они занимались не столько развитием бизнеса, сколько развитием своих платформ.
Условно говоря, группа сайта делала новый дизайн, группа мобильных приложений делала новую версию приложений, группа CRM делала новую версию интерфейса для процесса заведения акций и т.д.
Это продолжалось в каждом из подразделений уже по году без добавления какой бы то ни было новой функциональности в бизнес. Никто никому не мешал, но и не помогал, занимаясь своей частью.
Наши руководители были этим не очень довольны. И это привело, в том числе, к изменению курса.
С чего начали
В первую очередь я провел интервью со всеми топ-менеджерами компании и собрал список стратегических направлений, в которых компания видит свои главные точки роста. Их получилось 14. По мнению руководителей, каждым из этих 14 направлений кто-то занимался.
Но так как направления существовали отдельно, а команды — отдельно, то возникала ситуация, что 0,3 программиста занимается одним делом, а 2,7 программиста — другим и т.д. Это было странно и непрогнозируемо.
И у сотрудников, естественно, возникали отговорки: они не сделали одно, потому что занимались другим.
О чем договорились на старте
Мы сразу договорились о новом правиле: каждый программист, тестировщик, продакт-менеджер, проджект-менеджер должен быть только в одной группе развития и заниматься только одним направлением, и поделить пополам его нельзя. И, соответственно, если мы будем формировать новые группы развития, в них должны быть люди целочисленные.
Также мы договорились, что все те направления, которые мы выберем из четырнадцати существующих и которыми будем до конца года заниматься, для компании важны.
Понятно, что какие-то из них могут принести деньги сейчас, какие-то потом, какие-то более стратегически важные, какие-то менее — но все они в равной степени требуют внимания. Поэтому никакого сквозного приоритета больше не будет.То есть, если на каком-то направлении что-то «горит», перебрасывать туда людей с других направлений мы больше не будем.
Как расставили приоритеты
Естественно, 14 направлений требовали большого числа дополнительных сотрудников. Поэтому мы стали обсуждать с топ-менеджерами, какие из направлений наиболее приоритетны.
В итоге мы оставили в этом году 7 направлений развития:
● эффективность покупателей,
● эффективность внутренних процессов,
● персональные коммуникации,
● разработка маркетинга,
● развитие Frendi (еще один наш бренд),
● кэшбэк как новое, динамично развивающееся направление,
● направление бесшовного опыта (когда процесс покупки услуг происходит целиком на «Биглион», и клиенту не приходится отдельно покупать купон, а потом что-то доплачивать на месте).
Как подготовили инфраструктуру
Под каждое направление развития мы выделили группу, в которой есть веб-программисты, мобильные программисты, тестировщики, продакт-менеджеры. И там, где группа получилась большая, есть еще проджект-менеджеры.
Почему деление подразделений по платформам — плохая история? Потому что обычно какая-то функциональность требует разработки в бэк-энде, в мобильных приложениях, в базе данных, и все постоянно друг друга ждут, ведь у каждого своя система приоритезации задач.
А чем хорош подход с группами развития по направлениям бизнеса? Тем, что в группе для подавляющего большинства решаемых задач есть все необходимые технологии и люди, и они только внутри своей группы что-то приоритезируют. Людей разных компетенций подключают сразу к работе над одной задачей, она максимально быстро проходит стадию работы и становится доступна клиентам.
Для того, чтобы эти группы наиболее эффективно занимались вопросами развития, мы совместно с директором по разработке сформировали еще три поддерживающих подразделения:
● веб-платформа,
● мобильная платформа,
● IT.
Веб-платформа и мобильная платформа помогают продуктовым командам не терять скорости за счет контроля качества кода, периодических работ по рефакторингу, исправления возникающих ошибок в текущей функциональности. А IT-подразделение занимается тем, что готовит инфраструктуру для разработчиков.
Какие были сложности
Нам требовались квалифицированные продакт-менеджеры. Надо понимать, что когда вся разработка в компании была разбита по платформам, люди, которые назывались продакт-менеджерами, конечно, были, но по факту ими не являлись.
Просто приходил генеральный директор или другие менеджеры и рассказывали, какую фичу им нужно сделать следующей — и она как-то делалась.
А я считаю, что продуктовый подход включает в себя две составляющих: организация структуры продуктовых и технологических групп, а также целеполагания. Что это означает?
Продакт-менеджеры, которых мы теперь нанимали, должны были обязательно обладать самостоятельностью, проактивностью, бэкграундом в других компаниях, уметь на равных вести переговоры с топ-менеджерами, отстаивать свою позицию.
Как изменили целеполагание
Все это стало необходимым, потому что целеполагание теперь выглядит следующим образом. Выделив направления развития, мы определили, за какие метрики будет отвечать каждая команда.
Например, группа эффективности покупателей отвечает за конверсию на сайте и в приложениях или, например, за рост NPS (индекс удовлетворенности) наших продуктов.
И мы нанимаем продакт-менеджера, который уже работал в похожих условиях, имеет определенную экспертизу, понимает, как эти метрики растить.
Продакт-менеджер ежеквартально формулирует, насколько он собирается вырастить те или иные метрики, цели предварительно обсуждаются и согласовываются с командой разработки. Но это не классический подход, когда мы в диаграмме Ганта пишем все задачи одну за другой и просто их делаем по порядку. А это, можно сказать, предпринимательский подход.Например, мы хотим вырастить конверсию на 10%, у нас есть 10 гипотез, как это может произойти, что-то сработает, что-то не сработает.
Продакт-менеджер с командой выбирают эти гипотезы и от наиболее вероятной к менее вероятным в течение квартала реализуют функциональность, которая должна привести команду к планируемым результатам.
Продакт-менеджер отслеживает изменение этих метрик, и понимает, движется ли команда в правильном или неправильном направлении.
Мы пользуемся методом OKR. На практике это выглядит так: в компании есть файл в гугл-док, который доступен всему менеджменту. Раз в квартал на вкладках для каждой команды развития формулируются три-четыре цели, под каждой выставляются 2-4 ключевых результата с метриками, на основании которых мы будем понимать, достигается ли цель.
Продакт-менеджер приходит на собрание директоров, кратко это все излагает, а ему говорят, достаточно ли это амбициозно. В общем, происходит своего рода «защита» цели. И дальше группа работает в течение квартала, раз в одну-две недели обновляет в гугл-доке информацию о том, как метрики изменились. Все руководство в курсе.
И все понимают, кто чем занимается и почему.
Как теперь все работает
Раньше в компании были разработки длиной в год, теперь мы договорились со всеми продакт-менеджерами, что в разработку мы берем кусочки бизнес-ценности за раз не больше чем на два спринта, то есть на месяц. (Под бизнес-ценностью я понимаю что-то, что уже доступно в нашем сервисе конечным пользователям и как-то меняет наш бизнес).
Абсолютный минимум производительности каждой команды — не менее одного кусочка бизнес-ценности в месяц. Это самый крайний вариант, на деле все происходит гораздо быстрее. Все понимают, что мы движемся небольшими шажками, но достаточно быстро.
Также мы очень внимательно относимся к коммуникациям между подразделениями внутри компании. В компании и раньше были демо-презентации, которое проводили айтишники сами для себя — и мы его перепрофилировали.
Теперь у нас на демо приходят представители продаж, маркетинга, бухгалтерии, юристы, гендиректор, приходят заинтересованные люди из ИТ-департамента.
И каждая команда кратко показывает некую презентацию, как она за месяц улучшила бизнес.
Мы говорим о том, какая функциональность стала доступна клиентам, как она повлияла на бизнес. Выводы делаем на основании AB тестов, которые проводим при запуске каждого кусочка функциональности. И таким образом у нас получается полная прозрачность на этапе планирования и на этапе демонстрации результатов.А благодаря тому, что мы всю разработку разбили на семь направлений, фактически получается, что у каждого продакт-менеджера задача, упрощенно говоря, в семь раз легче, чем развитие всей компании. Потому что он отвечает только за свое направление, и задача у него поменьше.
А моя роль заключается в организации этих процессов, в настройке коммуникаций между всеми бизнес-подразделениями, ИТ-подразделениями, продакт-менеджерами, дизайнерами и аналитиками.
А также в том, чтобы наше видение бизнеса, несмотря на то, что мы его развиваем по кусочкам, не распадалось, как пазл — для этого мы проводим синхронизационные встречи.
Результаты
То, что было невозможно еще полгода назад, стало возможным. Мы за 1-2 спринта (2-4 недели) запускаем такие продукты, например, как доставка еды без купона, оффлайн-кэшбэк по чекам, обновленный поиск с подсказками. Это, на мой взгляд, очень хорошая скорость.
Мы отказались от части классных идей, но зато другие классные идеи теперь действительно быстро реализуются.
Все процессы стали не только быстрее, но и прозрачнее, исчезло недопонимание со стороны операционных подразделений.
И я считаю, что это нас приведет к серьезным успехам уже в следующем году. До конца этого года наша цель — нагнать все технологические и продуктовые моменты, от которых мы отстали за то время, пока делались какие-то большие вещи, которые не улучшали бизнес. И несмотря на это уже сейчас заметны изменения, в том числе в сводных отчетах по выручке и эффективности бизнеса.
Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.
Написать
Источник: https://vc.ru/flood/44727-keys-kak-organizovat-rabotu-it-podrazdeleniya-chtoby-ono-razvivalo-vash-biznes
Кейс: как мы подготовили IT-системы для работы 12 тысяч магазинов к высокому сезону | Rusbase
Если в конце декабря вы только и делали, что чинили и настраивали перегруженные IT-системы, пытаясь справиться с потоком клиентов, но во время февральских и мартовских праздников так делать не хотите, то почитайте этот текст.
По нашему опыту, в продуктовой рознице самое горячее время – период с 1 ноября по 15 января. Рост количества транзакций у других ритейлеров может произойти и в другое время: в преддверии 23 февраля, 8 марта или школьных каникул.
Так что берите на заметку наш опыт, чтобы воспользоваться им в нужный момент. Мы начали готовить IT-системы к высокому сезону очень заранее – за 6 месяцев.
Наши главные цели:
Подписывайтесь на канал Rusbase в «Яндекс.Дзен», чтобы ничего не пропустить
- Создать запас прочности и надежности
- Устранить возможные риски
- Подготовить запасные ресурсы к периоду пиковых нагрузок
Во время высокого сезона в продуктовой рознице существенно вырастает количество транзакций, а за ним и количество обращений к системам. Параллельно происходит закрытие бухгалтерского года с тысячами контрагентов, что также создает дополнительную нагрузку на системы.
Итак, как мы готовим наши сани летом.
1. Проверяем инфраструктуру
Удаленно и локально тестируем работоспособность всего оборудования.
От сканеров на кассах, электронных весов в каждом магазине и серверов в распределительных центрах, до ЦОДов и систем, обрабатывающих данные программы лояльности, и систем связи. Устаревшие и ломающиеся элементы систем меняем и чиним заранее.
Тут важен такой принцип: если что-то может сломаться, оно сломается. Поэтому для нас не существует оборудования, которое не будет протестировано.
Нужно тестировать и core-элементы системы.
Так, в прошлом году мы поняли, что ядро сети не обеспечит нам необходимый ресурс для высокого сезона, и заменили его.
Также мы оценивали мощность оборудования, чтобы иметь «запас прочности» для активной работы.
Оборудование, которое не соответствовало планируемым нагрузкам нужно заранее заменить на более производительное. Так, например, в четырех региональных офисах после нагрузочного тестирования мы полностью поменяли серверы, а новый подход к резервному копированию позволил освободить ресурсы для мгновенного увеличения дискового пространства и оперативной памяти.
- Важно проверить средства и качество связи.
Мы это делаем в удаленном режиме и полуавтоматически, так как количество элементов в системе крайне высоко. Автоматизация процессов и тестирования очень упрощает жизнь и позволяет избежать «ручных ошибок».
С помощью автоматической системы мониторинга мы круглосуточно контролируем около 100 показателей работоспособности систем, оборудования и бизнес-процессов. Часть типовых ошибок фиксируется и устраняется также автоматически, поэтому мы можем сконцентрировать человеческий ресурс на решении нестандартных проблем.
Важно хорошо скоординировать команды сотрудников, сделать четкий таймплан и контролировать процесс еженедельно.
Так как систем и оборудования много, нужно построить работу так, чтобы можно было одновременно проверять и доработать сразу несколько видов оборудования. Также нужно установить себе ясные критерии эффективности. Для работы в высокий сезон мы считаем целевым показатель 100% доступности систем и оборудования. То есть мы вообще не допускали возможность отказов оборудования и связи.
2. Проверяем программное обеспечение
В первую очередь мы проверяли и обновляли кассовое ПО.
В магазинах работает порядка 42 тысяч касс. Каждую кассу нужно было протестировать и установить наиболее надежную версию ПО, а также обновить до лучшей версии ПО фискальные регистраторы.
За 6 месяцев мы сделали это несколько раз. Перед установкой новых версий кассовых программ мы обязательно проверяли их на тестовых объектах и ставили в «продуктив» только стопроцентно работающие версии.
Если все-таки случались ошибки – «откатывали» ПО на предыдущую версию.
У нас для этого есть собственная разработка — система удаленного управления ПО фискальных регистраторов, с помощью которой можно за ночь обновить все кассы.
Параллельно мы обновили ПО на 42 тысяч пин-падов – устройств для безналичной оплаты.
Это оборудование принадлежит и управляется банком-эквайером, поэтому гарантировать его надежность для бизнеса не так просто. В случае с пин-падами мы подключили к работе банк, заранее выработали рабочую схему обновления. Сделали централизованные инструменты по сбору конфигурационной информации о пин-падах, инструменты распределения и балансировки нагрузки на сервера банка при обновлении ПО.
Отдельно мы занимались ключевыми системами, стабилизируя их работу.
Проверку прошли ERP, TMS, WMS модули, системы планирования товарных запасов, прогнозирования цен и ассортимента и промо. В частности, чтобы снизить возможность отказа и время отклика, мы проверили архитектуру систем и исключили лишние действия и «прослойки» — промежуточные шлюзы между модулями.
3. Проверяем точность работы бизнес-процессов
Так как в прошлом году появились онлайн-кассы, мы начали отслеживать очередь отправки чеков в ФНС на всех кассах и регулировать их работу. Еще одна «превентивная мера» — проверка сертификатов ЭЦП для торговли алкоголем. Суммарно по итогам проверки мы перезаписали 5138 ключей ЕГАИС.
Также важно было убедиться на 100% в точности работы бизнес-процессов – то есть взаимодействия между бизнес-единицами компании.
Нужно, чтобы в период большой нагрузки все стороны действовали по инструкциям и вовремя выполняли свои задачи. Мы обращали особенное внимание на взаимодействие с регионами и процессам, связанным с промо, так как на них приходится большая часть типовых операций в высокий сезон.
Приготовив все системы и процессы к высокому сезону, нам удалось пройти его без серьезных сбоев и не привлекая дополнительные ресурсы. Удалось значительно сократить количество сбоев относительно 2016 года.Несмотря на то что сеть магазинов и количество оборудования за год увеличились почти на 30%, мы получили меньше обращений от торговых точек о сбоях в работе оборудования, обеспечив 99,34% доступности сервисов и систем.
Чеклист для поддержки: что проверить перед горячим сезоном
- Работоспособность и ресурс оборудования в торговых точках, централизованной инфраструктуры и каналов связи
- Архитектуру, обновления, работоспособность и типовые ошибки программного обеспечения и ключевых операционных систем
- Типовые ошибки баз данных и возможности для автоматизации их устранения
Как это сделать
- Сделать ясный таймплан для параллельной проверки систем и скоординировать команду сотрудников
- Установить понятный целевой показатель доступности и безопасности, ориентируясь на плановую нагрузку в высокий сезон
- Всегда учитывать худшие сценарии: все, что может сломаться, сломается в самый неподходящий момент.
- Полагаться на надежные схемы и проверенное оборудование. Горячий сезон – не время для инноваций.
- Автоматизировать все, что можно автоматизировать.
- Даже при отличных показателях доступности оборудования и сервиса приготовить дополнительные ресурсы оборудования и людей
Материалы по теме:
Большие данные в ритейле: что они дают и как с ними работать
Как повысить продажи в e-commerce – пять проверенных способов
Хотите предугадывать будущее ритейла? Следите за рынком Китая
10 необычных технологий в ритейле, которые выходят в мировой топ
Самые горячие инструменты торговли в XXI веке
В нашем Instagram @rusbase сегодня есть на что посмотреть! Подписаться
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Источник: https://rb.ru/opinion/kejs-it/