Операционные и технологические проблемы IT стартапов

В начале проекта – наведите порядок в голове, положите мысли на бумагу, нарисуйте mind-map карту и чётко структурируйте для себя тот проект, который задумали.

Сергей Петров и Пётр Коротков из компании MISolutions рассказали нам, какие ошибки в разработке чаще всего допускают начинающие стартапы и как с ними бороться.

Пётр Коротков (COO), Сергей Петров (CEO) и Юрий Цапков (CTO)

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

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

Как мы понимаем «сервисную» модель: к вам приходит клиент с ТЗ или ФТ, или общим описанием проблемы, которую надо ему решить, а вы предлагаете ему решение «под ключ»: от этапа проектирования до тестирования и приемо-сдаточных испытаний. Если проблема достаточно четко описана – то можно применять стандартный метод «waterfall», если проблема не очень понятна (когда клиент сам не до конца понимает, какой результат хочет получить) и нужно структурировать его «поток сознания», то применяем гибкие подходы к управлению проектом со всеми вытекающими.

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

Технологические проблемы

Одна крайность – давайте быстро сделаем что-нибудь и как-нибудь, и заработаем кучу денег. И в данном случае справедлив тезис «shit in – shit out»… Неопределенность на входе приводит к такой же неопределенности на выходе, бесконечным метаниям в выборе платформ и фреймоворков и, в итоге, к смене команды проектирования и разработки.

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

Стек технологий выбирается не с точки зрения оптимального и эффективного решения задачи, а исходя из компетенций команды разработки. Классический пример, когда важна последовательность решений. ВАЖНО, как мы приходим к разработке и от чего отталкиваемся. Из опыта экспертов рынка, а также коллег по цеху, правильная последовательность такова:

• Бизнес требования
• Продуктовые требования
• Проектирование архитектуры решений
• Подбор соответствующих персоналий для реализации
• Собственно реализация

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

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

Платформами, фреймворками, языками программирования. Программисты – люди увлекающиеся! Им только дай волю – все время потратят на эксперименты. В итоге фокус смещается с работы над задачами на прокачку скиллов и поиск новых решений. Время уходит, задачи не выполняются, инвестор расстраивается, а ваш проект начинает разваливаться. Ответственность за выбор технологии (в том числе и экспериментальной) несёт главный технический специалист стартапа (СТО и/или архитектор) и неправильный её выбор сразу говорит об уровне его компетенции. Решить эту проблему можно только одним способом: пригласить в стартап нового эксперта.

Операционные проблемы

С чем конкретно нам пришлось столкнуться?

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

Это касается как сферы управления, так и сферы разработки. А также человеческого фактора и фактора команды.

• Например, управляющие не понимают, что смысл стартапа — это поиск потребителей и продукта или услуги для них, и нужно гибко подходить к управлению организацией, принимать обратимые решения и смотреть на отклики потребителей. А управляющие мыслят понятием “бизнес план” и слепо следуют этому плану, в результате чего снова создают ненужный потребителю продукт и в качестве итога имеют остановку в развитии или полное закрытие проекта.
• Простой набор персонала для работы над стартапом. С одной стороны это должны быть надежные и проверенные люди, с другой — заряженные на работу и готовые терпеть неудачи, поскольку стартап — это постоянный поиск успешной бизнес модели через множество неудач.
• Ещё одной частой проблемой является непонимание инвестором самой сути проекта. Инвестор зачастую думает только о том, когда он вернет свои вложения и получит прибыль. Он не понимает, что к стартапу не применимо понятие бизнес плана. Стартап — это поиск воспроизводимой масштабируемой бизнес модели. Бизнес модель можно не найти никогда. И инвестор своими постоянными требованиями «когда я получу прибыль» заставляет принимать решения, которые и ведут к гибели стартапа. Например, слишком быстрый вывод продукта на рынок.

Скажу очевидные вещи, но они встречаются достаточно часто, поэтому полезно будет еще раз упомянуть об этом: