Путь в IT: от первых шагов до создания компании 70+ сотрудников

Я руковожу IT-компанией БЛИЦ. Мы занимаемся автоматизацией бизнеса клиентов.

Расскажу о своем пути в профессию, преимуществах Agile-подхода и о том, почему так важно строить команду.

Программирование интересовало меня еще в школе.

В Санкт-Петербурге есть такой прекрасный институт – ИТМО.

Он организовал специальную программу для школьников, где я учился с 8 по 11 класс и изучал общие принципы информатики, экономики, математики. Параллельно профессионально занимался футболом.

Высшее образование решил получать в ВОЕНМЕХе, куда поступил, в том числе, благодаря своим успехам в спорте.

Сначала учился на инженерном факультете – хотел попробовать себя в ракетостроении, но впоследствии перевелся на специальность «Менеджмент организации». Знания, полученные в вузе, пригодились мне в будущем.

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

На 4 году обучения студенты выбирали компанию для стажировки. Один из приятелей, с которым мы вместе играли в команде по футболу, работал в банке и пригласил меня. Там я впервые применил свои знания и навыки в реальных IT-проектах.

Я начал работать в техподдержке «Балтинвестбанка». Параллельно проходил курсы от Microsoft – базовые программы, которые помогли расширить кругозор и получить знания в разных областях IT. С обязанностями разобрался быстро и показал себя с самой лучшей стороны.

Сначала перешел в первую специализированную IT-компанию.

Но довольно быстро там сформировалась команда, которая отделилась и вела собственные проекты – мы не просто их создавали, но и поддерживали.

С сетью ресторанов ТОКИО-CITY мы сотрудничали очень плодотворно.

Первым делом внедрили систему обработки заявок для сотрудников франшизы ТОКИО-CITY: создали портал, куда приходили все заявки и распределялись по подрядчикам.

Второй проект для этого же заказчика – внедрение электронного документооборота. Это позволило создать систему персонального контроля, автоматизировать работу со многими задачами.

Третий большой проект для ТОКИО-CITY – консалтинг и переработка всей IT-архитектуры. Необходимость в проекте назрела из-за того, что у франшизы было много подрядчиков, и нужно было как-то более эффективно организовать их работу.

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

Для ТОКИО-CITY мы внедряли CRM-систему. У компании образовалась битая база – где-то не хватало контактов, кого-то неправильно или не туда внесли. Иногда возникали проблемы с утерянными или забытыми карточками, которые выдавались клиентам.

У фирмы была довольно громоздкая система по восстановлению карт – нужно было заполнять анкету, отправлять менеджеру, который занимался одобрением заявок по мере возможностей.

Мы сделали так, чтобы процедура была практически мгновенной – при условии, что данные совпадали с теми, что были в базе, они тут же переносились, и карта регистрировалась заново. Мы восстановили базу и залили ее в новую CRM-систему.

Работая с ТОКИО-CITY, я понял, что большинство компаний сегмента IT Horeca не занимается разработкой продукта, а специализируется лишь на установке готовых решений.

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

Хотелось не только устанавливать ПО для ресторанов, но и создавать уникальные продукты. Постепенно вокруг меня сформировалась команда, которая разделила и поддержала мои идеи.

Так и появилась компания БЛИЦ.

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

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

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

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

Я – фанат Agile-подхода. Меня привлекает гибкость и возможность поменять задание на ходу без бесконечных согласований и переписываний технического задания. А именно этим грешат некоторые старые методологии вроде водопадного подхода.

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

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

Второй сценарий развития событий – через 3 месяца вы понимаете, что нужно что-то изменить в проекте. За внесение правок в ТЗ с заказчика могут попросить и 500 тысяч, и миллион рублей. Даже если там нужно переделать пару кнопок, эту сумму исполнитель сможет обосновать. Например, сказать, что половина программы уже написана, и теперь ради корректной работы запрашиваемых кнопок нужно переделать 10 модулей.

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

И если на каком-то этапе произойдет недопонимание в постановке задач, ТЗ будет написано плохо.И в результате дело может дойти до суда.

Считаю наиболее эффективным именно этот подход.

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

Из минусов такого подхода можно назвать отсутствие ТЗ и возможности четко прописать конечный результат.

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

От заказчика требуется вовремя предоставлять функциональные требования, согласовывать задачи. Например, для этого активно используется таск-трекер Jira или подобный инструмент.

А исполнитель обязуется предоставить все, что необходимо для технической реализации проекта – программистов, аналитиков, менеджера проекта. Это позволяет активно работать на результат.

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

Agile подходит не всем. Например, у госорганов есть своя методология.

Но если можно выбрать, считаю ее наилучшим вариантом для сотрудничества.

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

Сейчас в штате БЛИЦ более 70 человек. Это и инженеры технической поддержки, которые работают удаленно и с выездом к заказчику, и веб-разработчики, и менеджеры проектов, и аналитики.

При подборе сотрудников мы ориентируемся на ценности.

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

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

Мне важнее коллектив, а не отдельный человек, ведь с одним сотрудником не достичь нужного результата.

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

Если заказчику нужна техподдержка, мы ее предоставим, если требуется организовать колл-центр для доставки – сделаем и это. Мы нацелены не на разовое, а на долгосрочное и взаимовыгодное сотрудничество.

На данный момент реализовано более 30 проектов, услугами компании пользуются 70 ресторанов, 12 кофеен и 35 dark kitchen. Более 480 000 человек ежемесячно используют наши продукты.

Для многих компаний это – вершина успеха. Но не для Fast Soft.

Спорт научил меня никогда не бояться сложностей, двигаться только вперед. Это очень пригодилось мне в бизнесе. Готовое коробочное решение может установить любой дилер, оказать техническую поддержку – тоже. А сделать то, что принесет новую ценность для ресторана, могут немногие компании. Мы – среди них.

Мой телеграмм: @dvshalinㅤㅤНаш сайт: БЛИЦ /Студия IT-разработки