Shiva Digital: портрет компании

Справка

Город: Москва 
Название: Shiva Digital (ранее — qb systems) 
Специализация: разработка и поддержка технически сложных веб-проектов, внутренних порталов, интеграционные решения, разработка на блокчейн
Платформы: SharePoint, 1С-Битрикс
Количество сотрудников: 16
Ключевые клиенты: Теле2, «Твой дом», Ростех, АНПФ, Ростелеком, НПФ «Будущее»

Shiva Digital: Начало

Мы на рынке давно, с 2011 года. В штате тогда было 5 человек, занимались поддержкой и разработкой сайтов, делали проекты для таких клиентов, как «Рестор», ideas4retail, «Летограф». Не могу сказать, что дела у нас тогда шли очень хорошо — мы вели большие проекты, работу свою выполняли качественно, но экономика никак не сходилась.

В 2013 году договорились с группой qb об объединении бизнесов и вошли туда. Привнесли свои компетенции: прототипирование, dot.net, Django и Python. С этого момента стали работать уже как qb systems.

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

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

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

В общем, через четыре года сотрудничества мы поняли, что настоящего объединения не получается. Мы так и остались двумя разными компаниями, которые, конечно, друг другу помогают, но совсем не в том масштабе, как это планировалось.

В середине 2016 года мы с qb обсудили это всё, рационально взвесили все «за» и «против» и договорились, что дальше нам правильнее идти под своим собственным флагом.

С этого момента начинается история Shiva Digital.

О названии

Когда выбирали название, миллион вариантов перебрали, в основном «технологических». Всякие «технолоджи» и прочее. А Shiva Digital появилась, когда попробовали наши компетенции обозначить. Оказалось, что у нас семь ключевых компетенций: блокчейн-проекты, разработка смартконтрактов и DApps, веб-разработка, портальные решения, мобильные решения, поддержка и развитие проектов. Тут и вспомнился многорукий Шива. Но какого-то религиозного подтекста здесь нет.

Айдентику вначале думали сами нарисовать, но дело это затянулось, и решили отдать ещё кому-нибудь. В итоге всё нам рисует Design Creators. Офигенно рисует, должен сказать.

Шиву вначале сделали в виде мультипликационного персонажа. На Еву из «ВАЛЛ-И» был похож, такого персонажа удобно было бы использовать на разных мероприятия, выразительнее, чем просто логотип.

Но потом отказались от такого подхода, более строго сделали. Раз за разом становилось всё лаконичнее, и вот финал:

Логотип с руками по кругу ещё и как прелоадер встал отлично.

О команде

Команда у нас распределённая. Есть офис в Москве, а ещё разработчики в Питере, Краснодаре, Ростове, Воронеже. В команде 9 программистов.

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

Ещё одна его миссия — уберечь разработчиков от постоянных клиентских «задач на пять минут», от которых как раз и слетают часто сроки проекта. Задача на пять минут, но разработчика выдёргивают из одной, погружают в другую — и на одном таком переключении можно до сорока минут потерять. В итоге всё планирование полетит кувырком.

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

При этом рабочий режим у нас стандартный, с 10 до 19, со всеми удалёнщиками мы сразу оговариваем, что в это время они должны быть на связи и на работе. Если надо отойти — предупредите заранее. Наш рабочий режим совпадает с режимом клиента.

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

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

О документировании проектов

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

«Архитектурный гайд» — где что располагается, какие компоненты для чего используются. С таким гайдом можно и самим в едином стиле всё делать, и при необходимости отдать другим разработчикам — тоже без проблем.

Второй документ — «Руководство программиста». Если в гайде мы описываем общую логику архитектуры и принципы подготовки кода, то в «Руководстве» уже более частные вопросы затрагиваем: описание функций, используемых библиотек, какой код за что отвечает. Это также обеспечивает преемственность внутри команды, единые стандарты логики. А кроме того, сильно упрощает вхождение в проект новых участников команды: человеку не нужно спрашивать ни у кого, что как устроено — взял документ, почитал, понял. Если не понял — ещё раз почитал.

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

Вся эта история про документацию звучит разумно, но почему-то мало кто в реальности такие документы делает. В итоге потом клиент страдает — никто не берётся за поддержку, или берётся, но с наценкой за «обратный инжиниринг», когда вначале проект разбирается, изучается, а потом только начинается поддержка.

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

Не знаю, почему такая практика не распространена. Если крайний самый случай представить — вот ушли из компании все программисты (ну, мало ли!), а обязательства перед клиентами остались. Нанять новых людей можно, но кто их в проект погрузит? Это же ад будет на первые месяцы для всех — и для клиента, и для компании. Да даже если не уволились — иногда старые клиенты обращаются, а что там было три года назад не помнит уже никто, придётся тратить время на то, чтобы разобраться. Разбираться — время нужно, а если его нет, то начинают костыли писать, поверх логики, лишь бы только быстрее проблему решить. Ну и потом костыль на костыль, и весь проект уже переписывать надо, ничего в нём непонятно.

А потратили бы день-два на документацию — и никаких проблем.

Об управленческих ошибках

Главная ошибка — в том, что не занимались целенаправленно маркетингом. В итоге кейсов много, а знают про нас мало. Это ключевая проблема, конечно. Два года назад мы уже решили, что запускаем Shiva Digital, но всё время откладывали все активности. Ну как — вот сейчас логотип нарисуем, и тогда... Вот сейчас сайт откроем, и тогда... И два года уже прошло. Сейчас над этим работаем, навёрстываем упущенное, так сказать.

Другая ошибка, которую поняли некоторое время назад — неверно построили учёт трудозатрат. Простой пример — формально рабочего времени в месяце 160 часов. А в реальности люди не работают 160 часов. Реальная выработка сильно меньше, на уровне 70%. Но клиенту же не скажешь вот так запросто, что исходить будем из 110 часов в месяц. В итоге это ведёт к фактическому занижению стоимости часа — ты оцениваешь проект из реальных часов, а клиенту это делится на условные 160. И все дополнительные услуги потом внезапно приходится считать с дисконтом уже из этой получившейся ставки. Для продаж это, наверное, неплохо, но для прибыли совсем грустно. Здесь мы тоже порядок уже навели, учёт отладили.

О работе с длинными проектами

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

О проектах с большим числом участников

Чем больше в проекте сторон, тем больше неразберихи, к этому сразу готовимся. Уже знаем, что даже если каждый подрядчик квалифицированный, на стыке всё равно фигня какая-то случится. Был пример, когда со стороны клиента участвовало ещё маркетинговое агентство, хорошее, вменяемое. Прислали нам код Google Analytics для установки, мы поставили, они говорят — плохо поставили, нам ерунда приходит какая-то. Мы — ну как «плохо», поставили тот код, что вы дали. И вот мы две недели с ними «интегрировались», уже до эмоций дошло, до обвинений, пока они не разобрались, что код неправильный сделали. Мало кто готов допустить, что ошибиться мог, всегда в первую очередь думают, что это кто-то другой накосячил.

О госзаказе и дружбе

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

О тендерах

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

О поддержке

Конечно, у нас есть трекер, где мы все задачи ведём. Но если клиенту удобно на почту писать — да пиши на почту, пожалуйста. Один вот только в WhatsApp пишет. Ну и пусть, если ему так проще. Нам ведь главное получить обращение, а дальше мы у себя уже это всё куда надо занесём.

О запросах

Мы с разными запросами работаем. Был случай, когда к нам пришли и сказали: «У нас есть что-то, но мы не знаем, что именно. Оно нам по франшизе досталось. Хотим точно такое же, но своё». Корпоративная система — и ни документации, ни описаний, ничего. Нам, чтобы написать ТЗ, пришлось изучать их систему, всю логику описывать, а потом только к составлению ТЗ подступаться.

О тестировании

На небольших и средних проектах не вижу смысла выделять отдельную позицию «тестировщик». Мы пишем по каждому проекту тест-листы, и дальше по ним работает менеджер проекта. Потом отдаём проект заказчику, оговаривая, что это тестирование, ещё не релиз. Это важно — отдать клиенту всё заранее, не в оговорённую дату сдачи, чтобы к назначенному сроку релиза он уже всё посмотрел и проверил. Тогда и не будет криков: «Что вы нам тут отдали, ничего не работает!».

На больших проектах, конечно, без полноценного QA не обойтись.

О ценообразовании

Всё считаем по часам. Приходит проект, оцениваем человекочасы по специалистам, добавляем маржу. Маржинальность бизнеса у нас около 15%. Конечно, если проект долгосрочный, если сразу понятно, что там ещё несколько лет поддержки будет, то на первых этапах можем даже без прибыли отработать. С короткими проектами так, понятно, невозможно.

О разнице между разработчиками и интеграторами

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

О бизнес-консалтинге

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