Оставьте заявку на демонстрацию возможностей продукта
Как создать успешный
ИТ-продукт, если вы
не айтишник?
Алексей Вагин, генеральный директор, основатель и архитектор платформы для обучения и управления персоналом «Эквио», рассказывает, как запустить успешный ИТ-сервис, если в ИТ вы не разбираетесь, и какими принципами стоит руководствоваться.
По данным исследования российского рынка технологического предпринимательства «Стартап Барометр-2019», около 20% стартапов на рынке основаны год назад, почти 14% — 2 года назад, 13% были запущены 3 года назад и 15% компаний старше 5 лет. Лишь 15% проектов имеют работающую бизнес-модель, и всего 5% стартапов активно завоевывают рынок и быстро растут. Чтобы ваш проект оказался долгоиграющим и прибыльным, нужно внимательно отнестись к его разработке.
Инсорсинг или аутсорсинг?
Я бы не рассматривал на старте вариант инсорсинга: иметь разработчиков в штате всегда дороже, несмотря на общую уверенность в обратном. Во-первых, вы несёте затраты на поиск. Во-вторых, полной нагрузки для них никогда не будет — и на начальном этапе погружения в разработку у вас нет шансов верно оценить временные затраты на ту или иную задачу. Лучше довериться профессионалам.
А вот после запуска коммерческой версии продукта уже можно думать, оставаться на аутсорсе или переходить на инхаус.
Инсорсинг нужен тогда, когда объём разработки очень большой, когда продукт коммерческий и частота обновлений выше 1 раза в месяц.

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

Можно поступить, как мы в свое время: добавить аутсорсинговую команду, которая параллельно с нуля разработала новое веб-приложение и «догнала» основной продукт, позволив заменить часть кода на созданный с нуля.
При разработке ИТ-решения обязательно:
Чётко разделяйте уровни разработки продукта.
Нужно понимать, что описание идеи на уровне бизнес-потребности не будет ясно конечному разработчику. Техническое задание даже верхнего уровня должно быть сделано с помощью ИТ-специалиста и быть понятным любому такому же ИТ-специалисту.
Правильно формулируйте ТЗ.
Так вы получите адекватную оценку сложности и дороговизны реализации проекта. Процесс лучше разбить на 2 этапа:
    1
    Во-первых, правильно поставить техническое задание.
    Нужно изложить, как будут выглядеть ключевые бизнес-процессы, функции, возможности продукта и с точки зрения пользователя, и с точки зрения владельца системы, и с точки зрения бизнеса.
    2
    Потом воспользуйтесь помощью ИТ-специалистов для окончательной формулировки технического задания.
    ТЗ должно быть понятно именно с точки зрения ИТ, в нём должны быть чётко указаны объём работ, сложность технической реализации и возможные ограничения, а также такие подробности, как операционная система, в которой будет работать продукт, и даже её версия.
    С подробным ТЗ вы избежите зависимости от подрядчика и риска переплаты. Без него любую неточную формулировку подрядчик будет трактовать в свою пользу.
    Выбирайте из нескольких подрядчиков.
    Так выше вероятность адекватной оценки сроков и затрат. При выборе руководствуйтесь рекомендациями и независимыми оценками других заказчиков, а не рейтингами — они не отражают реальной картины.
    Привлеките независимого ИТ-эксперта.
    Он поможет правильно оценить бюджет проекта, временные затраты, особенности будущей команды. Этот человек не должен в дальнейшем заниматься продуктом, он должен выступать вашим личным техническим консультантом. Такую консультацию можно получить в любой компании, профессионально занимающейся ИТ разработкой. Расходы будут невелики, но повлекут колоссальную экономию возможных затрат в будущем. Кроме того, вы проясните ранее непонятные моменты и сможете глубже разбираться в разработке вашего продукта.

    На стадии приемки продукта такая экспертиза обязательна, ведь заказчик, не являясь техническим специалистом, не сможет увидеть возможные проблемы в архитектуре или коде продукта.
    При заказе ИТ-решения всегда уточняйте, как будет делаться его тестирование.
    Иногда предполагается, что этим будет заниматься сам заказчик — но он не сможет понять, корректно ли работает приложение при любом варианте использования, например, при одновременном использовании пятью тысячами пользователей. Если же у подрядчика есть профессиональные тестировщики, это уже задаст минимальный уровень профессионально сделанного продукта.
    Делайте ревью промежуточных итогов.
    Не ждите, когда подрядчик сделает проект под ключ, всегда оценивайте происходящее на промежуточных стадиях готовности. Мне очень нравится формат Scrum, когда каждые две недели команда разработчиков показывает клиенту какую-то минимальную бизнес-ценность продукта. При таком подходе можно скорректировать разработку на любой стадии и избежать обмана недобросовестным подрядчиком.
    Учитывайте bus factor.
    Этот термин описывает, много ли сотрудников, по тем или иным причинам выбывших из строя, заставят работу над всем проектом застопориться. Продукт не должен зависеть от человеческого фактора, нужно иметь возможность подстраховаться на случай отпуска или больничного.
    Всегда проясняйте непонятные моменты.
    Гуглите, изучайте профильную литературу, проходите онлайн-курсы — сейчас доступно огромное количество источников профильных знаний. Здесь, как с ремонтом: строители могут сразу сыпать незнакомыми словами, и для того, чтобы составить собственное мнение, нужно быстро разобраться в конкретном вопросе. Да и отношение разработчиков к такому заказчику сразу меняется в лучшую сторону.
    Не пренебрегайте нетворкингом.
    Если вы решили начинать ИТ-бизнес, обязательно используйте возможности нетворкинга, это поможет вам и разобраться в отрасли, и приобрести знакомства с техническими профессионалами. Когда я начинал работу над продуктом, у меня в отличие от большинства стартапов не было сооснователя-CTO (chief technology officer). В моем кругу бизнес-знакомств просто не было таких людей. Это довольно типичная история в корпорациях.
    Создание и грамотное управление командой разработчиков: что важно знать?
    В разработке важна психологическая совместимость членов команды.
    В этом, кстати, отличие от традиционного бизнеса.
    Уровень компетенций членов команды должен быть чуть-чуть разным.
    Люди с одинаковым уровнем навыков будут бороться между собой
    за техническое первенство, что спровоцирует конфликты.
    Нужно сразу договориться о единых правилах написания кода.
    У каждого разработчика собственное видение стандартов, и во избежание противоречий необходимо принять удобные и понятные всем правила.
    Должны быть технические и командные руководители (лиды).
    Очень часто прекрасный технический эксперт, пишущий отличный код,
    не хочет или не может эффективно руководить самой командой и выстраивать в ней коммуникацию. Тимлид же может решать внутренние конфликты, мотивировать команду и грамотно распределять задачи. Встречаются и лиды-универсалы, но это редкость.
    Стиль управления командой разработчиков должен быть менее директивным, чем в других бизнес-областях.
    Больше открытости, ориентация на результат, отсутствие контроля мелких деталей. Вы ставите сотруднику задачу и не контролируете то, как именно он ее исполняет, потому что в разработке есть множество методов. В ИТ, на мой взгляд, вообще очень сложно (на самом деле не нужно) внедрить традиционную иерархическую систему.
    Нужен ли офис, и где его открывать?
    Наличие офиса не обязательно. Но если у продукта много частых обновлений и идет работа одновременно на нескольких платформах, то нужна ежедневная командная коммуникация. У нас основная часть команды работает по гибкому графику, некоторые работают удаленно.
    У нас основная часть команды работает по гибкому графику, некоторые — удаленно.
    Многие стремятся открыть офис разработки в регионах — для экономии. Нужно помнить, что там разработчики высокого уровня удаленно работают на московские или иностранные компании. Лучше, если масштабы вашей компании позволяют выстроить систему подготовки молодых специалистов: они очень быстро повышают свой профессиональный уровень, а их обучение в регионах не повлечет таких затрат, как в Москве.

    При разработке ИТ-продукта требуются и специалисты вспомогательных областей: тестировщики, специалисты технической поддержки, административный персонал. В регионах уровень таких профессионалов высок, и их проще найти, ниже конкуренция с другими хедхантерами. И не придется на старте тратиться на дорогой московский офис.
    Продемонстрируем завтра.
    Внедрим за пару недель.
    Заполните анкету или свяжитесь с нами по
    телефону +7 (495) 928-92-20 или почте team@e-queo.com
    Укажите ваш E-mail
    Как вас зовут?
    Контактный телефон
    Сколько пользователей хотите подключить?